UX Research for SaaS MVPs: What It Is and When You Actually Need It

UX research is one of the most misunderstood investments in SaaS product development. Some founders treat it as a luxury, something large product teams do when they have time and budget. Others treat it as a prerequisite, refusing to build anything until months of research are complete. Both are wrong. UX research at the MVP stage is a specific, time-boxed process with a clear purpose: replacing the assumptions your team has about users with evidence. When it is done well and at the right time, it prevents the most expensive mistakes in product development. When it is skipped entirely, those mistakes get built into the product. At Inity Agency, UX research is embedded into every MVP engagement, not as a separate phase, but as the foundation that every design decision is built on.

What UX Research Actually Is (and Is Not)

UX research is the structured collection of evidence about users: how they think, what they do, what language they use, where they struggle, and what outcomes they are trying to achieve. It is not a single activity. It is a category of activities that answer different questions at different stages of a product’s development.

What UX research is:

• Customer discovery interviews – conversations with target users before any design begins
• Usability testing – watching users attempt tasks in a wireframe, prototype, or live product
• Card sorting and tree testing – understanding how users mentally organise information
• Surveys – quantitative data about user preferences, pain severity, or feature interest
• Competitive analysis – evaluating the UX of existing solutions to understand where they fail your target users
• Behavioural analytics – tracking what users actually do in the live product

What UX research is not:

• Asking people if they like the design (“Yes” from users who are too polite to say no)
• Asking people if they would use your product (“Yes” from people who overestimate their own future behaviour)
• Asking colleagues and friends for feedback (they are not your users)
• Gathering large samples before making any decisions (five interviews reveal the majority of patterns)

The most important distinction for a pre-seed founder: UX research at the MVP stage is not the months-long, lab-based, rigorous process that enterprise product teams run. It is fast, targeted, and hypothesis-driven. Its purpose is to replace specific assumptions with specific evidence before those assumptions get built into the product.

The Two Types of UX Research – and When to Use Each

UX research falls into two broad categories, and confusing them leads to either over-investing in the wrong type or under-investing in the right one.

Generative Research – Learning What to Build

Generative research is conducted before design begins. Its purpose is to understand the problem space: who your users are, what they are trying to accomplish, how they currently solve the problem, where existing solutions fail them, and what language they use to describe their pain.

The primary method is the customer discovery interview – an open-ended, 45–60 minute conversation with a target user designed to understand behaviour and context, not to validate your solution idea.

Generative research answers: What should we build and for whom?

When to use it: Before any wireframes are drawn. Before the MVP scope is defined. At the earliest stage of product development, when you have a hypothesis about the problem but have not yet validated it with real users.

How much is enough at the MVP stage: Five to eight interviews with people who match your target user profile. At this volume, the majority of meaningful patterns emerge. More interviews add diminishing returns unless the user population is genuinely diverse across multiple segments.

Evaluative Research – Testing What You Have Built

Evaluative research is conducted on design artefacts: wireframes, prototypes, or live products. Its purpose is to test whether the design decisions made work for users: can they navigate the product, find what they need, and complete the core workflow without confusion or error.

The primary method is usability testing – watching a user attempt to complete specific tasks and observing where they succeed, hesitate, or fail.

Evaluative research answers: Does what we built work for our users?

When to use it: After wireframes are produced, to test whether the information architecture and user flow make sense before investing in high-fidelity design. After the high-fidelity prototype is complete, to test the full experience before development begins. After launch, continuously, to identify friction in the live product.

How much is enough at the MVP stage: Five usability tests on a Figma prototype reveal approximately 80% of friction points — enough to make informed design decisions without the cost and time of larger studies.

The 4 Research Methods Every SaaS MVP Needs

1. Customer Discovery Interviews (Before Design)

Five to eight 45-minute conversations with people who actively experience the problem you are solving. The goal is not to validate your idea – it is to understand the context and behaviour of your target user before you have imposed any solution thinking on the conversation.

What to ask:

• “Walk me through the last time you experienced [problem].”
• “What have you tried to solve this? What worked, what didn’t?”
• “How long does this take you? What does it cost you when it goes wrong?”
• “Who else is involved in this process?”

What not to ask:

• “Would you use a product that does X?” (Hypothetical questions produce hypothetical answers)
• “What features would you want?” (Users are not product designers – they describe symptoms, not solutions)

What you learn: The specific language users use to describe the problem (crucial for onboarding copy and positioning), the severity and frequency of the pain, the current workarounds, and the actors and systems involved in the workflow.

2. Competitive UX Analysis (Before Design)

A structured review of the UX of two to four competing or adjacent products. Not a feature comparison – a UX evaluation: how does a new user get from signup to first value? Where does the onboarding break down? What are the common information architecture patterns? Where do existing solutions create the friction that represents your opportunity?

This takes two to four hours and requires no recruitment. It produces a map of the UX landscape your product is entering – and identifies where the design bar is and where it needs to be cleared.

3. Prototype Usability Testing (Before Development)

Five usability tests on the high-fidelity Figma prototype, before a line of code is written. A usability test at this stage is simple: recruit five people who match your target user profile, give them a task (“create your first project”), and watch without intervening.

The patterns that emerge from five sessions, the screens that confuse, the labels that are misread, the steps that are skipped, are the friction points that, if built into the product, become expensive to fix. Identifying them in Figma takes an afternoon. Fixing them in a live product can take weeks.

4. Post-Launch Behavioural Analytics (After Launch)

Once the MVP is live, UX research shifts from qualitative to quantitative. Session recording tools (Hotjar, FullStory) reveal where users click, scroll, hesitate, and exit. Funnel analytics (Mixpanel, Amplitude) show where users drop off in the activation journey. These tools do not explain why users behave as they do, for that, you return to interviews, but they tell you precisely where in the product the problems are concentrated.

The combination of “where” (analytics) and “why” (interviews) is the ongoing research loop that drives product iteration after launch.

What UX Research Is Not Worth Doing at the MVP Stage

Not all UX research methods are appropriate at the MVP stage. Over-investing in the wrong methods at the wrong time wastes resources that should go toward building and shipping.

Not worth it at MVP stage:

• Large-scale surveys before launch – surveys require sample sizes of 50–100 to produce statistically meaningful results. At pre-seed stage, you rarely have access to this many target users, and the answers to survey questions are less revealing than conversations.
• Formal usability labs – renting a usability lab and running recorded sessions is appropriate for enterprise product teams iterating on mature products. For an MVP, five informal remote Figma tests produce equivalent insights at a fraction of the cost.
• Diary studies and longitudinal research – tracking users over weeks is appropriate for mature products. For an MVP, the time investment is disproportionate to the decisions it informs.
• A/B testing before you have enough traffic – A/B testing requires sufficient traffic to reach statistical significance. Running A/B tests with low traffic produces misleading results. Build the product, get to a baseline of users, then test.

The practical rule: at the MVP stage, every research activity should answer a specific design question within a week. If it cannot, it is too heavyweight for the stage.

A Practical UX Research Plan for a Pre-Seed SaaS MVP

Total pre-launch investment: approximately two to three weeks of elapsed time, with active research work concentrated in shorter bursts. This is not a research programme; it is a series of targeted questions answered at the moments when the answers most directly affect design decisions.

The Cost of Skipping UX Research

The argument for skipping UX research at the MVP stage is usually speed: there is no time, there is no budget, just need to get something built.

This argument misunderstands where time and money are lost. The expensive part of product development is not the research; it is the rework. Every design decision made on an unvalidated assumption is a potential rework. The most common ones at the MVP stage:

• Wrong information architecture – the product is organised the way the founder thinks about it, not the way users think about their workflow. The fix: restructuring the IA after launch, which means redesigning screens, rewriting navigation, and re-educating users.
• Wrong language – the product uses internal terminology that users do not recognise, creating confusion in onboarding and support overhead. The fix: rewriting UI copy, re-recording demo videos, and updating documentation.
• Missing the real pain – the product solves a problem adjacent to the real one, because the real one was never investigated. The fix: a pivot, which means throwing away a significant portion of the build.

Five to eight customer discovery interviews before design begins prevent all three of these categories of rework. The investment is in days. The prevention is weeks of redesign and development. Founders who validate continuously spend 30–60% less on development than those who build on assumptions.

How Inity Integrates UX Research Into the MVP Process

At Inity, UX research is not a separate engagement that precedes the design engagement. It is embedded into the Discovery Week, the first week of every MVP project, as the foundation for every design decision that follows.

During Discovery Week, we conduct structured problem-mapping with the founder (reviewing existing customer discovery if it exists, or guiding the founder through the customer discovery questions if it does not), competitive UX analysis of the two to three most relevant existing solutions, and user workflow mapping based on the validated problem.

The output of this research directly feeds the wireframing phase: the information architecture reflects how users think about their workflow, not how the founder imagined it. The onboarding flow reflects the language users use, not the product nomenclature the founder invented. The feature scope reflects the validated problem, not the founder’s wishlist.

After the high-fidelity prototype is complete, we run five usability tests as standard, catching the friction points before they are built into the product.

Conclusion

UX research for a SaaS MVP is not a luxury and it is not a months-long enterprise process. It is a targeted, time-boxed set of activities that replaces assumptions with evidence at the moments when those assumptions would otherwise be built into the product. Five customer discovery interviews before design, a competitive UX analysis, five usability tests on the prototype before development, this is the minimum viable research process for an MVP, and it consistently prevents the most expensive mistakes in SaaS product development. The founders who skip it do not save the time they think they are saving. They spend it later, in rework.

→ Building a SaaS MVP and not sure how much research you actually need? Inity’s Discovery Week includes UX research as a core component of every engagement. Book a call to find out what that looks like for your product.