You don't need a designer's eye to judge a design system

At some point a design system lands in front of someone who has to say yes to it and can’t assess it onc raft. It might be an engineering lead deciding whether the team builds on it, a Head of Product who inherited one from a previous hire, or a founder approving the invoice. What they get shown is usually the file: tidy pages of components, a colour palette, a set of rules. It looks finished. The trouble is that a system a whole team builds on every day and a system nobody has opened in a year look the same in a file.

The natural response, I’d guess, is to defer to whoever built it, on the grounds that judging a design system takes a designer’s eye. I think that’s the wrong instrument. If you lead engineering you already know how to judge something like this, because you wouldn’t judge an internal library by how clean its README is. You’d ask whether its interface is clear, whether a new hire can use it without the author sitting next to them, and whether anybody imports it by choice. A design system answers to the same three questions, and none of them needs taste.

Can someone who wasn’t in the room check a rule?

Pick one rule from the system’s documentation and one screen from the live product. Then try to decide whether the screen follows the rule, alone, without asking anyone.

Some rules allow that. “No colour outside these six” can be checked by anybody with the screen open. So can “every number shows its source”. A rule like “the interface should feel premium” can’t, because there is nothing to hold the screen against. The answer ends up depending on who happens to be in the meeting and how senior they are.

At Mistaek we call a rule that passes a Standing Decision. I’d go through the documentation and count how many there are. Every rule that fails still needs a person to interpret it each time it comes up, and that person turns into a queue.

Where does a new person take their questions?

Ask someone who didn’t build the system to make one ordinary screen with it, a results table with a filter, say, and keep a list of every question they ask on the way.

The length of the list matters less than where the questions go. If the documentation answers them, the reasoning was written down and the system can outlive the people who made it. If they all go to one colleague, the system lives in that colleague’s head and the file is a picture of it. Colleagues go on holiday, change teams and leave, and the answers go with them.

My guess is that most documentation does better on what was decided than on why. The what is sitting in the file, and the why was said out loud in a meeting some months ago. The why is exactly what a newcomer is asking for.

Does anyone use it who wasn’t told to?

A mandate can make a people open a system. It can’t tell you whether the system is any good, so I’d look for use that nobody ordered.

The strongest evidence I’ve seen was a foundation that the team I was in had built for its own work. It had been tested across several countries and it was flexible enough to carry far more than it was carrying. Another team adopted it without anyone instructing them to.

In a company of thirty there may be no second team, so the question gets smaller. When a developer builds a screen that no designer is going to review, do they reach for the system’s component or write their own? And where people do go around it, is that recorded anywhere, with a name and a reason? Going around a system is sometimes the right call. What I’d want to know is whether somebody decided it or whether it just happened.

What the three questions can’t tell you

They can’t tell you whether the system is beautiful or whether it suits your company, and they prevent nothing. A team under deadline can ignore a rule that is easy to check as readily as a vague one. What you gain is that ignoring it becomes a choice somebody made, on the record, where before it would have dissolved into the product without anyone noticing.

I should also say what this is. It comes from design systems I’ve built and worked inside at large, regulated companies, and from there on it’s reasoning. I can’t show you a number for what a system that fails these questions costs, and I’d distrust anyone who could.

If you run the three on your own product and aren’t sure what the answers mean, that’s what the discovery call is for. It’s free, and I’ll tell you honestly whether a program makes sense for where you are.