We worked with United Airlines from late 2017 – early 2020 through our friends at Big Medium to help them get their Atmos design system stood up. Two years later, it’s interesting to see how the design system has rolled out to their flagship website, among other digital properties.

(Note: though we were intimately familiar with the initial design system work, we haven’t had much interaction with the teams there since—other than remaining casual SuperFriends with each other via the socials—so this is very much an outsider’s perspective.)

Here’s the current version of the United Airlines homepage as it stands today (April 7, 2022):

Here’s the current version of the United Airlines homepage, broken down by what is an Atmos design system component (highlighted in neon green) and what is not (highlighted in pink).

Fascinating! As a reminder, this isn’t based on any insider knowledge of any back-end code or logic. This is purely an analysis of front-end HTML. You can perform the same assessment yourself by inspecting the HTML of this page and looking for any class that starts with atm-, the design system “namespace” that we used for all Atmos components.

Here are all the different kinds of components that live together on one page:

• Components that come straight out of the design system
• Components that are custom built for this page or a specific feature on this page
• Components that are forked or duplicated versions of what also lives in the design system
• Components that started here where an abstracted version eventually ended up in the design system
• Components from the design system whose styles are being augmented and/or overwritten
• Design system components nested inside of non-design system containers
• Custom components nested inside of design system containers

What variety! And that’s ok! This is the reality of enterprise product design at scale. It reflects the nature of parallel roadmaps, design system team resourcing and bandwidth, business priorities, and many more factors.

Design systems aren’t all or nothing

Some organizations seem to hold up the ideal that, once a design system exists, everything in an interface can and should be built with it. Not only is that an unrealistic goal for most enterprises, but it can often be a toxic mindset that anything less than 100% coverage is misuse of a design system at best or utter failure at worst.

We often use the Pareto principle—often known as the “80/20 rule”—to set an actionable target for teams: aim for up to 80% of any given page to be made of design system components and leave room for 20% of the page to be custom. That remaining 20% is where the invention and innovation can happen. One of our recent clients added some anecdotal and complementary motivation to this: they reported that they spent only 20% of their sprint time creating 80% of their pages with the design system, which then freed up 80% of the sprint time to work on the 20% of custom functionality that really made the experience sing. This is exactly the kind of efficiency that design systems should enable!

One nuance to add to this 80/20 rule for page makeup is that 80% is the maximum target. It’s not the starting point. So what’s a good starting target for design system coverage on a page?

We used to suggest 10% as a starting point, with a plan to work up to 80% eventually, likely over the course of a year or two. Coincidentally, the United Airlines homepage shows this in action. Of 8 major sections of the page—admittedly a tad oversimplified for the purposes of this example—1 major section (12.5%) is powered by the design system.

But even 10% is too ambitious sometimes. So we’ve started to tell our design system team clients that they should start by trying to get 1 component adopted by a few feature teams simultaneously. It seems trivial, but there’s actually a mountain of work that goes into implementing one component—especially the first component—into a codebase that will eventually make its way to production. The effort from 0 adopted components to 1 is the steepest, and there’s a long tail of decreasing effort from there.

And, for teams where even 1 component is too much to take on, get anything adopted is a good first step. We often suggest a plain neon green box, like a <div> with a width, height, and background color. At first, teams think we’re joking. But we’re not! Once the hurdle of getting something from one codebase imported into another is crossed, it’s easier to revise and iterate into more, better, and higher quality components than it is to try and create a perfect one the first time around.

So, don’t worry if you aren’t creating everything with your design system! Be kind to yourself, your colleagues, and your teams. Feel free to start with just one component, or even just one neon green box. If you can make that happen, it’s all downhill from there!

Join 57,400+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!