Write-first design

Most design teams decide things in Figma, exploring and refining a direction until it becomes the plan without anyone agreeing to it.

We work the other way round: the decision gets written down before anyone opens a design file. Writing is the first design tool, and 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.

Writing "we believe this change will improve clarity, because users currently misread the loading state" makes every part of the decision open to challenge. Someone can question the belief or the evidence for it while the direction 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, while one 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.

A doc is written once and read by everyone who has to act on it, so the time you spend making it shorter is multiplied across the team. As the Blaise Pascal line goes, if I had more time I would have written a shorter letter (yep, he said it first, in French). The first draft helps you work out what you mean; the edit makes it easier for everyone else to follow.

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. The doc states the goal, explains why the work matters now and defines success in terms specific enough to test against later. Its most important line is the hypothesis, which 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 where the real decision gets made. It lays out the background and research findings, makes a proposal, then does the thing I care about most: it lists what is different about the design and puts the reason next to each change.

Write more than "we removed the container". Explain that it pulled attention without improving the action people took and that removing it frees space for richer content later. We pair every visual change with the reason it exists, and cut changes we can’t explain clearly enough.

Only then do we build. By the time code gets written, the difficult thinking is recorded and the experiment can test a hypothesis we wrote weeks earlier. We still validate it against real behaviour and roll it out gradually; writing the argument clearly doesn’t mean it will 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. 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, but what stops a sharp comment reading as a cold one and offers 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 and a doc before the build are the same machinery a good PM uses, and I won’t pretend otherwise.

The difference is who holds the pen. This isn’t a spec handed down for a designer to make pretty, then passed to an engineer to make real. The person writing the hypothesis also designs the screen and writes the code, so there’s no handoff for the original reasoning to get lost in. For us, writing 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, and the discipline is in the order: decide in words, where being wrong costs an afternoon, then 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.