Mia Ward on building a design system people want to use

Introduction

Mia Ward joined DrumKit in 2021 as its fourth designer. Today she leads a design team of eleven across our Collingwood and Surry Hills studios, and she owns the thing our customers touch most without noticing: DrumKit’s own design system, the library every button, menu and dialog in the editor is drawn from.

I sat down with her on a wet Thursday in Collingwood, between a component review and a call with a customer in Berlin, to talk about what it takes to build a system people choose to use, rather than one they are told to use.

Every change to the library ships to our own editor first. If a new menu breaks keyboard focus, our engineers find out before a customer does, and they are not shy about saying so. “We are the harshest users we have,” Mia says. “That’s the point. If a component survives our own product for a month, I trust it in yours.”

It also changes how the team argues. A proposal for a new component starts with a screen in the editor that needs it, never with a sketch of the component on its own. “Components invented in a vacuum are the ones nobody places,” she says. “The unused ones in our reports were almost always designed first and justified later.”

Those reports are blunt. Each component shows how many files place it, how many detach it and which properties people override. A high detach rate is the loudest signal the team gets: it means the component almost fits, and people are fixing it by hand.

Tokens, names and the word no

Mia’s rule that every token has a reason started as a joke on a sticky note and ended up in the contribution guide. A token can only be added if it names a decision, such as the colour of a destructive action, rather than a value, such as a particular red. “Values change. Decisions mostly don’t,” she says. “When we rebuilt dark mode, the decisions stayed put and only the values moved. That’s the whole trick.”

Naming gets the same care. Components are named for what they are, variants for the choice a designer makes, and the names in the design panel match the names in code letter for letter. Johnny Bell, who builds the editor’s canvas, keeps a list of every mismatch he finds. It gets shorter every month.

Saying no is the hardest part of the job, and Mia is candid about it. Most requests are reasonable on their own; together they would turn a small library into a large one that nobody can learn. So every request gets an answer within a week, with a reason, and a no usually comes with a way to build the thing from parts that already exist.

Where she would start today

I asked what she would do if she were starting a system from scratch tomorrow, at a company with one product and a handful of designers. She didn’t hesitate.

1. Start with the ten components your product uses most, and make those excellent before you add an eleventh.
2. Write down why each token exists, in one sentence, right next to the token.
3. Publish usage numbers where everyone can see them, and treat a detached component as a bug report.

The rest, she says, is patience. A system earns trust slowly: one component that behaves the same way in every file, then another, until people stop checking. “Adoption isn’t a launch,” she says. “It’s a thousand small moments where the library was the easiest way to do the right thing.”

It shows. Nine in ten frames in our own product files now place components straight from the library, up from about half when she joined, and the design team spends its Fridays on new work instead of reconciling old files.