The 5 UX decisions that make or break an MVP

When an MVP flops, the post-mortem usually blames the wrong thing. "We needed more features." "The design was not polished enough." Occasionally true, but far more often the product was quietly sunk by a handful of UX decisions made in the first week — before a single feature was built, before anyone thought of it as "design." These five decisions matter more than polish, and getting them right early is cheaper than fixing them after users have already bounced.

1. What is the one thing, and is it obvious in five seconds?

Every product does several things. Every good product makes one of them obviously primary. If a new user cannot tell within five seconds what your product is for and what to do first, they will leave, and no amount of feature richness will bring them back.

This is a decision, not an accident. You choose the single most important action and you make it the loudest thing on the screen. Everything else gets quieter. The hardest part is resisting the urge to show off everything at once — a busy first screen is a product that has not decided what it is.

2. What does the empty state say?

Every new user starts with nothing: no data, no history, no content. Yet teams design for the full, thriving version of the app and treat the empty state as an afterthought — a blank screen that says, effectively, "you are on your own." That blank screen is where most new users quit.

The empty state is your best onboarding surface. It should show what the product will look like when it is working, and give the user one clear, easy first action to get there. Design the empty state as carefully as the full one; it is the version every single user sees first.

3. How does the product behave when something goes wrong?

Forms get submitted twice. Networks drop. Payments fail. Users type the wrong thing. In a demo none of this happens; in the real world all of it does, constantly. How your product handles these moments is not an edge case — it is a core part of the experience, and it is where trust is won or lost.

A clear, calm error message that tells the user what happened and what to do next is worth more than any feature. A silent failure, or a wall of technical jargon, tells the user your product is fragile — and they will believe it.

4. How many steps to the payoff?

Count the taps or clicks from arriving to getting the core value. Then cut the number. Every step between a user and the thing they came for is a place they can hesitate, get confused, or give up. MVPs are especially unforgiving here because the user has no loyalty yet — they will not push through friction for a product they are not sure about.

This does not mean cramming everything onto one screen. It means being honest about which steps are truly necessary and deleting the ones that exist only because they were easy to build. Ask of every step: does the user actually need this, right now, to get value?

5. Does the product speak the user's language?

Your internal words are not your users' words. The labels, buttons, and messages that make sense to the team who built the thing are often opaque to the person using it for the first time. "Provision a workspace" means nothing to someone who just wants to "start a project."

Getting the words right is one of the cheapest, highest-impact UX decisions there is, and one of the most neglected. Use the language your users already use for the problem you solve. If you are not sure what that is, that is a sign you should talk to a few of them before you finish building.

1. 1The one thingobvious in five seconds, or they leave
2. 2The empty statethe version every user sees first
3. 3When it goes wrongcalm errors win or lose trust
4. 4Steps to the payoffcount them, then cut them
5. 5The user's languagetheir words, not your internal ones

Why these beat polish

Notice what is not on this list: animations, custom illustrations, a distinctive visual style. Those matter — later. They make a good product feel great. But they cannot rescue a product where the core action is unclear, the first screen is empty and cold, errors are baffling, the path to value is long, and the words are confusing. Polish amplifies a working experience; it cannot create one.

Get the five fundamentals right and a plain-looking MVP will outperform a beautiful one that got them wrong. Every time.

The good news is that all five are decisions, not budgets. They cost thought, not money, and the earlier you make them the cheaper they are. That is why we settle them in week one of every build, with a clickable prototype, before writing production code — so the fundamentals are right before anything is expensive to change.

If you are shaping an MVP and want a second pair of eyes on these decisions, we're happy to help.

Frequently asked questions

What makes or breaks an MVP's UX?

Five decisions made in the first week, before any feature is built: whether the one primary action is obvious in five seconds, what the empty state says, how the product behaves when something goes wrong, how many steps it takes to reach the payoff, and whether it speaks the user's language rather than your internal one.

Why does the empty state matter so much?

Because it's the version every single user sees first — everyone starts with no data, no history, no content. Teams design for the thriving, full app and treat the empty state as an afterthought, which is exactly where most new users quit. It's your best onboarding surface: show what the product looks like working, and give one clear first action.

Isn't visual polish what makes a product feel good?

Polish amplifies a working experience; it can't create one. Animations and a distinctive style matter later. They can't rescue a product where the core action is unclear, the first screen is cold, errors are baffling, the path to value is long, and the words confuse people. Get the five fundamentals right first.

How early should these UX decisions be made?

Week one, before writing production code. All five are decisions, not budgets — they cost thought, not money — and the earlier you make them the cheaper they are to change. We settle them with a clickable prototype so the fundamentals are right before anything is expensive to move.