By Robert R. Glaser UX Designer ©2014

Before MVP (minimum viable product) was a buzzword, it was something that I have striven for. In the past, the most common obstacle was not surprisingly the common executive decision that for any product a customer would see prior to an often lengthy introduction (re: mini or not so mini-training session) had to show at the top level, every major feature the application/service/device could perform. It was the competitive stance of “Our product is better than the competition because we do more for you, and you can see it right here.”

Now, MVP has become the highest level buzzword for the start-up in terms of product capability, usability, and reliability. The other two critical and closely related major issues in start-ups are money based. One being VC and the other would be profit. Executives loved it until the understood what it meant and what they would have to do to implement it.

A note in reference to the abridgement of this postmortem: most of the removal of the extraneous information was based on either preventing excessive length, issues that weren’t MVP related or issues specific to the environment.

The postmortem of a recent project I worked on.

I use this project because it was a good example of the commonly confronted issues I’m addressing here and I’m selectively leaving out issues that were project, sector or unique use case specific. The final product was moderately (at best) successful when it could have been far more successful. By “moderately” it improved sales by almost 100%. Much of this success came in the form of ‘selling the UX’ rather than in the effectiveness of the UX because of the possible impediments that could have been easily and fairly cheaply (in fact extraordinarily cheaply when accounting for profit margins.)

First I developed my strategy.

This was based on the

1. User analysis (psychology, cognitive, environment/context, business sector)
2. local product development environment
3. direct user tests
4. heuristic evaluations of each of the existing products and workflow for each of the products
5. market based analysis
6. competitive research
7. Business goals of the new or updated/replacement products.

Now, I thought when coming into this project, that the existing product was an MVP although not without flaw. The existing products primary and by far the most significant (though not only) flaw was that the user was often unaware of whether they were using the company’s app which had many significant advantages and value) or the native app that came with the device. So minimally, if I were to address this UX problem, it wasn’t one of usability, but of creating simple user differentiation. Simple to address but outside of my somewhat rigidly assigned scope.

There were a number of obstacles that I needed to overcome. First, was to determine which obstacles were achievable and which were the “insurmountable brick walls”. I’d learned in the past, to not assume which are likely to be which, since office politics, (siloing, territorialism, etc.) and biases vary from company to company. In addition, there is the issue of individual clout which can be based on expertise, seniority, or in smaller companies: financial investment.

I won’t go into risk-reward issues, in any depth, since there are myriad articles already available on these areas. I will briefly say that what’s consistent in taking risks (and the ‘fail fast and fail often in order to learn’) is the reward vs. loss is often ignored out of fear. This is merely a reinforcement that the low risk short term small gain will almost always outweigh the long-term geometrically larger gain in terms of comparatively low early investment costs of high risk design vs. the safety of long term small, but possibly consistent, profit that comes from the higher production costs of corrective post release development.

1 User analysis (psychology, cognitive, environment/context, business sector.)

This issue was almost completely dismissed because of the single most common mistake of the developer/PM who doesn’t understand or even know about the basic usability maxim: “You are not the user.” What I find really amazing about this, particularly is the constant examples of confirmation bias in decision makers (or anyone in a position of power who can blindly dismiss usability facts.) It  most often manifests itself in the “I do it this way and everyone I know does it that way too.” or the somewhat weaker “I do it this way because it’s the best/smartest/most efficient/logical way to do it.” In these cases, There is often an inability to separate the empirical with the personal preference.

2 Local product development environment

Here we have a different issue. Sometimes the SW engineers see the work of the UX designer as someone who’s great pleasure it is to through a monkey wrench into their smoothly operating process. There is also the issue that UX design is an arbitrary “touchy feely” discipline that lacks the precision and hard data and requirements derived from that hard data. In this case it is looked at as step in the process that someone decided on as a whim or useless trend with no real value other than creating another unnecessary person on the payroll.

3 User testing

This to me is often perceived as the biggest waste of time. “We already know our products and our users.” This attitude is usually strengthened by distance between the product knowledge from the development stand point and the actual user (as in having never met a real end user and only a few internal users who aren’t developers or QA people.).

4 Heuristic evaluations of each of the existing products and workflow for each of the products

This is probably one of the few areas where internal input is useful. The only caveat I’d have here is time spent on solving unlikely situations that could be better spent on refining and improving the UX more frequently used features.

5 market based analysis

Usually this is fairly easy and often marketing has easily accessible data as long as they give you access to it. (I’ve had occasions where they were highly protective of this data and I never got a reasonable, if any, explanation as to why. These kinds of issues are often not worth spending time trying to discover the why when you could be gather information yourself.)

6 competitive research

Same issues as No 5

7 Business goals of the new or updated/replacement products.

Sometimes these are in the form of tribal knowledge (‘everyone’ knows it but it’s not written anywhere) which can lead to varying interpretations (many of which can be completely wrong). This will lead to unfocused business goals.

In other cases, the business goals are stated but not properly tied to actual work being done. In these cases, it is crucial to simply ask if the current business goals are being met, if they need to change due to the current business environment or sector activity. Here, my goal is to present UX specifically in terms of the current business goals. If there are significant business goals that are counter to creating a good UX, then these need to be addressed point by point. Also, each point needs a correlation to UX, and its ROI as well as a suggested strategic and or tactical approach to dealing with it.

Now the hard part – MVP

Here’s the acronym that everyone loves until they mistakenly perceive their pet features and capabilities being thrown under the bus. In recent gatherings and seminars, I’ve begun to notice the ubiquity with which the the MVP concept is dropped like a buzzword at a networking meeting where no one wants to acknowledge that the prime requirement is the ‘trimming of the fat’ of an application.

My father used to tell me. “Always leave a party while it’s still going on and fun, because you will enjoy the party and remember it well if you left wanting more rather than being disappointed as it faded.” This is where in the words of Don Norman, you need a “Design Dictator”. One who will throw out all ideas, both good and bad that do not simply focus on the primary purpose of the application or product. Leave your users wanting more and then later, after adoption begins to grow because you did “ONE THING EXCEPTIONALLY” you nay then slowly and methodically add features to the product. Timing is everything here. This is not done without all of the customer/user research previously mentioned.

A simple project is hard to accomplish because most of your obstacles are going to be internal. It you show an app like the highly Dropbox to someone who’s unfamiliar with it, you will rarely get the res-response of uninterrupted attention that you would get with a flashily designed UX of a new product that full of bells and whistles that “users are craving”. These later apps are typically “flash in the pan” with big releases and slow painful discards.

The distraction and addiction of flash and dazzle.

Hiring managers and Clients are disproportionately enthralled with this approach. This is not about stupidity but rather a lack of the understanding of good UX. There is no amount of decades of history in marketing classes that have been teaching this basic tenant of marketing. “there is no amount of brilliance in marketing that sell a bad product twice.” This has not changed. The one thing that has changed is that a product that is disliked in the contemporary marketplace will be discarded because of a bad user experience and the not only does this place a bad taste in the consumer/users mouth, it spreads to other products in the brand, often whether it is deserved of not. The market place is far more transient and fickle in today’s market.

Yet people (executives and marketing people and even developers) want to see something flashy and cool because they can sell it. This is clearly more of a B2B issue than B2C since the direct consumer (particularly when deluged with free versions of apps) is quick to discard (or allow to lie dormant) any application which doesn’t do exactly what they wanted quickly, easily and as expected.

Consider the original Twitter, a fairly simple UI which after adoption, feature were added, but not until the basic premise gained widespread adoption with it’s still simple UI prior to Hashtags and embedded links became part of the experience in a more subtle way than you might imagine. This would not have sold had the developers not taken it on themselves to bypass the ‘experienced’ naysayers and put it out there.

A correlated concept is what the MVP is supposed to do. If it is supposed to entertain, then dazzle is actually a relevant attribute. However, if the function/tack is one that the user simple wants to complete or needs to achieve in the easiest possible way, then invisibility is the goal. Your goal is to create a path that the user doesn’t have to think about, one that’s intuitive, unimpeded, and designed for a low cognitive load through mental mapping and minimal choices. There are of course, user experiences that fall between these ends of the spectrum as well as UX that include environmental elements and contextual elements which may be also considered whether they have to do with a narrow user based with special skills or a litany of government regulations. None of these restrictions should prevent an excellent UX and often an innovative one.

This attitude of dazzle over content stems from two primary perspectives which the individual may be be prone to one or both.

1. The ignorance of the difference between ease, affordance, intuitiveness and attributes like usefulness and affordance.
2. The other is one of distraction. This is not unlike the magicians trick. This is particularly evident in demonstrations that we are exposed to numerous times a day in the media, by sales people. Here, the ‘slight-of-hand’ is exemplified in the statements like “All you do is this.” And the result seems to appear in the click of a button, where there are two separate intentionally distracted aspects
   1. The demonstrator will talk while doing tasks that are not being enumerated.
   2. The set up demonstration often has many preset settings, prepopulated data, and even preworked example ‘starter files. (Anyone who’s done an online tutorial will know just what I refer to.)

The “Minimum” portion of the MVP. Excluding most products that have yet to be developed, this is often a big pill to swallow. In fact, the larger the company is, the larger and more unwieldy this pill becomes. This is because the term is singular. Most companies, regardless of the size, have their own pet assets and features that they consider the most important, and it really has to the one single task that is done in such an excellent/seamless/flawless/sin qua non way that the competition cannot broach.

Risk vs. reward

This is a huge factor since many companies proclaim the need to fail often and learn, the reality is far closer to “fail once” and you’re escorted to the door. There are ways around this by trail and error on your own time when you don’t need to report your failures until after you’ve succeeded AND there is already positive outcome (usually and most effectively expressed in potential revenue.) Even then, office politics can work against you. I once personally identified a company process that was both costly and moderately time consuming. I took it on myself to develop a solution for the company that reduced an internal process by eliminating 80% of the internal labor, eliminated approximately 98% of the cost of materials as well as completely eliminating the outsourcing expense of time (which was a minimum of 24 hours). The perception was taken, at the local hierarchy level as one that might be perceived in terms of “Why were we talking so much time and spending so much money until now.” Essentially saying that if this improvement is made, the department may be viewed as have wasted a lot of money, time and labor up until now. So never underestimate company politics which can become very complex and unpredictable as the size of a company grows. This is just one story, and may not be valid in many companies but it is far more common than you might think. Companies do not admit this, but that doesn’t mean it isn’t true. On a side note, the process was implemented, but I could write an entire blog on that alone.

The other aspect of the risk-reward paradigm of development is that it is very common to assume the causes of success or failure and these assumptions are rarely made on data with significant samples to back them up. The common reason for this is not empathy, but rather, that it will take the clout away from the assigner of reward and blame.

Personally, I want to know if the success of a product is because of or in spite of the work I did so that I may learn from the error (if that’s the case) or know that a good decision was made could be considered (but not blindly applied) to the next round of development.

Start-ups and very small companies with limited products (lines)

How often I’ve heard of new start-ups who’s self-description is essentially “It’s like [fill in other existing start-up, or recent IPO, or even old technology], except our’s is totally different. This seems to be the example of more of the start-ups that I’ve come across than the ones that are a genuinely new concept. Of the former, the biggest obstacle is the competitive race to gain the critical mass of adoption that makes them win, and a significant portion of that is luck and timing assuming that the product really is effective in its intent, effective in its UX and has a good business model.

Lack of focus due to feature bloat doesn’t seem to be a problem until an app has been released and possibly building momentum or even profit. Here is where the delicate balance of MVP and added features can so easily sway towards the added feature, thus overweighing the improvement of the primary function first. This is not to say that new features should be avoided or discarded, but they need to be governed in a way that makes them

If the product is on the other hand, a new invention (as opposed to an innovation), then competition is far less important than comprehension and adoption. Here’s where ‘first follower” can be a significant aspect of this. See for example Derek Slivers TED talk on this http://www.ted.com/talks/derek_sivers_how_to_start_a_movement.html

To paraphrase what Don Norman PhD said, the biggest common problem with most product startups is focus on the minimum viable aspect and not letting additional features and capabilities lead you astray.

In small-medium companies.

The MVP feature is going to require thought and collaboration for its proper definition as well as buy-in and accepted by all who work on it. You may look ahead into future possibilities but minimal time ought to be spent on this future development until the primary MVP is met. Remember, before the iPhone was the iPod and all it’s incarnations, or more generically, before the smartphone was the cell phone. The MVP of the cell phone was merely it’s portability. Seemingly a small feature, but one that changed the world. Like the transistor replacing the vacuum tube before it (for you history buffs and audiophiles), it changed the landscape of broadcasting. There are many things in hindsight (TV, internet, etc.) as there are in the present that are in the midst of transmuting the world like electric cars, alternative energy, social media, new interfaces – many of which are nowhere near being new but are finding development audiences and possibly public adoption.

I would use a product that I was very involved in the UX on but I that may create the impression of bias so let me use Evernote as an example via observation and survey. To be honest, when I first downloaded it a few years ago and started to use it, I could not see any great benefit. Now, I read about it and all of its powerful features. The problem remains though. Its use isn’t that intuitive, because so many features are overwhelming, and while many are presented in a simple way, the results are not. I realized that I had several other applications that did some of the things that Evernote did but these other applications were so simple to use, the advantages that I was apparently giving up by not using Evernote instead were not as important to me as was simply completing the task at hand. Now I know that Evernote has many powerful features. If someone gave me an older used Cray computer for free to put in my basement for some awesomely powerful multithreaded processing power, that would sound great until I realize that I would have to invest a great deal of time into understanding how to set it up, then the time of actually setting it up, and then making sure that I’m not losing some significant regularly used features from some little Dual Xeon PC. Yes, I know the comparison is extreme but it points out the primary problem.

Now, while I read and hear all about Evernote and am regularly impressed with the press coverage, I’ve yet to run across one person who uses it (though I’ve run across many how have installed it on their mobile devices. In all the cases where I could, I asked why they installed it, and the general answer was “to have an easy organized way of [various individual tasks for each user]”, Then after I found that they were not using it, I asked why, the answer was the same in all cases. “Because I use [single task application] instead because it’s easier and/or faster to use. At this point, follow up questions preceded by “But did you know that with Evernote you could [fill in appropriate related feature here]. I didn’t, because those are more marketing issues and they circumvent the primary focus on MVP. I did notice a number of comments saying that the user used another application instead, clearly indicating that they were unaware of Evernote’s other features or that the other features were difficult to ascertain as to their use in terms of integration into the product as a whole. There is no irony in my opinion of Evernote in terms of its functionality is that I am impressed with the implementation and integration of technology that they have incorporated and are incorporating in their product. This makes it apparent to me an extraordinary application which needs the focus of an MVP which would not compromise its power.

Now it appears that while Evernote is taking steps to alleviate this problem, it points another common problem pointed out in the EEEI Spectrum Issue on Software Sept 2005. “A problem not solved before release of a product typically takes 100 times more money to fix it after the release.” This is not simply the resources of correcting the problem, but also includes costs of regaining lost market share, or re acquiring previously annoyed/confused/angered users.

In large companies.

An application like Adobe’s Photoshop (or Autodesk’s 3DS Max and many others, but I’ll use Photoshop as the example) on the other hand, already has a majority market share and is used by a multi-sectored user population, Each of these demographic groups, typically has a primary focus. Web asset creation, commercial retouching, bitmap artwork creation, technical image manipulation (color correction, etc), and others, not to mention the myriad of amateur users and their needs. The Photoshop MVP approach is a relatively simple interface when first installed that is easily customizable to the user’s specific needs. The more advanced the user (which in this case is a very large population) knows most of the ins and outs of that customization of such a complex program.