Design System Coverage

How much of a page should be made up of design system components?

By Dan Mall — 11 April 2022 at 10:19:00 am

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):

The United Airlines homepage

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).

The United Airlines homepage, broken down by design system component

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:

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!