Case study · Design systems · fromAtoB
One design system, three platforms.
Rebuilding a sprawling, undocumented style guide into a governed system the whole team could build from, spanning web, iOS, and Android.
I drove the architectural decisions behind fromAtoB's first real design system, owned its color and accessibility audit end to end, and co-built its component library, 47 documented components, with the design team. The system was in active production when I left, after cutting design handoff from 45 minutes to 10 and consolidating a sprawling style guide (28 colors, 64 text styles, 80 components) into a documented, governed set roughly half the size.
The piece I'm proudest of is the component library. Not because it was mine alone (the design team built it together), but because it's where the system stopped being documentation and became the way people actually worked.
The problem
The style guide existed. The system didn't.
fromAtoB already had a style guide. On paper. In the live product, it had stopped meaning anything.
Colors, fonts, and styles that weren't in the guide had crept into shipping screens, so the product looked inconsistent not just across web, iOS, and Android, but within a single platform. The same error message used dark red with white text in one place and light red with dark text in another, depending on which designer had built it.
The guide itself was part of the problem. Designers wanted to use it, but the components were buried in Sketch and nobody could find them, so they rebuilt from scratch and the drift got worse. Across six designers and three platforms, every new screen made the inconsistency a little harder to undo.
My role
The honest ownership map.
Two efforts ran in parallel, a full redesign of web + iOS + Android, and the design system underneath it. My work centered on the system. On a team of six designers, it's worth being exact about what was mine and what was ours.
The color audit and accessibility pass. The full inventory of what was actually shipping, the consolidation from 28 colors to 17, and the WCAG contrast work that moved the primary CTA from failing to AA.
The two architectural calls that shaped the system, building on Material rather than from scratch, and staying in Sketch rather than migrating to Figma mid-flight.
The component library, 47 documented components, built with the design team.
Recommendations into the design principles workshops. The sessions themselves were a team effort.
Key decisions
Build on Material Design, not from scratch
We could have designed a system from first principles. I made the case against it. Engineering had already built much of the product on Material, so anchoring the design system to the same foundation meant the design and the codebase spoke the same language from day one. Less translation, less drift, faster adoption.
Less distinctiveness in the primitives, bought back deliberately through the brand layer of color, type, and principles on top.
Stay on Sketch instead of migrating to Figma
The tempting move was to do everything at once. Redesign the product, build the design system, and migrate to Figma. I made the call to stay. Chasing three changes simultaneously tripled the risk to the one that actually mattered, the system shipping. The team already worked in Sketch, so we stayed, and spent the saved risk budget on getting the foundation right.
This is the decision I'd point to as the most senior one I made on the project was knowing what not to do.
Staying on aging tooling, accepted knowingly to protect the launch.
Inventory reality before designing the ideal
Rather than design a clean system in a vacuum, I started by auditing what was actually in the product. I ran the audit myself. I captured every screen across web, iOS, and Android, pulled every color and style into one table (name, HEX, where it was used, a real example from the product) and only then designed the consolidated set.
That's how 28 colors became 17 and 80 components became 47. The cuts were based on evidence, not taste, which made them defensible to marketing and engineering both.
Weeks of unglamorous inventory work before any visible design, paid back the moment the cuts had to survive review.
How it came together
Foundation first, then the library.
1 Foundation: principles the team actually agreed on
The team ran design principles workshops until we agreed on five. Simple, Helpful, Consistent, Joyful, Dynamic, each with a shared, written definition, so "consistent" meant the same thing to every designer instead of five different things. I contributed recommendations into those sessions rather than facilitating them. The principles were genuinely a team artifact. From there it was color, typography, iconography, spacing, grid.
2 Accessibility: the audit doubled as a contrast pass
Testing the live palette against WCAG contrast ratios surfaced real failures, including the primary CTA, the control users press most in a booking flow, which was failing outright. My rework moved it from failing to AA.
Low contrast isn't cosmetic here. fromAtoB's travelers include exactly the users a 4.5:1 ratio exists for.
3 Components: 47, documented, with every state
With the foundation locked, the design team and I built the component library, 47 documented components with full interaction states (enabled, hover, pressed, focus, disabled) in light and dark, documented so a designer could find a component in Sketch and use it without rebuilding it.
4 Validation: old vs. new, with real users
Our researcher ran usability tests with nine employees, 30-minute sessions comparing old and new, focused on type and color, producing a prioritized list of fixes that fed straight back into the system.
Impact
The redesign the system shipped into moved the product numbers too. Booking conversion up 28%, checkout time down 10%, abandonment down 18% in the 60 days after launch. Those are team outcomes, six designers and a rebrand deep, but the checkout and search simplification I worked on sits behind two of them, and the system is what let three platforms ship the changes consistently.
When I left to move to the US, the system was in active production, not yet complete in design and code but already paying off.
Documented and governed, rather than sprawling and undocumented, a set the whole team could build from without rebuilding it first.
What I'd do differently
I'd have instrumented adoption from day one. We measured handoff time because it was easy to measure. Adoption, how many designers were actually building from the shared library, was the number that mattered, and I let it stay anecdotal. A lightweight metric from week one would have made the system's value legible in numbers rather than in how the work felt.