By Robert R Glaser
UX designer and architect.
This is an issue that seems omnipresent in many businesses save for a miniscule percentage. It is often replaced by a bulldozer approach or worse a decision based on a random guess approach to problem solving.
What do I mean by this? Well its surprisingly easy to describe and will be easy to recognize. Whether you watch old sitcom on TVLand or new ones on a streaming service, the plot device is used commonly in sitcoms is that the one or more characters are presented with a problem (e.g. suddenly needing cash, or meeting someone, or fixing something.) They quickly realize what needs to be done and then devise a method to achieve the results. This method is typically silly and irrelevant. Something happens which quashes their process, so they fail. (Here’s where the sitcom logic comes in) After failure, the concept is discarded in whole without a thorough postmortem to determine where the problem truly lies which is usually the method for the solution which for the sake of the sitcom is usually silly. Although often a review is performed and maybe some superficial details are addressed but not thoroughly enough, so the entire project (including the initial theory, which is usually valid) is discarded.
Jeff Catlin in Forbes talks about the failure of IBM “Watson for Oncology for MD Anderson due to lack of consideration of varying cultural models and have a 62-million-dollar investment halted. Interestingly, I had previously worked at Phillips Healthcare and one of the aspects I had to consider in any [UX] design work was that the resultant design needed to work in multiple markets outside the US. So, for example, something that has little or no value in the US may have significant or even critical value in Germany or the U.K.
Another example is expressed through the issue of innovation and invention without proper commercialization. The story of the Apple visits to Xerox PARC has become mythologized, but in the long run, Xerox and Apple both had technologies which revolutionized the personal computer industry. The difference is that Apple didn’t discard or ignore these technologies, but rather commercialized them (which was significantly surpassed by Microsoft) to the point where they are ubiquitous across the industry of hardware and operating systems and applications.
Don Norman has talked about how it often takes decades for a new technology to be adopted on a massive scale. This adoption isn’t merely waiting for it to be cost-effective but rather that it be viewed as non-threatening in nature (even if it never was) or not foreign in its mental model, even though its actually easier to use or manipulate. He has used the touch screen as an example that took over 30 years to become ubiquitous (from it’s functional invention in 1975 and first production in 1982 to the real large-scale adoption with the iPhone’s release in 2007.)
My own experience has shown this is often true, particularly when some new technology is trendy. It is common for people to present it as a possible solution or methodology that is forward-looking without the background check of (even superficially) of determining whether it’s actually useful or appropriate for the case at hand. Currently, I work on the in-vehicle experience and see what technology can be used to support it. The most frequent error I hear is “Why don’t we do x because I can do that on my smartphone” without the simple consideration of the fact that cell phone use in cars is limited (to varying amounts dependent on individual State Laws, some of which allow you to do almost nothing with a cell phone.) While it seems obvious to some, most people don’t realize that the mental model is significantly different. Using a smartphone by the average smartphone user requires or draws full attention sometimes to the point of being unexpectedly and dangerously undivided. If you have seen the youtube videos of people walking into walls, polls, other objects, and even people while interacting with some social media or games, feel free to look it up.
Decisions that are made need to cover a range of issues and those issues should be graded based on how and what biases drove them. Common food is a good way of demonstrating this. If you poll people across the US to find out their favorite foods and also what foods are the most consumed, you will probably find there is some overlap but that they are not the same. You would also find out that these change over time. There are significant variables like cost, availability, and trends that have a significant effect on these. There are other variables as well and this list changes significantly between regions and even more so if you start considering countries outside of the US. Here, an important issue is brought forth. The more people are added to the averaging process, the less likely you will have a genuinely ‘average person’.
What this means from a UX standpoint is that designing to the average creates a mediocre outcome for most. So you may have an excellent theory for the UX but the data that it is based on drives the method for a solution that takes no individual into account and therefore, often, pleases few users. The difficulty here is in figuring out how to effectively subdivide the user population so that each subdivision has a way of letting the UX be seemingly (as opposed to discrete customization made by a user) customized to them. These subdivisions can be by age, culture (geographical and/or racial and/or religious), economic, sex/gender, and educational. There may be other subdivisions depending on the target audience. Some of these may not be relevant to a specific case, but they should be addressed before they are dismissed. This issue is a common driver of mediocrity or worse, failure.
What often happens here is an example common in application development where the placing all features at the same level overwhelms the user. The mistake that is certain features are eliminated (along with the users who find those important) rather than finding out how to address smaller percentages of users. This can cause a failure of the application to gain a growing or even sustainable user base.
These kinds of issues are common in applications with large feature sets. You would be unlikely to find a user (other than a person certified to teach the use of the application) who used all of the features of a complex system. Complex applications like this often have overlapping user bases which utilize the application for different purposes. Adobe’s Photoshop is a good example of this which can be seen by opening and examining all the menus and submenus available. It has users who are professional illustrators, or photographic cleaner/retouchers, or visual designers for applications development (both software and hardware) in addition to hobbyists, and even people who specialize in creating maps for cgi (3D) work. There are sets of tools for each of these groups which are often never used by other groups but are critical to the work of a specific group. The interface for Photoshop is customizable for optimization of whatever the user’s primary task is. There are also features which overlap several groups and a few features which are used by all groups. When decision makers are either out of touch with the actual users, or worse believe that their own use paradigm is (or should be) applicable to all.
So when, in circumstances such as this, there is a failure, and the solution is discarded then there is often a reconfiguration of the problem under the assumption without review, that the initial problem was wrong when in fact it was the solution that was wrong. For example, there isn’t a simple review to determine whether the problem being solved is actually needed. I may have a revolutionary solution to a problem, but if no one has any interest in solving that problem, then the implementation may be successful but the product fails.
Really innovative companies release products usually with a primary intent for a product and some ancillary solutions as well. Once in the market, the users focus primarily on one or more of the ancillary capabilities and focus minimally, if at all on the primary function. The company then realizes that instead of seeing the product as a failure, simply starts focusing on the secondary functionality as the new primary feature(s.) If they are really driven by the user’s needs, then they will genuinely asses whether the primary function is simply not needed, or was not well implemented. It really takes some fairly rigorous evaluation by the decision makers to see past their individual confirmation biases.
Personally, I learned a long time ago the deep importance of “I am not the user.” This has been really useful when going through user result analysis. Outside of basic heuristic evaluations, I always assume that my preferences are atypical and therefore irrelevant. This way I’m more open to alternative viewpoints and particularly interested in the times when many of those alternative viewpoints are similar. That becomes a simple if unexpected, target. I can then see whether the original problem definition was wrong or the solution was wrong, or maybe both. We do learn from our failures.