Migrated a fragmented component library into a unified, scalable design system by defining foundation tokens, standardizing components and patterns, and documenting cross-platform guidelines.
Role
User experience designer working student @ PAYBACK
Scope
Cross-platform Design System Foundation & Component Architecture (Material, HIG, Custom Guideline Integration)
Duration
Mar 2024 - NOW
Collaboration
2 designers, 2 developers+
Platform
Mobile(Androind, iOS), Web
Tool
Figma
Overview
This project was conducted at PAYBACK, part of American express, a leading multi-partner loyalty platform founded in 2000 and operating across Germany, Poland, Italy, and Austria. In Germany alone, the platform serves over 34 million users, including 16 million mobile app users (as of June 2025). PAYBACK’s ecosystem spans both physical and digital channels and connects over 700 partner companies, including major brands such as Amazon, dm-drogerie markt, and EDEKA.
As a working student, I was trusted with ownership beyond my title and contributed to building a more scalable and maintainable internal design system. I helped consolidate fragmented platform foundations, introduced a token-based structure, and improved documentation workflows.
I also optimized components in response to Figma updates and kept both designers and developers aligned through regular cross-functional syncs.
Challenge & Opportunity
PAYBACK operates native mobile apps on both iOS and Android, alongside a connected B2C e-commerce website. As users moved between these platforms, differences in design language and interaction patterns—particularly across iOS, Android, and web—resulted in inconsistent user experiences and duplicated design efforts.
While each app adhered to platform-specific guidelines like Material Design and Human Interface Guidelines, the absence of a unified foundation made it challenging to deliver a cohesive and scalable experience. Recognizing this, I initiated the development of a unified design system aimed at bridging platform differences while maintaining native interaction principles.
As the product evolved, I identified several key challenges that surfaced naturally during growth. These became valuable opportunities to enhance the design system’s structure, clarity, and collaboration processes:
Platform-specific inconsistencies
Visual and interaction patterns had diverged across iOS, Android, and web. Without a unified foundation, this fragmentation affected the overall user experience and introduced inefficiencies for designers working across platforms.
Limited scalability and documentation gaps
As the system grew, maintaining consistency and clarity became increasingly complex. The component library was variant-heavy and lacked semantic structure and reliable documentation, which hindered onboarding and reduced design reusability.
Workflow misalignment
With evolving tools and the migration to Material 3, our update and collaboration workflows needed to adapt. Designers and developers alike needed up-to-date guidance on foundations and components to support more effective design handoff and implementation.
Despite limited resources, this challenge offered an opportunity to reassess the system’s structure, strengthen maintainability, and foster better cross-functional collaboration.
Consistent, shared global foundation
To address inconsistencies across platforms, we introduced semantic design tokens and platform-agnostic foundations. This enabled us to create a unified design language that could be applied across iOS, Android, and web while preserving native interaction principles.
Optimizing components
To improve scalability and reduce complexity, we reorganized the design system using a modular structure and optimized the component library. This approach enhanced reusability, minimized redundancy, and made onboarding more intuitive for new team members.
Alignment Communication
To close workflow gaps, we established regular alignment rituals and updated our documentation to reflect ongoing changes. Strengthening our shared understanding of platform-specific guidelines (Material, HIG) helped facilitate smoother collaboration between designers and developers as the system evolved.
Approach
Previously, foundation styles, shared components, and feature-specific components were all managed within a single file using extensive variants. While this allowed for convenient switching between elements in one place, it introduced several challenges as the system grew. Also, the web design library uses different color and font systems, so it made hard to communicate between the platforms.
As the number of components and use cases increased, the single-file structure became harder to scale and maintain. It created friction when trying to collaborate across platforms, slowed down performance in large files, and made ownership unclear—especially when different teams worked on different layers of the system.
To address this, I proposed a layered file structure that clearly separates design foundations, platform-specific components, and feature-level assets.
This new structure enabled each layer to evolve independently while remaining connected through shared tokens and principles. It also made it easier to assign ownership, improve performance in Figma, and allow deeper focus on foundational decisions without being distracted by feature-specific variations.
I defined a global foundation that could be shared across mobile environments (Android, iOS) and web. This foundation included color, typography, spacing, elevation, corner radius, stroke, and icon systems.
Most foundation layers followed a primitive–semantic token structure. In the case of color, we expanded this into three levels:
Primitive values (e.g., hex codes)
Tonal values (e.g., Blue-60, Gray-30)
Semantic values (e.g., primary, info, surface, surface-container)
This hierarchy helped clarify when and where each color should be used.
Given that our brand heavily uses the blue spectrum, I defined a more granular tonal scale for blue and gray compared to other color groups. This allowed for better expression of visual hierarchy—such as state changes and surface levels—while staying aligned with our brand identity.
All design tokens at the foundation level were managed through Figma variables, and we collaboratively defined token aliases with developers to ensure consistency across design and implementation.
For spacing tokens, I initially considered a t-shirt sizing convention (e.g., sm, md, lg) for clarity. However, after aligning with developers, we adopted a numeric convention (e.g., spacing-12) for better implementation efficiency. All spacing tokens were based on a 4px scale, allowing the system to remain consistent within a clearly defined range.
Each token was documented with usage guidelines and pairing logic, specifying when and how to use it. This improved cross-functional communication, simplified handoff, and supported both scalability and future theming.
To support a smooth migration, I also mapped legacy values to the new token structure, enabling a consistent and efficient transition from the previous color system.
After establishing the foundation layer, I applied these values systematically to core components across platforms.
Semantic tokens served as the backbone for defining component states, surfaces, and interactions, allowing us to maintain visual and behavioral consistency while still accommodating platform-specific needs.
As part of this process, I also revisited how components were structured in Figma. With improved update features in the tool, I was able to simplify our variant logic—reducing redundancy and minimizing confusion for designers. What was previously handled through extensive variants was now managed more efficiently, without compromising flexibility.
To ensure the design system could be easily adopted by all team members, I created documentation that went beyond just listing tokens or components. The documentation introduced the purpose and structure of the system itself—explaining what design tokens and Figma variables are, why we use them, and how they connect to our visual language.
I also included platform-specific examples that showed how tokens could be applied within actual product screens, helping designers understand usage patterns in context.
This helped reduce ambiguity, supported onboarding for new team members, and aligned the team around shared principles and practices.
To ensure the design system was not only well-structured but also actively adopted, I helped lead regular syncs and cross-functional communication sessions.
Design System Weekly (Designers only)
I participated in and sometimes led weekly sessions within the design team to share updates on the system, onboard designers to newly added foundations or components, and discuss open questions around component usage. These meetings served as a space to maintain consistency, gather feedback, and support alignment across crews.
Design–Dev Sync (Designers + Developers)
This was a focused session held between design system designers and workstream developers. I worked closely with developers to create implementation tickets for upcoming components, clarify expected behaviors, and resolve any platform-specific constraints.
Through this regular alignment, we ensured that components were not only consistent and accessible, but also technically feasible and easy to implement.
Through these structured rituals, the design system became more than a static file—it evolved into a shared language that the whole team could understand and contribute to.
Impact
While this project focused primarily on building the foundational layers of the design system, it has already contributed meaningful outcomes at multiple levels.
The full impact will become more visible over time, but early feedback and adoption across teams point to the following areas of value:
Structured onboarding for designers
Established a more organized and up-to-date design library using semantic foundations, improving day-to-day usability and reducing confusion for designers.
Cross-platform foundation alignment
Helped unify design language across Android and iOS by introducing shared tokens and component logic, setting the stage for future integration with the web.
Improved developer experience
According to internal feedback, developers experienced less friction and fewer iteration cycles due to clearer specs and a reduced need for clarification.
Reflection
Working on this design system taught me how even small changes, like refining a token or adjusting a naming convention, can ripple across an entire product ecosystem. It made me appreciate the power of tokenization, not just for visual consistency, but for enabling scalable and adaptable systems that respond to a wide range of use cases and edge conditions.
Regular communication with designers was essential. Their feedback helped me iterate continuously, and I realized that a successful design system is not static—it needs to evolve in close collaboration with those who use and build with it.
I also learned that clear documentation isn’t just about recording decisions. It’s a tool for reducing ambiguity, aligning designers and developers, and smoothing daily workflows across teams.
As a working student with a 20 hour per week schedule, I had to be intentional with my time, prioritizing high-impact areas, aligning quickly with stakeholders, and improving the system through small, focused iterations. These constraints sharpened my ability to think structurally and lead initiatives even within a part-time capacity.
Due to confidentiality, this case study presents only abstracted insights and system-level structures. This project is ongoing and being continuously updated for better optimization. Upon request, I’d be happy to walk through more detailed aspects of the work.