Editor’s note: This is an excerpt from our recent book Lean UX; it is part of a free curated collection of chapters from the O’Reilly Design library. Download a free copy of the Experience Design ebook here.
Lean UX makes heavy use of the notion of minimum viable product (MVP). MVPs help test our assumptions — will this tactic achieve the desired outcome — while minimizing the work we put into unproven ideas. The sooner we can find which features are worth investing in, the sooner we can focus our limited resources on the best solutions to our business problems. This concept is an important part of how Lean UX minimizes waste.
Your prioritized list of hypotheses has given you several paths to explore. To do this exploration, you are going to want to create the smallest thing you can to determine the validity of each of these hypothesis statements. That is your MVP. You will use your MVP to run experiments. The outcome of the experiments will tell you whether your hypothesis was correct, and thus whether the direction you are exploring should be pursued, refined, or abandoned.
The focus of an MVP
The phrase MVP has caused a lot of confusion in its short life. The problem is that it gets used in two different ways. Sometimes teams create an MVP primarily to learn something. They’re not concerned with delivering value to the market; they’re just trying to figure out what the market wants. In other cases, teams create a small version of a product or a feature because they want to start delivering value to the market as quickly as possible. In this second case, if you design and deploy the MVP correctly, you should also be able to learn from it, even if that’s not the primary focus.
Let’s take as an example a medium-sized company with which I consulted recently. They were exploring new marketing tactics and wanted to launch a monthly newsletter. Newsletter creation is no small task. You need to prepare a content strategy, editorial calendar, layout and design, as well as an ongoing marketing strategy. You need writers and editors to work on it. All in all, it’s a big expenditure for the company to undertake. The team decided to treat this newsletter idea as a hypothesis.
The first question they had to answer was whether there was enough customer demand for a newsletter to justify the effort. The MVP they used to test the idea was a signup form on their current website. The signup form promoted the newsletter and asked for a customer’s email address. This approach wouldn’t deliver any value to the customer — yet. Instead, the focus was on helping the team learn enough to make a good decision about whether to proceed.
They spent half a day designing and coding the form and were able to launch it that same afternoon. The team knew that their site received a significant amount of traffic each day: They would be able to learn very quickly if there was interest in their newsletter.
At this point, the team made no effort to design or build the actual newsletter. That would come later, after the team had gathered enough data to make a GO/NO-GO decision. After the team had gathered enough data, and if the data showed that their customers wanted the newsletter, the team would move on to their next MVP, one that would begin to deliver value and learning. They planned to experiment with MVP versions of the newsletter itself that would let them test content strategy, design, and other newsletter features.
Creating an MVP
When you start planning your MVP, the first thing you have to do is consider what you’re trying to learn. It’s useful to think about these three basic questions:
- Is there a need for the solution I’m designing?
- Is there value in the solution and features I’m offering?
- Is my solution usable?
Although you can build an MVP to help you answer any of these questions, the first question is probably best answered with traditional design research methods. (In the next chapter, we discuss Lean approaches to this research.) But for the second and third questions, using an MVP adds a lot of value.
If you’re trying to answer question two, you will likely find yourself creating an MVP that is optimized for learning. If your question is about the usability of your solution, you will want to emphasize value delivery in your product. This step will allow you to “release” a product into the market and “observe” users interacting with it in realistic contexts.
Here are some guidelines to follow if you’re trying to maximize your learning:
- Be clear and concise: Spend your time distilling your idea to its core value proposition and present that to your customers.
- Prioritize ruthlessly: Ideas, like artifacts, are transient. Let the best ones prove themselves.
- Stay agile: Information will come in quickly, so make sure you’re working in a medium that allows you to make updates easily.
- Measure behavior: Build MVPs that allow you to observe and measure what people actually do, not just what people say. In digital product design, behavior trumps opinion.
- Use a call to action: You will know people value your solution when they demonstrate that they are using it. A call to action is a clear phrase, sometimes complemented by an image, that asks the user to take a specific action: “sign up” or “buy now.” Giving people a way to opt in to or sign up for a service is a great way to know if they’re interested.
Here are some guidelines to follow if you’re trying to deliver value to your customers:
- Be functional: Some level of integration with the rest of your application must be in place to create a realistic usage scenario.
- Integrate with existing analytics: Measuring the performance of your MVP must be done within the context of existing product workflows.
- Be consistent with the rest of the application: To minimize any biases toward the new functionality, design your MVP to fit with your current style guide and brand.
Of course, you’ll find that you’re trying to learn and deliver value at the same time. Keeping these guidelines in mind as you plan your MVPs will help you navigate the trade-offs and compromises you’re going to have to make.
Regardless of your desired outcome, build the smallest MVP possible. Remember that it is a tool for learning. You will be iterating. You will be modifying it. You may very well be throwing it away entirely.
And keep one last thing in mind: In many cases, your MVP won’t involve any code at all. Instead, you will rely on many of the UX designer’s existing tools: sketching, prototyping, copywriting, and visual design.
You can download the remaining free chapters from Experience Design here; author Jeff Gothelf’s Lean UX is available here.
This post is part of our ongoing investigation into Experience Design and Business.