Interview - Jeff Johnson of GUI Bloopers

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.