the brief nobody writes

every designer i know is working from a brief that exists only in their head.

not the official one — the client-sent PDF, the kick-off deck, the scope doc. that brief is written. i mean the one that actually drove the decisions: the version of the problem the designer believed was real. the assumptions they made about the user. the things they decided to optimise for because something felt important even though nobody asked them to.

that brief is usually more accurate than the official one. it’s the result of actually thinking about the problem. but it almost never gets written down.

and that’s fine, until you need feedback.

the moment someone else looks at your work, the internal brief becomes load-bearing. they’re evaluating what they see against some standard — “does this work?” — but they don’t know what “work” means in your terms. they don’t know what you decided the problem was. they don’t know what you traded off or why.

so they substitute their own brief. they think about what they would have done, or what they think users generally need, or what looks clean. and they give you feedback against that invisible standard instead of yours.

most feedback sessions are two people talking about different briefs without realising it.

i’ve started asking, before any crit session, “what were you trying to solve?” not “walk me through your work” — that starts at the output. i want to start at the decision.

often the answer surprises me. the design will show one thing and the designer will describe a problem that’s subtly different. they’re not wrong — they just translated the brief in a direction they never said out loud. and when i understand the translation, the work reads differently. things that looked like gaps become intentional constraints. things that looked bold become defensive.

the feedback i can give after understanding the internal brief is different in kind from the feedback i could give without it. it’s not “i’d do it differently” — it’s “does this actually resolve what you said you were resolving?”

that’s a harder question. it’s also the one worth asking.

the fix is boring: write the brief yourself before the crit. two paragraphs. what’s the problem as you understand it, what did you decide to optimise for, what did you deliberately not try to solve. you don’t have to share it — sometimes just writing it surfaces the gap yourself.

but if you do share it, the conversation changes. the reviewer isn’t guessing anymore. they can engage with your reasoning, not just your output.

and if the reasoning is wrong — if the brief you wrote isn’t actually the problem the work needs to solve — you want to find that out in a feedback session, not in production.

if your work is in that state — you know what you were trying to do, you’re not sure if it lands — i offer structured design critique. i’ll read what you were solving and tell you whether the design resolves it. $75.