Design systems are a staffing decision

Every few months someone sends us a screenshot of a design system we made two or three years ago. Sometimes it is to show us how far it has come. More often it is a component we would not recognise: a fourth button style, a second set of greys, a card that quietly ignores the spacing scale. The library itself is usually fine. What went missing was a person. We have handed over eleven systems since 2018, to product teams as small as three and as large as thirty. The ones still in good shape have one thing in common, and it is not the quality of the components. Somebody’s job description says they look after it.

The handover starts in week one

We used to treat ownership as a launch task: a training session, a documentation site, a cheerful email. By then it is too late. So now, in the first week of any product project, we ask the client to name the person who will own the system after we leave, and we put their name in the brief we both sign. If nobody can be named, that is our first finding, and we scope the project differently. The owner does not have to be senior. At Corso it was a mid-level designer, Clara Ventura, who joined our Thursday reviews from week three and drew her first components inside the system in week eight. By the time we left she had made more of the library than any of us had, which is exactly how it should be.

Size the system to the team

The right size for a system is the one the team can maintain at the speed the product changes. That sounds obvious, and it is the rule we break most often, because the temptation is to hand over everything we built.

• A team of three, usually one designer and two engineers: twenty to thirty components, tokens for colour, type and spacing, and no separate documentation site. The design file and the code repository are the documentation.
• A team of ten: a part-time owner, roughly a day a week, and a monthly review where new components are accepted or sent back. Forty to sixty components.
• A team of thirty or more: a full-time owner, usually a designer who can read code, and an engineer who shares the role. Without both, design and code drift apart within a quarter.

Corso sat between the second and third. Five more cities were planned within a year, each with its own engineers, so we built 64 components and one set of tokens shared by the design files and the code. Kinro was smaller and moving faster, and its in-house team took on 38 components and a rule that anything new waits a fortnight before it joins the library.

A design system without an owner is a snapshot of how the product looked on the day we left.

Write the job description with them

We now draft the owner’s role with the client’s head of product before handover. It is usually half a page: how many hours a week, who can approve a new component, what happens when a product team needs something the system does not have, and who decides when an old pattern is retired. The last one matters most. Systems rarely die from what is added. They die from what is never taken out. We also ask for the time to be protected in writing. A designer who looks after the system “when there is time” will never have time, because the roadmap always wins. At Corso the owner role was four days a month, booked into each quarter’s plan like any feature, and reviewed at the same meeting.

What the client gets back

Min-ji Park, Corso’s head of brand, told us they launched three cities on the system without needing to call anyone. That is the best review a design system can get, and very little of it was about the components. It was about one person who knew where everything was, and had the authority to say no. If you are commissioning a design system, budget for the person as carefully as the library. The library is the easy part: we can build it in twelve weeks. Keeping it true is a job, and it should be somebody’s.