User experience is a term often heard among those who create and use software. Though it is presented as something novel, it’s actually a pretty old concept—something considered explicitly at least since Xerox Parc—and perhaps even before that (for example, consider the obvious beauty of Babbage’s Difference Engine in the figure below). In spite of this, I am struck with what seems to be a growing buzz associated with ideas such as ‘usability’, ‘user-centered software’ and ‘passion for the user’. Microsoft and Google are gobbling up user experience engineers as fast as universities around the country can churn them out. Peers in other software shops are all playing the ‘we do usability too’ game. As things start to reach the frenetic level of ‘movement’, the skeptic looks for the snake-oil salesman hawking his miracle elixir.

Recently, I finished reading Subject to Change: Creating Great Products and Services for an Uncertain World,¹ by several authors from the venerable flagship of ‘product experience, strategy and design’, Adaptive Path. One may take Subject to Change as a manifesto of sorts for the software experience/user-focused software movement (note Adaptive Path would probably object being placed in so narrow a category as ‘software’). In order to support their claims, the authors of Subject to Change rely on inductive reasoning: they describe a number of anecdotes and observations that confirm and support their theories on the value of user experience to companies and the marketplace. The problem with this approach is that it tends to obfuscate the outliers, or the exceptions to the rule (which tend to be more interesting, but, alas, are rarely considered). In his book Fooled by Randomness, Nassim Nicholas Taleb describes the problem of induction from the perspective of philosopher Karl Popper:

There are only two types of theories:

1. Theories that are known to be wrong, as they were tested and adequately rejected (he [Popper] calls them falsified).
2. Theories that have not yet been known to be wrong, not falsified yet, but are exposed to be proved wrong.²

Or, put another way: “to paraphrase baseball coach Yogi Berra again, past data has a lot of good in it, but it is the bad side that is bad”.³

One is left with the impression that the claims based on inductive logic are more absolute and immutable than they really are. The authors of Subject to Change are really saying is ‘this is what works for the majority of cases we have seen in our (necessarily) limited experience, but there is always the possibility of an exception that is completely violates that patterns we describe’ (even though they don’t explicitly put it this way). With this in mind, I would like to explore what some of the exceptions to the rule might be (Black Swans, Taleb calls them), and, more importantly, how ignoring them can actually increase the probably of a software project failing. So, what are the limits of user experience? Are there domains in the practice of designing and building software where user experience is of little value?

Earlier in my career, I worked as a software engineer for a company that builds software for storing, managing and using digital images (e.g. MRIs, CT scans, mammograms, etc.) for hospitals. In the spirit of Subject to Change, I’ll call them PacsCo.⁴ The size of these images used in a clinical environment is quite large relative to those stored, for example, on a standard consumer digital camera. Not only this, but some devices such as CT scanners take pictures of ‘slices’ of the subject, increasing the size of the data by ‘orders of magnitude’, as folks at PacsCo are found of saying. PacsCo started with this particular problem: how can all this clinical information be stored and managed reliably and securely, in such a manner as the right information gets to the other systems when it is needed? Note this fundamental question has nothing to do directly with the user, as the ‘users’ of the PacsCo software are actually other software systems! They were building a software product essentially with no user interface.⁵ The raison d’être of PacsCo was to solve a plumbing and infrastructure issue. Their salespeople never demonstrated how intuitive their user interface was. There were no user interviews to determine their tastes, as there were no users to be found that could be interviewed. All the tools of traditional user experience research—card sorting exercises, information architecture, user empathy, etc.—would have absolutely no value for PacsCo. This is an example of software that mostly interacts with other systems, not humans. When PacsCo software is working as designed, there is no need for user interaction.

Now, PacsCo was quite effective at solving this core problem. They grew and became more successful. Eventually, the decision was made to expand their product offerings into something besides just infrastructure technology, and PacsCo merged with another company that we will call ‘ImageCo’. ImageCo in many ways was the counterpoint to PacsCo: ImageCo’s software was used by clinicians to view and manipulate all these complex medical images. ImageCo provided a very valuable tool to physicians. Their software helped physicians improve the accuracy and efficiency of their diagnoses (and consequently, improved patient care). ImageCo placed extremely high value on the user experience of its software products, and saw it as a competitive advantage in a crowded marketplace. ImageCo placed most of its engineering resources on optimizing the user experience, to the neglect of almost everything else.

Once PacsCo and ImageCo became one company, the focus of the combined engineering teams initially was integrating the two companies’ product lines. It was thought that this would be a fairly quick effort—after all, the two products could already ‘talk’ to each other. As it turned out, however, this effort was not completed for well over a year. ImageCo, while having done a superior job at delivering a unique and compelling user interface, had neglected other fundamental software issues such as performance and scalability. As a result, when ImageCo was integrated in hospital environments with extremely high volumes of traffic (where PacsCo excelled), the ImageCo applications bogged down and became unresponsive. One may claim that application responsiveness is, in itself, a key component of user experience. However, as a practical matter, ImageCo applied all the ‘traditional’ approaches of user experience and still missed this. The reason was simple: ImageCo had only so many resources, all of whom were busy optimizing the experience of the clinicians with the user interface. Classic user experience techniques often focus too narrowly on user interface, aesthetics, design, etc. This risks losing the bigger picture of the software problem, which may yield the unintended consequence degrading the user experience once the product is placed in real world situations.

Am I dismissing the value of user experience altogether? Certainly not! At PointClear, we consider our entire approach to designing and building software to be infused with concern for the user and how they will interact with what we build. By exploring the boundaries of where an idea or approach starts to fail, one can achieve a more balanced view of where a methodology can add value and where it cannot. More often than not, software companies put too much emphasis on the nut of bolts of building software and neglect user experience, resulting in products that users hate. On the other hand, one can allow the pendulum to swing too far in the other direction, resulting in myopic obsession for user experience. Strangely, this too can result in software that users hate—not because of poor UI, but because it doesn’t work. And further, as we have seen, there are some domains in software where user experience simply isn’t relevant.

What is required is a balanced approach: passionate empathy for the user’s experience, vigilant concern for traditional software problems such as performance and security, and the maturity and experience to know the limits of each.

¹Peter Merholz, Todd Wilkens, Brandon Schauer, and David Verba, Subject to Change: Creating Great Products and Services for an Uncertain World. Beijing: O’Reilly, 2008.

²Nassim Nicholas Taleb, Fooled by Randomness (New York: Random House, 2005) 126.

³Taleb 126.

⁴PACS stands for ‘Picture Archiving and Communication System’. http://en.wikipedia.org/wiki/Picture_archiving_and_communication_system

⁵One might argue that there had to be some user interface—such as an administrative tool—and this is true. The key point is that the value of the user interface was dwarfed by the need to solve the fundamental question with which PacsCo started.

This entry was posted on Wednesday, June 18th, 2008 at 2:12 pm and is filed under Usability, Philosophy. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.