An MVP is not a smaller version of your full product. It's the fastest way to learn whether people want the core thing you're building. The design job is to make that one thing work well and cut everything else. Here's the four-week process I use with early-stage founders.
Week 1: Define the one job
Before opening Figma, we answer three questions together:
- Who is the first user? One specific person, not "everyone who…".
- What is the one job they hire the product for? Book a ride. Order groceries. Track a student's progress.
- What does success look like in numbers? For example, "a user completes their first order in under 3 minutes".
Then I map the shortest path from opening the app to that job being done. Every screen that isn't on that path goes on a "later" list. This list is usually longer than the MVP itself, and that's the point.
Week 2: Wireframes and a clickable flow
I sketch the core flow in low-fidelity wireframes and link them into a clickable prototype. No colors, no polish. At this stage, changing a whole flow costs minutes, not days.
Then we put it in front of 4–5 people who match the first user. I give them a task ("you want to order dinner for two") and watch where they hesitate. Most of the big product decisions in an MVP come from these sessions, not from internal debates.
Week 3: Visual design and a lean design system
Once the flow holds up, I move to high fidelity. For an MVP I build only the components the screens actually need: buttons, inputs, cards, lists, navigation, and empty, loading and error states. A lean component set keeps the design consistent and gives developers fewer things to build.
Two things I never skip, even in an MVP:
- Empty and error states. A new user's first screen is often empty. If it looks broken, they leave.
- Onboarding for the one job. Not a five-slide tour, but just enough to get the user to their first success.
Week 4: Handoff and build support
A good handoff saves more time than a fast design. I organize the Figma file by flow, annotate behavior that a static screen can't show (what happens when the network fails, what the button does while loading), and share the component specs. During the first sprint I stay available for questions, because small gaps are cheaper to fix in a quick call than in a rebuild.
What to leave out of an MVP
- Settings screens beyond the basics
- Advanced filters and sorting
- Multiple user roles, unless the product can't work without them
- Custom illustrations and complex animations
- Admin dashboards beyond what your team needs to operate on day one
All of these can come in version two, once real usage shows you which ones matter.
Examples
You can see MVP-stage work in my portfolio, from the Edus SaaS landing page and Edus student app to the Waddini ride-hailing app.