Minimum Viable Product and Lean UX
When you want to assure clients that you are careful and efficient in your design approach, you might offer this adage: “Measure twice, cut once.” This motto implies that you adhere to rigorous standards and apply old-school craftsmanship to a project. After all, it’s the sloppy carpenter who wastes good wood with an imprecise measurement.
But the design landscape is undergoing profound change due to the advent of a Minimum Viable Product (MVP) as part of the Lean UX process. The key concept here is process: design that is the result of multiple iterations that are contoured by multiple sources of information and data.
Basically, measure once, cut once, measure again, cut again, and so on until you have reached a MVP.
And an MVP Is…
The truth is, there’s no single definition of a minimum viable product. In some ways, it’s better to begin with what it’s not. It’s not a prototype, because prototypes aren’t put into production. Neither is an MVP the first version of a design, because again there’s no real data being generated by users.
Thus, it’s crucial to understand that an MVP must generate data, so in effect, according to Eric Lies, author of The Lean Startup, an MVP is a version of a new product that allows the design team to learn as much about the product from actual users with the least effort.
Put another way, an MVP is the thing that the client most values. Or it’s the features set that fixes a pressing problem. Or it’s the thing a company can make the fastest that still functions. All of these definitions work, depending on the perspective taken of a stakeholder in the design process.
Now that we know that an MVP is a product that helps define value to a client, why should designers use this process? The easy answer is that the MVP factors in risk and reward. A new product carries the very real risk that either the client won’t like it or users will reject it. From a design standpoint, the temptation might be to add on features in order to cover all the bases, but this approach entails flying blind. What features should you add?
“Featuritis” is a disease you don’t want to catch.
That’s where an MVP can prove valuable. Let’s break the words for s deeper dive. It is a viable product, meaning that it can exist and be produced on its own. But it’s also the minimum, the least in terms of sunk cost and features. It’s stripped down and essential, or technically the best result of dividing return-on-investment by risk.
The MVP is intended to save money in the long run, to avoid having to go back to the drawing board and begin anew in case something goes wrong. That is, if users are experiencing friction on your page, something has clearly gone awry and solving the problem is a design issue. But clients want the problem solved by spending the least amount of money possible. These competing demands of rock-star UX and dirt-cheap solutions are what an MVP are built to handle.
But it’s difficult to understand the process that produces an MVP without diving into the largest context of Lean UX. In fact, the MVP is just the first stage of three that make up the intellectual core of Lean UX.
Lean UX is a way of designing products that discards the traditional playbook for something more like a Socratic seminar. A traditional approach might center on the twin demands of “requirements” and “deliverables” that are usually articulated by a client and then enshrined in a formal proposal. The design team then sets out to build what is called for.
But Lean UX eschews this approach for something far different, based on three pillars: Build, Measure, and Learn. It is hypothesis driven, meaning that any assumption about a product must be tested and verified with user data. The point is to create a product that has the best UX, and that can only happen if design teams can glean info from actual users and respond to the data.
The MVP is the fulcrum for the entire Lean UX process. It is the centerpiece of the Build phase, and no assumptions can be tested without an MVP. The user sits at the head of the table and drives the design of the MVP. Here some contextual inquiry will be very useful. Interviews with users can provide needed guidance on the parameters. In an initial MVP, the code won’t be finalized and the wireframes will remain roughed out. You just need something that users can interact with.
When users engage the MVP, now you’ve entered the measure phase. This is data collection that will shape how the assumptions play out. This usability testing will unearth error rates and other forms of friction. If users are spending too much time completing a task relative to an optimal benchmark value, then you can adjust your assumption and again test to see if you made the right adjustments.
Lean UX is predicated on a constant loop of gathering and analyzing user data. The learning phase is where the MVP can be tweaked–the part where measuring and cutting carry on in as many iterations necessary to document the assumptions about a product. A well-constructed MVP will be vetted with lots of supporting data to justify the design.
Be warned: an MVP is not something that a design team can pull out of a hat. By its nature, Lean UX is a very collaborative process where a design team must vibe dedicated to the idea that data will drive decisions. Alignment can often become a challenge if there are disagreements.
But the point is to create something that users find useful and even enjoyable. Lean UX puts every assumption under a microscope with a user-centric approach that focuses on the major purpose of a design instead of getting caught up in requirements and deliverables. The forest–not the trees.