FLYR
Category
Design Systems / B2B SaaS
Scaling a design system across a complex product ecosystem. FLYR bridges the gap between legacy systems and a new era of airline retail.
Turning a fragmented design system into scalable product infrastructure
At FLYR, I work on Orville, the design system supporting a complex B2B product ecosystem. As the system evolved across multiple product teams, inconsistencies and duplicated patterns began to emerge.
2+ years
Design-system experience4
Product teams50+
Components/patterns reviewed and consolidated1
Dedicated design-system designer
THE SITUATION
Keeping a design system alive after the team that built it shrank to one.
Took sole ownership of FLYR's design system after a team restructure, unified years of divergent components and a sprawling custom icon library, and built the processes that let a one-person team keep pace with product velocity. Sustaining the system that underpinned the booking experience FLYR launched with Riyadh Air, part of a $295M financing round.
The design system team shrank. The system's problems did not. A restructure changed the scope of the job overnight, not just the size of the team.
What changed
Full ownership meant inheriting more than day-to-day maintenance. It meant every unresolved inconsistency the previous team hadn't gotten to, with no one left to split the backlog with.
What I inherited
Multiple products had drifted into their own visual dialects, the same component existing in several incompatible versions depending on which team had built it. The icon library told the same story at smaller scale: a large set of custom icons I had designed over time, with no consistent categorisation, making it hard for anyone to find or trust what already existed before designing something new from scratch.
The real constraint
This was not a green-field systems project with a dedicated budget. It was one designer deciding, without a team to lean on, what mattered enough to fix first and then negotiating that prioritisation directly with product teams who each had their own deadlines.
The job stopped being "design the components" and became "decide what a design system team of one can realistically own."
THE APPROACH
Unify what existed before building anything new
The problem was not a lack of components. It was a lack of alignment. With no team behind me, the highest-leverage work was consolidation, not net-new components.
Component unification
Different product teams had developed variations of similar patterns over time. This created duplication in Figma, inconsistent experiences across products and additional complexity for engineering. For instance, four teams, four buttons. Fifty-plus components got reduced to one shared version each, so nobody has to guess which one is the real one anymore.
Icon library + categorisation
Designed a large set of custom icons and built a categorisation system so the library could be searched and reused, instead of quietly re-drawn.
Lightweight request process
A repeatable path for new component and icon requests, built so a team of one could keep up without becoming a bottleneck.
Platform-agnostic type tokens
Restructured the system’s typography tokens so the same type scale applies consistently across web, mobile, and different brand contexts — without redefining values per platform.
Design-code parity
Worked closely with engineering to keep component definitions in Figma matched to their Storybook implementation, so design and engineering always referenced one source of truth.
Ownership
The part of the job nobody puts in the job description.
Losing the team did not lower the bar. It meant deciding, alone, what actually mattered enough to fix. Unifying what already existed turned out to matter more than building anything new.
Growing the system with purpose
I introduced new components and custom icons only where they solved proven product needs, then documented and organized them for consistent reuse. This gave product teams a scalable foundation to build on without fragmenting the system again.
