Every time I've jumped straight into Figma, I've wasted at least half a day.
It feels productive. Screens are filling up. The file looks busy. But you're solving the wrong problem. You just don't know it yet.
At MontyCloud I'd get a user story or PRD and my instinct was to open Figma. Design the happy path. Then come to the PM with something polished. The PM would ask one question I hadn't considered and the whole thing would collapse. Back to square one.
Eventually I changed the order completely.
Now: read the PRD first. Ask two things — why are we building this? and what's the user actually trying to do? If I can't answer both clearly, I set up a call with the PM before I open any design tool. Then I write my approach in plain text. One paragraph. What I think the solution is and why. Share it. Takes ten minutes. Saves three rounds of revisions.
Only then do I open Figma.
Figma is visually satisfying. You feel like you're designing. But design isn't the screens — it's the thinking before them. The screens are just where the output lives.
Credits & further reading
- Lean UX — Jeff Gothelf & Josh Seiden. The discipline of aligning on the problem before moving to solutions — and using the simplest possible artifact at each stage — is the formal articulation of what this note describes. Their "assumption mapping" exercise is a useful structure for the pre-Figma thinking.
- Shape Up — Ryan Singer (Basecamp, free online). Basecamp's internal methodology explicitly advocates writing before wireframing. Their concept of "breadboards" (text-based interface outlines) and "fat marker sketches" is a practical system for doing the thinking before the tool takes over.
- Articulating Design Decisions — Tom Greever. His point that designers often skip the "why are we building this?" question and jump to execution is consistent with this note. The habit of translating requirements into one clear paragraph before designing is something he's described similarly in interviews.