Fund Administration Platform — Product Design Case Study

02 · Overview

What is the project?

The platform is a proprietary back-office solution used by a fund administration firm to manage their core operational workflows. The product handles everything from client onboarding and fund structuring to day-to-day operations like valuations, transactions, proposals, and holdings. It is used exclusively by internal teams — not end-consumers.

What it does

Centralises the administration of multiple fund vehicles. Teams use it to record and manage client portfolios, track asset valuations, process transactions, generate proposals, and monitor holdings — all within a single, structured interface.

Who it's for

Internal operations teams and fund administrators. Users are not designers or engineers — they are finance professionals who need reliability, clarity, and speed from their tools. The product must reduce cognitive load, not add to it.

03 · My Role

More than screen design

I was responsible for the full design layer of the product — from early discovery through to shipped components. But the work went beyond producing screens.

UX / UI Design

End-to-end interface design — wireframes, high-fidelity screens, responsive layouts, component states.

Information Architecture

Mapping navigation, module hierarchy, and data relationships across complex, interconnected workflows.

Stakeholder Collaboration

Working directly with product owners and operations leads to surface requirements, clarify scope, and align on priorities.

Component Thinking

Designing reusable, scalable patterns — tables, forms, modals, states — to create consistency across modules.

Requirements Clarification

Translating vague business needs into structured design briefs. Asking the right questions before building anything.

Roadmap Contribution

Contributing to feature prioritisation — balancing quick wins with long-term structural decisions.

Dev Handoff & Collaboration

Working closely with developers during implementation — clarifying intent, reviewing built components, and iterating in response to technical constraints.

Design QA

Reviewing implemented screens against design intent, raising inconsistencies, and ensuring the product shipped at the right quality.

04 · The Challenge

A product that had outgrown its process

When I came in, the product existed — but it had been built reactively, responding to individual requests without a unified design language or structure. Workflows were inconsistently handled, data was hard to navigate, and teams were working around the tool rather than with it.

The challenge wasn't simply about aesthetics or adding new features. It was about introducing design thinking into a product culture that hadn't had it — and doing so incrementally, without destabilising what was already in use.

Fragmented workflows

Related processes — valuations, holdings, clients — were siloed with no clear navigational thread between them.
Data density without hierarchy

Dense tables and forms had no visual hierarchy, making it hard for users to quickly find what they needed.
No shared design language

Components were inconsistent across modules — same actions triggered in different ways depending on where you were.
Undocumented requirements

Business logic lived in people's heads. Understanding what the product needed to do required sustained discovery work.
Scaling pressure

The team wanted to add features quickly — but without a consistent foundation, each new module risked adding more complexity, not less.

05 · Process & Approach

How I approached the work

Not a linear double diamond. More like a continuous loop of discovery, structure, design, and refinement — running in parallel with active development.

Phase 01

Understanding the workflows

Before touching a design tool, I spent time mapping how teams actually used the product. What did a full valuation cycle look like? How were clients linked to holdings? Where did proposals fit in the wider operational flow? This discovery phase was largely informal — conversations, screen recordings, and direct observation — but it was essential for understanding what I was designing for.

Workflow Mapping Stakeholder Interviews Requirements Gathering

Phase 02

Structuring the product

With a clearer picture of the system, I worked on the information architecture — defining how modules related to each other, establishing a navigation model, and creating a mental map of the product. This wasn't just wayfinding design; it was deciding what the core entities were and how users would move between them.

Information Architecture Navigation Design Entity Mapping

Phase 03

Designing the patterns

Rather than designing individual screens in isolation, I focused on establishing a small library of reusable patterns: data tables with consistent column behaviour, form layouts with clear hierarchy, action patterns (add, edit, delete, confirm), and empty and loading states. Getting these right early created a strong foundation for every subsequent module.

Component Design Pattern Library Wireframing Hi-Fi Screens

Hand-drawn wireframes laying out the initial screen structure and user flow concepts

Phase 04

Working with developers

Handoff wasn't a moment — it was a continuous conversation. I worked closely with the development team throughout implementation, clarifying design intent, adapting to technical constraints where necessary, and reviewing built screens against the original designs. This back-and-forth was one of the most valuable parts of the process.

Dev Collaboration Spec Annotations Design QA

Phase 05

Iterating after MVP

The first version of each module revealed things that earlier discovery couldn't. Real usage surfaced edge cases, usability gaps, and new requirements. Post-MVP iteration became its own ongoing phase — smaller in scope but just as important. The product improved continuously rather than in big, risky releases.

Iteration Feedback Integration Edge Cases

06 · Key Decisions

Where design choices had the most impact

Not every decision was visible. Many of the most important ones were structural or systematic — choices that shaped how every subsequent screen would behave.

Decision 01

A unified table pattern across all data views

Every module — transactions, holdings, valuations — relied on tabular data. Rather than letting each module develop its own table style, I designed a single, flexible table component with consistent column behaviours, sorting, filtering, row states, and action triggers. Modules would configure it, not reinvent it.

Reduced visual noise and made every data view immediately learnable.

Decision 02

Flat navigation over nested menus

An early proposal involved deep, categorised navigation — sub-menus within sub-menus. I pushed back on this and proposed a flatter model: a primary sidebar with clear module entries, and secondary navigation handled within each module's own interface. This made the product feel less complex and ensured users always knew where they were.

Reduced navigational friction and improved orientation across modules.

Decision 03

Explicit confirmation for destructive actions

In a financial back-office context, mistakes are costly. I introduced a consistent pattern for any irreversible or high-stakes action — a two-step confirmation with clear language about what would happen. The friction was intentional: it signalled to users that they were about to do something consequential, without being obstructive.

Increased user confidence when managing sensitive financial records.

Decision 04

Standardised form patterns across modules

Each module required forms — to add clients, record transactions, submit proposals. Without standardisation, each would have developed its own layout and interaction logic. I defined a shared form grammar: label position, field width, error states, required indicators, and submit behaviour. Developers could implement it once and apply it everywhere.

Consistent input experience regardless of which module was being used.

Decision 05

Progressive disclosure in complex workflows

Some workflows — particularly proposals and valuations — involved significant complexity. Presenting everything at once would overwhelm users. I used progressive disclosure: showing the minimum information needed to make a decision, with detail available on demand. This made complex processes feel manageable without removing control.

Complex multi-step workflows felt structured and approachable.

Decision 06

Design QA as a formal part of the process

In early sprints, built screens would drift from the designs — spacing, colours, interaction behaviour. Rather than accepting this as normal, I introduced a structured QA step: reviewing every implemented module against the design spec, documenting discrepancies, and tracking their resolution. This raised the quality bar for the whole team.

Shipped product better matched design intent. Team quality bar raised.

07 · Key Screens

Selected views from the platform

Branding, client names, and data have been fully anonymised. Screenshots are for illustrative purposes only.

Overview of all Fund Administration Platform screens arranged together, showing the full scope of modules designed

Core Views

Proposal Module — Main View

A dense data table surfacing fund proposals with key metrics (Price, PE, PEG Ratio, Beta, EM Exposure) and inline classification tags. Summary KPIs pinned at the top for quick status reads. The consistent table pattern applied here is the same one used across Valuations, Holdings, and Transactions.

Data Views

Valuations

Fund valuation records with tabbed views (Standard / Monthly / Batch), status-tagged rows, and date-based filtering. Summary KPIs surface totals, failures, and in-progress counts at a glance.

Holdings module — portfolio positions table with sector allocation bar chart and class rate KPIs

Holdings Overview

A consolidated view of portfolio positions with a sector allocation bar chart, class rate indicators across fund classes, and a searchable holdings table with book cost and market value columns.

Transactions module — chronological transaction log with subscription/redemption types, amounts, and action-needed flags

Transaction History

Chronological log of processed transactions with class-level breakdown, subscription/redemption type tagging, and inline "Action needed" flags for unassigned entries requiring review.

Interactions & States

Split Transaction form — complex multi-entry form for allocating a transaction across multiple clients and vehicles

Complex Form Flows — Split Transaction

A high-stakes form for splitting a single transaction across multiple clients and fund vehicles. Remaining balance tracks in real time, with validation ensuring total allocation matches the original amount.

File upload and asset management module — structured file listing with verification status per document

Document Management & Upload State

File upload with drag-and-drop interaction and a verification-status list below. Designed to give users clear confirmation that uploaded documents are processed — reducing the anxiety of sending financial files into a void.

08 · Roadmap

Structuring the path forward

Roadmap contribution was part of my remit. I helped the team think about not just what to build next, but in what order — and why.

Phase 01 · Foundation

Core structure & patterns

Navigation architecture
Table component system
Base form patterns
Client & holdings views
Confirmation patterns

Phase 02 · Depth

Advanced filtering & control

Advanced filter panels
Bulk action handling
Saved views & preferences
Inline editing in tables
Valuation workflows

Phase 03 · Insight

Reporting & export

Report generation views
Export formats (PDF, CSV)
Proposal management
Audit log access
Cross-module summaries

Phase 04 · Scale

Automation & efficiency

Workflow automation triggers
Notification system
Role-based permissions UI
Onboarding flows
Performance at scale

09 · Outcomes

What the work produced

The results here aren't metrics — they're structural shifts that the team can feel.

A consistent, navigable product

Modules that previously felt disconnected now share a recognisable structure. Users can apply knowledge from one area of the product to another — reducing the learning curve for new workflows.

A scalable component foundation

The pattern library established in Phase 01 is now the baseline for every new module. New features are designed faster, and there is less design debt with each release.

Clearer workflows, fewer workarounds

Teams are using the platform as intended — not building processes around it. The reduction in informal workarounds is a signal that the design is doing its job.

Faster onboarding for new team members

A well-structured interface reduces the time new administrators need to become productive. Consistent patterns mean less reliance on tribal knowledge to navigate the tool.

Design culture embedded in the team

The most enduring outcome isn't a screen — it's the shift in how the team approaches product decisions. Design QA, pattern-first thinking, and structured requirements are now part of the workflow.

A product ready to grow

The foundation now supports the roadmap ahead. Phases 02 and 03 can be built confidently on top of an established structure — not fought against an inconsistent one.

10 · Reflection

What I'd do differently, and what I learned

Honest reflection matters more to me than a polished wrap-up.

What I learned

Design in a data-heavy context is fundamentally different

Visual hierarchy in data-dense interfaces requires more precision than in consumer products.
Understanding the business logic behind the data is as important as designing how it's displayed.
Embedding design culture in a team that hasn't had one takes patience, repetition, and demonstrated value.
Consistency compounds — every well-designed pattern makes the next one easier to argue for.

What I'd improve

Earlier alignment, better documentation

Earlier stakeholder alignment on navigation architecture would have saved rework in later phases.
A more structured documentation approach from day one — not just Figma files — would have helped onboard new contributors faster.
I'd invest more in usability testing earlier, even informal sessions, rather than relying solely on stakeholder feedback.
Design tokens and a shared naming convention would have improved consistency in developer implementation.

What comes next

Depth, reporting, and refinement

The roadmap moves into Phase 02 — advanced filtering, saved views, and deeper data control.
Proposal management is the next major workflow to design end-to-end.
A formal design system — not just a pattern library — is on the horizon as the team grows.
Continued QA and iteration post-launch for the modules already shipped.