Building a Minimal Required Usability Vocabulary

When you build your software, you want to accommodate all the users, from beginners up through advanced. This is a difficult job; you want to make your software easy enough for the beginners to use, but at the same time, you neither want to insult your advanced users nor hold them back. How do you do this? Here’s how:

  • Make the most common and important tasks the most visible tasks.

  • Make the less-common tasks easily accessible, such as through menus and toolbars.

  • Allow the users to configure the menus and toolbars.

Usability experts talk about the vocabulary that you need for using the software. They talk about different levels of the vocabulary, with the lowest level being the process of pushing the mouse button down, possibly sliding the mouse, and lifting the mouse button, as well as pressing a key. These are like the letters of the alphabet in that they represent the smallest possible piece of a vocabulary.

You can’t change this lowest level of vocabulary (and if you attempt to, you’ll be making a big mistake in terms of sales potential). And you also don’t want to change the next level up, where you find the standard controls such as buttons and listboxes, as well as windows and such. In a language analogy, these are on the word level.

But the level of vocabulary you can change is in how your controls are organized in your window, how your menus and toolbars are laid out, how you make use of the space in your window, whether or not you use status bars and other feedback mechanisms, and so on. Using the language analogy, this is the level of vocabulary where you find sentences and even paragraphs.

While you are free to build as big and powerful a product as you want, on the surface you want your product to be easy to use. If you have a great number of features, then the users will need a large usability vocabulary for working with your product. The key, however, is to keep the required vocabulary to a minimum.

Look at a word processor, for example, our old standby product. How do you use a word processor? After starting the program, here’s how:

  1. Type your document by pressing keys.

  2. Print your document by choosing File Print.

  3. Save your document by choosing File Save As.

  4. Exit the program.

And later when running the program again:

  1. Load the document by choosing File Open.

That’s only five steps! The program is very easy to use. Even beginners can use it. Yet, if this is Microsoft Word we’re talking about, then you can also do a great deal more. But these five steps, I would argue, are the minimal vocabulary required to use the product.

Now think about what you are presented with when you start a word processor such as Microsoft Word. By far the biggest part of the screen is the blank page with the blinking cursor, ready for you to type. You don’t have to do anything at all to start writing your document; if you just press the A key, the letter a will appear on the screen. Yet, at the same time, all the functionality is there for the power users.

Now the standard word processors we use (such as Microsoft Word) are certainly not perfect in usability, but you have to admit, if you want to type a document, things couldn’t be much easier.

To build your own minimal vocabulary, sit down and think about the most common tasks people will do with your software—and make sure you’re thinking of your targeted user, not some idealized version of yourself. Make a list, and go through each item carefully. Are these really the most common tasks? Are there more tasks? Are there any tasks that aren’t very common that should be removed from the list? Ideally, you should have less than six or seven items on the list.

Then these items will be the focal point when your software starts up. However, make sure that these features are really available and that you’re not just starting with some kind of wizard; starting with a wizard, in my opinion, is “faking it.” If you need a wizard, then you are admitting that your software is difficult for the beginners to use. Time to go back to the drawing board.


One of the hardest things about developing software (similar to writing a book) is remembering what it was like when you didn’t know what you know now. Some things that seem like common knowledge to you now are mystifying to less-sophisticated users. Even something as simple as saving a file can be disastrous for the inexperienced. At public computers, for example, it’s common for users to work hours on a document, all the while saving it to the computer’s hard drive inadvertently. Then they pop out their floppy and leave, only to discover that it’s blank when they need to use the document days later. Stupid? Not really. It’s an easy mistake for new computer users to make. Even when creating applications for the professional programming market, you know a lot that your users don’t. Always keep that at the front of your mind as you develop your vocabulary.

REAL WORLD SCENARIO: A One-Handed Universe

start example

If you have two hands, consider yourself fortunate. Too much of this world is not engineered for people with one hand. I have two hands, yet I like to use each hand for different tasks. And when you start trying to do certain tasks using only one hand, you start to realize just how difficult it is for people with only one hand.

Here are a couple of examples. When I’m doing the dishes, I like to use the sprayer thing that’s attached to the back-right side of the sink, separate from the regular fixtures. The one in my house, however, has a slight flaw that may be adding to my gray hair. Remember how these things work; the nozzle is attached to a hose, and the hose retracts down under the sink. When you use the thing, you pull it out, and the hose extends. But the problem is that when I’m finished using mine, it doesn’t retract! If I somehow try to push while holding onto the nozzle, the hose just bunches up and doesn’t go back in, underneath the sink.

Now I usually use the nozzle only for larger dishes that I can’t rinse as easily under the faucet. When I do so, I hold the dish with my left hand, and I use the nozzle with my right hand. When I’m finished spraying, I might do some final rinsing under the faucet after I replace the nozzle. In other words, my left hand is holding the dish the entire time. When I’m finished with the nozzle, I just want to push it back in. But it won’t go back in. And so I have to set down the dish and use two hands to manually feed the hose back in. This is not meant for single-handed usage!

As another example, I prefer to use a book backpack instead of a briefcase. The backpack works great, but like the sprayer in the kitchen, it has a two-handed problem: You can’t zip it up with one hand! I’ve tried many times and it just doesn’t work. The cloth holding the zipper needs to be held taut for the zipper to work. But the backpack is too flexible. And once again, instead of zipping up, the whole thing just bunches and the zipper doesn’t budge. Grrr. And so I must use two hands to zip it up: one to hold the bag taut and the other to work the zipper.

I’m not a mechanical engineer, so I can’t say what the solution for the hose is. However, I suspect it wouldn’t be too hard to design some kind of spring system that would easily pull it back in when necessary. As for the zipper problem, that one’s easy: All they needed to include was a small wire sewn right into the material that would hold the zipper area taut, without me having to hold it. That’s all. And I’d gladly pay an extra couple bucks if it meant saving a few extra, valuable hairs on my head.

end example

Designing Highly Useable Software
Designing Highly Useable Software
ISBN: 0782143016
EAN: 2147483647
Year: 2003
Pages: 114 © 2008-2017.
If you may any questions please contact us: