By Nick Babich
Key Takeaways
- Scope decides the budget: Teams that define the job, the format and the cut list before the sprint spend the week testing a product instead of arguing about what it should be.
- Design for one job: Name the single job a specific user hires your product to do, and cut every feature that does not serve it.
- Count your screens: Map the happy path first, then design only the screens that path needs.
- Pick the cheapest format that answers your question: A concierge test or a clickable prototype often validates the idea before any code exists.
- Plan the test before the design: Book five target users for the last day of the sprint before the design work starts.
A design sprint is a week of focused work, and the quality of that week is set before it starts. Teams that scope their MVP first spend the sprint testing an idea. Teams that skip scoping spend it debating what the idea is.
Founders often treat the design sprint as the starting line. They book a week on a studio's calendar and expect a finished product to come out of it. But a sprint is an execution format, not a strategy session. In GV's five-day design sprint guide, the team maps the problem on Monday, sketches on Tuesday, decides on Wednesday, prototypes on Thursday, and tests with customers on Friday. None of those days leaves room to work out who the product is for or what it must do. You have to bring those answers with you.
That holds whoever runs the week. If you are still choosing a partner, our shortlist of UX studios that work with early-stage startups is a reasonable place to start, and the scoping work below will make every intro call with them sharper.
It also helps to remember what an MVP is for. Eric Ries, who popularized the term, defines the minimum viable product as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." It is an experiment, not a small version of your roadmap.
Here is what you need to define, decide, and discard before your first design sprint begins.
Define the Core Problem and the Single Job
Your product cannot be everything to everyone on day one. An MVP has to solve one specific problem for one specific user.
Describe that user with uncomfortable precision. "Small business owners" is too broad. "Plumbers who run three-person crews and struggle to invoice clients from their phones" is a user a designer can work with.
Next, define the single job the MVP must do. This borrows from Jobs-to-be-Done thinking: the user "hires" your product to reach a specific outcome. If you are building a marketplace for freelance writers, the job is not "managing profiles." The job is "paying for a 500-word article securely." Everything else is secondary.
Write a One-Page Product Brief
Your design team needs a single source of truth. A one-page product brief forces you to put your vision into plain language. It should cover four things:
- Target user: The person who feels the pain point most sharply.
- Core problem: The exact friction you are removing from their day.
- Value proposition: Why your solution is better, faster, or cheaper than their current workaround.
- Success metric: The number that will tell you the MVP worked.
Choose the success metric carefully. Skip vanity numbers like page views. Good examples are a 20% conversion rate on a pricing page, ten signed letters of intent, or five onboarding flows completed without help.
The one-pager is the condensed version. If your project will also go out to outside teams for proposals, see what a full UX design brief should cover and expand from there.
Choose Your MVP Format
An MVP does not always need code. Often it does not even need a complete interface. Pick the format that gets you to your success metric fastest.
| MVP format | How it works | What the design team delivers | Use it when |
|---|---|---|---|
| Concierge MVP | You deliver the service by hand. Building an AI travel planner? You research the flights and email the itinerary yourself. | Simple intake form and email templates | You need to know whether people want the outcome at all |
| Wizard of Oz MVP | The interface looks automated, but people do the work behind the scenes. | Customer-facing screens only | You want realistic behavior without building the back end |
| Single-feature MVP | One piece of working software that does the core job, with no profiles, settings, or extra menus. | Design for one flow, ready for development | The core job is clear and you need real usage data |
| Clickable prototype | Linked high-fidelity Figma screens that simulate the product. No engineering. | Interactive prototype | You need usability feedback or a demo for investors |
| Coded MVP | A basic working web or mobile app. | Full screen set plus handoff files | Technical execution is your biggest risk |
For most first sprints, a clickable prototype is the right output. It is realistic enough to get honest reactions and cheap enough to throw away.
Prioritize Features Ruthlessly
Feature bloat kills early products. You need a rule for what stays before designers start sketching. I use MoSCoW for pre-sprint scoping:
- Must have: The product fails without it.
- Should have: Important, but the launch works without it.
- Could have: Nice to include if time and budget allow.
- Won't have: Explicitly out of this sprint.
The method comes from the DSDM framework, and its MoSCoW prioritization guide includes a test I wish more founders used: if there is any workaround, "even if it is a manual and painful workaround," the item is not a Must Have. The same guide recommends keeping Must Haves to no more than 60% of the effort, so the plan has room to absorb surprises.
Then apply your own filter. If a feature does not support the single job in your brief, it goes in Won't have.
Map the Happy Path and the Minimum Screen List
Designers need to know the exact path a user takes to finish the core job. This is the happy path.
Write it out step by step. For a simple fintech tool it might be: land on the homepage, tap sign up, enter an email, connect a bank account, see the dashboard.
Then list the minimum set of screens that path needs. If the user can finish the core job in four screens, do not let anyone design twelve. A short screen list keeps the whole sprint on the interactions that matter.
Decide the Fidelity Level
Agree on the expected output before you sign anything. Mismatched expectations about fidelity cause more friction and overruns than almost anything else I see in post-mortems.
- Sketches: Hand-drawn concepts for fast alignment.
- Wireframes: Grayscale layouts for structure, hierarchy, and navigation.
- Design system basics: Core typography, colors, and button styles.
- High-fidelity prototype: Screens that look like the finished product.
For an MVP sprint, the target is usually a high-fidelity clickable prototype. Customers react honestly to something that looks real. They react politely to wireframes.
Plan Lightweight Validation
Decide how you will test the design before you pay to create it. I plan three layers:
- Problem interviews: Talk to target users before the sprint to confirm the pain point exists.
- Fake-door test: Put up a landing page with a "Sign up" or "Buy" button. When people click, tell them the product is in development and collect their email. It measures real intent for the cost of a page.
- Usability sessions: Schedule five one-hour interviews with target users for the last day of the sprint. In my projects, by the fourth or fifth session the same problems keep repeating, so more interviews add little in the first round.
Don't wait until development is done to test your assumptions. By then, every change costs engineering time.
Bring the Right Inputs to the Sprint
A sprint produces good output only when the inputs are ready. Before day one, have:
- A decider: One person with final authority to break ties.
- Existing research: Interview notes, support tickets, competitor screenshots.
- Technical constraints: Known limits from your engineering lead.
- The one-page brief: Shared with everyone in the room.
In return, expect three outputs: an interactive prototype, recorded feedback from five target users, and a clear decision to build, iterate, or drop the concept.
Realistic Timelines and Budgets in 2026
Founders tend to underestimate what good product design costs. Across the proposals I reviewed this year, a full scoping and design sprint process took two to four weeks: about a week for alignment, research, and scoping, then one to two weeks for the sprint itself.
| Design partner | Typical budget | Fits best when |
|---|---|---|
| Senior independent product designer | $5,000 to $12,000 | You have strong in-house product management and a clear brief |
| Boutique UX studio | $15,000 to $35,000 | You need research, strategy, and design from one small team |
| Large global agency | $50,000 and up | You need many disciplines at once or a complex, multi-platform product |
Once your screen list is finished, see how UX design costs break down by scope before you ask for quotes.
Don't optimize for the lowest hourly rate. Hire the partner who asks the hardest questions about your business logic during scoping.
Prepare the Developer Handoff
A design is only useful if your engineers can build it. Plan the handoff before the sprint begins.
Agree on how files will be delivered. Most teams work in Figma, and Figma's guide to Dev Mode describes a workspace where developers inspect designs, download assets, and review frames marked ready for development with statuses and annotations. Ask your design partner to use those statuses, name layers clearly, and document states like errors, empty screens, and loading.
Bring a technical lead into the sketching day. An engineer can flag an interaction that would take three weeks to code so the designer can switch to one that takes three days.
Common Scoping Mistakes to Avoid
The same errors show up again and again in the post-mortems I review:
- Designing for edge cases: Focus on the primary use case. If a user forgets their password in week one, they can email support. An MVP does not need an automated recovery flow.
- Skipping user research: Assuming you know what customers want is the most expensive mistake in software.
- Polishing visuals too early: Don't debate button colors before the core journey is validated. Structure comes before surface.
- No success metric: If you don't define success before the sprint, you will call any result a win.
The Pre-Sprint Scoping Checklist
Don't sign a contract or start a sprint until every item below is done:
- Target user defined with real specificity
- Single job to be done written down
- One-page product brief finished and shared
- Success metric defined
- MVP format chosen
- Features sorted with MoSCoW
- Happy path mapped
- Minimum screen list final
- Five target users booked for the last sprint day
- Technical constraints checked by an engineer
Frequently Asked Questions
What is the difference between a prototype and an MVP?
A prototype simulates the product, usually in Figma, to test usability and flow. An MVP is the broader experiment. It can be a prototype, but it can also be a manual concierge service or a basic coded app built to test one business hypothesis with real customers.
Should I hire a freelancer or a studio for my first MVP?
If your budget is under about $12,000 and you have strong product management in-house, a senior freelance product designer is usually enough. If you need research and strategy as well as screens, and your budget is $15,000 to $35,000, a boutique UX studio gives you more support.
How many features should an MVP have?
As few as it takes to do the single job, often just one core flow. For a ride-hailing app, that is requesting a ride and paying for it. Profiles, ride history, and driver ratings can wait.
How long does MVP design take?
In the projects I reviewed, two to four weeks: about a week of scoping and research, then one to two weeks of sprint work. Teams that arrive with a finished brief and screen list sit at the short end of that range.
Conclusion
A good design sprint comes from preparation, not from brainstorming on the day. When you define the user and the single job, sort features with MoSCoW, limit the screen list, and book your test users before the sprint starts, you protect your budget and get a clear answer from the week. The hardest part of MVP design is not deciding what to build. It is deciding what to leave out.
