Show me your UX work.

Show me your UX work – The portfolio and skill assessment in UX.

By Bob Glaser ©2014

The UX Process

From whiteboard to delivery.

I am occasionally annoyed by the often misleading concept of the UX portfolio. The very concept of it is often paradoxical. Showing completed work doesn’t address the myriad problems and directional changes and all the complex dependencies that drove solutions that were used to achieve the result. When those problems and associated solutions are presented, it is often overwhelming. What’s worse, is that no one has time or wants to read a lot about the problems. The paradox is further strengthened by the request for demonstrating simple solutions to complex problems. By their very nature and designation, a complex problem is ostensibly complex. You cannot understand the rationale and elegance of the simple solution if you don’t understand the complexity of the problem, and not merely that the problem was complex, but how and in what ways.

How often have you been in development meetings or brainstorming sessions and had each solution knocked down by one countering practical reality after another, not to mention personal agendas. These practical realities may not be known until you suggest solutions. This winnowing process is often time consuming but important, because it progressively leads you toward the the better solution given current restrictions. I avoid the ‘best solution’ because I’ve not worked on many problems with unlimited timeframes.

You can pick one specific example to explain that, but often, that may not be the problem to solution process and result that the viewer of the portfolio is looking for. They want a specific match rather than an example approach. If that approach is generalized, then you run the risk of not being specific enough. I’ve had reviewers look at a project and say, “Well that’s not a particularly complex UI.” To which, I will respond that “The UX/IxD/UI specification document is over 700 pages long.” So we’ve quickly gone from “too simple” to “too much information”.

If samples of work appear unremarkable, that may be the point of good UX. Most UI’s though not all) are not dazzling spectacles of design. They also should not be. They should be making the task simple, easy and relatively intuitive to the user. When someone has just purchased a new big screen TV, then the chances are pretty high that viewing content is their goal. It is not about have a great memorable experience in turning it on or off or changing channels or inputs, etc. That kind of emphasis may sell a TV, but it’s going to be very annoying after it’s sold. This is why demo’s and demo modes on appliances and software should be handled as separate items from UX. It is not that they should not work together, but rather that they have different goals which are likely to be contrary in many aspects.

The process of UX design is the same whether you’re designing a child’s toy or an application for Enterprise wide data analytics. The more knowledge I have in the proposed genre (whether children’s toys or enterprise software, the more likely I am to have biases.) Overcoming those biases can be as time consuming if not more so than learning from scratch from the observation of users. The reason is that the skill set of the UX designer is in knowing how to gather this data, ask questions, develop a strategy and design a process based on best UX design practices, and be more open to considering alternative approaches that were previously discounted by rote because of no longer valid or understood reasons.

Over-reliance on visual imagery vs. function in UX

Because of this lack of time to read about the problems, the visuals that are presented are typically only the visual aspects of UX and the visual solutions that were used to solve them. The other aspects that are not so easily described in a visual manner, are the nonvisual aspects of the user experience and the intangible problems, processes and solutions used to address and fix those problems. If you start to explain issues that have to do with cognitive load, cultural acceptance, mixed but specific demographics, user data, affordances and so on, there is difficulty in simply explaining this in a portfolio. The very existence of UX designers is often about “simplifying the complex” but in order to understand this, you must explain what the complexities where that you were simplifying. Typically the UX designer simplifies the presentation of complexity without actually eliminating it. This is necessary in any complex application. There is often a tremendous amount of thought, research, trial and error that goes into wireframing that has nothing to do with the look and feel of the end product. At the wireframing stage, these problems need to be solved before moving on. This is not to say that the visual design is unimportant or even that there no visual design consideration during the wireframing process, but rather that wireframing includes a lot more attributes than the just the visual design structure. Also wireframing is meant to help identify structure, interaction, and flow prior to the creation of a visual language in order to prevent a lot of unnecessary design and asset rework.

As someone who started out as a visual designer working in medical publishing, I often saw an attitude between the writers and graphic designers that each thought that their output was the more critical information in an article. Collaboration was something that happened by force and necessity and each thought the others field was something that anyone can do. I thought, along with a few of the writers, that we were interdependent on each other, but this was not the common view. I know personally that often professional graphic designers (as we were called then) were viewed as having some mysterious internal gift for creating art. Not that there was a massive amount of formal training, technical knowledge, and the understanding that what we created wasn’t something that we liked because of some inherent artistic gift but rather a carefully crafted design that was appropriate for the purpose and the audience for which it was intended, whether we liked it or not. I also know, from personal experience, that I’ve created some truly hideous designs that were extremely successful, because they were properly designed in that manner. Any inherent aesthetic ability I had told me that some of these designs were hideous. However, it was my training and experience and knowledge of the audience that informed the best design for these specific products was not aimed at me.

This desire to dazzle and distract the user rather than really do what the user wants (which, all too often, to the internal team, seems boring) often stems from internal political pressures. The user will often say, “I find this difficult to use or understand” To which the response is some form of either “Yes but isn’t it pretty.” or worse, (whether intentionally or not) incorrectly reinterpreting the users reaction to one of boredom rather than annoyance or confusion. This is reinforced even more by the “I know what I want and I know everyone else wants it too.” type of bias.

Flash vs. substance

There are 3 aspects of this. First, the ‘kitchen sink’ feature approach, and the second is a new feature approach, particularly when the new feature is considered more important than the needed feature and third, the ‘fix-it’ or triage approach. Surprisingly often, the emphasis on flash blinds the designer and often everyone on the production side of a product from executives, to marketing, to product development to engineering to quality assurance, to implementer/deployment (e.g. sales, integrators, VARs etc.)

1 The kitchen sink approach

This is often more of a marketing requirement rather than a user need. This is a way of selling a product based on an expansive set of features to accommodate anyone. Unfortunately there is no one “anyone” individual. The most common individual user will probably rely on a few features at best. Depending on their environment, habits, and expectations, those few features can vary significantly from one user (and associated use cases) to the next. In each of these use cases, most of the other features are either background noise or may unnecessary cognitive load, annoyance or confusion. Here the UX designer has to address the issue by simplifying the UI to accommodate the different use cases. The methods used vary depending on size of user base, resources (time, money, etc.) and actual capabilities existing that allow the desired outcome to be implemented. Here’s where there can be a huge difference between first impression and second impression. On an enterprise level, I would call it the primary impression (decision maker/purchaser of the product) and secondary and on impression (the user who may have little choice in the purchasing decision.) The UX designer must manage these second(ary) impressions since the focus is on using and reusing the product and less on selling the product. This also means that the UX designer should make sure that business goals of Marketing and UX are aligned.

2 The new feature approach

This is also focused more on selling than using the product. In this case, the new feature may have been added based on user requests, new available technology or some other innovation. In any case, the adoption of the feature may or may not be as expected. If the new feature is based on anything other than user request, then there should be an expectation of slow adoption, even if the feature works exceptionally well. New features are competitive market objects which are often used as differentiators or to follow new trends in predicted (but not tested) user expectations.

3 UX as a ‘fix-it’ step in the process

When UX is introduced late in the development cycle, the work that is done by UX designers is more about triage than design. It’s too late and far too costly to redesign something properly, so while the intent is to make a good UX design, the end result is making a bad design, “less bad.” This also tends to put the UX designer in a defensive mode rather than in a productive one. This is because, their failure to completely fix a problem which was caused by implementing UX too late in the process, reinforces the bias that it is an ineffective skill set of knowledge and expertise. Sometimes we [UX designers] are lucky and are presented with problems that are easily solved. This is when, for example, myopic product design vision fails to see obvious simple usability problems that are easily fixed. It is the responsibility of the UX designer to indicate at cycle wrap up, that what was addressed was the “low hanging fruit” of the product and that substantial changes may still need to be made on the next round. What happens after that depends on internal politics. Dancing around the individual and group egos is just something that you have to learn in business. That is a different subject that’s beyond the scope of this article.

Internal resistance to change

Interestingly, in small but growing companies, every time they add a new department (like research, design, new technology etc., and which is often initially a single person) to the production mix (and I’m assuming for this argument that the department/person is knowledgeable and experienced in their field), there is going to be a moment when that new department is likely to say “The emperor has no clothes.” A well-run company will say “Then tell us what we need to do.” Often, though, particularly as you start addressing progressively larger companies the new department may be dismissed as not understanding what has been done so far. Even though the new department’s expertise didn’t exist previously, there is still resistance to this change. Often, the skills of the new department are diminished by considering them obvious or a commodity or something that doesn’t require formal training or specialized skills and tools. This is normal human behavior but bad for business. Nevertheless, the new department will often have to earn respect rather than being given it initially. This is not very productive, and the department can end up failing in the process. Many seasoned UX designers know that more time and effort is spent on defending UX improvements than is spent on presenting UX improvements.

Originality

“How much of what I’m looking at did you do?” This question varies as much in meaning from person to person who is asking the question as does to the person who answers it.

Consider the following:

If addressing a painter (art): did you create this image entirely from your imagination (which is still derivative), Did you gesso the canvas?, Did you stretch the canvas yourself? Did you weave the linen? Did you grow the flax? Did you make the canvas frame? Did you cut the wood for the frame? Did you grow the tree that the wood came from? And so on with the pigments and brushes and any other tool used in the painting creation.

This example above shows that there may have been many people involved with the creation and production of a painting. While the example may seem ridiculous to many, it strikes close to home when dealing with a UX Designer. While reviewing my own portfolio, I can can point out myriad attributes that someone else or some other group was responsible for even though I may have had intense input and responsible for designing many of the assets or other more trivial aspects of UX design and production. These are irrelevant to me.

I’m more interested in the ability to use tools and resources, rather than making sure everything is original. Not everything needs to be a new invention. The great majority of the time, good UX design comes far more often from simplifying the UX than it does from coming up with and ‘innovative new concept’. Innovation is typically (though not always) more cost effective than invention is so you don’t have to waste resources “reinventing the wheel.” To that end, if you are replacing the wheel with something new, is it truly better or just ‘new’.

Consider the iPod. Here was a product that had virtually no invention (in terms of UI/UX) but rather innovated the world of UX in terms of creating an aspirational experience that superseded all of the prior mp3 players (and there were hundreds on the market when the iPod came out. There was little invention in this product, but rather a very clever marketing of music via the ‘experience of the iPod.’ A great majority of consumers [still] have a perception that Apple was the first to release a personal digital music player.

UX Design Knowledge Domain Knowledge

There is a counter-intuitive requirement that the UX Designer needs to have domain expertise in the product/marketing space. I have found that this concept seems like a no-brainer to the product developer. If you are going to work for a company that produces software for data analytics and solutions or a company that is producing an electronic music instrument for children or produces jewelry and accessories for the fashion conscious woman on a budget, there is this misguided idea that the domain knowledge and experience that is required is essential for the UX Designer. This myopic view causes problems for a UX designer. Prior knowledge also creates biases. Any good UX designer follows a process that includes determining the product features and functionality, research to determine an unbiased definition of the target user (interviews, persona creation, etc.), amongst a number of other process steps. Prior experience is more likely to prejudice the UX designer to draw premature conclusions. Learning the domain from scratch will often reveal more opportunities and expose areas of need in the existing products (if they exist.) This allows for creating more innovative UX because of the fresh outlook rather than innovation for the sake of innovation (which often has a poor ROI.) The more objective I am as a UX designer, the better the results of my work will be. This objectivity also helps reduce becoming emotionally attached to particular concepts and defending them without a solid foundation of logic, data, and testing.

Legal issues of IP

I’m curious as to how many companies want to see samples of your wireframe work, or specification documents, strategic UX planning etc. but don’t think that doing so would be breaching NDA’s or inappropriate (even if unintentional) requests to see the inner workings of another companies products and processes. I know I have to be very cautious of this sort of thing, but it seems oddly hypocritical to disallow you show your work for them and yet they want to see detailed work of others. Additionally, by the time you may be able to publicly display the material, it’s often old enough that it’s age alone will draw more focus than the solutions provided.

Concluding thoughts

I don’t think the requests for a UX portfolio are going to stop, but I believe that until we address the concepts of UX design as far more than merely a visual portfolio, it will be deemed an acceptable practice. Sadly, this means that good visual design may push a good visual designer into a UX role they are unequipped for while the right UX professional sits waiting. This also includes the fact that the visual designer, who may be brilliant in design, might be forced to do work in areas that they don’t want to be doing. The same goes for the coder.

“UX” is often tacked on to job titles without any real understanding of what UX designers do, or with the belief that UX design is a minor adjunct skill. This means that the job description and actual responsibilities relegate less than 20% of work to UX design, while the majority of the work that must be done is coding or visual design, or even marketing.

So if a job description places requirements of ‘expert knowledge’ in areas other than UX and then the UX requirements are looser, such as “Must be familiar with UX/UI best practices.” then the area where expertise is required is what the job is really about. The issue is not whether I have expertise in these areas but rather that the job is less about UX and more about the areas where “Expert Knowledge” is a must-have requirement.

Advertisements
Posted in UX Design | Tagged , , , , | 1 Comment

The necessity and risks of assumptions in UX.

By Bob Glaser ©2014

We make hundreds of assumptions every day. We have to make many of them to simply be productive. A very high percentage of them are reasonably accurate enough to meet the needs of any and every situation, often regardless of the situations importance.

The longer we live (given environmental and circumstantial uncertainties), the more we are likely to believe, with increasing certainty, that the assumptions we make are true. This is accurate up to a point. That point is when cognitive biases like confirmation bias, stop us from correcting errors.

Another cause of rationalized support for assumptions is the incidence of needing situation specific survival skills in the form of uniquely personal emotional tools may help an individual survive the high risk situation, but end up being destructive, once the risk is removed. Examples of these situations are children growing up in extremely abusive situations, a soldier returning from combat, an individual developing a drug dependency to address a situation that no longer exists like pain or environmentally triggered anxiety. I won’t be addressing these survival skill based assumptions because they vary too much in both cause and effect, from one individual to another.

Observing the User

As UX designers, we need to curb the use of assumption when silently observing the user. If we are doing a good job at observing, we are taking down facts of an interaction and set of observable behaviors. If there is any supposition based on assumption, it should be made after all the facts are recorded, and not during, since these assumptions are then highly likely to color progressive documentation of facts. We will begin to ignore those that don’t meet the assumption and placing undue weight on those that do meet the assumption. While this may seem obvious to most UX designers, it is often not followed methodically.

  1. Get the facts first
  2. Ask your predetermined survey questions next, separating:
    1. Qualitative data
    2. Quantitative data
    3. Ask your soft or open questions last.
    4. After all the participants are done, then you can start making and testing assumptions.
    5. Rework and iterate for next round.

It is a great example of how extra work done early can save a lot of time and money later. It is also gives you the opportunity of determining if a high success is due to the design working as intended (this is a very common ego based assumption) or if a high failure rate is caused by an assumed deficit. High speed, high iteration groups tend to make this methodical practice difficult to follow. What must be explained in terms of the project and ROI, is the importance of rigorous adherence to maintaining this clarity of distinction in terms of what assumptions were made.

Consider the following hypothetical where two successive pages of a form on a website are presented to the user. These two dialogues were the bottom of two successive form-pages. The later of the two was the last page in this three page form.

Bottom of page 2, below:

assumption1

Bottom of page 3, below:

assumption2

Given the lack of clarity that this causes, there are several possibilities of failure here.

  1. The repositioning of the buttons even though they are logically in the same order
    • Left to right followed by top to bottom: 1 Enter text, 2 continue, 3 cancel
    • The position of the “Continue” on the first page is where the “Cancel” is on the second page. (Maintaining common location but with contrary actions.)
  2. The changing of the wording.
    • The “Continue” button is two words on the first page but one word on the second page while the opposite is true with the “Cancel” button.
    • There are no words in the “Continue” button that match from page to page since “Submit” is used on the other page.
    • It may not be clear to some users that “Submit” may be for completion of the entire form and might be a dual action button that both saves responses and submits the form as completed. Some users may assume that there is no going back after submission, while others may assume that there will be a confirmation or possibility to edit responses afterwards.

The mistake commonly made by the UX designer, is considering one assumption instead of both (along with the possibility of others.) In spite of this being based on a real page that is currently in use by a major company, this is a somewhat severe example but sadly, not as uncommon as we’d like. There is an actual need to determine: “What is the most common reason for failure?”, based on factual observation. Then a reasonable follow-through would be to make sure that the target demographic has expectations that can be met by the redesign.

This leads next to the sweeping generalization of the type that is based on large group averaging and may need to be presented as such. It is acceptable make reasonable sweeping generalizations to make a point, but it isn’t acceptable when there are specific demographics that are being addressed. In those cases, the sweeping generalization could be flawed if the specific demographics total far less than a significant sample of all people. The sweeping generalization could also be flawed or if the sweeping generalization covers a range of objects of which the specific product being designed is only a small portion (e.g. business app. vs. consumer app.) or different paradigm (e.g. virtual vs. real object). There are many examples where a product is intentionally marketed and designed for an audience who is contrary to the general population despite the general population’s view of the target group. A good example here is the high-end audiophile consumer who wants tube based amplifiers and vinyl disk playing turntables for it’s ‘closer to real’ analog output and it is not because it’s ‘retro’ as the general population may perceive it.

The assumption of intended use

There is the example of the unintended function that is discovered or whose use is reimagined by the user and may surpass (exponentially) the intended function in the use of a product. This may come from need and basic adaptive use, like using a napkin folded to create a shiv to balance a rocking table that’s on an uneven surface. In this example, the problem and solution are obvious and the variable is in determining what is available in close proximity that will meet this need. Usually paper goods are chosen since they be folded to match the correct thickness (an additional sub variable) to solve the problem.

Take Facebook for example. Its original intent was to have a more narrowly focused user group of college students, in fact, it was narrower than that (first Harvard only, then Boston Colleges and Ivy League and Stanford.) It was restrictive by intent. Mark Zuckerberg and others recognized the monetization of the service by making it available to all. This was not accidental but rather smart observance of serendipity. There are countless other similar examples from children’s toys to pharmaceuticals.

The failures come from the apparent security of maintaining the status quo and not wanting to annoy the existing customers. Stay with the idea of “This is what we are known for”, so we can’t deviate from that path. Sometimes you must deviate and sometimes it’s adaptation by dropping a rigid business model to a more flexible one, changing the target demographic, adding/deleting/prioritization of functions, etc.

How to address the facts and assumptions

Be cynical. Don’t move forward thinking that the facts and assumptions are presumed correct.

  1. Remember: if you think that you’ve made no assumptions, then you’re already set up for problems unless you’re just plain lucky. Everyone make assumptions. Due diligence is required here.
  2. Clearly document and label assumptions and facts as different entities. This doesn’t have to be done in any complex way. Sometimes, something as simple as text formatting can help you keep these sorted.
  3. If errors show up later, go to your assumptions list first as this will save a lot of time. If the problem can’t be found there, then consider that there may be an error within the facts.

A personal example of effectively over-riding the common assumptions:

I managed to do something similar to these approaches when I was working in a small self-defined team. The numbers we were dealing with weren’t as massive as Facebook (few are) but they were exponentially greater than the original intent of the project we were working on. We fought diligently to solve a problem that no one perceived as a problem because of common group assumption. This was only a team of three, myself as the UX/UI Visual designer, a Human Factors Engineer to deal with the ergonomics of the machine, and an Industrial Designer.

The problem was identified when the mechanical engineering and R&D came up with some significant innovative and patented invention improvements and features. There was a proposal to make this device suitable for a larger segment by making it a scalable table top machine rather than a built in machine. As with all previous machines, it would use a simple black and white LED UI screen that gave feedback on settings and allowed for process counting (items completed by the machine) and would also require a trained dedicated user.

We proposed a color screen. In order justify the significantly increased cost of it. We had several weeks to come up with a rationale for its implementation. ROI, was the prime focus for a machine that would probably start at $20K for the simplest model.

We brainstormed, and ended up designing a prototype interface that would allow an untrained user to operate this machine. The primary assumption we were discarding was that these machines always have a dedicated user who is well trained. We had no budget beyond the time we spent in its development. So we had to discard common assumptions and make many new assumptions based on heuristics, experience, and simple user interviews. A bare bones user centered design. We gathered data from SW Engineering and Mechanical/Electrical Engineering to validate capabilities and information from Sales and Marketing via the marketing requirements document. We created a sample use case as our demo of user flow. One that would address the highest number of critical problems. We also considered a number of use cases so that we didn’t paint ourselves into a corner. This way, our sample use case in the form of a predefined workflow covered all of the top issues and would be factually defensible in presentation.

With the collaboration of my two colleagues, we designed the basic simple UI of a very complex system. I created the layout, graphic elements, and pseudo-prototype and with the help of the human factors engineer to determine the ergonomic considerations. The industrial designer on the project designed the first rough, of a product typically used on a factory floor, to look like it could look elegant in an office.

We presented our case to executives and major stakeholders. It passed and was implemented. Its success was demonstrated on the day it was released for sale (a few months after a completed prototype was demonstrated at a national convention.) Manufacturing had already built a projected 6 months’ supply of the products which sold out in 3 days. This was a product that ended up selling for between $25K to over $120K depending on the configuration. The majority of the sales were made based on the fact that a dedicated and trained operator would not be required for it.

This is not to say in any way that our solution was flawless, but it was magnitudes better than prior solutions on similar as well as more expensive machines.

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

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