Refining the foundations
Three years of learnings that shaped ADS 3.0
Note: All examples have been modified to protect sensitive data.
Table of contents
Overview
After years of quick fixes, we took a step back to understand how we could level up the system from good to great. It challenged us to think bigger, navigate ambiguity, and lead with both vision and flexibility.
The design team
Parnrawee (Parn) Ninlaphan
Product Design
Wichaya (Mild) Pintavirooj
Visual design
Tanisa (Fern) Law
Benchmarks & Audits
Ahra Yun
Benchmarks & Audits
Alexander Fandén
Project and design lead
The challange
Our last major update unified web and app with shared tokens and consistent UI. But without a clear design vision, the system felt generic and fragmented. Inconsistencies emerged — like mismatched component sizes and icon discrepancies:
Many components were bloated, and patching wasn’t sustainable. Bug reports and requests piled up. As adoption grew, teams needed more flexibility — and accessibility had to be addressed across the board.
There was alignment across Tech, Design, and Product that quick fixes weren’t enough:
Product: Fix accessibility, improve flexibility, reduce lead-times and blockers for experimentation.
Design: Create a cohesive, interoperable system
Tech: Rebuild on a headless foundation
Scoping the problem
Benchmarking
While the tech team reviewed the codebase, we benchmarked our components a competitors. We logged all insights and recommendations we could find:
I developed a 0–100% scoring system for each component’s capabilities. This quantified the gaps, sized the problem, and reassured leadership the project was worth pursuing:
Internal audits
Each designer took ownership of a set of components, working with product teams to uncover unsupported use cases and gather feedback. This example shows various unsupported Steppers:
Roadmap in batches
To work efficiently and maintain cohesion, I grouped related components into logical batches—like form fields or buttons. We prioritized foundational, high-dependency, and high-impact components to focus on what delivered the most business value:
We shared the roadmap openly and invited feedback, giving teams visibility into our priorities and a chance to shape them. Anyone who had submitted feedback, bugs, or requests was invited as a stakeholder for the relevant component.
We prioritized batches based on:
Business priorities (team needs)
Accessibility violations
Benchmark gaps
Feature requests
Bugs
Dependencies
Since priorities shift, we reviewed and revised the batches quarterly to stay aligned with team needs.
Getting to work
From day one, I created a new exploration library with my colleague Parn. We started by defining rules and foundations, applied them to components, and iterated to refine both over time—for example, unifying interactive states, setting color hierarchy guidance, and creating sizing charts:
For each component, the team mapped out all dependencies, so we could split the efforts and unblock the components efficiently:
We organized work into Jira epics and I co-created a to-do list with my PM and Dev Lead to cover all bases. Each component had a lead designer and developer, creating ownership and tight cross-functional collaboration to move fast with good results:
Now we had a good picture of the challenge ahead, and the structure needed to move efficiently.
Quality goals
Feedback from product teams showed we had to move from a system people had to use to one they wanted to use. We didn’t start the project with clear quality goals, but as the work came along I reframed our learnings into goals that defined what good meant for the system:
2.0 Problems
3.0 Goals
Inconsistent design, naming and code
Clear conventions, shared utilities
Inaccessible, Poor docs
A11y-first, examples over text
Rigid and Prop-heavy components
Modular
Generic
Branded
Limited involvement of product teams
Partnered early and often
Results
A clear understanding of the problems, established goals and a solid set of rules and foundations helped us move towards our goals.
Goal 1 — Coherent
The rules and foundations provided a more solid blueprint for component-making. Previously, we had components across 20 different sizes, making them hard to use together. We cut it to 12, pairing sizes to work smoothly across commonly combined components like form fields and buttons:
Some components were very rounded, others sharp. To bring them closer to our brand, we created a simple formula: divide the height by 5 and round up to the nearest token. This worked well across all new sizes:
We created a share utility in both code and Figma to make our interactive states accessible and drive consistency across the library:
Goal 2 — Usable
We used insights from accessibility audits and worked with our a11y experts to fix violations and guide teams toward better defaults.
Our new form fields addressed key issues—supporting longer labels, separate helper texts, and clearer validation messages:
We also removed unnecessary docs and partnered with teams to provide more relevant, accessible examples in both code and Figma.
Goal 3 — Scalable
We made the system more flexible by replacing props-only setups with composable sub-components—like breaking Select into reusable parts: Label, Helper Text, Field, and Validation:
Another example is our Timeline component, which comes as separate Markers, Tracks and Steps, in various configurations. We also provided ready-to-use templates and example use-cases:
This give product teams more flexibility to mix and match elements to fit their unique needs, without sacrificing consistency with the system.
Goal 4 — Recognizable
I worked with other design leads to translate our brand guidelines into visual UI principles and guidelines, putting words to how our products should look and feel going forward:
I worked with our brand team to find a new font that brought the product closer to the brand. The new font supports 500+ languages and tabular figures, helping users scan prices easier:
A brand designer joined us to turn our visual assets from generic to branded — 1,200+ icons, 100+ payment logos, and all country flags:
And we leveraged AI to re-generate illustrations that are true to our style, and solving long-standing lead-time bottle-necks in the process:
Goal 5 — Considerate
We involved teams early by reaching out to those who’d submitted bugs or requests, bringing them into the design process. We used feedback templates to share decisions, present options, and spark detailed discussions—both async and in person:
I used Figma Make to build a quick tool for the Loyalty team to pick ‘safe’ colors for their VIP Badges — automatically staying within our ADS palette and meeting accessibility standards:
We involved designers throughout—testing components in Figma and production—to catch issues early and build shared ownership that eased adoption:
And to encourage more designers and developers to build out ADS 3.0, we created bespoke contributor swags:
Trade-offs & Learnings
We never aimed for perfection. Our goal was to build a system people wanted to use—not just had to. That meant holding onto the bigger vision while staying flexible in how we got there.
1. Partner early and often
Partnering early reduced risk and created allies. One successful collaboration often opened doors to more.
2. Test first, tokenize later
Not everything was tokenized—and that was intentional. We logged one-off solutions for future cleanup, understanding that system maturity takes time.
3. Relevance over completion
Components or features that were in low/no demand were marked for contribution, so we could focus on what's most important for the org.
But systems work isn’t just about tokens and components. It’s about people, trust, timing, and navigating shifting priorities:
4. Buy-in is hard-earned, and fragile
Midway through the project, leadership changes reshaped our cross-functional landscape. Some of the trust we had built over years was suddenly up for re-evaluation. Staying adaptable and continuing to show value became critical to keep moving forward.
5. Co-creation is powerful, but not always enough
We partnered with teams early and often, but priorities shifted. New hypotheses, new directions, and new org goals meant some of our assumptions no longer held. We had to adjust the strategy and let go of parts we had deeply invested in.
6. Design systems reflect company culture
This work lived at the intersection of design, engineering, and product—and not all parts were equally valued by all stakeholders. While we pushed for a more cohesive, brand-aligned experience, others prioritized speed and experimentation. We tried to made space for both, even if it meant shifting how success was defined.
7. Building trust means leading and listening
Driving a strong point of view is essential—but so is making space for others. We learned to balance both by invite feedback without slipping into design-by-committee, and align by speaking each stakeholder’s language. Trust came from leading the way, but also from inviting others to play.
Final thoughs
This was one of the most challenging and rewarding projects of my career. It wasn’t just about components, but navigating ambiguity, shaping culture, and moving systems forward in a complex org.
We faced classic challenges: holding a vision without rigidity, adapting to shifting priorities, and involving others without losing momentum.
I learned when to push vs. let go, how to lead with clarity while staying open, and how to build trust through craft and by creating space for others.
It reminded me why I care about design systems—not just for quality, but for the alignment and momentum they create. I’m proud to have helped lay a foundation others can build on.
← Back
Next: Prioritizing Design Systems →