UX Case study
A design system is only living if it is used as code
This one is a position more than a project. Four goes at the same thing, at four companies, between 2017 and 2020, and one difference decided which of them was still in use after I left: whether the library was compiled into the product or filed as a document to be consulted. The method barely changed across the four. What follows is how the last of them was built, and what the earlier ones taught me by stopping short.
Sample of Floorplanner's design system. A text field can have multiple variants depending on its state.
Problem
Nobody decides to build four different buttons
Design in a company of any size is decentralised, and it is decentralised for good reasons: a designer sits with a team, learns that team's problem, and ships against that team's roadmap. The cost arrives later and somewhere else. Put two of those teams' screens side by side and the differences are immediate, and none of them was ever chosen.
They run at every scale. At the small end it is a font style that is one step off, or a shade of grey that exists because somebody sampled it from a screenshot. At the large end it is a whole flow that did not need to exist, built because the team that needed it had no way of knowing another team had already solved it.
What makes this hard to fix is that it is not a quality problem. Every one of those screens was made carefully by somebody competent. The inconsistency is a side effect of the structure, so the fix has to be structural too, and a document telling designers to be consistent is not a structure. It is a request.
So the thing to build is not a style guide. It is a place where designers and the front end developers who are inclined to care about design can codify a language together, and a route by which what they agree lands in the product without anyone retyping it.
Goals
What a system has to do to be worth the sprint
I have never fully hit all three of these, and I will say that before saying anything else. They are the bar, and how far short an attempt fell is the most useful thing about it.
Team & audience
One sprint in four, and no product owner
The arrangement that has worked best for me is a borrowed team rather than a standing one. One designer and one front end developer from each product team, meeting on a fixed schedule, and on the last attempt that schedule was one sprint in every four.
The gap is doing real work there. Three sprints of ordinary product delivery is how the team finds out what the library is actually missing, so the fourth arrives with a queue somebody has already felt the need for rather than a list of improvements imagined in a room.
It was six people: four front end developers, one from each team, and two designers. We ran a kanban board and we had no product owner, which is less a boast than an explanation of the next paragraph.
Without one, the ticket writing fell to me. Most of it was small and specific, one component's states or one component's naming. Occasionally it was not: bringing every colour and type token up to W3C contrast guidance was one ticket in the sense that it had one title.
Every component variant carries the name it will be called by in code, which makes design match the implementation.
Audience
Who actually opens it
Worth separating the two, because a system built for the wrong one of them fails in a way that is hard to see. The beneficiary is the customer. The users are four groups inside the building, and if any of them cannot get what they need out of it, that group starts keeping its own version.
Scope and constraints
What did not need an experiment
Almost none of this work was tested, and that was the correct call rather than a corner cut. Two kinds of change made up nearly all of it, and neither is the kind of question an experiment can answer.
The first is removing a variation nobody chose. If a product has three greys where two teams each invented one and nobody can say what the third is for, collapsing them is not a hypothesis. There is no version of the result that argues for keeping an accident.
The second is applying guidance that already exists and is better evidenced than anything we could run ourselves. Contrast ratios are the clearest case: W3C has done the work, at a sample size no single company reaches, and rerunning it locally to see whether our users also prefer being able to read things would be theatre.
When a change genuinely was a question, it left this team. It went down to the product team that owned that surface, where there was a product owner to prioritise it and a data scientist to design the test, which is also the only place the traffic to answer it lived. A design system team running its own experiments is a design system team competing with the roadmap it depends on.
Process
Six steps, and the first three are politics
The order matters more than the contents. Three of these six happen before a single component is drawn, and skipping them is how a design system becomes a folder somebody made once.
Mapping what is already there
An inventory before a proposal. Colours, text fields, font families, toggles, sliders, popups, buttons, split buttons, galleries, and every variation of each that the product turned out to contain.
The list is not the deliverable. The deliverable is the visual version of the list, because a count of thirteen button styles is a number somebody can dispute and thirteen buttons laid out across three slides is not. This is the artefact that makes the next step possible, and it is worth the days it takes.
The catalogue turned out to be its own best exhibit, which I only found rebuilding this page from it. The primary button is in there three times in three different blues: #3979F5 on the buttons slide, #0074F8 in the header, #4476FB in the dialogues. The gap between the first and the last is sixty-eight points of red. Nobody picked three. Sampled off the deck's own slides, five years after it was made.
Form
13Buttons
13Display
9Containers
8Images
5
Menus
3Navigation
3Overlays
2- #3979F5Buttons slide, Search
- #0074F8Header section, Search
- #4476FBDialog, Back to form
One primary button, three blues, no decision. This is the inventory arguing its own case.
Buying the time
With the inventory in hand, a lead developer and I put a presentation in front of the people who sign off on where sprints go. The audience picked itself. The people who had been complaining that the product does not look like itself in different places were the ones who would make this real, because they had already noticed the problem and had no name for it.
That is the whole trick of this step, and it is not a trick. Nobody funds a design system as an abstraction. They fund it once they have seen the thirteen buttons, at which point the argument is no longer that consistency is good in principle.
The deck itself is ten slides and hardly any of it is about buttons. It asks what the problems are and answers with the plain ones: features ship slowly, nobody is sure which components already exist or how to use them, small bugs in components never get fixed, accessibility is missing across the application. Then it spends two slides on consistency, efficiency, scale and quality, and one on what to avoid, which was getting rigid enough that the library starts deciding what can be designed. Read on its own it is the case that could be made at any company, and that is what it is for. The specific case was the board above. The deck is the general one you write down afterwards so that there is something to approve.
Composing the team from every team
One designer and one developer out of each product team, rather than the two or three people most enthusiastic about design systems. The enthusiasm is easier to find and produces a worse result.
A team drawn from everywhere has a representative in every room where the library will later be either used or ignored. That is what turns adoption from a rollout into something that has already happened, and it is the difference between a library the company uses and a library its authors use.
Four product teams, and the six people who put their strengths together: four front-end developers and two UX designers.
Choosing tools, mostly by not choosing
On the design side this came down to two decisions: what to draw in, and where to publish. At Maersk in 2019, InVision was already licensed and widely used. At Findhotel a year later it was Zeplin. Both companies had Sketch seats. In each case the answer was the tool already in the building, and going the other way would have spent the project's early credibility on a migration nobody had asked for.
On the development side there was a real requirement rather than an inherited one: as much of the path from a published component to a usable component as possible had to be automatic, because every manual step in that path is a place where the two copies start to differ.
Zeplin The source of truth both sides looked at. Everything below is arranged around keeping this one honest. 
Sketch Where the components were drawn, and the seat both companies had already paid for. 
Figma The online alternative, and in 2020 the challenger. It is the default now, and Sketch is the one that gets argued for. 
Storybook The other end of the same shelf. A component that exists here exists in the product. 
Chromatic What made a pull request something a designer could review, by turning a diff into a picture. Drawing components, and agreeing what one is
Divided among the designers, one component at a time, and the unit of work is the component in all of its states rather than the component. A field is not finished when it looks right empty.
Two designers dividing that work will produce two incompatible halves unless somebody writes down what finished means, so I did. Nine conditions, and a component met all nine or it did not go on the shelf.
- Flexible to resizing
- Using the official list of font styles and families
- Using the official list of colours
- Fitting exactly within the 8px grid, or the 4px one
- Carrying a mobile and a desktop version, where that applies
- Exposing the fewest editing permissions that still make it useful
- Properly named, including every sublayer
- Tested on a canvas for resizing and for permissions
- Published to the official platform
Four of them are worth seeing rather than reading, because each is a rule about a shape.
Publishing, which is where the argument is settled
This is the step my earlier attempts got wrong, and getting it wrong does not look like failure at the time. With InVision I published to designers. Designers used it. The results were fine and the products drifted anyway, because a design silo and a development silo produce the same drift as no system at all, one handover later.
Design becomes code eventually or it does not ship. So the last attempt went straight at the developers instead: components mapped one to one between the design side and the build side, each with a URL indexed in a file the front end could read.
Below is one component, the star rating, in the three places it exists. It is the same object in all three, and that is the entire argument of this page reduced to something checkable.
What shipped
Pages that came out of the shelf
None of these is a design I would put forward as a piece of work on its own. They are here as the other kind of evidence: pages assembled almost entirely out of parts somebody else could also have used.
In the order the systems happened, which for the first four is the order of the marks under the header. Two of those have screens here, one has a slot held for it, and Coolblue in 2017 has nothing left that I can show. The fifth is later than everything else on this page, and what it can show is a different kind of thing.
Floorplanner, 2018
The earliest one with anything left to show, and a different kind of product: a drawing tool rather than a funnel. The two marketing pages at the end are the interesting ones, because a marketing page assembled from the product's own components is the case where the guide reached past the product it was built for.
Maersk, 2019
The middle one, and the gap in this page. Maersk is named three times above this line, and again in the conclusion, where it is one half of the counter-example the whole argument turns on. Until something of it is shown here, that half rests on my word. The slot is held rather than quietly left out.
Material being selected
Findhotel, 2020
The whole funnel, on both devices. The mobile captures are full page exports and one of them is twelve times as tall as it is wide, so what is shown here is the top of each; opening one gives the page whole.
Zimmer Biomet, 2021
This one sits outside the run above. A surgical planner, built over eighteen months, and the only medical product of the five.
The screens first. Then the parts they are made of, which is what this page is about: most of the dialogues in this product are one component with different content inside it. Change the component once and every dialogue changes with it.
The parts. The first four are the same dialogue with something different in the middle. The next two were kept out of it on purpose, and deciding what is not one component is the same job as deciding what is. The last two are components as they appear in the product, with the button that opens them.
Conclusion
One of the four was still compiling when I left
By the time I left Findhotel it was a live library, imported by every product in the portfolio rather than referred to by them. What has become of it since, I have no way of knowing.
Bringing every token up to W3C contrast guidance changed every product at once, which is a thing a document cannot do at any speed.
Atoms listed in the published library, counted off the sidebar of the star rating screenshot in step six, where the list runs off the bottom of the screen.
Nobody measured what any of this did to how fast things got built. That gap is the last thing this page has to say, at the bottom of it.
The contrast with two of the earlier three is the reason this page exists. At Coolblue in 2017 and at Maersk in 2019 what I built was aimed at designers, with little developer involvement, and both were left at the mercy of whoever was sitting in a given team: it was that designer's job to reach for the components, to keep them current, and to apply them properly. That is too much to hang on one person's diligence, and it is not a criticism of any of the designers involved. A system whose enforcement mechanism is somebody remembering is a system that degrades on the first busy sprint.
The same six steps since
Everything above stops in 2020, which is when it was written. The method did not stop there. It has been used twice more since, in two fields with little in common with a booking funnel, or with each other.
Most of it carried over. The inventory still comes before the proposal, and publishing is still the step that decides whether the library gets used. What changes is how much a mistake costs. Where that cost is high, the nine rules get stricter rather than different.
Zimmer Biomet, 2021
A surgical planner, eighteen months, one designer on the product.
Step three did not happen. There was no designer and developer from every product team, because there was one designer and one product owner. So the library was used because the person who drew it was also the person using it. That is a much smaller test than the four projects above gave the method, and I would not read more into it than that.
The other steps ran as before. The tools were the ones already in use, Figma and Zeplin. Components were still drawn one at a time, in every state, and a component still was not finished when it only looked right empty.
What the medical setting added was a second level. Tokens first, then components built from those tokens. The reason is the paperwork. Every change to this product needed four things on the record: what success meant, the risk to the patient, what else the change touched, and evidence that it worked. When a change costs that much to write up, changing one token is far cheaper than changing forty components. That is the whole argument for the second level.
So the ninth rule grows. Publishing used to be where a component was finished. Here it is where its paperwork starts. The other eight are unchanged.
Whether two levels is the right answer for the next one, I do not know yet. It is the answer this project needed.
TrackBee
The second of the two, and the current one. The same slot as Maersk further up, held for the same reason and on the same terms.
Material being selected
Lessons
There is a fourth and it is the uncomfortable one. Nothing here has a number attached to it. I can show that the library was built, that it was imported, that dozens of components were standardised and duplicates removed, and I cannot tell you what any of it did to delivery speed, because nobody instrumented it and I did not push hard enough for somebody to.
The cost of that is not academic. Every design system I have worked on has had to be argued for again, from the beginning, in front of people who were entitled to ask what the last one returned. An answer to that question is the single most valuable artefact this work could have produced, and it is the one artefact I do not have. If I were starting the next one on Monday, the measurement would go in the first sprint, not the eventual one.