The Minimal Viable Design

It has long been accepted, thanks to the work of Steve Blank and Eric Ries, that the minimal viable product (MVP) is a fast and effective way to get early feedback on a product concept, and avoid the perilous act of over-engineering and over-designing, in light of what might be otherwise missing insights and validation. Teams all over the world embrace this approach and we, as a community of design professionals, willingly (if not lovingly) extol the virtues of designing and engineering only “what is needed”. This approach can work like a charm, and has likely saved us millions of dollars and hours that would have been spent on placing a bigger-than-needed bet on the entirely wrong horse.

Yet, the MVP approach does raise an important question for designers. -What is the minimal viable design? If a minimal viable product is expressed through a design that is too stripped down, will it sufficiently yield the insights that are needed? We all know the answer to this “no, it will not.”. How then, do we, as designers, make sure we’re designing to the appropriate level, and neither going too far, or not far enough? How do we, as designers, take control of what is the Minimal Viable Design?

In this article, I’ll share some strategies for what the MVD looks like, how to accomplish it, and how to move beyond it. I’ll break this into 3 parts;

• Part 1: How to Create a MVD, which is a series of ideas / recommendations around the issues at hand
• Part 2: What If…, which are some anticipated challenges and issues that I’ll address
• Part 3: Moving On, which is about how and when to move past the MVD (or not).

Part 1: How to Create a MVD

Idea 1: Clarify the Goal

Often, confusion and disagreement around what an appropriate MVD is stems from a lack of alignment on the project’s actual goal. Why are we making this product? What does success look like? What are the key metrics we’re trying to impact? Who is this for? Assumptions are not your friend at this stage. Other leaders in your organization may have all these answers, which is great. You, as the design leader, need to get in the loop, and make yourself and your team intimately aware of these answers. If you’re not getting the answers that you want, or if this information indeed has not been fleshed out, be a leader and help flesh it out.

Idea 2: Creating the Right MVD for Your Product

To create the appropriate MVD, first create the “utopian vision” for what your design can be. This is not your MVD, but rather your North Star. This is where you want to end up, this is what you want to see your product evolve into. You will need to allow for the time needed to create this, and it will be time well spent.

The reasons you want to do this are probably pretty clear, this ‘utopian vision’ design serves as both the rudder for where you want to get to, as well as a basis for what you’ll need to strip out. It also has an immeasurable number of ancillary benefits related to inspiring your team and investors, establishing what your brand voice is, rallying the larger organization around a goal, and more. At the same time, do not get too attached to it; the insights gained from your minimal viable product may (should) inform your product in a way that requires you to revisit what the utopian design is.

With your ideal / utopian design in hand, your next step is to remove as many elements as possible from your utopian design, in order to make it fast to produce. Strip it down. Take anything and everything that you can out. Be brave, and challenge assumptions around what needs to remain. And, do so with your product and engineering counterparts in order to make sure that what you’re removing will indeed make a difference. If you’re working as a small, scrappy ‘strike team’, you’ll move quickly and align your goals and vision. Instead, if you take this on in a bubble and lob it over the transom, you’ll be missing the point.

When this is done, you’ll have the basis for your MVD. Hooray!

Idea 3: Empower the Team, Get Everyone Else Out

Creating a MVD can be a delicate process where important decisions need to be made by the folks whose expertise resides firmly in visual communication and product development. The nucleus of the larger team needs to be empowered to create this solution, and the fewer ‘extras’ who are involved, the better. While this is generally a principle that applies to many phases and stages of product development, it is especially important during this one, because you’re all about moving quickly. Yes, the team needs to do their fair share in order to make the larger organization aware of the process, challenges, etc., but I encourage you to avoid, at all costs, an overly burdensome process with too many cooks in the kitchen, reviews, check ins, and what not.

Idea 4: Partner with Your Engineers & Product Managers

Ultimately, one could argue that your engineering and product manager partners are as much of the audience that you’re making your MVD for, as your end users. Your MVD isn’t supposed to be the perfect expression of your product and design vision. It is a means to an end, based on the premise of being able to bring something to market quickly, in order to gain insights. If you’re not fulfilling the “quickly” part of the promise, you’re not doing it right. While I generally am a fan of ‘swim lanes’ and helping keep teams focused, it is important that your MVD is created in partnership with these teams. And, it is important that your process (and your ego) allow for feedback and interaction, based on ease of implementation. This does not mean that your engineering and product manager partners need to dictate your process. Rather, it means that you’ll want to be joined at the hip, as a way to help things move quickly.

Idea 5: Use the Right Tools

A lesson I learned over and over in design school was to use the right tool for the right job. Cliche as it is, I find that it doesn’t happen as often as one might think. IIn the context of creating a MVD, use tools that allow you to move quickly between design and code, create design systems/libraries, and achieve the level of fidelity that you need. f you’ve seen a tool that you’ve wanted to try out for this kind of project, go for it — now is the time. And, if you’re not sure if you’ll get what you need out of a given tool, give the tool a quick once-over with your engineering and product manager partners. I also encourage an expanded definition of what a “tool” is. — Post It notes, Origami prototypes, PowerPoint files, hand drawings, are all viable tools.

Idea 6: Talk to Users

Frankly,I’ve never found a bad time in a product development cycle to talk to users, and the period during which a MVD is being created is certainly a great one. Beyond the overarching product concept, you’ll get feedback on how well your MVD is communicating to users. If your MVD is too basic, or too rich, you’ll want to know that early in your process so you can course-correct. The specific area that you’ll want to focus on in this kind of qualitative testing is whether the product is understood and usable , and whether enough of the brand is coming through to support the product’s promise. Don’t be afraid of your findings; if you learn that you’ve not hit the mark on your MVD, take another pass at it, spin up another round of testing.

Part 2: What If

What if… I can’t get consensus on what the right MVD is?

I hear this a lot when teaching; the overall idea of consensus building within the design process is an age old issue. While I generally do support the notion of having broad buy-in on a design solution, in the case of a MVD, my recommendation is usually more along the lines of “limit the number of people who are invited in the tent.”. Beyond your engineering and product manager partners, and your end-users, try to keep everyone out and worry less about consensus during this phase. It may well take some explaining to the rest of the organization, in terms of why this interim solution is a powerful and important step. This is also where your utopian vision can help focus your peers on where you’re planning to end up, rather than the steps along the way, as part of your process.

On the other hand, if you’re not even getting consensus from your engineering and product manager partners, you’re doing something wrong. Ask your partners “why” and what the issues are. If the feedback is that they don’t like the design and don’t feel like it represents the product vision, listen to them and look for solutions that get you closer, while also using the utopian design as the North Star, and re-stating that the MVD is a stepping stone. You also need to decide at this point the extent to which you need to create the swim lines and simply assert your role as the owner / decision maker. If, however, the feedback is more about the design not lending itself to a fast implementation, it would be very prudent to address it.

What if… my leadership is asking for a more high fidelity design

If the ask is based on your leadership’s desire to see where the design will end up, this is what the utopian design is for. Rather, if the ask is for the team to push the entire MVD further, you’ll need to work through the overall notion of what the MVP is, how the MVD fits into it, and the increased time and money that will be needed to take the MVD “far enough”. I also encourage folks to see this as an opportunity to partner with your leadership team, and help make them evangelists / believers in your process. It wouldn’t hurt at all to involve them in your research, to openly share the savings you’re helping achieve in time-to-market, and how this approach will bear fruit, in the long term, if executed properly.

What if… I feel as if my MVD isn’t telling the user or brand story that I want it to

This is the litmus test for your MVD; if users are not getting enough of your brand promise, than your MVD is probably too “M”, and not “V” enough. The devil is in the details here, and it will likely take some iteration in order to get to the “just right” solution. Don’t despair, by partnering with your team, talking to users, and having an awesome ‘North Star’ design that you’re distilling, you’ll get there.

Part 3: Moving On

Moving past your MVD can sometimes be more challenging than you might expect. Though, if you’re moving past it, the concept is having some success, which creates a bit of the prefect argument: “Why do we need to change this if it is already working?” We all know that this is silly question; do automotive companies sit around thinking each year “last year’s model sold fine, why should we bother with any updates?” Of course not. Yet, inertia can be a funny thing; workflows are established, people become accustomed to (and often attached to) the MVD. Some strategies that I’ve seen work in this kind of circumstance are as follows:

A. Seed the Evolution During Your Process

Establish, with your partners, when and how the ‘migration’ will take place, assuming you achieve success through your MVP. By baking this into the plan, it will not be an afterthought that ends up being de-prioritized. Along these lines, think realistically about how this work can be completed in an efficient manner; it does not have to be (and rarely is) an “all or none”. You may address this in phases. Or, you may address one dimension of your product at a time (such as color, or photography, or typography, iconography, etc).

B. Keep Repeating Yourself

Constantly remind your organization of your utopian design. — Don’t just create it once and then put it away for months on end. Print it out, poster the office with it. Use it in your design updates that you actively share out with the rest of your company. As the old saying goes “Out of sight, out of mind.” if you basically hide this, it will be hard for the rest of your organization to stay excited about it.

C. Test It

Conduct research on your utopian design (not at the same time as the research you’re conducting on your MVP; this will muddy the waters) and seek out ways to improve it, even while you’re in the throes of your MVD. And, when you do so, share these findings with the rest of your team and organization.

D. Be Willing to Not Move On

One of the hardest parts of designing is managing the balance between challenging all assumptions by believing that the impossible is possible, while also maintaining a level of confidence around what we can consider to be “good design”. And yet, there are times when we are surprised and don’t realize that we’ve finished running the race a few miles back and have actually gone too far. While I realistically don’t see this happen often, it takes a whole lot of guts to be able to say that a more distilled version of your utopian design is actually the right solution, and that the utopian design isn’t as utopian as you thought it was. In this case, don’t force it. Really, don’t. Don’t create unnecessary work, only to save face, or stand by “what you know to be right” when every other indicator around you is telling you otherwise.