Before MVP (minimum viable product) was a buzzword, it was something that I strived 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 startup in terms of product capability, usability, and reliability. The other two critical and closely related major issues in startups 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.

The post mortem 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 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 have to be 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. This is mostly because the individuals favorite feature (whether by use or the fact that they designed it) needs to be push deeper into the product. They perceive that this favorite feature is a favorite of most people. (yet another ubiquitous example of confirmation bias.)

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. (The good ones often work themselves in in later releases after the application has significant traction of many satisfied users.) 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 Drobox 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 addiction of flash and dazzle and the fear of losing existing customers.

First, a simple clarification: I refer to flash and dazzle as attributes that appeal to the presentation audience, no the user. These are typically intentionally distracting and often overly dynamic tasks and functions that are usually superficial, and often have little genuine value or appeal to the user (over a period of time where usage is regular or consistent. They are attributes, in this specific context, usually associated with catching the eye of the buyer (particularly when the buyer isn’t the user, and often may have little or no contact with the user.)

Hiring managers and Clients are disproportionately enthralled with this approach. 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 what to see something flashy and cool.) The interesting aspect of this is that what the executives and marketing people are often using as comparison of this level of trend is something that, in the time it takes to implement, is usually either ubiquitous or worse, a trend that is already considered passé. However, the risk involved in a genuinely new technology is a risk that, at present, is perceived as too high to invest time and resources into. This often generates faulty ideas and concepts of pseudo trends which manifest themselves in the superficial aspect of UX design which are really futile attempts at re-skinning an already flawed or outdated UX/UI.

A good example of this approach is RIM. Satisfied with their existing Blackberry market, their adaptation to new technologies didn’t account for the concurrent expectations of UX. Sadly, they waited too long before they realized that they need to start from the ground up. A recent case history that only verified the IEEE study in 2005 of why software fails. (Spectrum, IEEE  (Volume:42 , Issue: 9 ) Sept/Oct 2005). It is not surprising that amount of rationalization that companies go through, when this data is presented to them, that results in a “Well that’s not us” so as to avoid the self-examination that will implicate ‘tried and true’ processes. RIM took the initiative, finally, to essentially start from scratch. It was a risky move, and the kind of risky move that is usually a “Hail Mary Pass” before an imminent demise. As it stands, the choice seems to have been a good one since their business is improving though time will tell if they can regain enough market-share to remain viable.

As examples of MVP successes:

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.

Another example is Dropbox.

Here is a highly successful app and still remains so. It has many competitors now, but often they only knick the market-share because they often try to add too many extra features which, though they may be genuinely useful, occlude the simple function of what dropbox does so well. It looks like another drive on your computer or mobile device, and behaves in the same manner. There’s virtually nothing to learn and the mental map already exists. Additionally, it’s free and fully functional. You don’t have to pay until you want more space, but there are no crippled features (a user annoyance which is more likely to drive them somewhere else such as a competitor. There is also no ‘expiration date’ which can have the same negative effect in possibly permanent loss of business

MVP is easier to address when the product/company is a startup

This is a sadly true statement that gets back the risk factor. Few companies have the lack of hear necessary to focus an existing product. They are afraid of losing their current clients who are used to, pleased by or merely acclimated to an existing experience. The thought of losing one customer who’s actually paying money is far mor concrete than trying to gain 2 or for that matter 100 new customers who, for all practical purposes, don’t exist yet. So the status quo is far more comfortable than the unknown. Additionally, this fear is often supported by the bias of that one anecdotally happy customer over all the real data of potential but still noncustomer base. The most difficult aspect of dealing with this is that you have to talk to the executives on a one to one basis (no small feat) since trying to convince a room full of skeptics can easily overwhelm you with negative statements supported by a mob mentality. This isn’t a derogatory statement but rather one of simple human psychology. David and Goliath stories work in movies but rarely in the real world of business, especially when your dealing with internal politics..

UX of the MVP work together but the work but vary depending on the product. It is not one-size-fits-all.

This is a correlated concept of 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.

I will also point out again that the fundamentals of UX don’t change. It is a foundational approach to determining what is the best course for UX design. If I’m designing the UX for a video game, I depend on the researchers, content experts, engineers, marketing experts and executive stakeholders to provide me with the information to allow me to use my expertise to create the best experience. If I’m designing an ecommerce sight or a B2B sales application, I still need to collaborate with the other areas to create the best UX for the intended user while still producing a design that will satisfy the sales department.

Risk

This is a huge factor since many companies proclaim the need to fail often and learn, the actuality is “fail once” and you’re gone. There are ways around this by trail an error on your own time and don’t report your failures until after you’ succeeded AND there is already positive outcome (usually and most effectively in dollars.) Even then, office politics can work against you. I personally solved a company that reduced an internal process by over 50% and and eliminated 98% of the cost of that process. 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.” 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.

In medium-small to large companies.

This 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 a head 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.

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

How often I’ve heard of new startups who’s self-description is essentially “It’s like [fill in other existing startup, or recent IPO, or even old technology], except our’s is totally different. This seems to be the example of more of the startups 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 it’s intent, effective in it’s UX and has a good business model.

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. This means determining the fundamental use of the product. If this isn’t clear or you have to argue with various teams about it, then you need to step back and refocus on this basic tenant. If your response is, “Our product is complex” then you are sidestepping the answer and you will not be able to significantly improve the UX.

Take for example a complex (in fact very complex) application like Adobe’s Photoshop. It’s fundamental MVP is “manipulation of pixels.” It’ doesn’t get simpler. It accomplishes this in both simple and astoundingly complex ways, depending on the users’ needs and skills to utilize the hundreds of features as well as knowing how they may be interconnected, automated, and customized. They have even adapted this over time. Originally, it was to create (File/new) artwork with the added benefit of altering existing images, but it quickly became far more used as an bitmap (and other format) manipulation software package than one focused on creation, from scratch, of new digital bitmap images. They have not abandoned the ‘start from scratch user, but istead, have focused on their wider user base, without alienating the original base. I’m not implying that this happened without incident of problems, (Photoshop version 6 for example) but rather the method and success of a package that is long considered the industry standard.