Design system: How we redesigned a live bank without breaking it

Building a bank fast without breaking things requires a strong foundation. This design system

was that foundation.
Built from scratch during the hashbank MVP, it kept the product consistent through daily shipping and two full redesigns. Design got 55% faster

. Development 40% faster.
One system. Two major redesigns. Zero rebuilds from scratch.

ROLE

Sr. Product Designer

TIMELINE

27

Months

TEAM

2 Dev ‒ 2 Des.

OUTCOME

50%

UI Bug cut off

ROLE

Sr. Product Designer

TIMELINE

27

Months

TEAM

2 Dev ‒ 2 Des.

OUTCOME

50%

UI Bug cut off

Background

hashbank was growing fast

. Every week brought new features, new screens, and new problems. Designers kept rebuilding the same components. Developers kept asking the same questions.
QA kept sending back the same bugs

. Half of all QA issues were UI related. 40% of our time was going to rework instead of building new things.
I showed these numbers to leadership and got the green light

. Build the system. While the product was still shipping. That part was not easy.

Comparison Before vs After design system

60%

Design time reduced

60%

Design time reduced

~70%

Development time reduced

~70%

Development time reduced

50%

UI Bugs reduced

50%

UI Bugs reduced

Problem

Every new feature made things worse. Screens looked similar but not the same. Components had small differences nobody planned for.
Fixing one thing broke something else. Design and development were both working hard but in different directions. There were no shared rules so everyone made their own.
At some point fixing UI bugs was taking longer than shipping new features. That was the moment it became clear something had to change.

Developed

Designed

What I did

I built the design system from scratch while the product was actively shipping. Started with tokens, moved to components, then templates. Every piece was used across real features from day one.
I got designers and developers working from the same rules

. Less duplication, cleaner handoffs, fewer surprises in QA.
The numbers followed. Design speed up 60%. Development up 40%. UI bugs down 50%

. Not bad for something nobody could see in the final product.

System scope & audit

The first step was a full audit

. I reviewed the app screen by screen to collect every color, spacing rule, and typography style. Every recurring component and page layout was mapped to find system candidates.

Many colours without variable before design system

After collection, I filtered and cleaned the data

. Duplicated, unused, and inconsistent elements were removed. The remaining UI was grouped into clear categories like list items and form elements.

I also reviewed upcoming feature maps with the product team

. This helped identify missing system needs before they became problems. The audit made sure the system was ready for the future, not just a snapshot of the past.

Tokenisation strategy

I extracted every shared value from the UI

. Colors, font sizes, weights, spacing, border radius. Each one became a token reused across the product with zero hard-coded values left behind.

Tokens were organized into two levels

. Base tokens stored the raw values. Semantic tokens defined what those values actually did, like text color or background fill.
Every token was documented with a name, value, and description

. Developers always knew exactly what to use and why. Implementation mistakes dropped significantly from day one.

Atomic foundations

I started with the smallest parts

. Buttons, badges, icons, avatars. Each one built with all interaction states from day one so visual drift had nowhere to hide.

Every atom was driven by design tokens, not manual values

. Fix something at the atomic level and it updates across the entire product automatically. No manual rework, no inconsistencies left behind.
These small parts became the base for everything larger

. Components, templates, full page layouts. By getting the foundation right first, scaling the bank became a matter of assembly, not invention.

Core components at scale

After atoms, I focused on the most used UI parts

. List items, form inputs, selects, cards. These appeared across almost every screen and small inconsistencies here had a big impact on the whole product.

Each core component was designed once and reused everywhere

. Behavior, spacing, and rules defined in one place. QA issues dropped as soon as component behavior became predictable.

Core components were also built for future needs

. New features reused what already existed instead of creating something new. The system stayed stable while the product kept growing.

Reusable templates

After core components, I built ready-to-use templates for the most repeated page types

. Select modals for country, currency, category. The screens teams were rebuilding from scratch every single time.

Templates removed the need to debate layout decisions

. Setup time dropped, user flows stayed consistent, and designers could finally focus on logic and edge cases instead of spacing.
Complex page builds became simple assembly

. Pick a template, fill in the logic, ship it. Faster delivery and far fewer layout bugs as a result.

Documentation & handoff

Early on, speed came first

. Atoms and components shipped immediately to unblock the team. Documentation could wait, delivery could not.
After the first release, I went back and documented everything

. Component behavior, usage rules, edge cases. Cross-links showed exactly where each component lived across the product.

Developers got clear technical notes on states, variations, and constraints

. No more guessing values or misreading designs. Rework during implementation dropped significantly.
Documenting in stages kept the team fast

. The system got more organized over time without ever slowing down delivery. Structure followed momentum, not the other way around.

Governance

Core tokens and components became the default path for all new work

. New UI had to reuse what already existed unless a clear gap was found. This kept the product from drifting back into inconsistency.
System change requests moved to weekly Design and Dev meetings

. No more scattered messages and last minute decisions. Every update was evaluated for impact before it shipped.

Urgent requests were handled as temporary standalone components

. Need a new button in five minutes? Fine. But it gets reviewed later, then merged, modified, or removed entirely.
Nothing was left undocumented or forgotten

. By treating the system as a living product we kept delivery fast without sacrificing long term health. Quick fixes never quietly became permanent debt.

Team enablement

After the system stabilized, I focused on the people using it

. Developers were not fully comfortable with Figma or Dev Mode. I ran daily sessions for one week to cover component usage, tokens, and handoff basics.
Those sessions changed how the teams worked together

. Developers stopped guessing values and started reading designs directly. Handoffs got faster and implementation accuracy improved significantly.

I also added a changelog to track every system update

. Each entry described the what and the why. No more silent changes landing in production without context.
Over time the system became a shared language

. Design and engineering working from the same rules, the same components, the same source of truth. Next step is connecting the changelog directly to Jira for full version control.

Results

The design system became a core part of how the product was built and scaled

. It reduced friction across design, development, and QA without slowing delivery. Not just a UI asset, a real scaling tool.
By standardizing UI logic and behavior, teams shipped faster with fewer errors

. New features launched in weeks. When stakeholders pushed for dark mode, we shipped it in 3 days

. Design and development combined. That is what a real system feels like.

60%

Increase in design delivery speed after introducing tokens, components, and templates.

40%

Faster development due to reusable components and clear handoff rules.

50%

Reduction in UI-related bugs returned from QA.

30%

UI elements removed after audit and system cleanup.

Key Takeaways

The biggest issue was never visual inconsistency

. It was the lack of shared rules. Design and development were solving the same problems in different ways every single day, and it was draining everyone.
The system proved it was a scaling tool, not a UI library

. Less duplication, more stable behavior, faster output. Teams moved with confidence instead of guessing.
Building while the product was live taught me that progress beats perfection

. A flexible foundation matters more than complete documentation on day one. Ship it, document it, improve it.