Most design teams decide things in Figma. A direction gets explored and refined, and somewhere in that process it quietly becomes the plan. Nobody agreed to it. It simply accumulated.

We work the other way round. The decision gets written down before anyone opens a design file. Writing is the first design tool. The pixels come later.

I think of this as; write-first, build later. It runs through the whole design process, and it changes what design feels like to do.

Why writing comes first

A mockup is a persuasive object. It looks resolved even when the thinking underneath it is not. You can spend a week on a screen and never once state what problem it solves.

A paragraph cannot hide. Write "we believe this change will improve clarity, because users currently misread the loading state", and every part of that sentence is now arguable. Someone can challenge the belief, or the evidence for it. That is the point. You want the argument exposed while it is still cheap to change.

Writing also separates the decision from the craft. A reviewer can disagree with a direction without anyone having burned days in Figma first. The conversation happens at the level of intent, not execution. That keeps people honest, and it keeps egos out of it, because there is no beautiful artefact to defend yet.

Writing is durable too. A decision made in a meeting has evaporated by Friday. A decision made in a doc has a permanent, searchable home. Six months later, when someone asks why the answer card lost its border, the reasoning is right there. At DuckDuckGo we lean async by default, so this counts for more than it might elsewhere. Most review happens in comments, on people’s own time, not in a room.

The economics are simple. A doc is written once and read many times, by everyone who has to act on it. The time you spend making it shorter is not really your time. It is multiplied across every reader, and it compounds across a team. If I had more time, I would have written a shorter letter, as the Blaise Pascal line goes (yep, he said it first, in French). The first draft is for you. The edit is for them.

The shape of it

The process produces a sequence of written artefacts. Each one is a checkpoint where we decide whether to keep going. Design threads through all of them.

It starts with a discovery doc, written before any design exists. It does two things first. It states the goal, and it explains why the work matters now. Then it defines what success looks like, in terms specific enough to test against later. The most important line is the hypothesis, and it follows a fixed shape. We believe [change] will produce [outcome] because [reason]. If you cannot write that sentence, you do not understand the problem well enough to design for it. Better to learn that on day one than in week three.

Then comes the design peer review. You write a short summary of what you are exploring, link the file, and hand it to other designers and an engineer. The file is the input. The decisions happen in the written thread.

Here is a real example, anonymised. A designer shared early templates for an AI answer feature and asked whether to design desktop only, to save effort. The reply argued for mobile first. The reasoning was written out plainly. Mobile is the harder layout constraint to get right, and designing desktop-first tends to leave the mobile version underdone. On top of that, mobile is the majority of the traffic. The scope of the entire piece of work changed inside a comment box. No meeting. The argument that won was the one written down most clearly.

After the design firms up, but still before the production build, comes the direction doc. This is the heaviest writing in the process, and it is where the real decision gets made. It lays out the background and the research findings, then makes a proposal. Then it does the thing I care about most. It lists what is different about the design, and puts the reason next to each change.

Not "we removed the container". Instead: we removed the container, because it pulled attention without improving the action users actually took, and because it frees up space for richer content later. Every visual change is paired with the reason it exists. A simple rule falls out of this. If a change has no written reason, it gets cut. A design decision you cannot explain in a sentence is not a decision, it is a preference wearing a decision’s clothes.

Only then do we build. By the time code gets written, the hard thinking is done and recorded. The build is execution against a documented plan. The experiment that follows is a test of a hypothesis that was written weeks earlier. We validate with real behaviour, rolled out gradually, because a written argument earns you the right to test. It does not earn you the right to be correct.

The process closes with writing as well. A mid-mortem partway through catches drift before it becomes expensive. A postmortem at the end records what actually happened against what we predicted. That is how the next discovery doc starts further along than the last one did. The learning compounds, because it is written down rather than remembered.

Short, and sweet

Write-first only works if the writing is worth reading. A doc nobody finishes decides nothing.

So the craft is brevity, and brevity is harder than length. Cut the draft to its essence, then check you have not made it curt. A line of context or thanks is not padding. It is what stops a sharp comment reading as a cold one, and it is cheap insurance against being misread.

Prioritise inside the doc as well. If several points are competing in your head and one of them carries the decision, lead with that one. Putting them all at equal weight makes them look equally important, and the discussion drifts to the smallest. You can raise the rest later. Often you find you never needed to.

Sometimes the strongest move is not to write at all. Before you add a comment, ask whether it earns the attention of everyone who will read it. Updates usually do, because they let people question the direction. Replies to replies often do not, especially the fast ones. Give a heated thread five minutes before you add to it.

Stop me if this sounds like product management

Hypotheses, success criteria, written proposals, a doc before the build. It is the same machinery a good PM uses, and I won’t pretend otherwise.

The difference is who holds the pen. This is not a spec handed down for a designer to make pretty, then passed to an engineer to make real. The person writing the hypothesis is the person who designs the screen and writes the code. No handoff, so no translation loss. Writing is not a discipline that sits upstream of design. It is the first move of design.

Why this matters more for design engineers

If you only design, write-first stops you polishing the wrong thing. If you only build, it stops you implementing a direction nobody examined.

If you do both, which is the job, it protects you from the most seductive failure mode there is. You fall in love with an implementation. You build a lovely interaction, then quietly reverse-engineer a justification for shipping it, because the alternative is binning work you enjoyed making. Write-first breaks that loop. You commit to the reasoning in prose before you commit to it in code, so the code ends up serving the decision instead of becoming it.

There is a quieter payoff. Writing the argument first makes you a better builder, because you reach implementation already knowing what the thing is for. You waste less. You cut features sooner, because you can see they were never in the doc to begin with.

None of this is about producing documents for their own sake. The docs are short. The discipline is in the order. Decide in words, where being wrong costs an afternoon. Build in code, where being wrong costs a sprint. The cheapest place to be wrong is a paragraph. So that is where we do most of our being wrong.