UX is UX is UX – right? Not really.
User Experience Designers (UXDs) working on Minimum Viable Product (MVP) builds have it rough. The thought process has to shift ever so slightly in MVP builds, and in such a way that it can disrupt your conception of what “good UX” really is.
UX Designers, listen up: MVP builds serve a different purpose than full builds. MVP builds are tasked with learning as much as possible about the features required by users.
Rather than producing a fully-featured product, which addresses the needs of every possible user type, MVP builds are designed to create the absolute minimally viable product—one which creates the smallest feature set that someone would pay for, or even just use.
In turn, the UX process has to change, slightly, to reflect this.
So, you ask, how does it change?
UX In MVP Is About Changing What You Measure
UX Designers, at a really high level, are tasked with:
- Building out features
- Building them well (to put it bluntly)
Ryan Singer of Basecamp has designed a very good way to visualize this. Let’s call it “the blob”.
UX Designers are taught from the get-go to ask themselves: “Is this user friendly?” — is the blob deep, and does it take up a large surface area?
In MVP builds, a new question begins to take precedence:
“Would users pay the same price for this feature set?” — does the blob really have to be this huge?
The idea here is simple. In MVP builds, the depth of the blob should never change — that is, the quality of execution ought to remain consistent. The surface area, however, is what becomes the subject of significant scrutiny.
By diminishing the surface area of the blob, you are able to experiment with the notion that, perhaps users are perfectly okay without the ability to fulfil a particular task that, otherwise, you would have spent precious time perfecting, and time is money.
Testing feature-set viability is the bread and butter of MVP-driven UX Design.
And Becoming More Agile
The classic MVP [Build → Measure → Learn] cycle is the source of inspiration for the UX process in MVP builds:
[UX → Measure → Learn → Repeat]
Such a pattern emphasizes two key qualitative differences between non-MVP and MVP-based User Experiences: MVP builds ought to be produced quickly, and they ought to offer the absolute minimum set of features deemed acceptable by users.
Your UX senses are tingling here, I know. This goes against what you’ve learned about UX, and feels wrong. You take pride in the quality of your work, and in the depth of features that you account for in your designs.
UXDs: MVP builds do not inherently create gaps in the UX, contrary to what you may believe.
Speed, here, does not necessarily equate to the absence of quality. Adopting agile methods in your UX Design process will ensure fast, “quality” cycles of work, due to the inherently repetitive model of testing that is used in the Agile process.
This does not mean that building an MVP is a straightforward process. In fact, at my place of work we have found it beneficial to create a dedicated page to explain the importance of MVP and assist potential clients with building one. What I suggest is: Trust your UXD judgement, and embrace the MVP process and you will not be led astray. Kinks will be worked out in the multiple rounds of testing, while missing features will be discovered and implemented, during the many [Measure → Learn] portions of the Agile process.
Most importantly, don’t forget: MVP builds are an excellent opportunity to learn about your users, and what they want from you. Often, what you give them is much more than they are willing to put up with for the price.
And if that sounds too cynical to you, you’re in the wrong business, my friend.
(Lead image source: Pulpolux !!!)