Skip to main content

The usability world according to Tog

User interface expert Bruce Tognazzini has plenty to say -- ignore his words at your peril

Larry Loeb (larryloeb@prodigy.net), Author, Secure Electronic Transactions
Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been -- among other things -- a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX, and the VARBusiness Exchange. He's also written a book on the Secure Electronic Transaction Internet protocol. His first Mac had 128K of memory. His first 1130 had 4K, as did his first 1401. You can e-mail him at larryloeb@prodigy.net.

Summary:  Bruce Tognazzini has been at the forefront of the ongoing user interface debate for the past 20 years. He has been a relentless advocate of his own design principles, even when his work has been downplayed or ignored by computer companies that have hired him. This piece surveys his thoughts on the problems of usability, based on his online and offline writings. Since he has never been afraid to express his opinions on the subject, there's plenty of material to work with.

Date:  01 Apr 2001
Level:  Intermediate
Activity:  763 views

As a recognized leader in human/computer interaction design, Bruce Tognazzini has kept the industry on its toes for two decades. He spent 14 years at Apple Computer, during which time he founded the Apple Human Interface Group. He has has also served as Distinguished Engineer for Strategic Technology at Sun, and was a lead designer for the WebMD site. He has published two books -- Tog on Interface and Tog on Software Design (see Resources), and is now a principal at the Nielsen Norman Group (along with Jakob Nielsen and Don Norman).

When most systems programmers thought the command line was just fine, Tognazzini was thinking about how a well-designed graphical user interface (GUI) could help boost user productivity -- something very different from computer productivity. Even more radical, he tested his ideas with real users, the kind who would actually use the machines being designed.

Most of the following can be found in various articles on his AskTog Web site (see Resources). I've saved you the trouble of reading everything through. His verbatim thoughts are surrounded by quotes, while blame for everything else must be borne by the author.

Principia Tognazzinia

Tog (this is how he refers to himself when he speaks in the third person impersonal) avers that basic design principles remain the same whether the output is a GUI or a Web page. That universality makes sense in Tog's user-centric view, since the user-perceived output of the Web through the browser depends on a computer's display.

His basic principles of interfaces can be summarized in his own words:

"Effective interfaces are visually apparent and forgiving, instilling in their users a sense of control. Users quickly see the breadth of their options, grasp how to achieve their goals, and do their work."

"Effective interfaces do not concern the user with the inner workings of the system. Work is carefully and continuously saved, with full option for the user to undo any activity at any time."

"Effective applications and services perform a maximum of work, while requiring a minimum of information from users.""

As you can see, Tog's principles are user-centric and user-empowering. The user must be considered as a design parameter in the work process and determines the true measure of any interface. This concentration on the user doesn't imply that a good interface doesn't have rules that need to be followed to achieve a desired effect. On the contrary: "The computer, the interface, and the task environment all 'belong' to the user, but user-autonomy doesn't mean we abandon rules."


The autonomous user and consistency

An autonomous user still needs information, and a GUI must present relevant task status information clearly:

"No autonomy can exist in the absence of control, and control cannot be exerted in the absence of sufficient information. Status mechanisms are vital to supplying the information necessary for workers to respond appropriately to changing conditions. Users should not have to seek out status information. Rather, they should be able to glance at their work environment and be able to gather at least a first approximation of state and workload."

Users also need consistency across all areas of their computing and work. But how strict that consistency is across differing structures is a design decision. In the following, Tog rates the importance of consistency as it applies to certain parts of the overall interface.

"This list is ordered from those interface elements demanding the most faithful consistency effort to those demanding the least. Paradoxically, many people assume that the order of items one through five should be exactly the reverse, leading to applications that look alike, but act completely different in unpredictable ways: [1] interpretation of user behavior -- shortcut keys maintain their meanings; [2] invisible structures; [3] small visible structures; [4] the overall 'look' of a single application or service -- splash screens, design elements; [5] a suite of products; [6] in-house consistency; [7] platform-consistency."

Tog goes on to explain that, "'Invisible structures' refers to such invisible objects as Microsoft Word's clever little right border that has all kinds of magical properties, if you ever discover it is there. It may or may not appear in your version of Word. And if it doesn't, you'll never know for sure that it isn't really there, on account of it's invisible. Which is exactly what is wrong with invisible objects and why consistency is so important."

"'Small visible structures' refers to icons, size boxes, scroll arrows, etc. The appearance of such objects needs to be strictly controlled if people are not to spend half their time trying to figure out how to scroll or how to print. Location is only just slightly less important than appearance. Where it makes sense to standardize location, do so. The most important consistency is consistency with user expectations."

Don't forget that inconsistency is your ally in usability as well:

"It is just as important to be visually inconsistent when things must act differently as it is to be visually consistent when things act the same."


Get efficient and productive, too

It's good to discuss getting the maximum back from the minimum user investment into an interface, but don't think that usability efficiency is all in the GUI. Tog knows this:

"The great efficiency breakthroughs in software are to be found in the fundamental architecture of the system, not in the surface design of the interface. This simple truth is why it is so important for everyone involved in a software project to appreciate the importance of making user productivity goal one and to understand the vital difference between building an efficient system and empowering an efficient user. This truth is also key to the need for close and constant cooperation, communication, and conspiracy between engineers and human interface designers if this goal is to be achieved."

Summing up his message is simple: "Look at the user's productivity, not the computer's."


User performance

According to Tog, there are three tasks that users perform routinely when they interface with any machine -- be it computer or sewing machine. Interface designers should try to simplify these tasks for the user, thus leading to greater true productivity. These tasks are:

  1. "Users form judgments resulting in decisions relevant to the task being performed."
  2. "Users gather the data necessary to perform the task."
  3. "Users manipulate the machine by operating its controls."

Tog explains:

"User-performance is maximized by attacking each of the three steps, reducing the need for decision-making, enabling the machine to gather its own data, and cutting back on the amount of machine-manipulation necessary to achieve the goal."

Limiting decision-making that's required of the user can be implemented with these points in mind:

  1. "Do not use the user as a 'rules database.' Don't have users merely reporting decisions previously made and compiled into a book or binder."
  2. "Evaluate each remaining decision to ensure its necessity."
  3. "Provide the user with the information necessary to form decisions quickly and accurately."
  4. "Remove extraneous material."
  5. "Communicate through the visual design what are assumed to be the high-probability answers."

Getting the machine to get its own data (or just decreasing the data entry chores of the user) is a lofty goal, but decisions must be made regarding just what is acceptable in the pursuit of that goal. Tog again:

"Three techniques can increase performance in data entry by minimizing the amount of information to be entered."

  1. "Pull up previous records and auto-fill as many fields as possible."
  2. "Minimize or eliminate data to be entered. Can the information be inferred? Is the information strictly necessary to perform the task? If not, is any secondary use valuable enough to offset the cost of entry?"
  3. "Explore other means of obtaining the information."

"Approach 1 is most effective when the previously entered information can be depended upon to be up-to-date and accurate enough for the task. Otherwise, the user can quickly expend any time savings in comparing the old with the new, looking for disparities."

"Approach 2, minimizing data entry, can often be quite difficult to achieve for a reason that is often unexpected. The first thing many clients will attempt to do once they detect that a new system is going to save them lots of time and money is to try to reduce the efficiency of the system just as much as possible, so they can give all that time and money back. It's not that they really want to maintain an inefficient system, it's just that they recognize that now, for the first time, they can gather all that extra, secondary information that was prohibitively expensive to gather before. Work with your clients and show them exactly how much gathering that information is going to cost them. They will make the final decision; your job is to ensure that it is an informed decision."

"Approach 3, obtaining information by other means, is worth considerable effort. Make sure that you are looking at the 'big picture.' For example, one means of getting information off of paper forms and into the computer is to put the form through an optical character recognition system. Such systems are costly and, depending on the cleanliness and redundancy of the incoming information, may require more hand-work than they save."

Limiting machine manipulation can get rather tricky. One has to be very aware of what is and isn't machine manipulation. Tog is fairly explicit on this point:

"When analyzing a design, constantly separate out those components of an operation that are machine-manipulation vs. the more abstract task of telling the machine something it otherwise couldn't know, either in the form of external data or user judgments." Then:

  1. "Eliminate as much machine-manipulation as possible. Do this first on a gross level. Is this second screen necessary, or could this task be accomplished on one screen? Should the user really have to do this housekeeping task? Then perform the same review on a fine level. Is this keystroke/mouse click strictly necessary? Can this task be combined into a single step, rather than requiring two?"
  2. "Make the remaining machine-manipulation track the user's model of the task. Avoid requiring users to make mental translations of the way they look at a task into a form your machine can understand. Offer instead the most direct and natural control possible. Don't perform this second task in a vacuum. The most direct and natural approach is dependent not only on the task, but on the profile of your users."

Some examples of TogThink

The explorable interface

Let's look at some of Tog's bullet points for what he calls the "explorable interface." Such an interface should have the following characteristics:

  • "Give users well-marked roads and landmarks, then let them shift into four-wheel drive. Mimic the safety, smoothness, and consistency of the natural landscape. Don't trap users into a single path through a service, but do offer them a line of least resistance. This lets the new user and the user who just wants to get the job done in the quickest way possible [take a] 'no-brainer' way through, while still enabling those who want to explore and play 'what-if' a means to wander farther afield."
  • "Sometimes, however, you have to provide deep ruts. The closer you get to the naïve end of the experience curve, the more you have to rein in your users. A single-use application for accomplishing an unknown task requires a far more directive interface than a habitual-use interface for experts."
  • "Make actions reversible. People explore in ways beyond navigation. Sometimes they want to find out what would happen if they carried out some potentially dangerous action. Sometimes they don't want to find out, but they do anyway by accident. By making actions reversible, users can both explore and can 'get sloppy' with their work."
  • "Always allow 'undo.' The unavoidable result of not supporting undo is that you must then support a bunch of dialogs that say the equivalent of 'Are you really, really sure?' Needless to say, this slows people down. In the absence of such dialogs, people slow down even further. A study a few years back showed that people in a hazardous environment make no more mistakes than people in a supportive and more visually obvious environment, but they worked a lot slower and a lot more carefully to avoid making errors."
  • "Always allow a way out. Users should never feel trapped. They should have a clear path out."
  • "However, make it easier to stay in."

Human-interface objects

Objects that are user-oriented represent some aspect of the user's already familiar environment and thus can be used in an interface to communicate with the user on his own terms. As Tog puts it:

"Human-interface objects are not necessarily the same as objects found in object-oriented systems. They appear within the user's environment and may or may not map directly to an object-oriented object."

  • "Human-interface objects can be seen, heard, touched, or otherwise perceived."
  • "Human interface objects that can be seen are quite familiar in graphic user interfaces. Objects that play to another sense such as hearing or touch are less familiar."
  • "Human-interface objects have a standard way of interacting."
  • "Human-interface objects have standard resulting behaviors."
  • "Human-interface objects should be understandable, self-consistent, and stable."

Conclusions

Tog has much to say about what usability is and what it isn't. Some of it may sound like efficiency expert talk to a graphic designer, but it's Tog's point that a graphic artist alone shouldn't be expected to come up with good UI elements. A cross-pollination of many disciplines is needed to obtain the best overall user experience.


Resources

  • Bruce Tognazzini's AskTog site allows you to send him specific questions, and includes usability news and commentary from Tog himself.

  • His book Tog on Interface explores the central issues of user interface design, including probems presented by multimedia applications. Tog on Software Design includes insights on a range of software topics from quality management to the meaning of standards.

  • Tog is a principal at the Nielsen Norman Group, one of the leading user experience strategy consulting firms.

  • Visit IBM's Ease of Use site for the latest in design guidelines, from designing for the Web to out-of-box-experience.

  • developerWorks Web architecture zone: Get the Web development solutions you need.

About the author

Larry Loeb

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been -- among other things -- a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX, and the VARBusiness Exchange. He's also written a book on the Secure Electronic Transaction Internet protocol. His first Mac had 128K of memory. His first 1130 had 4K, as did his first 1401. You can e-mail him at larryloeb@prodigy.net.

Comments (Undergoing maintenance)



Trademarks  |  My developerWorks terms and conditions

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Web development
ArticleID=11524
ArticleTitle=The usability world according to Tog
publish-date=04012001
author1-email=larryloeb@prodigy.net
author1-email-cc=

My developerWorks community

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Special offers