Usability Institue Logo- A bolt that can be fastened with any of 4 tools
Reducing Training to Its Sensible Minimum: Zero...
Inexpensive, Independent Usability Consulting by Jack Bellis
Home Page- List of All Content Home Page- All content, in date order Resources: page describing tools you can use Morsels: just our short articles and blurbs Just our Before&After Articles Just our Before&After Articles About: details on who I am and what I do Address, phone, number,  and so on
User in Your Face- The Student Programmer's Before-and-After Guide to Usability and Usable Interface DesignUser in Your Face- The Student Programmer's Before-and-After Guide to Usability and Usable Interface Design

Table of Contents

Welcome. This is a book that I'll be writing in installments, published on this site, and interactive with visitors in that installments are written when requested... BY YOU!



  • A free, online book on user interface design.
  • To stop the problem where it starts, with new programmers starting over every day, recreating the mistakes of the past.
  • Read it, reference it, make students print it and read it, look for our paper version some day, a 4x6" flip book version.
  • Consider crediting at your option.
  • A single long page, for printing convenience (the old justification of structuring pages because of slow modems is dumb).
  • The conventional textbook organization will not be used, in favor of a more conversational flow and anecdotal organization. I'm not trying to put people to sleep; I'm trying to improve user interface design.
  How Much?
  • Free; the paper version might be $12.95 if I make it.
  • Updated 2006-Jan-29, Chapter 7: Grouping
  • Updated 2005-May-28, Chapter 6
  • Updated 2005-Apr-28, Chapters 4 & 5
  • Updated 2005-Apr-23, Chapters 2 & 3
  • Started February 19, 2005


The other day I was trying to find an online manual for a weedwacker that I saved from the trashheap some time ago. I finally found the manufacturer's page,, and eventually selected my model number from a dropdown list:

There was no Go button so I waited a second.

Nothing happened so I pressed [Enter].

Again, nothing.

I opened the dropdown again and there was something funny. It had changed from model numbers to a list—well, sort of—of serial numbers or so it said. The page hadn't responded because it was waiting for me to make another selection—a second selection—from the SAME dropdown list... ahhhh, the old Multi-Invocation, Drop-Down Selection/Function control... how could I miss it? Or as we say in the software world, how could I be such a stupid user?

And at that moment this book was born. I've written a lot about usability and user interface design over the years, but I always ask myself, what is the real solution to the bigger problem... not the individual UI fixes, but the whole industry. How can we stop raising whole legions of developers who will make the same mistake as on the weedwacker page? Where exactly is the root cause that must be pinpointed correctly to improve the situation. And I determined that it is in High School, in 10th or 11th grade, maybe earlier. That is what this book is for, to teach young programmers about the user side of software—what makes software friendly, or not.

Jack Bellis —June 14, 2004


Chapter 1, Basics

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

There are dozens of good books and maybe hundreds of good websites on usability. In fact, this book is a follow-up to my 1997 "Computers Stink." You can read the PDF on our Resources page. All of the books have got concepts, rules, ideas, and checklists galore. But somehow rules and concepts are making slow progress in improving user interfaces. Or are they? Perhaps it's possible that the universe of interface design is exploding so rapidly that any improvement is actually a great accomplishment. Maybe I shouldn't be disappointed at the Shindaiwa page... maybe I should be amazed that I can go three or four days between such experiences. And during that interval I will have looked at over 100 sites, perhaps 1000 pages!

In any case, it does appear that concepts are slow to sink in... slow to become inculturated. Checklists are good, too but they seem to be the tool of experts, not the food on which to grow. So our approach will be to simply supply a handful of carefully selected examples. Examples are everything in computer work. That's because everything is so new. Concepts are nice but they're really just an exercise undertaken by the pundits of the industy. What you need are techniques. That's where the rubber meets the road, so that's what this book will made of.

OK, Maybe Some Concepts Won't Hurt

So that the reviewers out there don't totally dis' us for presenting a rambling, stream-of-conciousness pile of blog, here's a summary of the principles we'll be demonstrating:


Usability can't be boiled down to a single item, but if you are forced to choose one, the best you can do is explicitness. Users can put up with almost any software shortcomings as long as they can figure things out. And the only way they can figure them out is if they can see what's going on.

Accuracy Be perfectly accurate. Users are dealing with extremely detailed situations. Information that doesn't exactly zero-in on the circumstances will eventually be a problem.
Use Verbose Phrasing Don't try to name features or web links with a single word. Use a noun and verb. Use several words if that's what it takes.
Directness Don't put intermediate words or links or buttons or images in between the user and the specific instruction.
Grouping Put related things together.
General-to-Specific Put important things at the top and left.
Segregation Now that you've got groups of things, separate and distinguish them to signify them accordingly.
Use Existing Solutions Creativity is great, but when it's unneccessary, it's a mistake.
Consistency? Everyone constantly says that you should be consistent, but this is overplayed. There are times when you need to differentiate things. The answer to many consistency questions is the same as the answer to all computer questions: "It depends."
Make Everything Browsable Sometimes this means using menus instead of special techniques or values. Sometimes it means using words instead of icons.
Use Descriptive Values, Not Internal Codes Use words that any competent Windows user will understand, not industry jargon, computerese, or even special business language. Translate things into what users are trying to do.
Use Images as an Additional Option—Not an Alternative—to Words Graphics are good for coming back to a feature, not for figuring things out in the first place.

Hopefully that didn't hurt too much. Beyond that, they get too detailed... not really principles. And did you notice that they're not particularly computer principles? They're actually principles of traditional print publishing, book-writing, newpaper layout, and so on... just general communication concepts. Yes, that's right—that's write?—computer design is communication design, just more dynamic.

The analogy to newspaper layout is from a great usability book, "Don't Make Me Think," by Steve Krug. Read my review.

If the list above is not detailed enough for you and you don't want to wait for the rest of this book to be completed, see Computers Stink on the Resources Page. Otherwise, please be seated and pull the safety bar down. The ride is about to start. We will attack the list in no particular order.

In the Shindaiwa example, the author tried using a creative solution. That's fine in some cases, but users are already accustomed to a different solution. The page should have a Go button and load a different page with the next choice.

Too Much Creativity, Before

Here's the second part of the Shindaiwa page, after I selected a Model Number. Remember, it was totally unnoticeable that the dropdown label changed.

Too Much Creativity, After

To improve the page, there are several options, but the most common one you'll see is to refresh the page after the first selection so the user knows a second selection is being made:

The lesson here is to use simple techniques that you see in use elsewhere, whenever they get the job done. If there are times when you must create a new technique, fine. But don't create new techniques just to save time or work, or because you think it's a better way to write the code.


Chapter 2: Accuracy

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

This motivation to finally commit this next block of content to little blips of magnetism on some far-away platter is thanks to Tim, a software engineer who's recently been nominated "The UI Guy" at his company. Other than that he gets no credit or blame for its content, satirical, technical, or otherwise. Let's hope that some day these little blips grow up to be proud pits on an optical disk, or even someday—try to imagine it—ink on a piece of paper.

The principle is as simple as can be: accuracy. You wouldn' think that would be a problem for such folks as are attracted to the precision on-off world of logic and algorithms, wudja? Well, my example is from no less than IBM. If you're reading this in the year 2045, that was a crusty ol' company that Megamergercast (the mega media conglomerate) bought and buried, indirectly by having bought and buried Microsoft in 2014. Anyway, here's how IBM did it in the good ol' days. What's wrong with this picture:?    ...or is it ?:

Accuracy, Before: IBM Login

Answer: the field label, "IBM ID" is inaccurate. It should simply say Email Address. Here's the "After" version, not exactly rocket surgery (give credit where it is due: Steve Krug/book on Amazon), but I promised before-and-after examples:

Accuracy, After: A Simple Fix

Now, I know what some of you are saying... "Hey, it says right there in the blue text that it's their email address, right?" No, it implies it. It's not in the field label, so it's not direct. That's the problem with this UI stuff, you could call this accuracy, or explicitness, or directness, or positioning. But you can't mistake this for an issue of brevity versus verbosity. So let's look at that next.

But first a note. Isn't it ironic that IBM, which ascended to prominence on its ability to speak Computerese, descended to dust on its inability to speak English?


Chapter 3: Verbosity

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

This might be my favorite UI issue. For the last few months I've been using this new source control system called Accurev. (Source control means a program that manages shared files on a network and prevents two people from editing a file at the same time.) Now, Accurev is an incredible product compared to the simpler tool I've used in the past. It provides a whole regimen for what's called configuration management, escalating software versions and so on. But it has this little Achille's Heel. (Hmm, there's no such thing as a little one, is there?) It tries to reduce all of its magic to single words, a new vocabulary of file contention dynamics. Look at the following figure:

Verbosity, Before: Accurev

Can you guess what the difference is between an external and stranded file is? Or how about member versus member modified? External, maybe you can intuit that one if you've got some code in your blood.

Verbosity, After: RoboHelp's Source Control System

Now lookie here. Here's a competing product, of sorts, that takes an entirely different approach:

It spells out "external" and all the other statuses in descriptive words. External becomes "not controlled." This is a file that one has not yet incorporated into the system. Stranded is one that was Removed from Version Control. Member/modified is "Checked Out Exclusive" and so on. All of a sudden, the system becomes self-training. And that is the goal of all usability if you ask me. (I'll take your presence here as evidence that you asked.)

The Goal of Usability
... is to eliminate the need for in-advance training.

Yes, usability also concerns itself with speed after training, but we'll get back to the ivory-tower-pontificating after we smother the topic of verbosity. The rationale for the Accurev approach is that brevity is a virtue, and eventually the short words are better, easier to scan, or more elegant whatever that means. Well, if elegant means that even brilliant programmers have to run around asking for help after they unintentionally clobber each others' files, then elegance has its place. Accurev has one of the worst and most dangerous learning curves I've ever seen. Even the brightest people I've worked with for years can't explain some of its statuses.

Getting back to the issue of speed after training, do the single words have any value? Absolutely. But there are two fixes needed:

  1. Make them an option that one turns on after learning the system. All complex systems, particularly business systems that computerize a whole job category or industry, should have a menu option for Beginner or Advanced Terminology.
  2. The information that causes the statuses should be explicitly displayed, probably as additional columns in the same listing. For intstance, it should list the date that the local and server copies were edited, flags for presence or absence in each place, and so on. Then one could account for the conclusions implied by the statuses. This gets us into implicitness versus explicitness. But that's another chapter.


Chapter 4: The Usability Pyramid

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

It's time to interrupt our examples for another commercial from our sponsors, the high priests of theory and concept. This time they would like you to consider that the usability principles are not an amorphous blob but indeed have a hidden beauty to them. Consider the following pyramid. Since the US FDA recently (April 2005) abandoned the pyramid for their food recommendations, we've taken that now unemployed icon and put it back to work.

Pyramid Diagram in High Resolution for Printing (171K)

Actually, ours started out as a tetrahedron, but depicting that left face cluttered the visual so poorly, we went back to the old King Tut style. By the way, there are two mistakes in the figure. Can you find them?

A picture being worth 1000 words, I'll let it speak for itself but let me clarify a couple of the items:

  • Menus are one extreme of letting users access functions, and I believe that drop-down menus are and will continue to be the ultimate (as far as learning goes) for a long, long time. But that final item in the Producing Tier, "Functions Accessed by Data... what's that all about. What that refers to is getting to functions by accessing items in a collapsible outline control, and seeing pertinent functions, either by right-clicking or having them otherwise enabled in the interface. Here's an example of a web application from approximately 1999, Asymetrix Librarian:

I see this as the diametric opposite of drop-down menus. Once you completely understand the metaphor/paradigm/data structure (call it whatever you want) of a system, you want to get to function in a single action, by finding the data on which you want to act.
  • The other thing to explain concerns "Multiple Metaphors" and "Multiple Paths to Functions." Multiple paths means that users should be able to find a function in more than one place, perhaps on a menu and in a toolbar... maybe even in two places on the menus. Multiple metaphors means that the most advanced programs should make themselves usable in more than one way. The simplest example is that systems with a robust GUI (graphical [point-and-click] user interface) should also have an ASCII (American Standard Code for Information Interchange, command line) interface. Let me think of another one.


Chapter 5: Directness

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

If you're looking for elaborate technology to answer your interface design problems, you'll probably be disappointed. Most situations can be improved with simple wording, as in our example here.

Directness, Before

How would you improve this dialog?

Before (3K)

This is one of the most common problems I find in the programming world. The example here was from approximately the year 2000. I came across the identical flaw in the system I'm working with today (in 2005). The "before" dialog is probably a simple case of "the convenience of the programmer taking precedence over the convenience of the user," (because it's easy to make a dialog with standard buttons). Many software development "environments" providea a standard "message box" capability and the programmer can choose to display one, two, or three standard buttons such as OK, Cancel and so on. So no matter how peculiar the actions are, the programmer looks for a way to map the options to the standard buttons. Well, that's fine if the choices naturally fit the words OK, No, and Cancel. But they have no relevance to the printer dilemma. Let's look at more explicit wording.

Directness, After

After (4K)

Stare at the before-and-after until it sinks in.


Chapter 6: General-to-Specific

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

Put important things at the top and left. That's what our concept list tells us.

In our part of the world, we read from left-to-right so you should position the most general items in the upper left. Our "before" poster child is from Microsoft Hotmail. Notice the name of the page running off the page to the right:

Before: Hotmail's Page Name

After: A Little Touch-Up Work

The page name is more general than the content of the page so it should be above and/or to the left of the content. So that's what we'll do.

We can't make this too complicated, there's just not that much to it. But then, how could the world's biggest software something-or-other get it wrong? (Maybe they wanted to advertise their Messenger product where your eyes would be looking.) Yet this issue is frequently the cause of complex problems. Let's look at another one, a more serious one that has caused hundreds of thousands—probably millions—of hours of lost time world-wide:

In this dialog from the world's most used software application, MS Word, the Apply To field is the most general item in the dialog. It controls something called the "scope" of the dialog... how much of the document the dialog applies to. In this dialog and a few others in Word, users don't realize until they mess up their document that they should have chosen a different scope. But not until spending a few minutes or hours backtracking and debugging. Where should the field be moved to? We'll leave that up to you.


Chapter 7: Grouping

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

If you haven't noticed by now, a lot of UI design is for the eyes, before the words are even read. Here's an example that shows the importance of putting things together in blocks. The following dialog appears in MS Word when you open a document (from your network) and someone else has it open already:

Without reading every word, it's a little hard to tell what the relationship is between the top two buttons. The following redesign groups the Notify button with its explanation. Just as importantly, it groups the Read Only button with Cancel. This helps clarify that your basic choice is to either open the document as read-only, or not. The notification feature is what you might think of as a side track. This is admmitedly an interesting situation, in that all three buttons are "terminating" buttons and I'm recommending putting one of them in a box (instead of at the bottom or side), but UI design is creative, folks. You're not going to help people if you try to use simplistic rules for complicated situations.

By grouping things separately, we let the 'mind's eye' quickly evaluate the choices. The user can instantly ignore the notification choice if they just want to read the document. And the usual choices of OK/Cancel are respected even though OK has the twist of being read-only.

Chapter 8: Noise Reduction

1: Basics | 2: Accuracy 2 | 3: Verbosity | 4: Pyramid
5: Directness | 6: Upper Left | 7: Grouping |  8: Noise    

This chapter is courtesy of a guest expert, Luke Wroblewski of LukeW Interface Designs ( If you want to be a slam-dunk genius at the visual side of interface design, spend a lot of time reading Luke's site. In his article, So the Necessary May Speak, Luke presents a wonderful before-and-after demonstration of how to present table data.

Take a look at this table. It's fairly common for work you'll see if you ask someone to take data from a database and put it in an HTML page:

It's not horrible but would you recognize any of its shortcomings? Now look at the "after" version:

Here are the techniques that were applied:

  • Eliminated fluff by removing "General" and "Number of." Even if these were the literal names in some other part of the system, writing is for reading, and no one wants to read repetitive phrases.
  • Eliminated redundant phrases. This is the biggest theme. It's equivalent to the old "distributive law" that we learned in fifth (?) grade about multiplication, right? (3 x 4) + (3 x 5) = 3 x (4+5). The "3" should only be stated once. As a result, "Discharges" and "Admissions" were changed to headings.
  • The black heading and bold black text were softened.
  • The vertical borders were removed. I've noticed this technique in better designed tables for years, not just on the web but in plenty of books and magazines.

All of those techniques come under the umbrella of reducing "noise," which is visual stuff that hides or distracts from the real story. Two more techniques were added that are just pure judgment...

  • The ultimate information—the numbers—was made bold.
  • The New Admissions section was "banded" with light blue.

But if there were no room for judgment, then we wouldn't be needed for this work in the first place, and it wouldn't be much fun either.


The following figure is from a "source control" system, one that has a shared database of files on the network. When you delete a file, here' s the message you get.

Now, you have to picture that the experience of learning a new source control system can be pretty harrowing since you're risking what seems like the loss of otherpeople's work... critical team work. Misunderstanding the system can be harrowing. So what does "delete is just delete" mean? The message is trying to tell you this:

"Explict" means "doesn't require any translation. Would you agree that the reworded message is as close as we can get to the issue?


*** The End for Now ***

To Do List

  • When the user does not have control, announce it prominently. If programmers were painters: Could you imagine "Wet Paint" that were the size of Post-it notes, perhaps stuck to the leg of a freshly painted park bench? Intermediate progress.
  • Be a communicator. Imperfect information is not an excuse for silence. Estimated download times
  • Embed the instructions: consider the example of MS Project, a software product that "sets the bar" on how complex a generic task can be. It requires lots of instruction on the screen.
  • Trap errors at every level and report them in descriptive words.
    Next Installment: It's Up To You!

    I'll write Chapter n when someone emails me that they're interested in reading more. And feel free to send a comment or question. Let me know if you want your comments added as a preamble to the chapter, with or without your identifying information. If you want your info included, at the minimum I'd expect to use first initial, last name, and city. Otherwise, it's up to you.

    Thanks, Jack May 28, 2005

"My interest in usability arose from the pain and tears of patching the wounds of suffering interface designs with the inadequate bandages of help files and user guides." — Daniel Cohen

2002,   All Rights Reserved
Any and all content may be reused without prior consent if you simply acknowledge the source,