Used in order. Used on every project. The earliest moves are the cheapest; the late ones get expensive.
The brief is the thing the rest of the work answers to. I won’t draw anything until I’ve named the user, the verb, the constraint, and the thing being traded against. Most projects that went sideways on me went sideways here — at the scope step, not at the screen step.
“What does this person need to get done by the end of this session?”
What’s being asked for is rarely what’s needed. A hospitality client said “we need a better booking flow” and what they actually needed was an admin tool — the booking flow worked fine, the operators were drowning. I treat the brief as the first hypothesis, never the deliverable.
Why? why? why? why? why?
Subtraction is design’s first move. I’d rather ship four fields than seventeen, four screens than eleven, four words than the paragraph the model wanted to write. The cuts are usually invisible to the user; they’re felt as clarity. The peer designer notices.
The hardest line of code to write is the one you delete.
Tokens, components, sections, steps — the names you choose are the names every later conversation will use. Get the names right and the system stays coherent for years. Get them wrong and you’ll be retconning prose for the rest of the project.
Bad names are the most expensive bug.
When I leave a project — and every project ends — the next designer needs to know why this is this way, not just what’s here. I write the decisions down. The Figma frame is an artifact; the brief and the rationale are the system. The frame can be redrawn; the rationale is what makes the redraw possible.
Documentation is what makes things last.
Walking away is a designer’s tool too. I’ve turned down work where the brief required hiding the truth from users, where the timeline required cutting the test, where the team didn’t have the muscle to ship what we agreed to. Saying no protects the work that does ship.
It is either a “hell yeah” or a “no”.