Designing MVPs from scratch can be done fairly quickly nowadays, but can they also be done well in short amounts of time? Absolutely—and this precisely what this article is about.
Today, we'll take a look at the design sprint methodology and how it can help startups build MVP by following a series of simple rules and a tight schedule.
Below, you’ll find an overview of the traditional design sprint framework, as well as an updated structure we use at the Adam Fard Studio.
Let’s dive right in, shall we?
What’s an MVP in design?
MVP stands for Minimum Viable Product—a very early form of a product that has but a set of core features to satisfy the users’ most basic needs. The idea here is to create something useful with the smallest possible investment of time and money.
An important premise behind creating MVPs is providing an environment where user behavior can be tested and documented. Rather than asking your users about their theoretical preferences, offering them an interface to interact with will yield more actionable insights to fuel future product iterations.
What’s an MVP Design Sprint?
Design sprint is a concept coined by Jake Knapp and Google Ventures that aims to validate, prototype, and test ideas via design in a short amount of time—five days, to be precise. The product of such sprints is MVPs rather than finished products.
"The goal of a design sprint is not to spit out a perfect solution at the end of one week, but to get feedback on one or two many possible solutions."
– Tim Hoffer, Designer, Design Sprint Facilitation
This methodology aims to create a low-risk and high-reward process that will allow organizations and startups to extract more information about their users’ needs and develop products that are fit for the market.
The sprint can generally be divided into five sections:
Section 1: identifying the user problem;
Section 2: defining the problem;
Section 3: brainstorming solutions and shortlisting the best ones;
Section 4: prototyping the above solutions;
Section 5: testing its viability on the market.
You may have noticed that this structure resembles the Design Thinking framework that consists of the following components:
Empathize—ensure an in-depth understanding of the user;
Define—outline user needs and explore the product’s opportunities for innovation;
Ideate—brainstorm solutions based on the defined problem;
Prototype—create a prototype based on a shortlisted solution;
Test—allow users to interact with your prototype and document their experience;
One of the core differences between the two is that Design Sprints are predominantly a problem-solving framework. That implies that before starting a sprint, we should have a clear challenge in mind. On top of being a problem-solving methodology, Design Thinking is also a problem definition framework—it allows teams to explore solutions in a broader, less targeted way by leveraging empathy.
Another critical difference between the two is their purpose. Just as Design Thinking allows to solve a broader spectrum of issues, it also has a broader scope. In contrast, design sprints have a clear, well-defined target.
So think of it this way—Design Thinking is a philosophy, and design sprints are a practical tool for validation that runs on it.
How much does it take?
Fundamentally, it depends on the scope. The original design spring calls for a five-day process, but we don’t think that you should be limited to that.
Here’s a brief overview of the original five-day framework:
Monday—start by planning the week and establishing a long-term goal and the problem you’re planning to solve—it should be both challenging and manageable;
Tuesday—review existing solutions and explore ways to refine and improve them;
Wednesday—the previous day resulted in a wide array of opportunities. It’s time to find the most viable ones by critiquing and analyzing each one. This should provide you with a storyboard;
Thursday—turn yesterday’s storyboard into a prototype;
Friday—select a group of users to test your prototypes with—that will provide you with a good understanding of the improvements your product needs to satisfy their needs;
While we don’t believe the original structure to be flawed in any way, in our experience, four weeks is a timeframe that provides for a more thorough sprint. This amount of time should be sufficient to deliver an MVP for a medium-complexity product. However, if you’re dealing with a much more intricate project with more ins and outs, feel free to double that time.
What goes into an MVP design sprint?
Let’s take a closer look at how we like to structure our design sprints.
Week 1
1.1 Define the sprint scope. This is the foundation of your sprint, and it will ultimately define its efficiency. According to a study published by CB Insights, over 40% of startups fail because of a lack of market need. The goal of an MVP is to validate market fitness.
1.2 Focus on the features that embody your unique selling proposition (USP). There is a variety of questions that will help you assess the quality of your USP and calibrate it to the existing market. Here are a few of them:
What is the most important problem that our product aims to solve?
Who are the people experiencing this problem? What do they have in common?
Is this problem substantial enough to warrant a new product?
How do people address this problem without the product we’ve set out to create?
1.3 Define necessary features (e.g., sign-up flow, onboarding, etc.). As you go through the questions above, you’ll establish a wide array of things your product could do, but the goal here is to define what it must do.
1.4 Map the user flow and journey with regard to the features you’ve outlined. Use the essential features above to create a meaningful path that users will take throughout your future product;
1.5 Define your UX strategy. A UX strategy is a document that provides an in-depth view of the qualities of a user’s experience with your brand. It should take into account your organization’s overarching objectives and marry them with the tools UX has to offer in achieving them.
Your startup might prioritize early adoption, securing adequate retention, and other central goals. It’s now the design team's job to make sure the UX works toward these goals as well.
1.6 Achieve team-wide alignment on the tools and processes. The whole team should have a good understanding of the goals you’ve set out to achieve, the design tools that will be used to do so, the frequency of calls and meetings, how accesses and credentials will be shared, and other important formalities.
1.7 Document your user persona. This is when you consolidate all available intel on your users, their goals, pains, background, and so forth.
Week 2
2.1 Run the first rounds of concepts and wireframes. Just like it is the case with Design Thinking, every phase of the design sprint methodology is tightly interconnected with prior and future steps. Now that we’ve established the most important features and the guiding UX strategy, we can look into execution.
During this step, designers can start creating some rough sketches and low-fidelity wireframes that will be refined and elevated afterward.
2.2 Start prototyping. Now that you’ve developed some key tangible designs, it’s time to make them clickable and interactive. There’s a variety of tools that can help you with that. We like to use Figma for these purposes, but there are also tools like Figma, Sketch, etc.
2.3 Run the first usability tests to validate initial assumptions. The reason you would create clickable prototypes in the first place is to test them with real users. Similarly, they allow you to establish whether they communicate your design vision accurately. Make sure to recruit at least 5 users, since this is an optimal number to uncover the most insights with the least effort. Aside from that, they’re a valuable asset when it comes to persuading potential investors.
Week 3
3.1 Iterate on the wireframes based on the usability test results. After you’ve collected some meaningful feedback from your users, you have a lot of actionable insight that you can incorporate into your product.
3.2 Update your prototypes as well. Once you’ve updated your wireframes, you can start making adjustments to your prototypes.
3.3 Run the second round of usability testing. Your goal is to validate your improved design with your users. Make sure that users no longer experience the problems mentioned in the previous test. However, your quest to identify new issues is not over. If your users mention other pressing issues, it’s essential to go back to the drawing board and run an extra prototype iteration.
3.4 Define the visual direction
Given that you now have a good understanding of your product’s architecture, it’s time to think about the visual direction as well. Generally, you would want to create a mood board, i.e., a compilation of design references, so that you can pick the patterns and visuals the team likes the most.
Moodboards are not the only thing you'd need though. Ideally, your visual identity should be documented in a style guide, or in a design system that also includes a style guide.
Week 4
4.1 Give your high-fidelity designs some final touch-ups. Having identified the visual direction and the product’s structure, you can bring these two together and have a fully designed app.
4.2 Prepare the hand-off file for the developer(s). In order to smooth out the process, it’s important to prepare design systems, introduce proper taxonomy, and so forth, so that the design is easy to implement.
The pitfalls of designing an MVP
Like all things in life, MVPs have their pros and cons. Therefore, it’s important to mention that there’s a wide array of things we need to be mindful of when designing them. Here are a few of them:
Visuals over content and growth
A common pitfall modern startups are subject to is excessive focus on visuals. While they are pretty important for design, their primary purpose is to build trust with first-time users, not be the star of the show.
The focus of your MVP should revolve around the value users are provided via content and careful tailoring of the product’s user experience.
"Lean" doesn’t mean no research
Trying to stay lean is often misconstrued as diving headfirst into the design and development process and figuring out everything else along the way. That’s only partly true. Design sprints demand a fair share of research in order to be successful. Working on an MVP implies sitting on a wealth of information that sheds light on the users’ and the market’s needs.
Failing to ensure that will result in developing a product that people just don’t need or want. At Adam Fard Studio, we always have a dedicated researcher on our projects. In our experience, it saves up to 50% time otherwise spent on needless iterations.
Narrow skillset
UX and UI designers are gradually becoming an indispensable part of a startup’s core team. While choosing to have a UX specialist as part of your crew is certainly laudable, delegating this broad field of work to a single person can be too much to handle. This can be an issue of time and expertise.
Here's an example of a T-shaped design professional that covers a large area on a surface level, and specializes deeply in just one field. | Source
Make sure to hire designers that specialize in your particular field or, at the very least, have a good understanding thereof. Creatives that have worked exclusively with e-Commerce might have a hard time quickly transitioning into MedTech, or other niches, especially if they’re the only designer on deck. Industry expertise aside, it's nearly impossible to find one person who can do expert interviews, research, UI, etc. all at the same time.
Poor choice of features & feature overload
It’s very hard to overstate the importance of good feature prioritization. Startups often make one of two mistakes—they either choose their features poorly or just throw a bunch of them in, hoping to entice their users with quantity. Needless to say, both of these scenarios aren’t conducive to a high-quality product.
Fortunately, frameworks like KANO and MoSCoW will allow you to find the most suitable features that will also be in line with your unique value proposition. Both will enable you to differentiate between the things that your users deem basic and the ones that will excite and impress them. Let’s take a closer look.
The MoSCoW framework is especially useful when dealing with very short deadlines. The point of this method is to consider all features as vital, but differentiate them based on the benefits they can provide and the amount of time it’ll take to develop them. The MoSCow framework has four feature categories:
Must-have;
Should-have;
Could-have;
Won’t have;
By finding the features that will have a greater impact on user satisfaction with the smallest time investment, you will be able to establish what the “must-haves” and “should-haves” of your product are.
The KANO framework was created back in the 1980s. The point here is to categorize user preferences into five different classes:
Basic — features that people take for granted. If delivered appropriately, your users will remain neutral. If delivered poorly, your users will be dissatisfied;
Performance — features that make users satisfied when delivered and dissatisfied when not;
Excitement — features users don’t take for granted. Their existence will excite your users, whereas their absence won’t upset them;
Indifferent — features that do not influence your users’ satisfaction or dissatisfaction. Typically considered unworthy of pursuing;
Reverse — not having these features will have a positive effect while including them in your product will upset them;
However, don’t hesitate to look into other feature prioritization frameworks if you think that these don’t necessarily fit your niche or industry. Feel free to tweak the ones above as well—there’s no method to the madness.
When do you start coding?
Well, you don’t always need to code your MVP. Depending on the kind of product you’re creating, you can use a no-code app builder as you’re designing the solution. If you're interested in learning more about no-code development, be sure to check out the article Why No-Code/Low-Code Is the Future of Development. This article explores the advantages of using no-code tools and why no-code/low-code is considered the future of development.
Some of the most popular no-code app builders include:
Webflow;
Adalo;
Glide;
Backendless;
However, the majority of MVPs will need to be coded. Fortunately, you can get started with the back-end fairly early since it has little impact on the product design. We advise you to consult with an experienced back-end developer to discuss all contingencies.
You can start coding the front end as soon as you’ve validated a piece of the high-fidelity interface. Anything that’s validated is good enough to be coded.
Conclusion
When applied correctly, the design sprint methodology will ensure that your MVP will satisfy user needs and be fit for the market it’s about to enter. Also, don’t hesitate to tweak and experiment with it, especially when it comes to timeframes.
We like to extend the sprint to 4 weeks when dealing with relatively complex products since it allows us to be more thorough and analytical about our decision-making.
We hope you’ve found this to be useful. Good luck and happy designing!
MVP Design Sprint Checklist
Check out our free editable MVP design checklist to design and validate your idea fast and with minimum effort.
DownloadQ&A
How do I create an MVP product?
First, identify the user problem, defining the problem, then brainstorm solutions and prototype them, and test its viability on the market.
Is MVP part of design thinking?
Design thinking is a philosphy at the core of developing an MVP.
What does MVP mean in Agile?
MVP stands for Minimum Viable Product. It's a product development philosophy that focuses on launching a viable product in the shortest amount of time.
