Interview – Jeff Johnson of GUI Bloopers

“As both a programmer and computer user, I felt strongly that computers should be easier to use than they were,” says Jeff Johnson.

Hmmm… making computers easier to use, eh? Sounds like a great idea. But has Jeff succeeded in this goal — one that he set himself while looking for employment after graduate school? SitePoint decided to ask Jeff a few questions to find out more about what exactly he has accomplished. After all, until now he has only chaired international conferences, worked for some of the leading companies in the world, authored and contributed to countless articles and books, and is now president of a product usability consulting firm he founded in 1996.

SitePoint: Hi Jeff, thanks for talking with us. I’d like to start off by asking you about how you first got involved with usability issues. What made you decide to get into this area?

In college (Yale) and grad school (Stanford), I studied cognitive psychology and computer science — this combination is often called Cognitive Science. My interest then was devising computer models of how people reason and solve problems.

But as I neared the end of graduate school, I realized that job opportunities in cognitive science were limited. However, there were significant opportunities in the field of human-computer interaction. This was in the late 1970s, when the micro-computer (also known as the personal computer) industry was just getting started. Computer and telecommunications companies were recruiting people who had the sort of background I had, to help make their computer systems easier to use.

As both a programmer and a computer user, I felt strongly that computers should be easier to use than they were. That feeling, combined with ample job opportunities, lured me into the user interface field.

I went to work in 1978 for a small microcomputer company in Silicon Valley called Cromemco. It had been founded a few years before by two Stanford electrical engineering grad students. They needed someone to design easy-to-use software applications and oversee the usability of hardware components such as keyboards. Because Cromemco had a very small programming staff, I had to be both designer and programmer for many projects. I designed word-processing, statistical, and graphics software for them.

Then, in the mid-1980’s I left Cromemco to work at Xerox. I didn’t work in their famous Palo Alto Research Center, but rather in the Office Systems Division, which was charged with turning PARC technology into products. I worked on successors to Xerox’s groundbreaking but unsuccessful Star workstation. As at Cromemco, my role was as a user-interface designer and implementer.

After a few years at the “University of Xerox”, I moved on to research positions at US West (a phone company, now called Qwest Communications), and then Hewlett-Packard Labs. Soon after HP Labs dismantled its human-computer interaction research group in 1992, I moved to a secret spin-off of Sun Microsystems called “FirstPerson”.

FirstPerson was Sun’s attempt to expand its business beyond computers into electronic consumer appliances. FirstPerson’s founders had developed a new language called “Oak” (now Java). I was the main usability guy: I helped design prototypes and test them on real people. The prototypes were things like TV set-top boxes, online video-on-demand services, that kind of thing. We weren’t even allowed to talk to other Sun employees about what we were doing. Soon after FirstPerson became JavaSoft, I left to form my own consulting firm, UI Wizards.

SP: Do you value user knowledge of the software over usability? Does this knowledge increase the usability of a product over time?

Human beings are very adaptable: they can learn a lot when they’re motivated. The question is: when are they motivated? I don’t think every software product has to be so easy that all of its functionality is instantly accessible. Violins and automobiles take serious effort to learn to use. Some people learn them; others struggle. But people who learn them love what they can do.

When people use software in a workplace, they often don’t choose it. It’s given to them to use, as a requirement of their job, and they’re therefore motivated to learn to use it. If it takes a little time to master, that’s probably OK. But remember: the employer bought the software to improve employee productivity. If the software takes forever to learn, is highly error-prone, or it’s just tedious or painful to use, productivity suffers. So employers as well as employees have reasons to want software to support, rather than get in the way of, the real work.

Software for the home is a different story. Here, there’s almost no motivation to learn. If you can’t figure something out quickly, you’ll abandon it pretty fast. Web users are even less tolerant of services that are hard to use. Why struggle, when there are several dozen (or several hundred) other sites offering the same thing for less hassle? We’ll just hit “Back” and go somewhere else.

With regards to knowledge affecting software usability, studies have shown that when people say they “use” a software product, this actually means they know how to use only a small fraction of that software’s total functionality. Once most people learn enough to accomplish their goals, they stick with that and rarely bother to learn much more. For example, almost no one uses Microsoft Word’s stylesheets facility. Most people leave all paragraphs “Normal” and set the fonts, margins, and other formatting directly.

SP: Do you feel that there is resistance to usability principles by designers? If so, what can be done to impress upon designers the importance of adhering to usability principles?

Most developers think usability costs extra time. They’re always under intense time-pressure, so anything that costs extra time is bad. In fact, using user-centred design from the start of a project can save time. It helps you figure out what users really need, so you can provide just that, rather than designing and building a myriad of functions no one will use.

There never seems to be time to do it right in the first place, but there is always time to do it over when customers throw it back in your face. Even if paying more attention to usability up front lengthens time-to-market, it may shorten time-to-profitability, because a more usable product has:

1. faster market acceptance, (i.e. higher initial sales), and
2. lower customer-support costs.

Finally, when customers really like a product, they’re loyal. In contrast, when they can barely tolerate a product, they’ll switch to your competitor in an instant. Usability fosters customer loyalty.

Developers also sometimes resist UI guidance because of control issues: they see UI designers as taking control away from them. If they were thinking rationally rather than emotionally, they’d realize that products are better when team members contribute their own best skills, and that their skills are in implementation, not UI design. Happily, once I’ve pulled programmers through a user-centered design process (sometimes kicking and screaming), they usually “see the light”, and are even relieved that someone else is taking some hard work off of their task list.

SP: Your book, GUI Bloopers, illustrates common pitfalls in user interface design. Can you tell me what’s the most common mistake that designers make? How they can avoid making it?

It’s hard to pick the most common mistake, but one that’s a strong candidate for that distinction is “Speaking Geek”. That blooper occurs when error messages, command names, and instructions are written in programmer jargon, rather than in terms that make sense to users. One cause of this blooper in error messages is failure to translate low-level software-to-software communication into something relevant to what the user was trying to do. This is why we see Java exceptions showing up in error messages.

The main cause of this blooper is mis-management: assigning the job of writing software text to programmers is obviously not the preferred option. Programmers are good at writing code; they’re typically not good at writing text. Who is? A technical writer. All text in software should be written, or at least reviewed, by technical writers before the software goes out the door.

SP: At what point do designers and developers go too far in trying to make a program “user friendly”? Where is the balance to be found?

There are many ways to go “over the top” with UI design. One is to spend so much time worrying about the graphical appearance that you don’t pay enough attention to the more important part of the user interface: the interaction and task-flow. This is why software development teams need interaction designers, not only graphic designers. It’s also the reason why I recommend starting a UI design by first developing a conceptual model that clarifies what the software does, rather than jumping right into sketching screens and laying out widgets.

Another way to go too far with usability is to conduct usability testing when you have no intention of doing anything about the problems that the tests find. That’s just a waste of time and money. I wish I could say no one makes this mistake, but it’s pretty common.

Finally, UI designers sometimes go over the top when they fail to prioritize the problems they uncover in usability tests or reviews. Some problems are more important than others. Developers need prioritized lists of problems so they can focus on the important ones and leave the others for later. Having said that, some problems that are low priority are also easy to fix, for example, changing the name of a menu command.

SP: There is no doubt that increasing a Website’s usability can lead to more users and repeat traffic. However, how can Web Designers convince their clients that this is the case, and that the investment in usability testing will pay off?

There’s a book called Cost-Justifying Usability, by Bias and Mayhew. It’s pre-Web, but the economic arguments would still apply to Websites.

Sometimes however, the only thing that really gets the message through is the “school of hard knocks”: putting a shoddy, geeky Website out there and having people stay away in droves. That usually gets management’s attention.

SP: Who are the big players in usability and what Websites do you visit regularly on the subject?

On my consulting Website, I list a few handy UI Design books — the “big players” are mainly the people who wrote those books. In my field, most people consider researchers such as Doug Engelbart (SRI in the 1960s), Stuart Card (Xerox PARC), Jim Foley (Georgia Tech), and Ben Shneiderman (U of Maryland) to be the sources of much of the discipline’s wisdom. Of course, there are practitioners who have become famous even outside the UI field, such as Jakob Nielsen, Alan Cooper, and Don Norman.

Sites I visit regularly? Well, there’s Jakob Nielsen’s site. There’s Dey Alexander, a UI consultant in Australia whose site includes a daily Web Blooper. There’s the User Interface Hall of Shame, operated by UI consultant Brian Hayes. Also, Keith Instone’s wonderful resource of links on Web usability. There’s the GUI Bloopers site, run by the publisher of my book, and finally there’s Vincent Flanders’ site.

SP: Software like Macromedia’s Flash has a reputation for creating unusable Websites. Will this be overcome or will it create even bigger problems?

A little animation can be good in a Website, but it is easy to go over the top. Unfortunately, many sites that use Flash do just that. Also, many Flash-based sites don’t provide an alternative for visitors who don’t have Flash.

Many designers think people will get Flash just to see their wonderful content, but they are dead wrong. Most people don’t know how to get Flash, and even if they did know, they assume (probably correctly) that attempting to install it would turn into a time-consuming nightmare, like so many software-installations do. So they don’t bother, and miss out on the content. Who loses? Not the users.

SP: Drawing from your extensive expertise, what would you say to anyone who wants to work in the field of usability?

In general, the best way to break into the field is through usability testing. Conducting usability tests is a great way to see what works and what doesn’t work. That will give you the experience you need to redesign software, or design it from scratch.

People also come into the field from other related fields:

• graphic design: they get tired of drawing icons and metallic buttons and want to do something about interaction.
• technical writing: they realize that software that is hard to explain is probably badly designed, so they start getting involved in the design.
• programming: they are frustrated with building stuff no one likes, and want to do better.

Give the current job market, I’d suggest not trying to become a consultant — it’s hard even for experienced consultants to find enough work. Instead, look for employment in a company.

SP: Thanks for you advice Jeff. Finally, can you tell us what’s next for usability? Can you predict what things will be like two years from now, five years from now? Will the Internet make it harder on usability experts?

Predictions are easy to make but rarely right. The TV show “The Jetsons” was set in 1999. Where are our flying cars, jet-packs, and meals-in-a-tube? With that in mind, here are some predictions:

• Certain common features on the Web will stabilize (e.g., shopping carts) and will be taken over by browsers. Sites will then only have to specify that they have the feature, and the browser will handle it.
• Speech-recognition will get better and become more widely used for interacting with computers. But people won’t think of them as computers, just as services.
• Computers will begin to disappear into special purpose information appliances.
• Cell phones will take on more PDA functions.
• The distinction between desktop software and browser-based Web services will disappear, as more apps become Internet-enabled. More and more apps will communicate with databases and other apps via the Internet, invisibly to users.
• Spam will increase without bound to the point where it threatens to bring down the Internet.

SitePoint thanks Jeff for talking to us. Make sure you look out for his next book!