How Much UI/UX Design Does a Startup Need Before Development Begins?
A decision matrix for how much UI/UX design to finish before the build, based on your riskiest unknown and delivery model, plus a ready-to-build checklist.
The short answer
Design enough to remove your riskiest unknown and to let developers estimate without guessing. For most MVPs that means the core user flows designed and tested, every state of those flows defined (including empty, error and loading), real content for key screens, a small component baseline and basic accessibility notes. It rarely means a polished, high-fidelity file for every screen. How far to go depends on two things: what you are least sure about, and how your build will be delivered.
A fixed-scope agency quote needs more detail up front, because anything left undefined becomes a change request later. An in-house team that ships every week can design further ahead by only a sprint or two. A no-code build sits in between: the platform constrains what you can design, so detailed custom visuals are often wasted. The matrix below puts those two factors together.
If you are still deciding what the MVP should include at all, start with prioritising MVP features; this guide assumes you know roughly what you are building.
Key takeaway
Under-designing shows up as rework, change requests and inconsistent screens. Over-designing shows up as polished screens for features that change after the first user test. Aim for the point where the riskiest question is answered and the estimate stops moving.
Step 1: name your riskiest unknown
The UK Government's Service Manual describes its alpha phase as building things "just complex enough to let you test different ideas" and calls identifying and testing "your riskiest assumptions" a crucial part of it. That is a good rule for startups too. Most early product risk falls into one of three types:
- Desirability: do people want this enough to change what they do today? Design work here is about testing concepts and value, not polish.
- Usability: can people work out how to use it and complete the key tasks? Design work here is about flows, interaction and testing with users.
- Feasibility: can it be built, integrated or run reliably at a sensible cost? The first work is technical, and design follows what the spike shows.
Step 2: read the decision matrix
Find the row for your riskiest unknown and the column for your delivery model. Each cell gives the recommended design depth before the build starts. "Low fidelity" and "high fidelity" follow NN/g's definition below.
| Riskiest unknown | Fixed-scope agency build | Iterative in-house team | No-code build |
|---|---|---|---|
| Desirability | Do not commission the full build yet. Test concepts with low-fidelity sketches, a landing page or a concierge version. Once demand is shown, specify the core flows to the ready-to-build standard before getting quotes. | Low-fidelity concepts and quick tests first. Then design only the first release's core flows at medium fidelity and let the team ship and measure. | Often the best route: build a rough working version on the platform and test it with real users. Keep design to flow sketches and content. |
| Usability | Highest design depth before build. Core flows as a tested, high-fidelity, interactive prototype, with all states, real content and a component baseline. This is what makes a fixed quote reliable. | Core flows tested as a clickable prototype (medium to high fidelity), then design one or two sprints ahead of development. Secondary screens can be designed during the build. | Test the flow in a prototype, then check it can be built with the platform's components before committing. Avoid custom interactions the tool cannot reproduce. |
| Feasibility | Pay for a technical spike or discovery first. Keep design at wireframe level until the spike confirms the approach, then specify fully before the fixed-scope build. | Run the spike in parallel with low-fidelity flows. Raise fidelity only for screens whose design depends on what the spike shows. | Check platform limits (data, integrations, performance) before designing anything detailed. If the tool cannot do it, the design does not matter. |
Pro tip
If two risks feel equal, deal with desirability first. A usable, buildable product that nobody wants is the most expensive outcome.
What "fidelity" means, and why it is not one setting
NN/g's Kara Pernice defines a prototype's fidelity as how closely it matches the look and feel of the final system, and notes that it can vary separately in three dimensions: interactivity, visuals, and content and commands. A prototype can have realistic copy and working navigation but plain grey boxes for visuals. For most startup questions, that mix is more useful than pixel-perfect screens.
The same article lists benefits of low-fidelity prototypes: less time preparing and more time designing before a test, easier changes between sessions, less pressure on participants, and less attachment from designers to work that should be thrown away. Stakeholders also recognise that the work is not finished. High fidelity earns its cost when you are testing detailed interactions, specific components or visual qualities such as legibility, or when participants need to behave as they would with live software.
For the definitions of wireframes, mockups and prototypes, see wireframing vs prototyping. This article is about how much of each you need before code.
How many users to test with before you build
The most quoted guidance is Jakob Nielsen's 2000 NN/g article, which recommends "testing no more than 5 users and running as many small tests as you can afford". It is often misquoted, so the caveats matter: For running the test itself, see how to test a website prototype before development.
- The claim that five users find about 85% of usability problems comes from a model that assumes each user finds, on average, 31% of the problems. It is an average across projects, not a guarantee for yours.
- It only holds "for comparable users who will be using the site in fairly similar ways". With two distinct user groups, NN/g suggests three or four users from each; with three or more groups, three from each.
- Finding all the problems takes at least 15 users, but NN/g recommends spending that on three rounds of five, fixing problems between rounds, rather than one round of 15.
- It applies to qualitative testing only. Nielsen's 2012 follow-up says quantitative studies need at least 20 users, and more for tight confidence intervals.
The ready-to-build checklist
Use this before you ask for a build quote or start the first sprint. If an item is missing, either complete it or record it as an explicit assumption in the estimate. It works as a shared definition of "done" for design, and it overlaps with what a good design handoff includes.
- Core flows mapped end to end: every step a user takes to get the main value, including sign-up and the first successful use.
- Core flows tested with target users at the fidelity the matrix suggests, with findings fixed or logged.
- Every state of each core screen: default, empty (no data yet), loading, error, success, partial data, permission denied and offline where relevant.
- Real content: actual headings, labels, button text, error messages and sample data, not lorem ipsum. Long names and missing data are shown.
- Responsive behaviour decided: which breakpoints or device sizes are supported and how key screens adapt.
- A component baseline: named buttons, inputs, type styles, colours and spacing, each with hover, focus, disabled and error states.
- Accessibility annotations: colour contrast checked, focus order and keyboard behaviour noted, touch target sizes, form labels and error messaging, and alt text for meaningful images.
- Analytics events named: the actions you will measure (for example sign-up completed or first booking made), agreed with whoever builds the tracking.
- Open questions logged with an owner, so developers know what is undecided rather than guessing.
What can safely be designed during the build
Not everything has to be finished first. Work can move into the build when it follows established patterns, does not affect the data model and will not change the estimate much.
| Usually safe to design during the build | Should be settled before the build |
|---|---|
| Settings, profile and account management screens that follow common patterns | Core flows and anything that decides the data model |
| Visual polish: illustrations, motion, final imagery | States of core screens, especially errors and empty states |
| Secondary content pages and help text | Payment, sign-up and permission flows |
| Admin and internal views, if a basic version is agreed | Integrations users see, such as third-party sign-in or maps |
| Additional components beyond the baseline | The component baseline itself |
| Later-release features behind the MVP | Anything a fixed-scope contract will be priced on |
Hypothetical example: one MVP specified at three depths
Hypothetical example: a startup plans a 12-screen web app for small clinics to manage appointment requests. The riskiest unknown is usability, because receptionists must triage requests quickly between phone calls.
Depth A, wireframes only. The developer can see the screens and navigation but must guess what happens when a request has missing details, when the list is empty, or when a save fails. A fixed-scope quote either pads for those unknowns or excludes them, and both lead to arguments later.
Depth B, tested core flows plus the checklist. The three core flows (receiving, triaging and confirming a request) are tested with five receptionists, then specified at high fidelity with every state, real copy and a component baseline. The other nine screens are wireframed with notes. A developer can estimate the core confidently and flag the rest as following standard patterns.
Depth C, every screen at high fidelity before build. Estimates are tight, but weeks go into polishing settings and reporting screens that the first round of clinic feedback is likely to change.
For a usability-led product on a fixed-scope build, Depth B is the sensible choice. If the same team were in-house and shipping weekly, it could start building after the core flows were tested and design the remaining screens a sprint ahead.
Common mistakes, and when this advice does not fit
The common mistakes are predictable: designing every screen at high fidelity before any user has seen the concept; handing over happy-path screens with no error, empty or loading states; using placeholder text, so layouts break with real content; skipping the component baseline, so each screen invents its own buttons; and treating a design system as an MVP requirement. Design systems for fast-moving teams explains when a fuller system starts to pay off.
This guidance assumes a typical early-stage product. It fits less well in a few cases. Regulated products (health, finance, public services) may need fuller specification and accessibility review up front for compliance reasons. Hardware-dependent or highly technical products should lead with feasibility work, as the matrix suggests. And if you are rebuilding an existing product with known users and proven flows, you can often specify more fully before the build because the desirability question is already answered.
Conclusion and next steps
The right amount of design before development is the amount that answers your riskiest question and lets a developer estimate without guessing. Name the risk, find your cell in the matrix, test the core flows with a small number of users per group, and work through the ready-to-build checklist. Leave secondary screens and polish for the build.
For the full sequence from research to launch, see the product design process. If you want help shaping the design scope for a first release, our UI/UX design service page explains how we approach MVP design.
Planning the design for an MVP?
ZSpace Labs is a remote-first technology studio that works with clients globally on UI/UX design and web application development. If useful, we can review your current designs against the ready-to-build checklist or talk through how much design your build needs.
Sources
NN/g: UX prototypes, low fidelity vs high fidelity (Kara Pernice, 18 December 2016); NN/g: why you only need to test with 5 users (Jakob Nielsen, 18 March 2000); NN/g: how many test users in a usability study? (Jakob Nielsen, 3 June 2012); GOV.UK Service Manual: how the alpha phase works (last updated 8 May 2019).
Accessed 14 October 2026. NN/g is an independent research and training firm; its figures are heuristics based on its own studies.
Common questions.
They can build structure from wireframes, but they will have to guess at visual details, copy, states such as errors and empty screens, and behaviour on different screen sizes. That is workable for an in-house team that can ask questions daily. For a fixed-price quote, guesses become change requests, so the flows and states need to be specified more fully.