Designing MVPs for Improved UX

How to create and test assumptions in order to rapidly learn and iterate.

In a time when dev teams are moving (or have already moved) towards an Agile software development methodology, why aren’t more design teams moving towards a Lean UX design process? Innumerable new products come onto the scene everyday, which is why it’s becoming more important than ever for designers to be able to move quickly. One of the best ways to do this is by focusing on designing for an MVP (minimum viable product) by embracing Lean UX.

More likely than not, you’ve already heard about the concept of an MVP. In case you haven’t, it’s essentially an idea in its simplest form that provides the shortest path to validated learning. This focus on learning is a big break from traditional UX design practices, which usually focuses on features and feature sets. As Ryan Hoover (founder of Product Hunt) put it so well in his now well-known article, The Wisdom of the 20-Minute Startup: “The purpose of an MVP is to learn, to validate and invalidate assumptions.”

Why hould you care about MVPs?

In essence, MVPs are the embodiment of all the best practices associated with Agile and Lean UX. These include an emphasis on collaboration and delivery (Agile) as well as measuring and validating product/market fit (Lean). Naturally, these are all great practices to implement with your whole team, but it’s worth noting that the ability to design effectively for MVPs is an especially great measure of general skill level for UX designers.

MVPs in detail

Having a holistic understanding of the concept of an MVP is a good place to start, but you need to have an understanding of its components in order to be able to effectively design for it. While the traditional UX model asks us to think about the design of a product holistically, Lean UX practices leave room for inevitable changes in plans. In line with this approach, MVPs allow us to take measured steps which can easily change according to what is learned through testing and iteration. However, choosing what type of MVP to create can be tricky because the focus of an MVP isn’t on the feature set, but on learning. While there is no one absolute correct way to create an MVP, here’s what it generally involves:

Create a hypothesis

Understand what kinds of assumptions you’re making in relation to your product — these usually relate to your presumed customers and problem definition. Out of all of your assumptions, identify the riskiest one, which you will test first. The riskiest assumption is the one that has to be true in order for your product to succeed, and yet is most likely to be false — in other words, it’s your hypothesis. While this might seem like a painful process, it’s important to go through because the sooner you do it, the sooner you can identify assumptions that are invalid and pivot to a solution that works. You might even find that a problem you assumed was widespread doesn’t actually exist (e.g. what’s the point of the Segway?)

Ryan Hoover gives a great example about how he tested an idea he and a friend had about creating a service to enable coffee customers to pre-order and skip long lines at the cafe. His riskiest assumption was that coffee shop owners have a problem with long lines.

Test your assumptions

Once you’ve formulated your hypothesis, create the simplest design possible that will effectively test it. Contrary to popular belief, you don’t always have to “build” your product in order to accomplish this. There’s a wide variety of methods you can utilize to test your hypothesis. You can go with something super simple, like an interactive prototype using programs like PowerPoint/Keynote or Prototyping on Paper. Similarly effective methods that are slightly more involved to implement include: landing page tests (Unbounce, Google Analytics, GoSquared), Wizard of Oz/Mechanical Turk experiments (Amazon Mechanical Turk), customer interviews (Olark, Intercom), looking at market data, competitive research, and more. Which testing method you choose depends on what type of feedback you’re looking for. Regardless, you’ll want to look for the test that will validate/invalidate your hypothesis the quickest.

To test his assumption, Ryan and his friend talked to many coffee shop owners and managers. They very quickly found that the owners and managers didn’t see long lines as a problem. In fact, some even saw long lines as positive because they signaled high-demand and quality to potential customers.

Learn and iterate

In the unlikely event that your first assumption is correct, test your next riskiest assumption. Most likely, your initial hypothesis will be invalid, in which case you should repeat steps #1 and #2: go back to the drawing board and reevaluate your problem definition and target audience, then test your new hypothesis.

After their riskiest assumption was invalidated, Ryan and his friend returned to the drawing board. The big thing is that they didn’t end up wasting a lot of time — they only had to spend two hours to figure out that they had a shitty idea.

In the end, you’ll probably end up using more than one approach to testing and iterating on your assumptions, so don’t feel like you have to limit yourself at the outset. You just have to look for the approach that offers the most learning at the lowest cost and best tests your riskiest assumptions. One of the most important things to keep in mind throughout the MVP creation process is that more often than not, your first idea won’t be your final idea. Nokia started out as a paper mill in Finland, Twitter was originally a podcasting company called Odeo…you get the idea.

Originally published at www.dtelepathy.com.