The job of an MVP
MVP stands for minimum viable product. In practice, many teams hear "minimum" and build a small version of everything. That is the wrong reading.
The job of an MVP is to teach you something. You build the smallest version that lets real people try the main idea, so you can learn if it is worth building more. It is a test with a user interface.
That changes how you design it. You are not trying to show the whole product. You are trying to make one thing work well enough that a real person can use it, understand it and tell you what they think. Good MVP design is mostly about what you leave out.
Write the one-sentence promise
Before we draw anything, we ask the founder to finish this sentence:
For [who], this product helps them [do what], so that [result].
For example: "For small accounting firms, this product helps them collect documents from clients, so that they stop chasing people by email." It is not poetry. It is a filter.
If you cannot write the sentence in one go, you probably have two products in your head. Choose one. You can build the other later.
Then check each idea against it. Does this screen help the accounting firm collect documents? Yes, keep it. Does the team calendar? Maybe later.
Map the core flow
Next, draw the single path a user must walk to get the promised result. Start at the moment they arrive and end at the moment they get the result. Use boxes and arrows on paper, or in a simple tool. No screens yet.
For the accounting example, it could be:
- Firm signs up.
- Firm adds a client and lists the documents it needs.
- Client gets a link and uploads files.
- Firm sees what has arrived and what is missing.
Four steps. That is the product. Everything else, such as billing, reports, team roles and settings, is support for this path or a different idea.
Count the steps and the decisions. If the path has fifteen steps, look for ones you can remove, merge or do by hand. Doing a step by hand in the first version is a legitimate choice. A person sending an email behind the scenes is much cheaper than a screen and a database.
The cut list
Now comes the hard part. Write down every feature you or your team want in the first version. Then go through the list one by one and ask three questions:
- Is the core flow broken without it?
- Will a first user be stopped or confused without it?
- Can we do it by hand, or leave it out, for the first ten users?
Sort every item into one of three groups.
| Group | Meaning | Examples |
|---|---|---|
| Must have | The flow breaks without it. | Sign-up, add client, upload, view status |
| Fake or manual | Needed in theory, but you can do it by hand now. | Reminders sent by you, reports made in a spreadsheet |
| Later | Good idea, not needed to test the promise. | Team roles, integrations, dark mode, mobile app |
Many founders are surprised by how short the must-have group is. That is normal. A smaller first version is faster to build and easier to learn from. It is also easier to change when users tell you something you did not expect.
Keep the "later" list. Writing it down makes it easier to let go. Nothing is deleted. It is just not in version one.
Design-system starter
Even a small product needs a few shared parts. If every screen is drawn from scratch, version two will be slow and inconsistent.
You do not need a full system. A starter is enough:
- A small color set: one brand color, neutrals, and colors for success, warning and error.
- Type styles: a few sizes for headings, body and small text.
- Spacing steps, so margins are consistent.
- The ten or so components you will use most: button, input, select, table, modal, tabs, toast, empty state, card, navigation.
Build the components once, with their states: hover, focus, disabled, loading, error. When you add a new screen in version two, you assemble it instead of redrawing it. This is the same starter we include in our MVP design sprint, and it takes only a small part of the project.
Handoff to developers
A lean design is easy to build if the handoff is clear. Developers need more than pretty screens. Give them:
- The core flow diagram, so they see how screens connect.
- Every screen in the flow, including empty, loading and error versions.
- The components and the names they should use in code.
- Notes on behavior: what happens when a field is wrong, what happens on a slow connection.
- A walkthrough call, so they can ask questions while the design is fresh.
The more your developers can build without guessing, the faster the first version ships.
What to learn from the first users
Launching is where the MVP starts doing its job. Before you launch, decide what you want to find out. Write two or three questions. For example:
- Do new users reach the result without help?
- Where do they stop or get confused?
- Do they come back after the first time?
- What do they ask for that we did not build?
Watch the first five to ten users as they try it, in person or on a call. You will learn more than from any survey. Then look at your "later" list again. Some items will move up. Some will turn out to be things nobody wants.
That is a good result. The aim of an MVP is not to be right the first time. It is to find out sooner.
Where we can help
Doing this with an outside partner can save time, because someone else asks the hard questions about the cut list. It is what our MVP design sprint is built for: four weeks, from $5,900, ending in dev-ready screens and a design-system starter. You can see how the full project runs on our process page, or read about the MVP design agency service. If you want to talk it through first, send us your promise sentence and your feature list, and we will tell you what we would cut.
