What Screens Should You Design Before MVP Development?

Founders usually start MVP design with a features list, not a screens list. That’s the first place scope quietly gets away from you. Features describe what the product does; screens describe what someone actually sees and taps through — and a development team can’t build from a features list alone. They need a concrete inventory of screens, states, and what belongs on each one.

This is not about scoping the product or picking your one core user journey — that decision should already be made. This is the next, more concrete step: once you know the journey, what specific screens does it require before a developer can start building without guessing?

Start From the Journey, Not the Feature List

Every screen you design should trace back to a single question: does this screen sit on the path a user takes to get value from the product, or does it support that path by handling a state the path will inevitably hit? If a screen answers “no” to both, it’s very likely something you can defer.

A simple booking MVP, for example, has a core journey of: browse availability → select a time → enter details → confirm. That’s four core screens. Everything else — login, empty calendar, a failed booking, a success message — exists to make those four screens work reliably in the real world, not to extend the journey itself.

The Core Screen Inventory

Below is a practical grouping of the screen types that show up in almost every MVP, regardless of industry. Not every category applies to every product, but treat this as the checklist to run your own screen list against before development starts.

Category	Screen type	Why it’s needed before coding
Entry	Landing / home screen	First impression and the doorway into the core flow
Entry	Onboarding (if any)	Sets expectations before the user reaches real functionality
Auth	Sign up	Only if account creation is required before core value
Auth	Log in	Needed wherever returning users must be identified
Auth	Password reset	Prevents a support ticket from becoming your first user complaint
Core flow	Each step of the primary journey	This is the product — the reason the MVP exists
Core flow	Review / summary step	Lets users confirm before an irreversible action
Supporting state	Empty state	Shown before a user has any data to display
Supporting state	Loading state	Shown during any request that isn’t instant
Supporting state	Error state	Shown when a request or input fails
Closing	Confirmation / success screen	Confirms the action worked and tells the user what happens next
Admin (if relevant)	Minimal internal view	Only if someone must manually manage requests during early operation

Entry Screens

The entry screen is where someone decides whether to keep going. For an MVP, resist the urge to over-design this — a clear headline, a clear next action, and enough context to explain what the product does is usually sufficient. If your MVP requires onboarding to make sense of an unfamiliar workflow, design that as its own short screen or two, separate from the entry screen itself.

Authentication Screens — Only If Actually Needed

A common way MVP scope grows unnecessarily is designing full authentication flows before checking whether they’re required on day one. If someone can experience the product’s core value without an account — browsing a catalog, trying a calculator, viewing sample results — delay sign-up until the point where it’s actually earned, such as right before checkout or saving progress. When auth is required, the minimum set is sign up, log in, and password reset; anything beyond that (social login, multi-factor authentication, invite flows) is worth scoping separately once you know the primary flow will need it.

Core Flow Screens

These are the screens the entire MVP exists to deliver. Map them directly from your one core user journey — one screen per meaningful step, not per possible feature. A booking flow might need four screens; a content-submission flow might need two. Where a step involves an irreversible action (a payment, a submission that can’t be edited later), add a review or summary screen immediately before it so users can catch mistakes before committing.

The States People Forget: Empty, Loading, Error

This is the category most founders skip in early wireframes, and it’s exactly where development teams end up improvising product decisions on their own. Three states deserve explicit design before coding starts:

• Empty states — what a new user sees before they’ve created any data. A blank screen with no explanation reads as broken, not as “nothing here yet.” At minimum, explain what will appear and how to create the first item.
• Loading states — anything that takes more than roughly a second needs a visible loading indicator, or users will assume the action failed and try again, sometimes duplicating a submission.
• Error states — design for the two or three most likely failures in your core flow (a failed submission, an invalid input, a lost connection), not every conceivable error. A generic fallback error screen can absorb rarer cases until you have real usage data to prioritize from.

Confirmation and Success Screens

Every core flow needs a screen that closes the loop — confirms the action succeeded and tells the user what happens next. Skipping this is a small thing that creates outsized confusion: users who don’t see clear confirmation often assume the action failed and repeat it, or simply abandon the product without trusting that it worked.

Minimal Admin Views, If Your MVP Needs Them

If your MVP depends on someone manually reviewing, approving, or fulfilling requests behind the scenes — common in marketplaces, booking tools, and B2B products — that internal view is part of the MVP’s screen list too, even if it’s a simple table with a few actions. It doesn’t need the same design polish as the customer-facing flow, but it can’t be left undesigned; otherwise developers will build it ad hoc, often inconsistently with how the rest of the product works. For a deeper look at scoping that internal view, see how to design an MVP wireframe before building.

A Quick Self-Check Before You Move to Development

Run your own screen list against these questions:

• Does every screen trace back to the core journey or to a required supporting state?
• Have you designed at least one empty, loading, and error state for the core flow?
• Is there a confirmation screen for every action that can’t be undone?
• Have you deferred authentication screens you don’t actually need on day one?
• Would removing any given screen still let the MVP prove its central assumption?

If you’re still unsure how many total screens that adds up to, how many screens your MVP needs for one user journey walks through counting them directly from a mapped flow. And if empty, loading, and error states still feel abstract, planning MVP design for empty, loading, and error states goes deeper into designing each one well.

Why This Inventory Matters Before Development Starts

A development team working from a vague brief will make dozens of small product decisions on your behalf — what an empty dashboard says, whether a failed submission shows an error or just does nothing, what “success” looks like after checkout. Some of those guesses will be wrong, and by the time you notice, they’re already built. A concrete screen inventory, reviewed before a single line of code is written, is one of the cheapest ways to prevent that kind of rework. Atlassian’s guide to product requirements makes a similar point about specificity — vague requirements shift decisions downstream, where they’re far more expensive to fix.

This doesn’t mean designing every screen to pixel-perfect polish. It means naming every screen your core journey and its supporting states require, so nothing gets invented on the fly during a sprint. Once your list matches the categories above, you have enough to hand to a development team with confidence — not a finished design system, but a complete map of what needs to exist.

Frequently Asked Questions

What screens does a minimal MVP actually need?

At minimum: an entry point, the core flow screens that deliver the product's main value, any required auth screens, at least one empty state, a loading state for anything that takes more than a second, an error state for the most likely failure, and a confirmation screen that closes the loop. Everything past that is a judgment call based on your specific journey.

Do I need to design login and signup screens for every MVP?

No. If people can get value before creating an account, delay authentication screens until they're actually needed — for example, right before checkout or saving progress. Designing auth screens you don't need yet is a common way MVP scope quietly grows.

What's the difference between an empty state and an error state?

An empty state appears when there's legitimately nothing to show yet, like a new user's dashboard before they've created anything — it should explain what belongs there and how to add it. An error state appears when something went wrong, like a failed request or invalid input — it should explain what happened and what the user can do next. Treating them as the same screen usually confuses users in both situations.

Should I design every possible error message before development starts?

No. Design the error states for the two or three most likely failures in your core flow — a failed submission, a validation error, a lost connection. Rare edge cases can be handled with a generic fallback error screen and refined after launch based on what actually happens.

How do I know if I'm designing too many screens for an MVP?

If a screen doesn't sit on the core journey and isn't one of the supporting states (empty, loading, error, confirmation) needed to make that journey trustworthy, it's a candidate to cut or defer. A useful test is asking whether the MVP would still prove its core assumption without that screen.