Why I Write 130-Requirement PRDs Before Touching Figma

Most designers I know start with a Figma file. Open a frame, pick some colors, start pushing rectangles around. And look — that works. Until it doesn't.

I start with a PRD. Not a fluffy "product brief" or a Notion page with three bullet points. A real, numbered, MoSCoW-prioritized requirements document with TypeScript interfaces, ASCII wireframes, error states, and acceptance criteria checklists. 130+ requirements is my baseline, not my ceiling.

The Problem With Designing First

When you jump into Figma before defining what the product actually needs to do, you're making architecture decisions with your visual cortex. You're choosing layouts before you know what data flows through them. You're picking animations before you know what states exist.

The result? Beautiful screens that fall apart the moment a developer asks "what happens when the API returns an error?"

Every redesign, every "wait, we didn't think about this," every sprint that goes sideways — most of them trace back to a missing requirement, not a missing mockup.

What a Real PRD Looks Like

My PRDs follow a specific format: every requirement gets a unique ID, a MoSCoW priority (Must / Should / Could / Won't), and clear acceptance criteria. I include ASCII wireframes — not because they're pretty, but because they force you to think about information hierarchy without getting seduced by visual polish.

I define TypeScript interfaces before I design a single component. If I know the shape of the data, I know the shape of the UI. Everything else is styling.

A PRD isn't a bureaucratic artifact. It's a decision log. Every line is a choice you made before the pressure hit.

The Build Order That Follows

Once the PRD is locked, everything cascades: Types and state first. Then the layout shell. Then Must-Have features, working from inputs to processors to outputs. Integration. Polish. Error hardening. QA against the acceptance criteria you already wrote.

No guessing. No "I think the client wanted..." conversations. No redesigns.

Why This Matters for You

If you're hiring a designer or building a product, ask one question: "Show me your PRD." If they don't have one, they're improvising. Sometimes improvisation works. But when you're shipping something real — with users, with money on the line, with a deadline — you want the person who did the thinking before they opened the design tool.

That's what I do. The PRD is the product. Everything after it is execution.