The Myth of the Stupid User (Revisited)

Another interview with Gerry Gaffney of Information & Design (Melbourne, Australia)

Conducted via email by John S. Rhodes (8-February-2000)

Preface

In the original Myth of the Stupid User interview, conducted about a week before this one, Gerry Gaffney talked about international usability and design issues. He also talked about some tools and methods that he uses to improve the customer experience. But a few WebWord readers told me that they expected to read more about users and their supposed lack of stupidity. Well, I asked Gerry to expound on some of his ideas. I have to say that he came through with a vengeance. His answers to the follow up questions should satisfy your curiosity.  -- John S. Rhodes

The Questions...

How are products confusing, rude, and belittling? 

I think we're all familiar with confusing products, particularly in the web arena. You can confuse people by asking them to make unnecessary decisions (such as specifying a screen resolution or type of internet connection), by making navigation difficult so that they have to wander around a site looking for appropriate information, and by being inconsistent with general practice, so that users have to figure out a new interface and interaction style on your site. You can confuse them by not having an appropriate acknowledgment of a Submit button, by being unclear about what will happen next during a transaction, by changing navigational styles, by cluttering screens with visual noise, and in a thousand other ways! 

As Reeves and Nass demonstrated so well in the fascinating book 'The Media Equation', we interact socially with computers. To some extent, we react to them in the same way as we do to humans. It follows that if a computer behaves in a way we could consider rude in a human, we will also consider it rude in a computer. Rude behaviour is often most evident in error messages. My favourite example (I swear this is true) is a software product which issued the message 'I told you - no blanks' if the user attempted to use the space bar twice in an entry field which didn't allow blank characters.  

Products that go beyond rudeness can belittle us if they actively diminish our standing in the community or in our own eyes. In Philip K. Dick's 1969 book 'Ubik', a coffee-machine tells the impecunious Joe that 'we can do without your kind'. I was surprised to come across a real-world example of this in the form of an ATM that displays a large cartoon character with empty pockets if you have insufficient funds to make a cash withdrawal. See http://www.infodesign.com.au/usability/rudeatm.html for a photograph of the screen (image size is about 55Kb). 

In a restaurant, good service is epitomised by a the waiter who is constantly available, never interrupts unnecessarily, and provides helpful, knowledgeable and useful advice when required. Sounds like a job description for a good interface. 

Technology fails to be good and simple for users. Are the designers and engineers behind the scenes failing users too? 

Yes.

Of course designers, engineers and others involved in product development have to deal with many constraints. 

Firstly, there are technical constraints. Anything that pushes against a technical boundary is likely to be difficult to sell to the engineers or programmers. It is quite common to hear 'We can't do that because...' when discussing user requirements or during participatory design sessions. I believe it's important to _ignore_ the technical constraints in the first instance, since this at least gets everybody thinking about the possibilities. Once the possibilities have been explored, reality checks will weed out the impossible or unachievable requirements. In addition, the process of opening up the possibilities can often lead to previously unconsidered solutions. 

In addition, there are budgetary constraints. Usability activities provide an 'invisible benefit'. No matter how much information may be available on the benefits of usability in general, the fact is that you can design and develop products without conducting any such activities. If time and money are tight, usability is one obvious candidate for chopping. Admittedly this is short-sighted, but it's the reality on many projects.

Beyond these constraints, there may be other issues. Often, developers who have not been previously exposed to customer-centred design or usability activities may be reluctant for a host of reasons. Alan Cooper has much to say on this topic in 'The Inmates are Running the Asylum'. 

I've found that in the main developers are enormously pro-usability once they have been exposed to some of the methods. 

I also think that to some extent the fault lies with the usability profession. We're convinced that we can do things better than anyone else (often without ever facing the real-world constraints of the development team). We tend to treat highly-experienced technical staff as incompetent, just because they have no experience in customer-centred design, and we have a tendency to identify problems without offering solutions. 

I like to think that eventually customer-centred design will be the norm, and the existence of a group of outsiders called 'usability consultants' will be a thing of the past.

Tell us more about the Myth of the Stupid User.  Exactly what is it? What does it really mean? 

By 'the myth of the stupid user' I mean the belief that users are stupid, and the concomitant inference that inability to use a particular product can be blamed on the user, thus exonerating the product itself and the development team. 

Anyone who hangs around with IT professionals knows that many of them consider users to be stupid. Do an internet search for 'stupid users' and you will find thousands of stories about the stupid things people do with their computers. For example, you can read dozens of variations of the story on the person who rang up their ISP and asked 'Is this the Internet?' 

This attitude permeates the whole of the IT and web development industry. Many people will be familiar with this attitude from dealing with technical support staff whose technical skills far outweigh their ability to communicate with other humans. 

My take on this is that it's a cop-out. Retailers don't treat their customers as if they are stupid. If a shop had a sign that no-one could read, the owners would change the sign, rather than throwing their hands in the air and lamenting the stupidity of shoppers. 

There are plenty of people who are uninterested in computers and the web, or who are technically unsophisticated. Does this make them stupid? Of course not. However, while we continue to design products that they can't use, we allow ourselves to think of them as stupid. Instead, we should be asking what's wrong with our products. 

Let's assume that a user is not an expert using a particular product. How can designers better develop a product that can be used by that non-expert (or "stupid") user? What works? Please give us advice and guidance. 

That's a big question! The following are some very brief guidelines. 

It's necessary to understand the users and the context of use. Who will use the product and why? What is their educational level? Do they have experience in using similar products? When will they use the product - at home, at work, in an office, on a production line? What sort of computers and browsers do they have? Everyone involved in the design and development needs to know the answers to these questions. 

If there is an existing user base for the product or one similar, get out on site and spend time with real users. Watch them use the product, ask them questions and find out the issues. 

Develop scenarios or use cases that describe all the interactions that take place between the user and the product. These describe at a high level what the user will actually do with the product. These same scenarios or use cases can be used throughout the design process, and can also provide the basis for usability testing activities. 

If possible, involve 'real people' (representative users) in the design process. Many usability organisations avoid doing this (and for many good reasons). However, I believe that getting developers together with real users is an extremely worthwhile activity, particularly if the users are novices who will be completely alien to many of the developers. If you don't want to involve real users, then it's doubly important that your user profiles are very well detailed and understood. 

Avoid compromises that will have a negative effect on the user interface. Often technical constraints are given precedence over usability constraints. Ensure that developers and managers are informed of the likely consequence of any such compromise. Don't be embarrassed to put these consequences on the table and escalate them to someone who can make a decision. 

Be consistent with others. In the web arena this is particularly important. Some de-facto standards exist - don't make users learn new techniques to use your site. 

Don't fix user interface problems in the documentation (since many people will never read it). 

Prototype and test. It's easier to throw away a paper mock-up than a finished product.

Gerry, wow. Thank you for a truly awesome follow up interview.

What next?

If you want to know when new interviews go online,
subscribe to the WebWord.com Usability Newsletter!