On writing as a design tool

Before I open Figma, I usually write. Not docs, not specs — just thinking. A paragraph that tries to explain the problem forces clarity that mockups can’t.

The problem with jumping to visuals

Visuals are seductive. You can produce something that looks like a solution before you’ve understood the problem. This is one of the most common failure modes in product design — beautiful screens built on unclear thinking.

Writing is harder to fake. A sentence has to mean something. If you can’t write a clear problem statement, you probably don’t have one.

What writing forces

Writing forces linearity. You have to decide what comes first, what follows, what depends on what. This constraint is useful — it surfaces hidden assumptions and logical gaps that a canvas of components can paper over.

It also forces specificity. “The user feels confused” is a visual thought. “The user doesn’t know whether their action succeeded because the feedback appears below the fold” is a written thought. The second one suggests a solution. The first one doesn’t.

The format that works for me

I write a short paragraph before starting any significant design problem. Not a brief or a spec — just a description of the problem from the user’s perspective, and what resolution looks like.

It usually takes ten minutes. And it almost always changes what I build.

Writing as a communication tool

The output isn’t just for me. A short piece of writing that frames a design decision is far more persuasive in a review than the design alone. It shows the reasoning, not just the result.

When someone disagrees with a design choice, they’re often disagreeing with an unstated assumption. Making the assumption explicit — in writing — gives the conversation somewhere to go.