What MVP is not
MVP, or Minimum Viable Product, has become a worn-out term. Most teams treat MVP as "let's build fast and see what happens". That shortcut is what turns MVP into a refactor 6 months later.
The original definition is more precise: MVP is the minimum version that validates a business hypothesis in a real environment. It is not "incomplete product". It is "product enough to answer a business question". The question must be clear before the first sprint. Without a hypothesis, no MVP — just code thrown around.
In UX-first projects, MVP is born from the opposite: it starts with the question, validates with research and prototype, and only becomes code after the hypothesis passes the test. Forrester/IBM research showed the impact of this arrangement: 50% fewer bugs in production, 75% reduction in design and development time, and 301% ROI over 3 years.
The Rework Rule 1:10:100
The most well-known rule of thumb in software engineering also applies directly to the decision of whether to skip the UX phase before the MVP.
Fixing a product problem in the research phase costs 1 unit of effort. The same problem, if it slips into the prototype phase, costs 10. If it reaches production, it costs 100.
The rule explains why MVP without UX gets expensive. Each wrong hypothesis becomes code. Wrong code becomes a bug. Bug in production becomes a support ticket, support becomes churn, and churn becomes the end of the startup. The cascade starts with the decision to skip 3 weeks of research.
Mature companies treat UX before MVP as financial risk mitigation. It is not "an optional design phase". It is the phase that prevents spending $50k to $500k on code nobody wants to use.
The 5 UX phases before code
There is a consolidated framework to run UX before MVP in 3 to 4 weeks. The five phases are sequential and each has a concrete deliverable.
Phase 1 — Diagnosis and alignment
The team meets to map symptoms versus structural causes. The client usually arrives with a symptom (low conversion rate, high churn, funnel abandonment). The diagnosis phase separates symptom from cause.
Dominant tool here: CSD Matrix (Certainties, Suppositions, Doubts). It separates what the team knows from what it is assuming. What enters "Supposition" becomes a hypothesis to test in the next phase.
Deliverable: 1- to 2-page document with central hypothesis + prioritized list of assumptions to validate.
Phase 2 — User research
Here happens the most brutal saving of the MVP. Nielsen Norman Group's five-user rule: structured tests with five users per segment identify more than 80% of serious usability problems.
For market hypothesis validation, the recommendation is 15 to 30 interviews distributed across 2 or 3 segments. The Mom Test framework anchors the interview in historical behavior ("what did you do yesterday to solve X?") instead of opinion about the future ("would you use an app that does X?"). Habit is fact. Opinion is courtesy.
Deliverable: report with 8 to 12 critical insights + prioritized list of real problems to solve in the MVP.
Phase 3 — Heuristic audit
If the product already exists (even as a legacy prototype), Jakob Nielsen's 10 heuristics are applied to map violations: system status feedback, error prevention, match between system and real world, user control, consistency, recognition rather than recall, flexibility, aesthetic and minimalist design, help users recognize and recover from errors.
Each violation gets a severity score (1 to 4). Severity 3 and 4 become immediate backlog.
Deliverable: heuristics matrix with 20 to 40 items classified by severity.
Phase 4 — Solution and prototyping
High-fidelity prototype in Figma, navigable, with critical flows covered. It is not a static mockup. It is clickable, testable, and detailed enough for the developer to look and implement without ambiguity.
The practical rule here: every important state must be in the prototype. Empty state, error state, loading state, success state. State missing from Figma becomes improvisation in code, and improvisation in code becomes bug.
Deliverable: navigable Figma prototype + state documentation + technical handoff.
Phase 5 — Validation and delivery
Before the code, the prototype is tested again with the same users from phase 2. Validation question: "does this solve the problem you described?" If 4 out of 5 say yes, it passes to MVP. If responses come diffuse, it goes back to phase 4 with adjustments.
Together comes the implementation of a centralized Design System: color, typography, spacing tokens, and components named with business vocabulary. Without that, design becomes theater and engineering improvises.
Deliverable: design system + approved prototype + prioritized technical roadmap.
The numbers of UX-first MVP
Forrester/IBM research, in the Total Economic Impact (TEI) study with 5 development teams and 60 Fortune 1000 executives, measured the results of design thinking applied to complex systems:
- 75% reduction in design and development time, because the team focuses on the right problem from the start.
- Launch of new features 2x faster, because prior validation kills wrong decisions before code.
- 33% reduction in post-launch redesigns, because user research identifies the right flows before implementation.
- Over 50% reduction in software defects, because requirements ambiguity drops when the prototype was tested first.
- 301% accumulated ROI over 3 years, with payback period under 6 months.
In parallel, the McKinsey Design Index tracked 300 companies over 5 years. Companies in the top quartile of design practices saw revenue growth 32 percentage points above peers and shareholder returns 56 points higher.
The most common mistakes of those who skip UX in MVP
Three patterns appear repeatedly in projects that skipped UX and blew budget:
-
Confusing speed with rush: "we want to ship fast" becomes "let's skip research". The result is launching the wrong product. Execution speed is higher when the hypothesis is right. Rushing without a hypothesis is just capital burn.
-
Treating prototype as cost, not investment: 3 weeks of tested Figma save 12 weeks of refactored code. The math is direct. Anyone treating it as cost will find out late.
-
Confusing family feedback with market validation: the team shows the prototype to colleagues and friends, hears "looks great", and considers it validated. Courtesy is not a market. Real validation requires interviewing people who do not know the team.
Otther insight: MVP in 12 weeks with UX-first
At Otther, we treat UX-first as a prerequisite for MVP. The practical model we apply: 3 weeks of research + tested prototype, followed by 8 to 10 weeks of engineering with closed scope and mapped states. Total: 11 to 13 weeks, with the full saving in no-rework.
The criterion we apply to decide MVP scope is the rule of three states. Every critical feature must have three clear answers before becoming code: empty state (what does the user see when they have not used it yet?), error state (what happens when something goes wrong?), success state (what does the user see when they complete?). A feature without the three states defined in Figma does not enter the sprint.
If you are about to start an MVP, or have an MVP in production that needs a redesign, it is worth a conversation. 90 minutes of focused discovery usually show whether the current scope is validated or needs adjustment before the next sprint.