Good UX design isn’t data or experience. It’s both.

By Bob Glaser ©2014

The two primary types of the information that we use in UX design is the raw data that is quantitative and the experiential (or qualitative data.) When I was in college, one of the things I studied was music (mostly music theory and orchestration.) This was because I discovered in an odd and roundabout way, classical music, or more accurately, orchestral music. I had learned to read orchestral scores (those giant tomes of music on the conductors stand.) It showed what exactly what the composer wrote for every single instrument in that big orchestra. This was not a simple feat since there are times when massive amounts of information need to be processed at one time.

In the picture below is a page from a score which is three measures long, lasting about 14 seconds. Every instrument is clearly defined following the standards of a conductors score for the time.

Korngold Score

Marietta’s entrance in “The Dead City” by E.W. Korngold

Listen to the fragment here.

(I created this recording using 59 tracks for all of individual parts.)

The entire page is read left to right. A vertical line extending from the top to the bottom moving left to right would essentially cross each note as it was to be played by the assigned instruments. If each instrumentalist follows their part based on the beats (timing) directed by the conductor, a lush and grand ‘aural experience’ is heard. You don’t have to know how to read this in order to enjoy it, but if you can read it, it changes the experience. That change can be for the better or worse. Better if what they read corresponds to what is being heard. If however, it doesn’t correspond, you then realize that there are mistakes or excessive liberties being taken because you essentially have the musical blueprint in front of you. I can’t count the number of CD’s or downloads I’ve purchased for scores that I own, hoping that I’ll find one that corresponds to the score that I have. Sometimes, I may enjoy a performance despite deviations from the score, so the issue isn’t perfection but rather reaching the best outcome

So in a similar way, a good UX designer will be observing, knowing the rules and seeing how users follow or ignore or break them and then ask why. All of the ‘whys’. The object, the individual’s abilities or previous experience or lack of it, the interrelationships of tangible and intangible attributes and so on. The more information the UX designer has to draw upon and apply, the better the UX is likely to be

Experience defined

Technically, experience is anything that you have been exposed to and received some sort of sensory input. The level to which it is remembered, contextually defined, cognitively analyzed and more importantly applied, interpreted and deconstructed determines the level on whether the experience qualifies as “professional” or not.

Two different people can be in the same place at the same time, during the same intentionally pleasant event (a fireworks display, a concert, the unveiling of a new architectural structure, a scenic overview, a new tech toy, etc.) and be exposed to the same sensory input. (For the sake of the argument here, let’s not delve into the fine deviation of the fact that they may be standing 18 inches apart or that the presence of the other person; one being to the left of the other while the other being to the right of the prior mentioned person. I realize that these can be important factors for a number of reasons, but not for the sake of this argument.) Let’s assume that one person (Person A) is in a professional field that requires observations of subjective details and reasonable speculative inference on the how’s and whys of the event. The other is in a profession the deals primarily in assessing empirical data. The second person (Person B) is experiencing the same event as person A. Both will have certain emotional reactions that are similar or different based on their entire life experience. These emotional experiences, both good, bad, or merely relational, may or may not overlap regardless of the reasons behind them.

The difference I refer to regarding UX is that Person A is more likely to not simply take in the sensory input and just enjoy it. They are likely to start analyzing how it does or might work, what makes some aspect relate to another aspect, what is or isn’t intentional, what’s the science/math/physics/aesthetics/history that preceded and influenced it. Then they will think how it is better or needs to be improved, how can it be applied in other situations, temporal questions of why here and now. Person B is more likely to simply enjoy the event.

Any good critical thinker (and there unfortunately fewer than you might think) will be able to maintain the balance between pleasure/satisfaction and cynicism. This is essential to UX design. It is one of the foundations behind “You are not the user” because it guides you to be more objective, even if the subject is an emotional one. Empathy is a powerful tool in this aspect, but without the balance of detachment, the observer part of the UX designer is likely to project their own emotions onto the participant.

Data: Qualitative and Quantitative

Quantitative data is easy. It is only a clearly defined set of numbers. How many passed, and how many failed. That’s oversimplifying it, but it makes the basic definition clear.

The issues with gathering quantitative data in surveys, (assuming that it’s honest data) is whether the right questions are asked and whether the questions asked are worded and presented neutrally. In gathering observational quantitative data the most common issue is accuracy of the method of gathering the information (e.g. sample size, appropriate demographic targets, simple math errors, etc.)

Qualitative data is very important in UX design since it’s usually the part that addresses the experiential/emotional aspects of the UX. One of the largest obstacles for qualitative data is that since it can’t be statistically analyzed, it is often given far less weight when determining the UX of a product. Sometimes it is dismissed entirely. One of my early mentors once said during a presentation where changing from a black and white display to a color one (in the context of the application it would be used for) will not improve the usability of the product, but, that it should be considered for a more important reason: users like ‘color’. They find more satisfaction in using a color display over a black and white one when there are no color based attributes that would improve the usability. They will also perceive it to be of better quality even though there is no change in function or ease of use.

A different problem with qualitative data is that sometimes it’s improperly defined and incorrectly ascribed as quantitative data. When questions are not clearly defined or arbitrarily defined. For example, affluence and socioeconomic level data is often incorrectly defined in this way. This can become precarious when one considers that socioeconomic class definitions vary geographically. Additionally, what are the measurements used to determine these levels. Then there’s the self-determined reference (which will probably give you more information on state of the individuals ego rather than any true measure of affluence).

Lastly, in terms of UX design specifically, you can’t use the same levels or types of satisfaction across the board to measuring the success of a task. It is easy to fall into the trap of marketing vs. satisfying user experience. For example, UX designers are often asked to design a UI that delights the customer. This is sometimes completely contrary to an exceptional user experience. A task to be completed in a business application will produce a great user experience if the user is able to accomplish their task with as little thought about the application as possible. You don’t try to make a phone ‘fun to dial’, because the user’s intent when using a phone is to talk to someone, not to ‘have fun’ dialing their number.

User Testing

This is not a user testing “how to”, but rather points out the need for balance and understanding of the data you’re gathering and using.

When doing user testing, the methods are going to vary depending on everything from budgets to testing methodologies. Personally, I like to start with existing data and validating how it was gathered. Hopefully there is some, and if not that’s where I’ll start. I’ll make sure that I’ve clearly defined what is quantitative and what is qualitative. Quantitative tells me if something works or not, but qualitative tells me whether or not something matters or not regardless of effectiveness. It is also one of the better determinants of helping to create focus which is critical to new product development and MVP. Good research of qualitative data will tell me if the products biggest advertised feature is actually tangential to the experience. Paying attention to such things can indicate the need for a pivot in design and focus before they become very expensive (high cost with little or no return.)

I have personally gathered more usable and actionable qualitative data by focusing primarily on observation and then following up with a few questions based on the observations. This type of feedback is targeted specifically to the individuals for clarification. They can give me insights as to the ‘whys’ of actions taken. They are never used as quantitative data. Much of UX is based on quantitative data. I’ve found that certain problems were drawing a great deal of resources for fixing that were of insignificant importance to most users. These were not the infrequent but critical need functions (e.g. safety issues, calling 911, etc.) but rather functions that were far more important to the designers than the users and often weren’t dependent upon user critical functions.

Conclusion – Maintaining the balance.

A good way to self monitor this balancing act is ask your self during data gathering “What assumptions am I making?” If you say “None” you failed. So what you should regularly do is list the assumptions and track them from iteration to iteration and from project to project. This way you can identify and address potentially limiting patterns that people naturally develop.

Depending on the length of the development cycle, significant quantitative data is gathered at the very beginning of the design process, and again at the end after deployment. I’m excluding QA bug fix types of data that need to be done mid process.

Qualitative data is gathered, assessed, addressed with each iteration in the development cycle. This is often because correcting or improving an attribute of good UX design needs to be monitored to make sure that there are no snowball effects of the change. Conversely, it could create a well-reasoned change in the overall UX design.

Posted in UX Design | Tagged , | 2 Comments

UX and the Minimum Viable Product goal: An abridged post mortem example.

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.

Posted in UX Design | Tagged , , | Leave a comment

UX and the Minimum Viable Product goal: A post mortem example.

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.

Image

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.

Posted in MVP, UX Design | Tagged | Leave a comment

Is it me or has UX become a marketing tool rather than a discipline.

cropped-bgbackground12.pngThis idea stems from a seeming disconnect between LinkedIn and LinkIn’s professional forums. I use LinkedIn readers in the areas of talent aquisition/HR as an example instead of LinkedIn’s professionals in various disciplines.

I know that the primary reason that I read and respond to these forums is to both provide a potential solution or direction for the original poster’s comment or question (or in some cases a subsequent poser), as well as forcing me to carefully consider a well reasoned and cohesive response. The occasional responses that I get are typically excellent descriptions of gaps in my thought process, presentation of facts that I was uninformed of, or just great alternative approaches. Having been a design major in college, I long ago learned to leave the ego at the door and carefully consider constructive criticism and simply add that new information or perspective to my UX or analytical toolbox.

Perhaps the forums give an individual an unrealistic perspective of  self evaluation. I will use myself as the example. I belong to 42 professional forums. Out of all of these there are 12 that I participate in fairly regularly and they are:

Interaction Design Association
UX / UI Designer
User Experience Professionals Association
User Experience Professionals Network
UX Professionals
UX Thought
User Experience
User Experience || UX Professionals
UX Strategy and Planning
Human Factors and Ergonomics Society (HFES)
Mobile User Experience Professionals
Graphic Design

In these groups, my input ranges, according to LinkedIn, from “Getting Started” to “Top Contributor”, and it is apparent that these designations have more to do with quantity of input rather than quality. There may be other metrics such as numbers of ‘likes’ to a post, but I haven’t found and statement of this.

Granted, I try to answer queries with reasoned and well considered statements, facts and examples. I don’t feel that it’s a soapbox to proclaim my expertise (particularly when there are a number of people contributing who are better than I am.) I try merely to be helpful, provide additional insight based on experience, or occasionally correct “common knowledge” which is often information that ranges from outdated to superstition with actual up-to date facts based on real testing , data and sometime merely commonly known and yet misrepresented facts which are well known in the scientific community. I defend when poorly challenged and rescind when genuinely corrected. (My father, a scientist, once said to me, that the more surety I had in being correct, the more resistance and barriers I would create to learning the truth.)

Additionally, I try to segregate the theory, from theorem, from fact. I’m also careful and diligent in parsing the selective use of qualifiers like “The fact is…”, “Peer reviewed testing has shown…”, “[a] is a perception, whereas [b] is a fact…”, as well as the more open ended qualifiers such as “In my experience…”, “My user testing results have shown…”, and even the broadest “In my professional opinion…”

more and less

Here’s where I find UX becomes a marketing tool rather than a discipline. In response to several jobs, it seems that my skills have nothing to do with my process but almost entirely to do with my portfolio. My original portfolio had detailed process showing UX development (from a proactive team of three following the presentation of the idea to upper management, presentation of ROI and cost analysis research, user task analysis, personae, environment and context study, taxonomy and wireframes, first round prototypes, asset design and creation for proprietary systems, first production releases, international awards, and astounding returns (6 months inventory sold out in 3 days.) The response I got was that it was “too much to go through” even though it told a complete story of all the aspects of a product life cycle.

So, I pared down my portfolio and additionally broadened the various markets I’d created UX designs for from B2B, to B2C, to service, etc. as well as focusing of specific skills. It became the superficial overview that everyone was asking for. Except for one small aspect. A new, and rather ironic complaint. “I need to see more wireframes and examples of whether or not you can take a project from ideation to deployment and release.”

This is the Catch 22 between superficial and trivial ‘dazzle’ and substantive UX design. I feel often at a loss of trying to ask, “Do you want me to provide an exceptional UX or would you prefer the Laser show with confetti cannons?

This attitude that I’ve been presented with isn’t unique to HR and Talent Scouts but often hiring managers are choosing UX people based on flash and dazzle rather than genuinely good UX principles. I guess this should come at no surprise, since the first thing a UX designer needs to know is “You are not the user.” and that need to be conveyed to the hiring manager and/or decision makers. I don’t have a problem doing that successfully, but I can’t do it until I’m in front of  them.  It is a hard sell to tell someone that what they think the customer loves (based on highly limited and biased anecdotal feedback) is often the exact opposite of what the customer actually thinks.

I remember a VP saying to me,
“We have a customer that doesn’t like this. So know we have a data point that shows customers [clearly implying all customers] don’t like this.”
There was no further evidence nor an opportunity to gather more background information. We know had a single piece of evidence, based, no less, on a single anecdote that was being presented not only as fact, but also as a fact that no time of effort would be spent in verification.

So know I’m in the process of redoing my portfolio and pounding my head trying to figure out what the proper balance between useless superficial dazzle and substantial example of detailed process and result.

Trying to come up with a ‘happy medium’ may be a futile experiment. Here’s why. As a UX designer, unless you are comfortable working a single sector (e.g. consumer eCommerce, B2B massive data analytics, etc.) and your job is stable you will probably (no guarantees) be fortunate to remain in that area.
My problem is that I’m interested in UX regardless of the sector. My jobs have been in different sectors: telecom (at ShoreTel), postal process development (Pitney Bowes) , instructional design, multimedia development and computer based training (Xerox), Data Visualization and presentation (Gartner Group), commercial home products (Conair corporation), medical publication and advertising (Patient Care Magazine), and retail advertising (Ad Agency). Because of this, I have learned that Don Norman’s statement that as technology improves and cultures become more collectively aligned in user expectation, the fundamentals of UX have not changed.

So when I lose a job to someone else, I realize that in 90% of the cases one of three things,

  1. They have a greater domain knowledge of the sector and that commonly though incorrectly outweighs UX capabilities and experience or
  2. The job was focused primarily on a skill that wasn’t specifically UX (such as coding  or graphic design) or
  3. They are a better UX designer than me

This isn’t a sour grapes response though. I know when someone’s knowledge of UX is greater than mine and I’m thrilled when I get to work with such people. On the other hand, I’ve learned that there are many people who’ve devoted tremendous great amounts of time marketing themselves instead of expanding and improving their UX knowledge and skills. When you think about it, being well known is not necessarily a direct correlation to being better. Charlatans can (and often require) being well known in order to be successful.

The lack of comprehension of what constitutes being a good UX designer is something that hiring managers and talent recruiters are unwilling to admit. When the hiring manager is a UX designer, the problem may come from having a competitive personality that they want to remain unchallenged, or perhaps insecurity. The later is often more detrimental to the company since it puts the hiring manger in the precarious position of being bettered then ousted by a subordinate, even though any good company wants the best and having the skill and knowledge to hire someone better than yourself is good for the company in the long run and a well known company will recognize that skill in itself.

Ideally I enjoy working for someone I consider smarter than me and who recognizes that I bring something to the table that is genuinely useful and innovative. I had that experience recently and am thankful for both the opportunity as well as the knowledge that I was fortunate to leave with.

So, in all, there’s still the paradox. People want to know who you solved a complex problem, but at the same time, they don’t want to know what the complexities of the problem were, nor the extremely relevant (I know that’s superfluous, but it’s for emphasis) problem solving methods you used to alleviate it. So the simple answer is both palatable to them, but presents little in your capabilities and methods for solving the problem and therefor eliminates your competitive edge.

My favorite irony of all is that coming up with an entirely new, innovative and successful solution to a problem that has, though good UX design, been made into a simple process, seems obvious to the listener, mostly because, like the world 15-20 years ago when the cell phone was not ubiquitous, they can no longer imaging the world without it in spite of the short time they’ve been here.

Posted in UX Design | Tagged , | Leave a comment

UX: A Link In The Product Life Cycle Chain

Here is an article I wrote for UsabilityGeek about UX have equal importance the product design and development.

Link | Posted on by | Tagged | Leave a comment

Here is an article for which I was a guest poster on UXbyDesign

Becoming A UX Designer: My Path And Observations

 

Posted in UX Design | Tagged | Leave a comment