UX for startups: how much at which stage?

In short: UX by stage

In the early stage, the real job of UX is deciding what you won't build. A paper sketch of the right task teaches more than ten polished screens.

The table below sums up this guide. I describe each row in a section of its own.

Stage	The real question	The job of UX
Idea	Does the problem really exist?	Conversations and paper sketches.
MVP	Does our solution work?	One flow, small tests.
First customers	Why do they stop?	First session and support messages.
Growth	How do we keep the pace?	Design system and regular research.

Idea stage: listen to the problem first

At this stage you don't need to design screens. Talk to people who have the problem. Instead of explaining your product, ask how they solve the task today.

Paul Graham describes in his 2013 essay “Do Things that Don't Scale” that the first users have to be won by hand. Founders don't wait for them; they go out and find them. Those conversations are also your first UX research.

Once a solution takes shape, sketch it on paper. According to Jakob Nielsen's 2003 article on paper prototyping, usability data gathered early has ten times the impact of data gathered late. By the most common estimate in the same article, a change before the first code is 100 times cheaper.

What do you ask in the conversation?

In the conversation, don't try to get your idea confirmed; listen to what the person did in the past. Asked “Would you use an app like this?”, people easily say yes to be polite, and that answer teaches you nothing.

Ask concrete questions about the past instead:

• When did you last do this task? Can you walk me through it step by step?
• Where was it hardest? What did you do at that moment?
• What tool do you use for it today, and how much do you pay?
• Have you ever tried something to solve the problem?

Write up the notes the same day and keep the person's own words. Those words later become button text and menu names.

Testing with paper sketches

Show the paper sketch to a few people and give them a task, such as “How would you pay your invoice here?”. Note where they tap and where they hesitate.

The paper sketch comes before the wireframe, mockup and prototype stages and is cheaper than all of them. The logo and detailed screens can wait, because neither answers the question “Does the problem really exist?”.

MVP: one flow, small tests

The answer to “Where does MVP design start?” is the product's one core flow. That flow is the task the user opens the product for. A profile screen or notification settings can wait.

Eric Ries defines the MVP in his 2009 piece as the version that lets you collect the maximum amount of validated learning about customers with the least effort. According to Ries, MVP doesn't mean building a small product. The goal is learning. I explain the term itself on the glossary page for MVP.

Ries also warns that learning from the first version often takes effort. You have to set aside real time for talking to customers or for the numbers. So releasing the MVP and waiting isn't enough.

Test the flow before launch. According to Nielsen's 2000 article, five users find about 85% of the usability problems in a design.

Instead of one big test, Nielsen recommends as many small tests as the budget allows. You fix the problems and see in the next test whether the fix works. How many people to test with, and when, is in the guide how many users to test with.

Example: invoicing app for small businesses

Say you're building an invoicing app for contractors and freelancers. You have lots of features in mind: expenses, inventory, reports, bank connections. They all seem sensible.

To find the core flow, ask one question: why does the user open the app? The answer: to send their client an invoice.

The MVP makes that flow work from start to finish. The user picks the client, enters the line items and sends the invoice. Everything else goes on the list for version two.

In the test, give five people the task “Send your client an invoice for yesterday's work”. See how many finish and where they hesitate. If even one person gets stuck on the sales tax line, fix that before the reports.

In the visual design, start with a ready-made UI library. Drawing your own component set is a waste of time at this stage. Don't test the button's colour; test its position.

First customers: find out why they stop

The product is live and you have a few customers. Now the question is: why do some users stop? Look for the answer in the first session first.

Count the steps a new user goes through from sign-up to first value. At which step do most hesitate? Onboarding screens and empty states are the real work of this stage.

Collect support messages in a list and group them by screen. If three different customers complain about the same screen, there is very likely a design problem there. One of the first places to look in that list is the error messages.

Graham tells in the same essay how Wufoo sent each new user a hand-written thank-you note. One advantage of being small, according to him, is being able to offer service no big company can.

Set up the product together with a few customers over screen share yourself, too. That way you see with your own eyes where they hesitate.

At this stage, pick a single number to watch. For example: how many of those who signed up sent their first invoice? Compare that number before and after each change.

Keep changes small. If you change five things at once, you can't tell which one worked.

If your product is SaaS, time to value is a topic of its own. I cover it in the guide to SaaS UX.

Growth: put what repeats into a system

As the team grows, the same button gets drawn differently on different screens. At that point a design system solves a real problem. A system built earlier usually solves a problem that doesn't exist yet.

At this stage put research in the calendar too. For example, talk to a few users every month and have an expert review done at intervals. Founders can no longer talk to every customer; you need a routine that collects the knowledge.

Also make accessibility part of the process at this stage. Accessibility added afterwards means reopening finished screens. I describe the core criteria in the WCAG guide.

In a growing team, keep a decision log too: why was a screen designed this way, what came out of which test? That way newcomers don't ask the same question again. And when you change an old decision, you know what you might break.

What comes first in your situation?

Even at the same stage, the make-up of the team shifts the priorities. A team with a designer starts differently from a team of two founders. Pick your situation below.

Pick your stage

The list below is for a founders-only team at the MVP stage. The text covers the other stages in sections of their own.

MVP · Founders only

These three tasks first

1. Pick the product's one core flow. In the first version only that flow works end to end.
2. Test that flow with five people before launch. Fix the place where they get stuck most often.
3. Start with a ready-made UI library or a template. Don't draw your own components.

Can wait

• Settings and profile screens
• Dark mode
• Animations
• A full design system

Pick a stage and a team. The list shows the three UX tasks that come first in that situation, and what can wait for now. It isn't a rule; it's my suggestion for getting started.

What you can do yourself

Most UX tasks in the early stage don't need a designer but the founders' time and attention. You can do these yourself:

• Talk to people who have the problem and write up the notes the same day.
• Sketch the solution on paper and show it to a few people with a task.
• Run small tests with five people. Ask them to think aloud, and only watch.
• Go through your own product screen by screen against Nielsen's 10 heuristics.
• Group support messages by screen.
• Rewrite button and error text in the users' words.

How do you run a test with five people?

1. Find five people from your product's target group. Not friends, or they'll be too nice.
2. Give each a single realistic task. Share your screen or hand them the phone.
3. Ask them to think aloud. Don't help; only take notes.
4. After five sessions, pick the two problems that came up most often and fix them.
5. Try again next week with the same task.

A session can take about half an hour. If you record, ask the person explicitly for permission.

In 2009 Nielsen divided “discount usability” into three parts: simple think-aloud tests, paper prototypes that support a single path, and a review against heuristics. His motto works for founders too: “Bad user testing beats no user testing.”

If you want to build your own list, the UX audit checklist is a good start.

When is outside help worth it?

Outside help is worth it when there is a task you can't do yourself or don't have time for. If nobody uses the product yet, have the conversations before you spend money. Then, in my opinion, the honest answer to “Do I need outside help?” is “Not yet.”

An outside view helps with these signs:

• You know users stop in a flow, but you can't find the reason.
• The team is so used to the product that it no longer sees where newcomers get stuck.
• Before a funding round or a meeting with a big customer, the product's first impression matters.
• You have a developer, but it's unclear who designs the screens.

My offers follow these signs. If the problem is known but the reason isn't, start with the UX Audit ($79, one flow, delivered within 48 hours). If it's clear what needs fixing, the Design & Ship Sprint brings design and code into your repo: $999 for one week or $1,949 for two. If you booked an audit within the last 30 days, the audit fee comes off the sprint price.

If you want the MVP built from scratch, the fixed-price project may fit better. You describe what you have in mind, and within 24 hours you get one price and a delivery date. Which model suits you I compare in the guide design subscription or fixed price.

Common UX mistakes founders make

Polishing the first version. Dark mode and animations are done, but nobody has tested the core flow. Polish only makes a wrong flow more expensive.

Building the design system too early. A component library for a product with three screens freezes decisions that are still going to change.

Making the test a big event. Instead of one study with 15 users, Nielsen recommends three studies with five each. Fix things after every round.

Copying a competitor's screen. Another product's flow is built for its users and its business model. Show it to your own users before you copy.

Taking yourself for the user. Founders know the product best. That's exactly why they find it hardest to see where new users get stuck.

My note

The sentence “We need a nice interface” is a weak starting point for a startup. Usually the real need is different: to see what users experience in the first ten minutes.

That's why my first question is: when did you last talk to the five people who most recently used your product? If the answer is “never”, I recommend the conversations before the design.

Take an afternoon before you pay a designer. Let five people use your product and stay quiet. The notes you bring me then are also the most valuable input for an audit.