I gave a talk at Refresh Chicago last week and afterwards a fellow came up to me with a question. He does UI on a team of mostly engineers, and the engineers are big fans of the “Minimum Viable Product” concept. MVP, if you aren’t familiar, is an idea from the Lean Startup scene. In a nutshell, it means to do as little as possible so you can learn if you did the right thing or not. The fellow who approached me after the talk was having a problem with MVP. It seemed like their product suffered from bad experience holes. Their team was trying to do the minimum possible to ship, but their definition of minimum didn’t include things like a smooth way to reset your password. Things like password-reset were “never important enough”, so they languished as swamps of bad experience among the dry hills of minimally viable features.
Does the minimum-viable approach lead to gaps in the user experience? It doesn’t have to. There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.
Features can be different sizes with more or less complexity, but quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.
I like to visualize software. Here’s an intuition that works for me. Feature complexity is like surface area and quality of execution is like height.
I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I’m committing to a baseline of effort on the user experience. That way feature complexity — scope — is always the cost multiplier, not user experience. There aren’t debates about experience or how far to take it. The user experience simply has to be up to base standard in order to ship, no matter how trimmed down the feature is.
Minimum viable products are about learning what you need to build. They are matters of surface area. Whatever minimal feature set you decide to build, you can decide to build it properly. That commitment to quality at every step is the way to keep customers with you as you work upward from minimally viable to featureful and beyond.
Ryan wrote this on Jun 27 2011 There are 24 comments.
Henrik N 27 Jun 11
I very much agree, and that’s a nice way of visualizing it.
And this goes not only for UI but very much for back-end work as well. You can settle for “make it work” and move on to the next feature, but realistically you won’t get the time to go back and make it good later.
Anonymous Coward 27 Jun 11
@37signals
If only I had a penny for every time you blogged about keeping products “simple” ... I’d be a mega-millionaire by now.
Vitali Kniazeu 27 Jun 11
@Anonymous Coward
About 4,410 results * 1 penny= $44.10 Can I join you where that makes you a mega-millionaire :-)
Alex Le 27 Jun 11
Password Reset is more important than most people expect. It would be pretty simple to add a link to the log in page that said “Reset my password” that simply counted how many times it got clicked and had a message saying “we haven’t implemented this yet but please email support@somesite.com”.
I bet the engineering team would be surprised at how often it gets clicked. Lean is about measuring and not assuming you know what customers actually want.
RS 27 Jun 11
That is, by the way, something I don’t like about lean. If you don’t know what your customers want, you’re in the wrong business.
The practices for avoiding waste and getting early feedback are good. This other stuff about not knowing what you are doing doesn’t make any sense to me.
Steve R 28 Jun 11
I love the visualization. Makes the case in a very easy to comprehend way without losing explanatory power or significant detail. I will steal this mechanism and attribute.
Jonta 28 Jun 11
Just a quick unrelated thing (delete this when you’ve read it): Above closed blogposts, it still says “n comments so far”, implying that more are to come. Which they.. aren’t. Or have I missed something?
My suggestion: Transform it to “n comments” when commenting is closed.
Alex Le 28 Jun 11
@RS: Agree that there are good and bad elements of the “Lean” philosophy and I also think that products tend to be better when the designers are their own customers. I think “Lean” is about bridging the gap between what you-the-designer want and what a huge market of consumers wants. In reality the work usually lands somewhere in between “knowing exactly what to do” and “not knowing what you’re doing”.
I don’t personally subscribe to the philosophy primarily because it hasn’t been fun for me to build things that way.
Tomi Zilk 28 Jun 11
I must admit that I found it a bit hard to conceptualize until I got to the diagram, thanks
Gabriel 28 Jun 11
User experience quality is constantly a second class citizen with large corporate’s internal applications. I’m always stumped as to why internal applications (from my experience) don’t enjoy the same user experience as applications we ship to customers.
Insightful and articulate. Thank you for this. I’ll be sharing with my co workers.
Peter Boersma 28 Jun 11
If “complexity” is the cost multiplier, there’s still the issue of measuring complexity of a feature: a feature may be complex in terms of software, but simple in terms of UX, or vice versa. I assume your complexity (surface) isn’t just software and quality (height) not just UX?
(And then there’s the fact that some features are related to each other, independent of the individual features’ complexity, but I guess that’s dealt with by talking about a “set” of features, implying that some features come in pairs or triplets – think create/edit/delete.)
RS 28 Jun 11
Peter, that’s a good point. I addressed that on this post about visualizing UI and code layers. In the post I compare “icebergs”, products with a lot of code and little UI, to “layer cakes”, products with a small amount of code roughly corresponding to each bit of UI . When your code largely interfaces to other code, then it can be difficult to estimate. Fortunately it’s more common for us (and I think many others) to write features that have a balanced amount of code and UI.
Adnan 28 Jun 11
Are you saying that UI for an MVP should follow “Get Things Done?”
Jim Benson 28 Jun 11
I am saddened by your take on lean.
My view of lean is that it’s about respecting everyone involved and understanding your full value stream. This includes customers. You cannot create software of quality without understanding and respecting what your customers actually want. Their desire and needs are the final arbiter of quality.
Waste reduction isn’t really the central focus of Lean, it’s part of corruptions of Lean like six sigma which took a by-product and made it a sales campaign. In the process, they created a popular, though incorrect, vision of what lean was after.
In agile, we gave lip service to understanding the customer. We created client proxies and product owners which were arguably much better than what came before – but did not go far enough. When I work with teams to build better software, we include the customer in the entire process.
I like your point about MVP degenerating into a barely launchable prototype. It’s a fine line to walk.
Matt 28 Jun 11
Height is an interesting concept. keep in mind how much volume it takes to increase the height(user experience) just a small amount. Did u mean to correspond volume to work or am i just reading into it.
RS 28 Jun 11
Hi Matt. Yeah, I think your “volume is work” metaphor holds true for the illustration. The idea is that most of the volume (work) comes from increasing the scope because the height (user experience) is more or less constant.
Mike B. 28 Jun 11
Great concept and illustration. I’d almost like to see the converse illustration with peaks and valleys representing the disparity in quality.
Igwe 29 Jun 11
ryan, when is your book coming out? Have found your articles on design to be very illuminating. lots of aha moments.
TotalTab 30 Jun 11
So in my view, this is just a balancing act.
IMO : MVP doesn’t mean you drop quality. It means you drop features. Releasing a product that has buttons that don’t work at all, to me, is just stupid. Remove the buttons in that case.
MVP simply means reduce the feature set of the product to its lowest level that people will buy into. It still has to be secure.
I “sort of” wrote about this in the context of mobile apps in this blog post here: Building High Quality Mobile Apps that are Easy to Use.
Great post! I particularly love your chart.
Ross Belmont 30 Jun 11
Question: does anyone see a downside to having different levels of height (beyond the minimum of course)? Maybe even vastly different levels for “more important” areas of the application?
Let’s say password resetting is functional and “good enough,” while Messages and To-do Lists are polished to perfection. It feels OK to me to lavish effort on specific features if there’s an outsized usage pattern or customer benefit. Does anyone have a counterargument?
Example: scrolling in iOS is always smooth, but setting an alarm in the Clock app takes more taps than I’d like.
Willem Maas 30 Jun 11
Only counterargument would be making that investment on intuition, gut. Armed with research that supports it, polishing “more important” areas sounds right to me.
Anonymous Coward 01 Jul 11
@Ross. I agree in a general sense, but i have two thoughts.
1. It is a tough balance to achieve and I’ve seen it backfire. good enough turns into ‘we have spent alot of time on this part so it has to be good enough right?’ 2. I think in the context of MVP the feature set is so small that they all have to be the same level by definition of the methodology. (everything is important otherwise it wouldn’t be in our feature set) maybe a over generalization of the philosophy.
just my thoughts.
Matt 01 Jul 11
the above comment is mine. forgot the name and email fields :(
RS 01 Jul 11
@Ross said “does anyone see a downside to having different levels of height?”
As long as each area has a minimum baseline of quality, then it’s no problem. The more you can improve things, the better. I don’t think everything has to be at the exact same level once the baseline is met.
This discussion is closed.