AirFrame - Building a scaleable design system for 38 million passengers.
Early 2024
Me - (Senior Product Designer)
Paul (Design System Manager)
Dan (Tech Lead)
James (Developer)
Ken (Lead QA)TLDR
- Led the redesign of British Airways' design system into a system of systems approach (named AirFrame) scaling to support BA's 25+ digital products, integrating multi brand, theme and native support.
- Achieved #1 ranking in 2023 CAA airline digital accessibility audit through implementation of our design system.
- Drove a near 100% design system adoption rate across products through education, democratisation and efficiency.
A bit of background
Our design system is called BAgel, (British Airways Global Experience Language). BAgel is our main design system, currently supporting about 25 + digital products at BA. We're a team of 5 on the design system team now and we own and maintain a central library for our UI components and patterns.
BAgel was originally spun up out of a piece of work by an agency in 2019, the codebase was half built before Covid mothballed everything. At the time, many of the components were crowdsourced amongst developers from the products, and had little accessibility or QA done to them at all. I joined the team in September 2022 and over the last couple of years, BAgel has gotten pretty robust. We'd spent a great deal of time "resetting the foundations", making our codebase and Figma files fully WCAG compliant and really centralising the design language into one team, all on the back of an existing UI. Earlier in 2024, BAgel was getting to a point where we as a team knew it needed to scale. From a UI perspective but also from a building blocks perspective.
BAgel was originally spun up out of a piece of work by an agency in 2019, the codebase was half built before Covid mothballed everything. At the time, many of the components were crowdsourced amongst developers from the products, and had little accessibility or QA done to them at all. I joined the team in September 2022 and over the last couple of years, BAgel has gotten pretty robust. We'd spent a great deal of time "resetting the foundations", making our codebase and Figma files fully WCAG compliant and really centralising the design language into one team, all on the back of an existing UI. Earlier in 2024, BAgel was getting to a point where we as a team knew it needed to scale. From a UI perspective but also from a building blocks perspective.
BAgel 1.0
- A style guide
- There was a simple code library but not well adopted or maintained
- Not accessible
BAgel 2.0
- Full accessibility reset
- QA’d components
- Updated typestack and other breaking changes
BAgel 3.0 ✨
- New UI and new components
- WCAG 2.2 compliant
- Improved colour theory
- Theming
- Multi brand support
- Native app support
Creating one source of truth
We wanted to create one single source of truth for our design language. On the design side, we had a library for each previous version of BAgel and we really wanted a way to consolidate this and make it scalable going forward. We did what all designers do and got in a room and whiteboarded it out. We already had buy-in from the business and a stable white-label code foundation, what we needed now was a way to bring this scaleability into Figma and the design side. We decided to name this AirFrame.
Whiteboarding AirFrame.. (We originally called it Runway)
Our initial cover thumbnail for AirFrame
Starting with primitives
Figma had recently released modes and variables and this was the perfect opportunity to start baking these into AirFrame. We toyed with the idea of using something like TokenStudio but wanted to wait until Figma natively supported it. The code already had design tokens so we really wanted to match this current setup. As part of BAgel 3.0 we also revamped our colour theory so we started with creating primitive colours so we could start embedding these into new components.
Multi brand support
We had a dilemma where some products and features were still actively being worked on that were still reliant on previous versions of BAgel. We needed a way to support these products but also move them towards AirFrame. At the same time, we also had big ambitions for AirFrame. BA is part of the IAG group which all have individual operating companies. We wanted to build a system that could potentially support the UI's of all of these brands.
We utilised modes to segment iterations of our brands. We had an unbranded version (everything was basically grey), BAgel 2.0, BAgel 3.0 web, and BAgel 3.0 native. Each brand would have it's own set of primitives, with it's own variant of component, all tied together with variables.
We separated BAgel 3.0 native components from BAgel 3.0 web components as the details, interactions and states vary quite a bit between the platforms. Even though they share the same UI, we found it was much easier to manage them as separate brands.
We utilised modes to segment iterations of our brands. We had an unbranded version (everything was basically grey), BAgel 2.0, BAgel 3.0 web, and BAgel 3.0 native. Each brand would have it's own set of primitives, with it's own variant of component, all tied together with variables.
We separated BAgel 3.0 native components from BAgel 3.0 web components as the details, interactions and states vary quite a bit between the platforms. Even though they share the same UI, we found it was much easier to manage them as separate brands.
The AirFrame concept - with support for multi iterations of our brands
Theming under the hood
The BAgel codebase itself was also built upon theming. Every component and property is tested and QA'd against a theme. This also required creating a theme layer of variables for every part of our UI. Because everything was also underpinned by variables, switching themes also meant every part of our components would update to be fully accessible.
Making it useful for designers and teaching new ways
There's no point in creating this level of sophistication if designers don't know how to update their ways of working. We as a design system team did a bunch of education sessions across the business to help with this. On the Figma side, we also deep linked our theme variables into the styles that designers were already using.
Driving efficiencies towards a near 100% adoption rate
Adoption is probably the number one challenge that any design system has. BAgel/AirFrame as a design system was well known across the business. Through education and buy-in, the design system became part of most product OKRs and replatforming priorities. The benefits were simple and conveyed effectively across the department. A testament to the work of my team and I - Less UI debt, better consistency and a more accessible experience.Achievements 🏆
BA came first in 2023 out of a range of airlines in a CAA audit for digital accessibility. This was largely due to BAgel 2.0 and the work everyone in squads was doing to adhere to accessibility standards. Implementing pure BAgel/AirFrame components without any other changes to the experience lead to a 39% increase in barrier score* for users with accessibility needs.
* Barrier Score: Estimated chance of someone with a disability hitting a barrier in your experience they cannot pass
Things we're working on
More in depth validation is needed from a component level in the wild:
How do people interact with our components in reality?
Do they understand the interactions on them? Are people tripping up anywhere? This will come with time and testing.
We're working on ways to further track DS adoption across the business, especially in code. We know people are using the design system, but the tracking of component usage is minimal.
More resource allocation to native only components. We've done loads of work on web components, but dedicated dev and design resource is needed further to take this to the next level and help with consistency.
We're working on ways to further track DS adoption across the business, especially in code. We know people are using the design system, but the tracking of component usage is minimal.
More resource allocation to native only components. We've done loads of work on web components, but dedicated dev and design resource is needed further to take this to the next level and help with consistency.
Some UI demos
