Where to Start When You're Starting From Scratch

A founder asked me what I'd do first on a brand-new product. This is the actual answer — five steps, the order they go in, and what breaks when you skip one.

A founder asked me this directly a few weeks ago. Non-designer, technical, staring at a product that existed as a pitch deck and a domain name: "What would your approach be, to start from scratch on this project?"

It is the most reasonable question anyone can ask a designer, and I think we mostly answer it badly. We either retreat into vagueness — "well, it depends on the problem space" — or we skip ahead to the part we enjoy, which is usually screens. Both answers are useless to the person asking, because what they actually want is a sequence. They want to know what happens in week one, what happens in week two, and why that order and not some other one.

So here is the sequence I gave, written out properly. Five steps. The order matters more than any individual step, and I'll be specific about what breaks when you get it wrong — including the way I've gotten it wrong myself, which is at the end and is the part I'd read first.

1. Define the project — before you open any tool

Not a brief. A definition.

What I want on paper before anything else: what type of users we have, what exactly we're targeting, the high-level flow, and a handful of real scenarios and use cases. Concrete ones. Not "a homeowner wants to manage their project" but "a homeowner who has never done this before, on a phone, in the evening, trying to find out whether the thing they want to build needs approval at all."

The reason this comes first is not diligence theatre. It is that every later decision is downstream of it, and if you leave it implicit, you will make those decisions anyway — just silently, and inconsistently, and three weeks apart from each other.

What breaks if you skip it: you get a product that is a pile of features rather than a path through a problem. You also lose the ability to say no, because "should we add this?" has no answer without a definition to check it against. Teams that skip this step don't notice the cost for about a month, and then spend the following month in circular discussions that are all secretly the same discussion.

The output is small. A page, maybe two. Users, targets, the flow at the altitude of eight or ten boxes, and the scenarios. If it's longer than that you're writing a spec, which is a different document for a later day.

2. Map information architecture and navigation — for the product you'll have, not the one you're building

This is the step people are most tempted to defer, and deferring it is the most expensive mistake on the list.

From experience it is always worth investing the time up front to think about how navigation will scale — how new blocks get added, where a second user type would live, what happens when today's single list becomes tomorrow's three sections. Not because you should build all of that now. Because the structure you pick now silently decides whether adding it later is an afternoon or a rewrite.

Navigation is not a menu. It is the shape of the product's thinking, made visible. When someone lands in a section, the surrounding structure is telling them what kind of place they're in and what they're allowed to do there. Get it wrong and every screen inside it has to work harder to compensate.

What breaks if you skip it: you will need to remake it down the road, and "down the road" always arrives at the least convenient moment — usually right when you have real users whose habits you'd now be breaking. Retrofitting IA is one of the few design tasks that gets strictly harder with time, because the cost isn't the design work, it's the migration and the relearning you're imposing on people.

Sketch it flat. Boxes and nesting. Then ask one question: if we doubled the scope of this product, where would the new things go? If the honest answer is "I'd have to redo the nav," redo the nav now, while it's free.

3. Define entities and actors — the model underneath the screens

This is the step that most reliably separates people who've done this a few times from people who haven't, and it's the one I'd add if I could only add one thing to how most teams start.

Write down what entities exist and how they relate to each other. A project, a document, a submission, an organisation, a review — whatever the nouns of your domain are. Then the relationships: one-to-many, who owns what, what can exist without what.

And then the people. Here I want to be pedantic about a word, because the pedantry is load-bearing: it's not only personas, it's actors.

A persona is a portrait — demographics, goals, frustrations, a stock photo, a pull-quote. Useful for empathy, mostly decorative for structure. An actor is a role in the system: something that can take actions, hold permissions, own records, and be acted upon. One human being can be several actors. A contractor might be an applicant on one file, a collaborator on another, and an approver on a third. If you modelled that person as a single persona you would never see it. If you modelled them as actors, your permissions model falls out almost for free.

What breaks if you skip it: you discover the data model by accident, through screens, one contradiction at a time. Someone designs a detail page that implies a relationship the backend can't express. Someone else designs a list that assumes single ownership. Both look fine in isolation. Neither can ship. And the conversation that resolves it happens in engineering, in a ticket, weeks later, without you.

This is also the artefact that makes you legible to engineers. A designer who arrives with an entity diagram is having a different conversation than one who arrives with screens.

4. Build a minimal design system — a kit, not a cathedral

Now, and only now, I'd start on the design system. And I want to be precise about the size of the thing I mean, because "design system" has become a word that makes people picture six months of work.

I mean tokens. Spacing, colour, type, radius, elevation. A small set of primitives, named by purpose rather than appearance. Then the handful of components you cannot avoid: button, input, select, checkbox, card, whatever your product's actual atoms are. Three button sizes, not nine.

I'm not talking about a fully fleshed-out system. It is a design kit — the minimum shared vocabulary that lets everything built after it be consistent by default rather than consistent by vigilance.

Two things I'd argue for specifically:

Name tokens semantically, not literally. Not "grey-600" but the role it plays. The difference sounds cosmetic and isn't: semantic names make design decisions arguable. If a token is called "border-subtle," someone can say "that shouldn't be subtle here, this is a destructive action" and now you're having a design conversation. If it's called "grey-300," the only available conversation is about grey. Naming determines which disagreements are even sayable.

Keep the variant count brutally low. This used to be an aesthetic preference and is now close to a technical constraint. When a generative tool reads your library to produce new work, an overloaded file floods its context and the output gets measurably worse. Every speculative variant you leave lying around is a small tax on everything generated afterwards. Restraint in the kit is no longer just good taste; it's throughput.

What breaks if you skip it: you don't actually skip it. You build it anyway, implicitly, one hardcoded value at a time, distributed across forty screens, and then pay to extract it later under deadline. The only real choice is whether it's deliberate.

5. Prototype the key flows — in parallel, not after

The instinct is to treat this as step five in a strict queue: finish the foundation, then prototype. I don't think that's right, and I'd push back on my own list here.

Prototype the main flows while the tokens are being defined. Quickly, roughly, in whatever medium is fastest for you. The point is to see whether the thing makes sense as an experience before you've invested in making it consistent.

The two tracks feed each other. The flow tells you which components you actually need, which kills the urge to build a component library speculatively. The tokens tell the flow what it's allowed to look like. Run them serially and you'll build components nobody needs and discover missing ones late.

There's a deeper version of this that I've come to believe: with generative tooling in the loop, the design tool has quietly changed jobs. It stopped being where I draw screens and became where I set context — structure, spacing, tokens, components, all defined precisely so that what gets generated afterwards is consistent. The screens themselves increasingly get made and refined somewhere closer to the real thing. That reallocation is a large part of why steps two through four are worth their cost: they're not preparation for the design work anymore, they are the design work.

The caveat, which is the part I'd actually read first

Everything above is a defensible order. It is also, on a short runway, a trap — and I say that having walked into it.

Here is the failure mode. The sequence is technically correct, so you follow it. You spend the early weeks on definition, structure, model, and tokens. All of it real, all of it compounding, none of it visible. Meanwhile the people paying for the work are watching for the thing they named in the brief. They asked for a dashboard. Four weeks in, there is an excellent foundation and no dashboard.

Foundation work compounds quietly. Stakeholder trust does not compound at all — it depletes on a schedule, and it depletes fastest when nothing legible has appeared.

So the amendment I'd now make to my own list: ship something in their words in week one. If the brief says dashboard, week one produces a dashboard, however thin, however wrong. Build the substrate underneath it, in parallel, as a by-product of that named deliverable — never as a precursor to it.

This isn't a compromise of the method. It's a correction to how I was sequencing it. Steps one through four don't require a month of silence; they require a few days of thought and then a decision to let the visible thing pull them forward. The foundation gets built either way. The difference is whether anyone watching believes it's being built.

The version of this advice I'd give now is the same five steps, with one instruction stapled to the front: do them behind something they can see.

If you take one thing: the order is definition → structure → model → kit → flows, and the flows overlap the kit. But the order is a private discipline, not a delivery plan. What you show should always be the thing they asked for.