01
Wireframes
With discovery already done, the first step was wireframes across all four modules. Each round went back to the client for feedback, and we updated until each module was signed off.
case study
fintech
A design system for First Digital Trust's multi-module back office
Created a shared design foundation for a complex fintech back office, from token architecture to component governance, enabling consistent and scalable product design.
Context and
the problem
This work was part of a full redesign of First Digital's multi-module fintech back office. The product included four large modules (CRM, Compliance, Finance, and AMS), each with its own flows and screens.
The stakes were specific to back-office fintech: dense, data-heavy interfaces used by operational roles, where inconsistency isn't just ugly. It slowed the people who ran the business and eroded trust in the tooling.
A file of design primitives (colors, typography, spacing) already existed, inherited from another First Digital product, but no shared component library existed yet. Without one, each module risked being built with its own version of buttons, forms, and navigation: slower to design, harder to keep consistent and in sync with a parallel development team.
My role
I joined the project after the discovery phase, which the lead designer had already completed. Alongside other team members, I worked on the wireframes and then moved into UI. Within the team, I was responsible for the Design System (structuring tokens, components, and documentation), while every component decision was a team call.
Process
02
UI and design system foundations
We started with the CRM module. Colors and typography were already in place, so the focus was on designing all screens while building the component library in parallel. Components were extracted screen by screen (buttons, forms, navigation, headers) and reused across modules as the design system took shape.
03
Scaling to other modules
As each module's wireframes were approved, UI work continued across Compliance, Finance, and AMS. The component library grew with each module, and more of each new one could be assembled from existing pieces.
04
Cleanup and dev handoff
Dev collaboration started later than it should have been. Once regular syncs were in place, we went through the library component by component, refactoring where design and code had diverged. That process also shaped the governance model: an approval pipeline (For review → Approved → To be refactored), a dated changelog sent with each update, and recurring design-review meetings.
Before vs After
Before
Module selector
After
Module selector
Before
CRM module
Clients
After
CRM module
Clients
Before
Finance module
Bank reconciliation
After
Finance module
Bank reconciliation
More screens available on request
What went off-plan
Partway through rollout, the dev team's implementation had drifted from the kit on several components. We went back through each one together, reconciled the differences, and re-established the UI kit as the shared source of truth. Design systems need active maintenance, not just an initial handoff.
Impact
01
Speed
Design accelerated noticeably after the first module; informally around 2–3×, because most UI patterns could be reused rather than designed from scratch.
02
Reuse and consistency
Two shared files covered all four modules: a Primitives kit (colors, typography, icons, spacing, effects) and a Foundation kit with the core component library. Designed once, reused everywhere. Module-specific components lived in each module's own file.
03
Adoption and handoff
The Primitives and Foundation kits were handed off and worked through with the dev team component by component. Each was reviewed, refactored where needed, and signed off by both design and engineering before being approved.
04
Accessibility
Accessibility was built into the component spec: contrast ratios, interaction states, and keyboard behavior documented alongside each component, and reviewed with the dev team.
Learnings
If I started this now, I'd bring the engineering team in earlier, before components were already in reuse, to avoid reconciling design and implementation after the fact. Keeping two teams pointed at one source of truth over time turned out to be harder than building the system itself.