Building a scalable design system and improving collaboration across a growing fintech product
Core fintech, cash management & White label mobile wallet.
Role
UX/UI Designer
Duration
2 years
Team
2 designers initially, within an 80–100 person company
Product
Fintech platform, including Dashboard, Cash Management, BNPL and White-label Mobile Wallet
THE
CHALLENGE
The company was quickly growing, and without design leadership, I was slowly getting into the eye of the storm.
BUILDING THE DESIGN SYSTEM
The design system became the most important piece of the work.
I helped restructure the existing UI into reusable components following an Atomic Design approach, establishing relationships between foundational elements, components and larger patterns.
Instead of maintaining isolated versions of the same UI, we created a centralized library that could be connected to different projects.
This had an important consequence: changes could propagate across products instead of requiring designers to manually update every instance.
The system also needed to accommodate white-label requirements. Not every client could use exactly the same product, so we had to distinguish between what was genuinely reusable and what needed to remain configurable.
That meant the system was designed around controlled flexibility rather than forcing everything into a single visual language.
NEW FACES
Like a family tree stretching its branches, our team grew with fresh faces and new energy.
Collaboration became part of the design work
As the company matured, the structure around design also changed.
Product Owners, developers, QA and other stakeholders became more involved throughout the product lifecycle. Jira and Agile practices were introduced, creating clearer ownership and prioritization.
My role consequently shifted from working mostly within design to collaborating more closely with the people responsible for building and validating the product.
A design decision increasingly had to account for:
product requirements
technical constraints
client-specific customization
QA feedback
responsive behaviour
consistency with the wider system
This was particularly important for financial products, where a visually simple interface could hide relatively complex rules and states.
The design system helped here because discussions could happen around existing patterns rather than repeatedly debating individual screens.
What didn't work
Not everything we introduced was optimal from the beginning.
One assumption was that adding structure would automatically improve efficiency. It didn't.
A design system only creates value when the team actually uses it. Early on, there was still a tendency to create one-off solutions when deadlines were tight or a requirement appeared unusual.
That made adoption an ongoing collaboration problem rather than simply a Figma problem.
Another lesson was that documentation can easily become a second product to maintain. The more information we tried to document separately, the greater the risk that the documentation and actual design would diverge.
Moving more information into the design system and Figma itself was a better long-term direction.
What I would change
If I were doing this again, I would establish the system's governance and contribution rules earlier.
The technical foundation was important, but ownership, naming conventions, versioning and decision-making rules are equally important when multiple designers and teams start contributing.
I would also validate the system against a smaller set of high-frequency workflows before expanding it across the entire product.
Impact
The clearest impact was operational rather than a single product metric.
Over the two-year engagement, the design team supported a growing fintech organisation while the product expanded across multiple domains and client requirements.
The work resulted in:
The work resulted in:
A centralized design library
A shared source for reusable components across projects.
Reusable responsive patterns
Components and layouts designed to adapt across desktop, tablet and mobile.
More consistent developer handoff
Greater use of components, specifications and Figma Dev Mode.
Reduced duplicated design work
Common UI no longer needed to be recreated independently across projects.
A clearer customization model
Guidelines established what could be customized for white-label products and what should remain consistent.
A more collaborative workflow
Design became more closely connected to Product, Development and QA as the organisation matured.
Trade-offs and lessons learned
The biggest trade-off was between flexibility and consistency.
A fintech platform serving different clients cannot have a completely rigid design system. But allowing every requirement to become a special case quickly destroys the benefits of having one.
The solution was not to eliminate exceptions, but to make them intentional.
I also learned that a design system is less about building a large component library and more about reducing repeated decisions.
The most valuable outcome was therefore not the number of components created. It was establishing a shared foundation that allowed designers, developers and stakeholders to work from the same reference as the product and team continued to grow.
The lesson I took from this project: scalable design is not only about designing better interfaces. It is about creating the conditions that allow good design to remain consistent as the product, team and constraints change.
