MVP design: what is minimum viable product design?

We're Usarion, and we design and build MVPs for founders. Two of the products we've shipped are our own, Moodly and Sociarion, and both are live with real users. So this guide mixes what the well-known sources say with what we've learned shipping our own first versions and designing products for clients. Where a point comes from someone else, we link to them.

What a minimum viable product actually is

The term was coined in 2001 by Frank Robinson and made popular by Steve Blank and Eric Ries, according to Wikipedia's article on the minimum viable product. Ries's definition, as Delve quotes it, reads: the MVP is the version of a new product that lets a team learn the most about its customers for the least effort. The Interaction Design Foundation quotes his rule of thumb for building one: remove any feature, process or effort that doesn't contribute directly to the learning you seek.

That last part matters more than the word "product". An MVP is an experiment with a question attached. If you can't say what you'll learn from it, you're building a small product, not an MVP.

The three words each do a job:

• Minimum: the smallest scope that can answer your question.
• Viable: people can actually use it to get the job done, without you standing behind them.
• Product: it's something real people use, not a slide or a survey about a hypothetical.

Where design fits in an MVP

It's tempting to treat design as the part you add once the idea is proven. The problem is that a confusing first version doesn't tell you whether the idea is good. It tells you people got lost. Nielsen Norman Group put it plainly in its MVP definition: without enough usability, "an MVP test becomes a test of the interface, not of the idea."

So the design job in an MVP isn't polish. It's three things:

• Decide what's in. Design is where the roadmap gets cut down to the one flow that answers your question, because that's where every screen has to be justified.
• Make the core task obvious. Someone who's never heard of you should get from the first screen to the result without help.
• Make the test readable. If people drop off, you want to know whether it was the idea or step three of the signup form.

Henrik Kniberg's skateboard drawing is a good picture of this. In his 2016 post on making sense of MVP, a customer who ordered a car gets a front wheel first, which is no use to him, while a skateboard, rough as it is, already gets him from A to B. He also suggests swapping "MVP" for three clearer names: the Earliest Testable Product, the Earliest Usable Product and the Earliest Lovable Product. We like that framing because it makes you say which one you're designing.

MVP, prototype, proof of concept or beta?

People often mix up an MVP and a prototype, and the difference changes what you design. Here's how we tell them apart:

Maze makes the same point in its MVP UX guide: an MVP isn't the same thing as a beta, which has its features built and is mostly hunting bugs. The practical upshot is that a prototype is usually a step inside MVP design, not a substitute for the MVP.

The kinds of MVP, and the design each one needs

An MVP doesn't have to be an app. Some of the best-known ones were barely software at all.

• Fake door: a button or link for something that doesn't exist yet, which counts who clicks. UserTesting's guide describes Buffer putting a "plans and pricing" button on its landing page before it had any paid plans, to see whether people wanted them.
• Landing page: a page that describes the product and asks people to sign up, with traffic sent to it. The design work is the message and one clear call to action.
• Concierge: you do the service by hand for a few customers. The Interaction Design Foundation suggests testing a service by performing it for someone and measuring what they'd pay.
• Wizard of Oz: it looks automated, but a person does the work behind the scenes. Nielsen Norman Group lists it as a prototype format for seeing how people react to complex or intelligent systems before they're built.
• Single-feature product: real software that does one job well. This is what people usually picture when they say MVP, and it needs the most design.

Zappos is the classic manual example. UserTesting tells the story of its founder, Nick Swinmurn, photographing shoes in local stores and putting the pictures online, then buying the shoes only when someone ordered. It wasn't a fancy website, just pictures of shoes online, but it showed the idea had potential before anyone built the logistics.

Pick the format by the question. If you don't yet know whether anyone wants the thing, a fake door or landing page answers that for very little. If you already know they want it and the question is whether they'll use your version every week, you need a single-feature product, and you need it designed properly.

The MVP design process, step by step

Most MVP design guides, Tenet's and Maze's among them, follow a similar order. Here's the order we use, with notes on where it tends to go wrong.

1. Write the problem and the one task

Start with a sentence: who has the problem, what they're trying to do, and what changes for them when they can. Then pick the single action that proves the product works, such as "sends the first invoice" or "approves a draft". Nielsen Norman Group suggests writing the hypothesis with the signal you'll look for, so you know in advance what "it worked" means. Its template is a good starting point: "We believe that [value proposition] is valuable to [audience]. We will know this is true when we observe [behavioral signal] during testing." For an invoicing tool, the signal might be that six of eight test users send their first invoice without help, or that half come back within a week. Agree that number with everyone before a screen is drawn, or the results become an argument.

2. Do a small amount of research, on purpose

You don't need a big study. Talk to five to eight people who have the problem right now and ask them about the last time it happened, not about your idea. Look at what they use today, even if it's a spreadsheet and a group chat. The goal is their words and their workarounds, which become your copy and your flows.

3. Cut the scope, and write down what waits

Most of the time saved in an MVP is saved here. List everything the team wants, then sort it. MoSCoW (must, should, could, won't), a value against effort grid, RICE scoring and the Kano model are the usual tools, and any of them is fine. The one question that does the real work is this: can someone complete the core task without this feature? If they can, it waits.

We split the list three ways: what ships in v1, what comes later, and what we fake for now, such as a manual step behind a button. The "later" list matters as much as the v1 list. It stops good ideas being lost, and it stops them creeping back in during week three.

4. Map the flow, then wireframe it

Draw the path from the first screen to the result, one box per screen, before anything has colour in it. Then sketch each screen in grey. When we redesigned Metabolix, a remote monitoring platform for weight-loss clinics, we started from a user flow and a list of 32 questions for their team. It was a redesign of a working platform rather than an MVP, but the order holds: the flow shows you the missing screens and the questions the client hasn't answered yet.

5. Prototype the core flow and test it

Turn the wireframes into a clickable prototype with real words in it, not placeholder text. Give it to five people who match your user and ask them to do the core task without help. Nielsen Norman Group's research on test sizes found the best results come from testing no more than five users and running as many small rounds as you can afford. Watch where they stop. If several stop at the same place, fix that screen and test again. This is the cheapest point in the whole project to change your mind.

6. Design the states, not just the screens

A screen in a design file usually shows the happy moment. Real software spends a lot of its time in other states: empty before the first item, loading, failed, half done, not allowed for this user. An MVP that skips them feels broken even when the code works.

Timerack taught us this at scale. It's an established time and attendance platform, not an MVP, so the size is different, but the lesson carries over. Its punch screen is built around five states (not started, punched in, on break, on a meal, shift ended), and in each one it shows a large clock and only the actions that make sense right now. Managers can switch features on or off for each employee, so we drew the employee dashboard in four versions, and people only ever see what they can use. For an MVP, a short list of states for the core flow is enough. Just don't leave it out.

7. Give it just enough visual system

An MVP doesn't need a full design system. It needs one type family, a small colour set, a spacing rule and the handful of components the core flow uses, drawn once with their states. Check contrast while the set is still small: WCAG asks for at least 4.5:1 for body text and 3:1 for large text (W3C), and it's far easier to pick passing colours now than to fix them across forty screens later. That keeps the product looking deliberate, and we think that counts for more than it seems when you're asking strangers to trust a new product with their data. It also means the second version starts from parts, not from a pile of one-off screens.

8. Build it with the people who designed it

The gap between the design file and the code is where details get lost, and the build drifts from the prototype. We design and build in one team partly for this reason: when the people drawing a screen also have to build it, the costly ideas get cut on paper. If your designer and developers are separate, hold a walkthrough of the core flow and its states before the build starts, and agree which events analytics should track. If you can't measure the one task from step 1, the launch won't teach you much.

9. Launch small, watch, and change the design

Release to a small group first. Look at where people drop off in the core flow, and talk to the ones who stopped. Then change the design, not just the copy. Our own Sociarion is the clearest example we have of this, so it gets its own section.

What we learned shipping our own MVP

Sociarion is one of our two own products. It turns one upload into a post for each of a brand's social accounts, each in that brand's voice. We built it for founders, solo operators and small agencies who are the whole marketing team.

The Sociarion case study tells the full story. The first users had it five weeks after we started. To get there that fast, the first version asked each user to create their own Telegram bot and paste its key into Sociarion. It was quick for us to build, it kept every account separate, and it was enough to prove the loop worked: send a photo or a note in a chat app, get a draft for each platform back in about a minute, approve it, and it goes out on schedule.

Real users then showed us that the bot setup was the slowest step in getting started. So it went. Everyone now shares Sociarion's own bot, and connecting takes one tap. That one change is the whole method in miniature: ship the smallest thing that works, then let real use tell you what to fix first.

Two design decisions protect the first impression. Nothing publishes until a person approves it, and a test mode runs the whole pipeline without posting anything, so a new user can watch it work before it touches a real account. Both answer the worry the case study names: one post in the wrong voice, live overnight, can undo months of sounding like yourself. The case study reports 82% of drafts approved without an edit. That's the number that tells us whether the tool is doing the rewriting it promises.

Questions to answer before design starts

The Metabolix project started with 32 questions. You don't need 32. Here are ten we'd want answered before designing any MVP, and having them ready before the first call saves time:

1. Who is the first user, in one sentence, and how will you reach the first fifty of them?
2. What's the one task the product must get done?
3. What do those people use today instead?
4. What would make you call the MVP a success, as a number?
5. What are you deliberately leaving out of v1?
6. Who sets the product up: the user, you, or someone else on their behalf?
7. What data does it need on day one, and where does it come from?
8. Is there anything users must agree to first, such as terms, permissions or payment?
9. Which parts could be done by hand for the first users?
10. Who will build it, and when do they need the designs?

Question 6 shaped Metabolix. Patients there don't sign up at all: a physician enrols them, the clinic ships the devices, and an email arrives with a username. So the app had to start from what the clinic had already set up, not from a blank signup form.

How long MVP design takes, and what it costs

For the products we build, the full MVP, design and build, takes six to ten weeks in most cases. The scope takes two to three days, the prototype another one to two weeks, and then the build and launch. You see real design in the first week, not at a reveal at the end. The details are on our MVP development company page.

What moves the time and the price is mostly scope:

• How many distinct screens the core flow needs.
• Whether the data model is already decided, or still being worked out.
• How much is built from scratch rather than configured from existing tools.
• Whether you need design only, or design and build.

Our own prices are published on the pricing page. Fixed-scope projects start from $5,000, quoted once against a written scope. If you'd rather have a designer on the product every month, plans start at $2,000 a month for 40 hours, then $3,500 for 80 hours and $8,000 for two senior designers and 200 hours. A fixed project suits the MVP itself; a plan suits the months after launch, when the changes come in small batches.

We haven't quoted market averages here, because the ones we found on other sites didn't point to a source we could check. If you want to compare studios, our list of the best MVP development companies gives each one's own published prices and timelines where they have them.

Common MVP design mistakes

• The whole product designed, with the first slice called an MVP. If the file has settings pages for features that don't exist yet, the scope wasn't cut.
• Polish on screens nobody has tested. Test the grey version first; colour can wait a week.
• No empty, error or loading states. The product feels broken on the first day, when first impressions are made.
• Tests with friends. They'll be kind and they already know what the product is for.
• No analytics. Without the core task measured, the launch is an opinion.
• Launch treated as the end. The first version is a question, and the answer usually arrives in the weeks after launch.
• A big product's design, copied. Their onboarding solves problems at a scale you don't have yet.

Tools for MVP design

You don't need much. A whiteboard tool such as FigJam or Miro for the flow and the scope list; Figma for wireframes, the prototype and the handful of components; a testing tool such as Maze or UserTesting if you can't run sessions yourself; and product analytics, such as Mixpanel or Amplitude, set up before launch. If you're building with AI coding tools, the order still holds. Nielsen Norman Group makes the point that faster building lowers the cost of development but not the cost of being wrong, so the scope and the test still come first.

Should you design it yourself, hire a freelancer or work with a studio?

If you're a designer, or the MVP is a fake door or a landing page, do it yourself. A good freelancer suits a single-feature product where you, or a technical co-founder, can own the scope and the build. A studio makes sense when you want the scope, design and build handled by one team on a fixed timeline, or when the product has two sides, like a patient app and a clinic dashboard.

Whoever you pick, ask to see a product they took from scope to launch, and ask what they cut from it. Our guide on how to choose a product design agency goes through what to check.

FAQ

If you're scoping a first version and want a second opinion on what belongs in v1, we're happy to look at it with you.