TSA Design System
Structuring a scalable design system foundation | 2024
MY CONTRIBUTION
As part of the Design System team, I helped shape a scalable cross-platform component library for app and web, in close collaboration with the Design Ops Lead and alongside the broader product design effort.
My contribution included component architecture, mapping and exploration, library structure, documentation, design-development collaboration, client discussions, and supporting designers using the system across product flows, helping keep the system consistent, scalable, accessible, and aligned with real product needs.
SCOPE
Foundations & design tokens, Cross-platform component library, Component architecture & research, Light & dark theming, Accessibility (WCAG), Design documentation, Design–development alignment
SKILS
Design systems, Component architecture, Design tokens, Component auditing, Component anatomy, Variants & states, Figma libraries, Design governance, Design documentation, Design–development collaboration
BACKGROUND
Within a broader telecom self-service product, our goal was to establish a scalable design system architecture that could support the product’s long-term evolution across web and mobile. Rather than starting from scratch, we transformed existing product patterns, brand assets, and technical constraints into a cohesive, reusable system.
The client already had brand guidelines, visual assets, existing UI components, and recurring interaction patterns. We audited and mapped these assets against product flows, user needs, research insights, and engineering constraints to identify reusable foundations, define component architecture, and establish a scalable design system tailored to the product’s real implementation context.
The outcome was a scalable, developer-validated design system with documented foundations, reusable components, accessibility guidelines, and implementation standards. The system established shared design principles and governance that enabled consistent decision-making, predictable component behavior, and seamless collaboration between design and development across web and mobile products.
THE CHALLENGE
The design system had to resolve several layers of complexity at once: product-specific flows, brand expression, component behavior, accessibility requirements, theme modes, and implementation constraints.
Without clear system rules, similar UI elements could easily be interpreted differently by designers and developers, leading to inconsistency, rework, and gaps between design and implementation.
At the same time, the system needed to support both web and mobile experiences while remaining flexible enough to evolve with future product needs.
Finding the right level of abstraction where components were reusable without becoming overly generic, became one of the project’s central challenges.
This meant making clear decisions around:
-
Which patterns should become shared design system components, and which should remain product-specific.
-
How foundations, accessibility, and theming should work consistently across web and mobile.
-
How component anatomy, variants, states, and properties should be structured for consistency and scalability.
-
How documentation, naming conventions, and implementation guidelines keep design and development aligned.
THE PROCESS
From foundations to a scalable library
The process was structured to turn existing system foundations into a practical source of truth for ongoing product design work. We moved through discovery and mapping, foundation architecture, component research, library structuring, and ongoing documentation - creating a Figma library that designers could rely on while staying aligned with development.
Discovery & audit
Foundation architecture
Component research
Component library
Documentation layer
1 / 5
Discovery & audit
We started by auditing the client’s existing product journeys, brand guidelines, visual assets, UI components, and recurring patterns across web and mobile. The goal was to understand how the product was evolving, identify reusable patterns, and establish informed design system decisions.
.png)
​This stage helped us identify:
-
Existing components that could be refined or formalized
-
Patterns that appeared in product screens but were not part of the shared library
-
Duplicated or overlapping UI solutions
-
Local design decisions that needed clearer system logic
-
Gaps between design files, product screens, and implementation expectations
2 / 5
Foundation architecture
This stage translated the mapped brand and product language into system foundations including color roles, typography, spacing, radius, effects, grids, and theme behavior that could support real interface work.
The goal was to keep the system consistent, adaptable, and aligned with the brand as the product continued to evolve.
​To make sure these foundations worked beyond isolated definitions, we tested and refined them across the following contexts,
reviewing the explorations with the client-side team to keep them aligned with the brand while remaining practical for product design and implementation:​
-
Light and dark mode scenarios
-
Accessibility needs such as contrast and state visibility
-
Component states and interaction feedback
-
Real product screens and usage contexts
The result was a structured foundation library in Figma, where the system’s core building blocks were defined through variables, styles, semantic roles, and theme behavior - creating a clear hierarchy that flows from foundations into components, visual assets, and final product screens.
3 / 5
Component research & exploration
After the foundations were in place, we focused on components that needed deeper exploration before entering the library.
.png)
For these components, we conducted focused research and visual benchmarking across other design systems and product experiences, then explored different ways each component could work within the product’s visual language and interface context.
The goal was to understand how each component should express the brand, behave functionally, support variants and states, and sit alongside other components in real layouts. This helped us validate component decisions while keeping the library grounded in the actual product context.
4 / 5
Component library
At this stage, the design system moved from foundation work into a structured component library. Decisions around color, spacing, typography, theme modes, and behavior were carried into the components themselves, so each component reflected the system’s visual and functional logic.
.png)
As the components took shape, we had to define the right balance between flexibility and fixed structure. Slot-based structures helped keep the component layout consistent, while allowing defined content areas to adapt to different product scenarios. Alongside the component structure, the library was organized into clear component categories, making it easier to find the relevant component and use it consistently across app and web screens.
The result was a library that served as a single source of truth for component usage and product design decisions,
helping designers apply components consistently while giving development a clearer reference for supported behavior, structure, and implementation expectations.
5 / 5
Documentation layer
Documentation was treated as an ongoing layer of the design system, not as a final handoff step.
After the research, exploration, and component decisions, documentation became the place where each component’s usage boundaries were made explicit - when to use it, how it behaves, which variants it supports, and what should remain consistent across different product scenarios.
For each component, the documentation captured:
-
Usage guidance and boundaries
-
Structure, variations, and behavior
-
Properties and configurable options
-
Accessibility guidance
-
Related components, comparisons, and references
By making these decisions clear, the documentation helped designers use components in a more consistent way,
reducing local interpretation and supporting a more coherent experience for users across app and web.
It also gave development a clearer reference for expected behavior, supported states, and implementation expectations.
COMPONENT DEEP DIVE
Wizard / Progress Indicator
The Wizard / Progress Indicator was used in a key checkout flow, where users move through several order steps before completing the purchase. In this context, the component had to do more than show progress.
It needed to help users understand where they are, what they have already completed, and what still remains, without taking too much attention away from the page content.
The main challenge was making the component scalable within a multi-step checkout flow and across breakpoints. While the desktop version could show the full process as a horizontal stepper, with step names, connectors, and clear state differences, the mobile version needed a more compact structure that still made the user’s progress clear within limited screen width.
To support the decision, we reviewed visual and functional references from product interfaces
and other design systems
.png)
Rather than evaluating the references only by their visual direction, we tested how well each option could hold up inside real checkout screens, with different resolutions, varying numbers of steps, and content below the component.
We evaluated the options based on:
Visual state distinction
Page layout impact
Current step visibility
Step count scalability
Typography hierarchy
Responsive behavior
The more expressive options were visually interesting, but became less effective when tested against these constraints. Some options created too much height, some made scanning harder, and some risked looking like tabs rather than a progress indicator.
Exploration snapshot
Following the reference review, we explored multiple Wizard directions across desktop and mobile, testing different ways to express progress, current-step visibility, state distinction, and step density. This helped us compare not only how each direction looked, but how well it could adapt to real product scenarios, different step counts, and changing screen sizes.
Final direction: consistent logic, adaptive layout
The final direction prioritized clarity, scalability, and a consistent process model over visual complexity. The Wizard was designed to help users understand the flow as a clear sequence - what they completed, where they are now, and what remains, while defining consistent states for completed, current, upcoming, and disabled steps.
On desktop, the full step sequence is visible as a horizontal stepper. On mobile, the same process model is preserved through a compact structure that highlights the current step, step count, and access to progress details. This allowed the component to scale across breakpoints and checkout scenarios without forcing one layout into every context.
OUTCOME
A structured system for consistent product experiences
The work resulted in a structured design system for app and web, built on top of existing client assets, product screens, and system materials. It connected foundations, components, documentation, and implementation expectations into a clearer source of truth for product design work.
The system helped support:
Consistent app and web component usage
Connected libraries shaped by brand and system logic
Clearer design-development alignment around component behavior
A scalable base for future product flows
REFLECTION