Before week one
An MVP design sprint is a four-week project that takes you from an idea, or a rough prototype, to dev-ready screens. It is fixed scope. We agree what you get before we start, so the plan below is the same plan you will see in the proposal.
Before the first day, we ask for a few things:
- A short description of the product and who it is for.
- Any notes, sketches, old screens or competitor examples you already have.
- Analytics or user feedback, if you have any. If you have none, that is fine.
- The name of one person on your side who can make decisions.
We also agree the scope: roughly how many flows, how many screens, and what is out. The sprint covers 15 to 25 core screens. The exact number depends on how complex your flows are. The price starts at $5,900 and depends mainly on the number of flows and screens. You can see all current prices on the pricing page.
If you started with a UX audit in the last 30 days, the audit fee is credited toward the sprint.
Week one: discovery and brief
We start with a discovery session. This is a live call, usually the longest one in the project. We want to learn:
- Who the users are and what they are trying to do.
- What the product must do in its first version, and what can wait.
- What limits you have: timeline, developers, technology, budget.
- What exists already, and what you have tried.
After the call, we write a one-page product brief. It states the goal, the user, the main job the product does, and the list of what is in and out of the first version. We cut features here, early, because it is far cheaper to remove an idea on paper than a screen later.
What you do: join the discovery session, share what you have, and read the brief. Tell us plainly if we got something wrong.
What you get: the product brief, and the first weekly Loom update.
Week two: flows
With the brief agreed, we draw the user flows for the main tasks. A flow is a map of the steps a person takes, from the start (such as signing up) to the point where the product first helps them. At this stage there are boxes and arrows, not polished screens.
We work this way because flows are where most of the real decisions are. If the flow is wrong, polished screens will not fix it. Reviewing flows is quick, and changing them costs almost nothing.
We show you the flows before we design any screen. You review them, and we adjust. We also look for steps that could be merged, removed or handled by hand in version one.
What you do: review the flows and give clear feedback. If your developers are involved, this is a good time to have them look, because they will spot technical problems early.
What you get: signed-off flows for the main tasks, and a Loom walkthrough.
Week three: core screens
Now we design. This week we turn the flows into the core screens, working through them in order of importance. We start with the screens where the user does the main job, and then fill in the rest.
We design the states as well as the happy path: empty, loading, error, and the moments when something goes wrong. These are the screens that usually get left out, and then show up as bugs after launch.
In parallel, we start the design-system starter: colors, type, spacing and the key components. Screens are built from these parts, which keeps them consistent and makes version two faster.
You see progress in the weekly Loom, and can comment as we go. We would rather hear "this is not right" in week three than at handoff.
What you do: watch the update, comment on direction, and answer questions quickly. Slow feedback is a common reason a sprint runs long.
What you get: most of the 15 to 25 core screens, and a working design-system starter.
Week four: prototype and handoff
In the last week, we finish the screens and link them into a clickable prototype. The prototype lets you, your team and a few real users click through the main flow, as if it were the product. It is a good time to show it to people outside your team, such as an advisor, an investor or a first customer.
Then we prepare the handoff. We organize the Figma file so developers can find things: flows, screens, components, states and notes. We finish the design-system starter. And we hold a final walkthrough call with your team, where we explain the file and answer your engineers' questions.
What you do: review the prototype, join the walkthrough with your developers, and tell us what is unclear.
What you get: the final deliverables, listed below.
What you hold at the end
- A discovery session and a one-page product brief.
- User flows for the main tasks.
- 15 to 25 core screens.
- A design-system starter: colors, type and key components.
- A clickable prototype.
- A dev-ready handoff in Figma.
- Weekly Loom updates along the way.
- A final walkthrough call with your team.
What your team needs to do
A sprint goes best when the client treats it as a shared project. The list is short:
- One decision-maker. Feedback that goes through five people takes a week.
- Fast answers. Aim to reply within a working day or two.
- Honest feedback. "I don't like it" is useful if you say why. "It's fine" when it isn't is not.
- Access to the right people. A developer for a call, a customer to talk to, the person who knows the data.
- Time for the key calls. The discovery session and the final walkthrough.
If the scope changes, small changes are fine. If the change is large, we tell you what it affects and you choose: swap something out, or add time and cost. There are no surprises.
After the sprint
When the sprint ends, you have a design your developers can build. Many teams do exactly that. Some bring us back in other ways:
- A design partner plan, with a senior designer on your product month by month.
- A front-end engineer to build the UI with us, if you want production code.
- A separate project, like a marketing website.
Or none of these, which is also fine. The sprint is designed to stand on its own.
You can read the full details on the MVP design sprint page, or learn about the kind of teams we work with on the MVP design agency page. If you have a product idea and want to see if a sprint fits, tell us about it through the contact page, and we will tell you honestly what we would do.
