Sergey Berezyuk Cases · Contact
<- Go to cases

Orville Design System for FLYR

Turned fragmented UI efforts into a single product infrastructure and helped close a $295M deal

Orville Design System for FLYR
Client
  • FLYR, Modular airline retailing
Visit
flyr.com
Date, duration
2023–2025, 24+ months
Team
  • Front-end Engineer, x2
  • UX Designer, x2
My role
  • Design System Lead
Deliverables
  • Figma libraries and component kit
  • React component library with Storybook and usage metrics
  • Documentation in Confluence, Zeroheight, and Storybook
  • Contribution, deprecation, and release workflows
Goal
  • To build and enable a unified design system and shared experience for designers and engineers, reducing delivery time and rework.

Design System · Products

Overview

Over two years, we took FLYR from “every team designs their own buttons and tables” to one shared design system for the whole Revenue Operating System.

Components & patterns
  • 50+ core components in React and Figma
  • 80+ patterns
  • Fully documented and versioned
Figma adoption
  • 96.6% Figma component insertions
  • -31.2% component detachments year-over-year
Production usage
  • 100% product UI in production built on Orville
  • ~2k component usages in the codebase
  • +50% usages growth over a year
Riyadh Air impact
  • End-to-end booking flow delivered in 6 months instead of 12-18
  • Supporting a $295M funding round

Framing question

"How do we turn a pile of local UI decisions into infrastructure that lets us ship new products much faster, without losing quality?"

Problem & insight

What wasn't working

In 2021, every FLYR product team designed its own components. Each new flow meant:

  • Rebuilding basic UI like tables, filters, and forms from scratch.
  • Different spacing, color, and state conventions on every team.
  • Manual syncing between Figma and code, with no single source of truth.
  • Noticeable UX drift between products in the same ecosystem.

For the business it meant slower launches, higher maintenance costs, and no coherent "platform" story to sell.

What I saw

My users here were internal. Designers spent weeks rebuilding basic UI instead of solving real user problems. Engineers cleaned up inconsistent patterns from every team by hand. And without a shared vocabulary, even talking through a UI decision was hard. Three principles came out of that:

Simplicity
fewer custom one-offs, more reusable building blocks.
Consistency
the same pattern behaves the same way everywhere.
Control
the design system team guides, not blocks, with transparent evolution paths.

Goal

Turn those one-off UI decisions into shared infrastructure, so teams stop rebuilding the basics and ship faster.

Building Orville

Foundation

I started by setting the system's boundaries and mission:

What "design system" means at FLYR: the official story of how the company makes digital interfaces.
Which standards, assets, and processes must be shared across the organization.
Which deliverables and metrics will define success.

Then the basics every product would share:

4pt grid for spacing, sizing, and radii.
Color system CAM02 (Ch) to ensure perceptual consistency in real-world lighting conditions.
Typographic scale and system fonts.
Three-layer design tokens, synchronized between code and Figma Variables via Token Studio.

The structure follows atomic design: tokens feed icons and components, which build up into atoms, molecules, organisms, layouts, and pages. I split the master file into three Figma libraries that version on their own (Style, Icons, Components), and together they make up the Core DS that every other team builds on. Two more layers sit on top: a 380+ icon set based on Tabler and extended for airline and B2B cases, and a set of data-heavy patterns (charts, tables, graphs) with accessibility built in.

The master file split into focused libraries (Style, Icons, Components), alongside per-product and per-pillar libraries such as Highcharts, BuildCurves, Charts, and Filters.

2025 101 80
The master file

I pressure-tested a lot of these architecture calls at Brad and Ian Frost's live Design System masterclass (Hatch, Berlin, 2023) and their Subatomic course on design tokens.

2023 10 04 Hatch Brad Frost 2
With Brad Frost, Berlin 2023
2023 10 04 Hatch Brad Frost
Design System Masterclass certificate, Hatch, Berlin
2025 05 30 Brad Frost Subatomic
Subatomic completion certificate

Layered Storybooks

The Main storybook brings the whole system into one view: the Core DS at the base, and each product and feature storybook layered on top where it made sense. Every product and feature reuses that same core.

Main Storybook
Core Design System Storybook
Design Tokens
Icons
Components
Patterns
Product & Feature Storybooks
Local Components
Assemblies
Patterns
Layouts
Pages

A shared component language

I turned UI choices into a structured language, spelling out every component's states, slots, intents, objects, and grades:

State
  • rest
  • hover
  • pressed
  • dragged
State
  • focus
  • disabled
  • read-only
  • inactive
Slot
  • trailingVisual
  • leadingVisual
  • icon
  • text
Intent
  • neutral
  • primary
  • success
  • danger
  • warning
Object
  • bg
  • icon
  • text
  • border
  • shadow
Grade
  • min
  • weak
  • medium
  • strong
  • max

That took care of a lot of "which button do I use here?" guesswork and cut the random variation in the UI.

Built for how each role works

I mapped how each role actually works with the system. That is what turned Orville into a product people relied on, not a library they ignored:

Designer
discover component
understand guidelines
assemble flow from existing blocks
raise a contribution when something is missing
Engineer
find implementation
inspect prop API and states in Storybook
implement without manually translating from Figma
Product
understand system capabilities and constraints without diving into Figma or code

Shipped in React and Figma

Orville ships in two forms. Design: a Figma library built around real product scenarios (Accordion, Table, Button, Checkbox, SegmentedControl, and so on). Code: React components documented in Storybook and tracked with omlet.dev. Using it is meant to be boring: import, wire it in, test, ship.

2025 101 91
Consumption flow: a product team imports the versioned lib, wires the component in and tests. If it works, they launch; if not, they file a bug per DS guidelines.

Process & documentation

To keep the system growing instead of going stale, I added contribution templates for components, properties, and icons, and pulled the documentation together across Confluence, Zeroheight, and Storybook, all searchable and versioned for designers, engineers, and PMs. The intake-to-release path puts a few questions in front of every request before any code gets written: does the component exist, does it meet the need, does it belong in the DS, and can it hit the timeline.

2025 101 90
The full contribution workflow, from a product team request through existence, fit, ownership and timeline checks to backlog, build, review and release.

Transparent, defensible prioritization

With 10 designers and 50+ developers depending on the system, informal prioritization stopped working. Requests conflicted, urgency was unclear, and no one could see when work would land. I replaced the negotiation with a public, defensible contract.

Outcome. Prioritization became a predictable weekly rhythm. Every reschedule carried a reason and went straight to the affected team. Nothing slipped silently, so even delays built trust and let stakeholders plan around our cadence.

I wrote it up as a public contract shared with every team, combining the Eisenhower Matrix and RICE scoring, adapted to our org. Requests lived in Jira across separate design and engineering boards, linked to intake forms for bugs and feature requests.

Scoring criteria
Business priority
Of the requesting team; company-wide priorities set the queue order
Reach
How many surfaces and users the request touches
Effort
Implementation cost for design and engineering
Alternatives
Whether a workaround already exists

Company-wide priorities set the queue order: requests from lower-priority product lines were always scheduled after higher-priority ones. No negotiations, just a shared reference.

Rituals and cadence
Ritual Cadence Purpose
Intake review 1-2×/week, 15 min Score new requests, set priorities; incomplete ones go back to the requester
Requester sync As needed Confirm problem, edge cases, and scope before work starts
Weekly grooming Weekly Break requests into tickets across design + engineering boards, cross-linked
Sprint & release planning Per sprint Groomed tickets feed sprints; release dates shared with stakeholders
How requests were handled

Bugs were immediate interrupts. They jumped the queue, and affected teams heard about the schedule change right away. Non-urgent requests followed the intake cadence, handled live with the team or async by the on-duty lead.

A core principle: Figma specs had to be unambiguous before engineering began. Open questions during estimation or mid-sprint were resolved upstream through close design and dev collaboration, which prevented costly corrections later.

Figma updates in Slack

Figma updates triggered a Slack workflow so teams saw when components or tokens changed.

2025 101 10
+
2025 101 9
2025 101 1
2025 101 16
2025 101 17

Figma deprecation

I defined a deprecation process with migration steps and staged releases.

Old components are removed in a planned way with clear instructions on how to update them. Every change goes through a formal request and peer-review process. Releases are done in stages through automated pipelines, and the documentation is updated each time, giving clear guidance for future changes.

2025 101 50
Process description
For the following use cases
  • fully remove a Figma component from the lib without any replacement.
  • deprecate and then remove a Figma component from the lib providing a replacement.
Procedure

  1. Duplicate original component
    1. duplicated component after applying all necessary changes must be published providing release notes
    2. original component must be renamed
    3. description field of the Figma component should be filled up with instructions (see template below)
  2. Rename
    1. ⚠ use a warning sign in the title: ⚠ Button
    2. add Banner with a message in order to keep visual separation from other components on the page
  3. Provide timelines
    1. by default any deprecated component in Figma can be removed in 2-3 months
  4. Tips
    1. Deprecating/removing library components will not change existing design layouts
    2. Restore Component button can be used in order to restore missing or removed components
    3. Communication link must be provided

Message template
Description

  • New version: Component Name (e.g. TableFooter)
  • Deprecated: MMMM YYYY (e.g. February 2024)
  • To be removed: MMMM YYYY (e.g. April 2025)
  • Reason: Describe reasons in 1-2 sentences, stay specific (e.g. Refactoring of the [prop name] was causing breaking changes)

Tips

  • Deprecating/removing library components will not change your existing design layouts.
  • Deprecated components will be removed after 2-3 months.
  • Use the Restore Component button to restore missing or removed components, however consider switching to a new version first.
  • Need help? Reach us in #design.

Components

Button
_Button-wireframe
Button wireframe rest state Button wireframe rest state with leading icon Button wireframe rest state with trailing icon Button wireframe rest state with trailing action Button wireframe rest state with leading icon, trailing icon, and trailing action
Button-primary
rest Button primary rest state Button primary rest state with leading icon Button primary rest state with trailing icon Button primary rest state with trailing action Button primary rest state with leading icon, trailing icon, and trailing action
hover Button primary hover state Button primary hover state with leading icon Button primary hover state with trailing icon Button primary hover state with trailing action Button primary hover state with leading icon, trailing icon, and trailing action
pressed Button primary pressed state Button primary pressed state with leading icon Button primary pressed state with trailing icon Button primary pressed state with trailing action Button primary pressed state with leading icon, trailing icon, and trailing action
focus Button primary focus state Button primary focus state with leading icon Button primary focus state with trailing icon Button primary focus state with trailing action Button primary focus state with leading icon, trailing icon, and trailing action
Button-secondary
rest Button secondary rest state Button secondary rest state with leading icon Button secondary rest state with trailing icon Button secondary rest state with trailing action Button secondary rest state with leading icon, trailing icon, and trailing action
hover Button secondary hover state Button secondary hover state with leading icon Button secondary hover state with trailing icon Button secondary hover state with trailing action Button secondary hover state with leading icon, trailing icon, and trailing action
pressed Button secondary pressed state Button secondary pressed state with leading icon Button secondary pressed state with trailing icon Button secondary pressed state with trailing action Button secondary pressed state with leading icon, trailing icon, and trailing action
focus Button secondary focus state Button secondary focus state with leading icon Button secondary focus state with trailing icon Button secondary focus state with trailing action Button secondary focus state with leading icon, trailing icon, and trailing action
Button-primary-invisible
rest Button primary invisible rest state Button primary invisible rest state with leading icon Button primary invisible rest state with trailing icon Button primary invisible rest state with trailing action Button primary invisible rest state with leading icon, trailing icon, and trailing action
hover Button primary invisible hover state Button primary invisible hover state with leading icon Button primary invisible hover state with trailing icon Button primary invisible hover state with trailing action Button primary invisible hover state with leading icon, trailing icon, and trailing action
pressed Button primary invisible pressed state Button primary invisible pressed state with leading icon Button primary invisible pressed state with trailing icon Button primary invisible pressed state with trailing action Button primary invisible pressed state with leading icon, trailing icon, and trailing action
focus Button primary invisible focus state Button primary invisible focus state with leading icon Button primary invisible focus state with trailing icon Button primary invisible focus state with trailing action Button primary invisible focus state with leading icon, trailing icon, and trailing action
Button-secondary-invisible
rest Button secondary invisible rest state Button secondary invisible rest state with leading icon Button secondary invisible rest state with trailing icon Button secondary invisible rest state with trailing action Button secondary invisible rest state with leading icon, trailing icon, and trailing action
hover Button secondary invisible hover state Button secondary invisible hover state with leading icon Button secondary invisible hover state with trailing icon Button secondary invisible hover state with trailing action Button secondary invisible hover state with leading icon, trailing icon, and trailing action
pressed Button secondary invisible pressed state Button secondary invisible pressed state with leading icon Button secondary invisible pressed state with trailing icon Button secondary invisible pressed state with trailing action Button secondary invisible pressed state with leading icon, trailing icon, and trailing action
focus Button secondary invisible focus state Button secondary invisible focus state with leading icon Button secondary invisible focus state with trailing icon Button secondary invisible focus state with trailing action Button secondary invisible focus state with leading icon, trailing icon, and trailing action
Button-positive
rest Button positive rest state Button positive rest state with leading icon Button positive rest state with trailing icon Button positive rest state with trailing action Button positive rest state with leading icon, trailing icon, and trailing action
hover Button positive hover state Button positive hover state with leading icon Button positive hover state with trailing icon Button positive hover state with trailing action Button positive hover state with leading icon, trailing icon, and trailing action
pressed Button positive pressed state Button positive pressed state with leading icon Button positive pressed state with trailing icon Button positive pressed state with trailing action Button positive pressed state with leading icon, trailing icon, and trailing action
focus Button positive focus state Button positive focus state with leading icon Button positive focus state with trailing icon Button positive focus state with trailing action Button positive focus state with leading icon, trailing icon, and trailing action
Button-negative
rest Button negative rest state Button negative rest state with leading icon Button negative rest state with trailing icon Button negative rest state with trailing action Button negative rest state with leading icon, trailing icon, and trailing action
hover Button negative hover state Button negative hover state with leading icon Button negative hover state with trailing icon Button negative hover state with trailing action Button negative hover state with leading icon, trailing icon, and trailing action
pressed Button negative pressed state Button negative pressed state with leading icon Button negative pressed state with trailing icon Button negative pressed state with trailing action Button negative pressed state with leading icon, trailing icon, and trailing action
focus Button negative focus state Button negative focus state with leading icon Button negative focus state with trailing icon Button negative focus state with trailing action Button negative focus state with leading icon, trailing icon, and trailing action
Button-disabled
Button disabled rest state Button disabled rest state with leading icon Button disabled rest state with trailing icon Button disabled rest state with trailing action Button disabled rest state with leading icon, trailing icon, and trailing action
Component layer structure
content
  └ content-wrapper
    ├ leading-icon
    ├ Label
    └ trailing-icon
  └ trailing-action
ButtonIcon
ButtonIcon
primary secondary primary-invisible secondary-invisible
rest ButtonIcon primary rest state ButtonIcon secondary rest state ButtonIcon primary invisible rest state ButtonIcon secondary invisible rest state
hover ButtonIcon primary hover state ButtonIcon secondary hover state ButtonIcon primary invisible hover state ButtonIcon secondary invisible hover state
pressed ButtonIcon primary pressed state ButtonIcon secondary pressed state ButtonIcon primary invisible pressed state ButtonIcon secondary invisible pressed state
focus ButtonIcon primary focus state ButtonIcon secondary focus state ButtonIcon primary invisible focus state ButtonIcon secondary invisible focus state
RadioInput
RadioInput
rest Radio input default rest state Radio input checked rest state
focus Radio input default focus state Radio input checked focus state
disabled Radio input default disabled state Radio input checked disabled state
Component layer structure
dot
focus-outline
radio
Radio
Radio
rest Radio default rest state Radio checked rest state
focus Radio default focus state Radio checked focus state
disabled Radio default disabled state Radio checked disabled state
Component layer structure
radio-wrapper
    └ RadioInput
label-wrapper
    ├ Label
    └ Caption

Proof: Riyadh Air

In 2024, FLYR had to show it was a full retail platform and not only a pricing engine. Riyadh Air wanted a booking experience that could go head to head with the best airline sites: cart, order management, seat selection, ancillaries, and payment. It had to run on a modular architecture we could reuse for other airlines, and it had to land fast enough to back a partnership announcement and a $295M funding round.

Without a shared UI foundation, a build like this runs 18 months or more. We had 12. We shipped in 6. Every booking pattern (Shopping Cart, Product Catalog, Ancillary Selector, Order Search) came straight out of existing Orville components. We didn't build a single new primitive; it was all composition.

My role

I led a small cross-functional team, a designer and two front-end engineers. We kept feature priorities tied to the pilot's business goals, held the patterns consistent across flows, and leaned on Orville instead of spinning up a client-specific mini design system.

Outcome

  • Full search → seat selection → cart → payment booking flow.
  • A strategic partnership with Riyadh Air, positioned publicly as a digital-first airline.
  • A $295M funding round where the digital experience helped tell FLYR's platform story.

Impact

Rolling out the system

We treated adoption as a product launch:

  • Regular enablement sessions and workshops with product teams.
  • Slack-based support and “office hours” for design-system questions.
  • Usage tracking across the React codebase and Figma libraries.

Core components React library adoption

Building it wasn't enough on its own. We ran workshops, answered questions in Slack, and tracked how components were actually used.

2025 101 4
Via omlet.dev
100%
Total code components
+50% since 2023
~2k
React component usage gains
+49.5% since May 2024

Figma libraries adoption

Figma adoption grew through targeted workshops and learning sessions. Components are the main piece designers shape through the contribution process, and the documentation keeps it all connected and easy to find.

2025 101 63
Via Figma stats
13
Used by teams
+8 teams since 2023
96.6%
Figma components inserts
31.2% less detaches, since 2024
Icons and Styles stats
2025 101 61
2025 101 60

What changed

  • Teams stopped building bespoke UI and started composing flows from existing Orville components.
  • New features shipped sooner, because reusable patterns replaced one-off UI.
  • The product suite ended up with one visual language that holds up across new domains and customers.

By the numbers

The system earned its own budget and a second designer, and by July 2025 every new FLYR product was built on Orville. We survey designers and engineers twice a year. Here are the latest numbers:

+1
Designer hired
4 people in total
$
Budget allocated
The team got its own budget
95.5%
Designer sentiment
+24.5% since 2024, 10 designers
87.5%
Engineer sentiment
+34.5% since 2024, 30 engineers

Lessons learned

  • Start small. Twenty well-chosen components that solve real problems beat two hundred abstract ones.
  • Get buy-in early. Leadership wants to see value fast: metrics, speed, and help closing key deals.
  • Treat adoption as a product. It only works with enablement, support, and a clear process.
  • Documentation beats perfection. A well-documented “good enough” component outperforms a perfect one nobody can use.
  • Design systems drive deals. We weren't selling “50 components.” We were selling faster delivery and wins like Riyadh Air.

In press

Travel Startup Flyr Raises $295 Million in Equity and Debt.

Bloomberg

We will be at the forefront of innovation when it comes to booking travel experiences.

Tony Douglas, CEO, Riyadh Air

Riyadh Air will be the world's first digitally native airline.

CNBC

Together, Riyadh Air and FLYR are transforming the passenger experience with shopping cart capabilities for passengers at every touch point.

Yahoo!Finance

Offer & Order: Built Right. Designed to Deliver.

FLYR

Sergey Berezyuk
Sergey Berezyuk

Thanks for reading. Questions? Challenges? Let's talk!

See more projects