MAS PRIME - OCTOBER 2024

Beirut, LEBANON

Building design infrastructure for banking at scale

Overview

MSDL S.a.L., a Lebanese banking technology provider, operates a white-label platform serving multiple financial institutions. Each client gets the same core functionality—merchant transaction management, sales analytics, service request workflows—but branded for their organization.

The platform existed across iOS, Android, and web. Designs existed in Figma. But the system had fundamental problems: no design documentation, styles managed through style guides making rebranding painful, and no systematic approach to accessibility or theming. Adding a new client meant weeks of manual work changing colors across hundreds of components.

I was brought in to transform this collection of screens into a proper design system—one that would make white-label deployment efficient, accessibility compliant, and design-to-development handoff predictable.

Timeline:

3 months

Platform:

ios

Android

Web App

Project Goals

01

Transform fragmented screen collection into systematic design foundation that enables efficient white-label deployment and brand customization.

02

Establish design infrastructure that makes accessibility compliance, theming, and cross-platform consistency systematic rather than manual effort.

Discovery

Understanding the system gaps through strategic collaboration

Before restructuring the design system, I needed to understand how the current Figma file was being used, what problems teams faced, and where the system was breaking down. I conducted stakeholder interviews with business teams to understand white-label requirements, collaborated with product and design teams to map current workflows, analyzed the existing design documentation (or lack thereof), and mapped the design-to-development handoff process to identify bottlenecks.

The discovery revealed systemic problems: no single source of truth for components, accessibility was retrofitted after development rather than designed in, and rebranding required manual changes across hundreds of instances instead of token updates.

Stakeholder Interviews - Business Team

Interviewed business stakeholders to understand white-label deployment process. How long does onboarding a new banking client take? What customization do they request? Which elements need to flex per brand vs. stay consistent? Learning: Current system required 3-4 weeks of manual rebranding work per client due to hardcoded styles.

Stakeholder Interviews - Business Team

Interviewed business stakeholders to understand white-label deployment process. How long does onboarding a new banking client take? What customization do they request? Which elements need to flex per brand vs. stay consistent? Learning: Current system required 3-4 weeks of manual rebranding work per client due to hardcoded styles.

Product & Design Team Collaboration

Worked with product managers and designers to understand feature development workflow. How do new features get designed? How are accessibility requirements handled? Where does design review happen? Learning: Accessibility was treated as post-design checklist, not designed into components from the start.

Product & Design Team Collaboration

Worked with product managers and designers to understand feature development workflow. How do new features get designed? How are accessibility requirements handled? Where does design review happen? Learning: Accessibility was treated as post-design checklist, not designed into components from the start.

Process Mapping - Design & Delivery

Mapped the complete design-to-development handoff process. How do developers receive specs? What questions come up repeatedly? Where does implementation deviate from design? Learning: No component documentation meant developers made interpretation decisions, creating inconsistency across platforms.

Process Mapping - Design & Delivery

Mapped the complete design-to-development handoff process. How do developers receive specs? What questions come up repeatedly? Where does implementation deviate from design? Learning: No component documentation meant developers made interpretation decisions, creating inconsistency across platforms.

Design Documentation Analysis

Audited existing Figma file and any documentation. What's documented? What's tribal knowledge? How are components organized? How is accessibility handled? Learning: Style guide approach meant changing a brand color required finding and updating hundreds of instances. No systematic token structure.

Design Documentation Analysis

Audited existing Figma file and any documentation. What's documented? What's tribal knowledge? How are components organized? How is accessibility handled? Learning: Style guide approach meant changing a brand color required finding and updating hundreds of instances. No systematic token structure.

Problems Defined

Problems Defined

Lack of Documentation Foundation

No component documentation or usage guidelines. Inconsistent implementation across platforms because developers had no single source of truth for behavior, states, or accessibility requirements.

Lack of Documentation Foundation

No component documentation or usage guidelines. Inconsistent implementation across platforms because developers had no single source of truth for behavior, states, or accessibility requirements.

Accessibility as Afterthought

Accessibility treated as post-design checklist rather than product requirement. Components built without WCAG or GDPR compliance resulted in non-compliant interfaces requiring expensive retrofitting.

Accessibility as Afterthought

Accessibility treated as post-design checklist rather than product requirement. Components built without WCAG or GDPR compliance resulted in non-compliant interfaces requiring expensive retrofitting.

Inefficient Design Delivery

Design-to-development handoff required extensive back-and-forth. Lack of specifications meant developers guessed at spacing, states, and edge cases. This extended timelines and created implementation inconsistencies.

Inefficient Design Delivery

Design-to-development handoff required extensive back-and-forth. Lack of specifications meant developers guessed at spacing, states, and edge cases. This extended timelines and created implementation inconsistencies.

Designing

Design systems enable velocity, consistency, and global scale

A proper design system isn't just organized Figma files—it's infrastructure that changes how teams work. When components are documented, tokens are systematic, and accessibility is built in, designers move faster because they're composing with reliable parts instead of reinventing patterns. Developers move faster because specifications are clear and consistent. The business moves faster because white-label deployment becomes token updates, not weeks of manual work.


I restructured the system around three core principles: reusability through variables (components reference tokens, not hardcoded values, making theming systematic), accessibility as default (WCAG compliance built into component structure, not retrofitted), and platform-appropriate implementation (same design language expressed through native patterns per platform).


The technical work involved establishing semantic token architecture—separating primitive values from contextual meanings so components adapt to different brands and themes automatically. Every component needed documentation: usage guidelines, accessibility requirements, platform-specific behavior, and implementation specs. This upfront investment in structure is what enables the system to scale globally without accumulating design debt.


For white-label specifically, the token structure makes rebranding efficient. A new banking client needs their brand colors applied. Instead of changing hundreds of component instances, we update primitive token values. Every component across all platforms and themes updates automatically because they reference semantic tokens, not raw values.

Systematic design infrastructure that scales

Three pillars solving the core problems

Variables & Component Architecture

01

01

I built a two-tier token system: primitive tokens store raw values (neutral-900, primary-500, spacing-4), semantic tokens define contextual meaning (color/background/primary, color/text/secondary, spacing/component/padding). Components reference semantic tokens exclusively.

This architecture solves white-label deployment. When onboarding a new banking client, we update primitive brand color values. Semantic tokens (color/interactive/primary, color/surface/default) automatically resolve to new brand colors. Every component across iOS, Android, and web updates systematically. What took 3-4 weeks of manual work now happens in hours through token updates.

Theme support works the same way. Light and dark modes are variable modes in Figma. Semantic tokens have different values per mode. Components inherit correct behavior automatically—no manual dark mode work, no checking every state variation.

Documentation for Developer Confidence

02

02

Design systems fail when developers guess at implementation. I created comprehensive component documentation that serves as a single source of truth—eliminating the back-and-forth that previously consumed 30% of development time.

Each component includes usage guidelines (when to use, when not to use), anatomy specifications (spacing, sizing, hierarchy), complete state coverage (default, hover, focus, active, disabled, error), and platform-specific implementation notes. The documentation answers questions before developers need to ask them.

Token naming follows semantic patterns that are self-documenting: color/background/primary, spacing/component/padding Developers understand intent without designer clarification—"background" category, "primary" context, clear purpose. This systematic naming reduced handoff questions by 40% and enabled multiple dev teams to implement consistently without constant oversight.

Cross-Platform Native Experiences

03

03

The design system provides the visual language—colors, typography, spacing, component states. Each platform expresses this language through native patterns. iOS uses native navigation (large titles, swipe gestures, SF Symbols), bottom tab bars, and iOS-standard shadows. Android uses Material Design patterns (FABs, bottom sheets, elevation through surface lightness), Material Icons, and top app bars. Web uses responsive grid behavior, hover states, and keyboard focus rings.

Component specifications document platform differences explicitly. A data table component specifies: iOS uses swipe actions for row interactions, Android uses long-press with bottom sheet menu, web uses right-click context menu and keyboard shortcuts. Same component, three native implementations.

This separation keeps the system clean. Design system handles universal patterns (token structure, accessibility requirements, information hierarchy). Platform conventions handle interaction patterns (navigation, gestures, elevation). The result: applications that feel native to each platform while maintaining consistent data, hierarchy, and visual language.

Impact

From fragmented screens to systematic infrastructure

0%

Faster white-label rebranding

0%

WCAG AA compliance built in

0

Platforms with consistent foundation

0

Faster design-to-dev handoff

0%

Faster design-to-dev handoff

White-Label Efficiency

New banking client onboarding went from 3-4 weeks of manual rebranding work to updating primitive token values—a process that now takes days instead of weeks. Business team can confidently quote shorter deployment timelines to prospective clients

Design Team Velocity

Designers compose screens with documented, tested components instead of creating variations from scratch. Accessibility requirements are built into components, not retrofitted during QA. New features inherit correct theme behavior and platform patterns automatically.

Development Confidence

Component documentation provides single source of truth for implementation. Developers know exactly how components should behave across states, platforms, and themes. Questions decreased significantly—developers implement with confidence instead of interpretation.

"The new design system transformed our development process. Clear component specifications, built-in accessibility, and proper token structure eliminated the guesswork. We ship features faster with fewer inconsistencies across platforms."

Vimarsh Rana

Lead Developer, WebVoltz Development Team

MAS Prime

Scope:

Create a free website with Framer, the website builder loved by startups, designers and agencies.