Case Study — Design Systems & Strategy

Building a unified architecture
for 15+ enterprise banking products.

How a fragmented suite of independent banking products at Tosan was brought together under one Atomic Design System — spanning eight teams, three hundred Figma files, and a process built to outlast any single release.

Role
Lead Product Designer
Timeline
2021 – 2024
Domain
FinTech / Enterprise Banking
Scope
15+ Products · 8 Teams
01 — Executive Summary

One core system, fifteen products, eight teams.

Tosan is a leading provider of electronic banking infrastructure in Iran, managing an ecosystem of more than fifteen banking products across eight independent teams. Before this initiative, each team operated in its own silo — leading to fragmented user experiences, mounting technical debt, and slow, inconsistent delivery. I was tasked with architecting and leading a scalable Atomic Design System to unify the product suite, close the gap between design and code, and bring one coherent visual language to the entire platform.

Tosan Atomic Core became the shared foundation for multiple enterprise banking products and teams — the hub that fifteen distinct product surfaces now draw from.
Impact at a Glance

Measurable change across the product suite.

40%
Reduction in design redundancy
25%
Faster delivery cycles
150+
Standardized components
15+
Products aligned
8
Teams onboarded
02 — The Challenge

Fifteen products, fifteen different ways of solving the same problem.

The lack of a shared design language showed up everywhere: over 150 UI variations existed for the same functional components — buttons, inputs, modals — across the product suite. Designers and developers were reinventing the wheel for every new feature, doubling time-to-market. Updating a single brand asset required manual changes across fifteen separate codebases. Users felt the difference too, encountering different interaction patterns every time they moved between Tosan products.

From fragmented product decisions to a unified system of reusable patterns — before, four teams solved the same interface problem four different ways; after, every team draws from one shared source.
03 — My Role & Strategy

Owning the system end to end.

As Lead Product Designer, I owned the full strategy behind the Design System — from the initial audit through to the governance model that keeps it alive today.

  1. Audit & ResearchEvaluated 300+ Figma files across 15 products to identify commonalities, conflicts, and redundant patterns.
  2. ArchitectureDesigned a three-layer Atomic Core System: Base Tokens → Core Components → Patterns.
  3. StandardizationDefined specifications for 150+ interactive components used across the entire suite.
  4. GovernanceEstablished a Contribution Model so teams could propose and update components without breaking the core.
  5. CollaborationActed as the bridge between 8 product teams, PMs, and frontend engineers throughout the rollout.
04 — System Architecture

A layered approach, not just a UI kit.

The system was built as a modular, four-layer architecture — moving from foundational design tokens up through core components, product patterns, and finally the real product experiences that ship to users. This structure is what separates a true design platform from a static component library.

The system was structured in layers to support scale, consistency, and product-specific flexibility — from foundational tokens to enterprise product patterns.

"In those environments, design has to do more than create polished screens. It has to create clarity."

— Mobin M. Bahrami, Lead Product Designer
05 — The Process

From audit to governance.

A deep audit of existing products — categorizing components by usage frequency and complexity — revealed that 60% of design time was spent on repetitive UI tasks that could be standardized or automated entirely. That insight shaped everything that followed.

Phase A

The UI Audit

Categorized components across every product by usage frequency and complexity, surfacing where the real redundancy lived.

Phase B

System Architecture — The Atomic Approach

Built design tokens for color, typography, spacing, and elevation; core components that are flexible, accessible, and state-aware; and standardized complex patterns like multi-step transaction verification and multi-factor authentication.

Phase C

Documentation & Hand-off

A documentation portal covering usage guidelines, interaction specs, motion behaviors, code parity details, and accessibility standards for enterprise banking.

Component Inventory

A shared library teams stopped rebuilding from scratch.

A shared component inventory helped teams stop rebuilding the same interface patterns — every button, input, and table now traces back to one governed source.

Buttons
Inputs
Dropdowns
Alerts
Tables
Filters
Cards
Forms
Steppers
Tabs
Pagination
Empty States
Design Tokens

A shared language between design and development.

Tokens created a shared language between design and development — a single source of truth for color, type, spacing, and elevation that both Figma and code could read from.

06 — Key Challenges & Solutions

Resistance and technical diversity, addressed directly.

Challenge

Resistance from established teams who feared losing creative freedom.

Solution

Conducted weekly System Syncs and demonstrated how the system frees up their time for high-level UX problem solving rather than pixel-pushing.

Challenge

Technical diversity across React, Angular, and legacy frameworks.

Solution

Focused on framework-agnostic design tokens and clear CSS/HTML specs to ensure visual parity regardless of stack.

Governance Model

A process, not just a Figma file.

A contribution process ensured that the system could evolve without becoming fragmented again — every new component request follows the same path from need to adoption.

Team Need
Component Request
Design Review
Engineering Review
Documentation
Release Version
Adoption by Teams
A governance process ensured the system could evolve without becoming fragmented again.
Design-to-Development Workflow

Systematic hand-off, not a one-time export.

The design-to-development workflow reduced hand-off ambiguity and improved implementation consistency — every component travels the same path from Figma to production.

Migration Roadmap

A gradual rollout, built to avoid disruption.

Gradual adoption reduced resistance and allowed teams to migrate without disrupting product delivery — the system earned trust phase by phase, not by mandate.

Phase 1

Audit & Prioritization

Mapped existing components and ranked them by impact and redundancy.

Phase 2

Tokens & Core Components

Established the foundational layer that every later layer would depend on.

Phase 3

High-Impact Product Patterns

Standardized the flows used most often across the suite, like authentication and transactions.

Phase 4

Pilot with 2 Teams

Tested adoption end-to-end with two teams before wider rollout.

Phase 5

Rollout to 8 Teams

Expanded adoption across the full organization with hands-on support.

Phase 6

Governance & Continuous Improvement

Shifted from rollout to long-term maintenance through the contribution model.

Applied to Product

The system in production, not just in Figma.

Diagrams explain the thinking — but the system only proves itself once it's running across real banking surfaces. Due to confidentiality, these are reconstructed layouts rather than live product screens.

Dashboard
Transaction Confirmation
Authentication Flow
Data Table
Form Flow
Error State
Impact, Revisited

The system created measurable operational impact across product teams.

40%
Reduction in design redundancy
25%
Increase in delivery speed
30%
UX consistency improvement
150+
Standardized components
07 — Conclusion & Lessons Learned

A design system is 20% design and 80% people and process.

This project taught me that success wasn't just about the Figma library — it was about building a culture of collaboration across eight different teams. It reinforced the importance of DesignOps in large-scale enterprise environments, and how a well-structured system can become a genuine competitive advantage.

"A well-structured system can be a significant competitive advantage."

— Mobin M. Bahrami

see more of my

WORK