Sometimes you should try to build the thing instead of writing about the thing. While I’m a staunch believer that writing is a super power (especially for remote teams), it can make small problems seem bigger than they actually are. Knowing when to reach for a brief can be difficult to pin down.
When should you write a brief or just build?
If it’s obvious and small (days not weeks), skip the brief and build it. You don’t want to make more work for yourself.
If you have an idea of what to do but are not feeling clear about how important it is, write a short brief. It’s okay to write in order to justify your idea—in fact, writing to convince others can be clarifying (and sometimes convinces you it’s not important after all).
If you catch yourself thinking of a solution disguised as a problem. Write a brief to get to the bottom of what’s actually going on.
If it’s a technical problem, taking the first few steps to build it and then write a brief. It might be necessary to try to make a prototype just to know the shape of the problem so you can write about it. Code can be very if you can write software fast and it might turn out to be not that hard at all.
If you have a vague understanding of a problem, write the intro of a brief to quickly identify what you don’t know.
(Tips for writing a brief is covered in how to write for remote teams).
Links to this note
-
Solution Disguised as a Problem
There is a tendency to write a problem statement as the problem you want to solve (i.e. the solution). For example, “We give users no guidance on X” is unlikely to be the problem statement rather than “users are confused”. The former is a solution disguising as a problem and the latter is actually the problem which may have many other solutions.
-
SCQA stands for the *s*ituation, *c*omplication, *q*uestion, and *a*nswer. It’s a way of writing an introduction in a way that clearly communicates the key question a piece of writing will answer.