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.
Henrik N
on 27 Jun 11I 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
on 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
on 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
on 27 Jun 11Password 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 [email protected]”.
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
on 27 Jun 11That 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
on 28 Jun 11I 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
on 28 Jun 11Just 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
on 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
on 28 Jun 11I must admit that I found it a bit hard to conceptualize until I got to the diagram, thanks
Gabriel
on 28 Jun 11User 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
on 28 Jun 11If “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
on 28 Jun 11Peter, 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
on 28 Jun 11Are you saying that UI for an MVP should follow “Get Things Done?”
Jim Benson
on 28 Jun 11I 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
on 28 Jun 11Height 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
on 28 Jun 11Hi 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.
on 28 Jun 11Great concept and illustration. I’d almost like to see the converse illustration with peaks and valleys representing the disparity in quality.
Igwe
on 29 Jun 11ryan, when is your book coming out? Have found your articles on design to be very illuminating. lots of aha moments.
TotalTab
on 30 Jun 11So 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
on 30 Jun 11Question: 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
on 30 Jun 11Only 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
on 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
on 01 Jul 11the above comment is mine. forgot the name and email fields :(
RS
on 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.