Now and then I write a bug report (sometimes several on the identical subject, sorry Wassim!) and I comment that a certain term may not be understood by the user. That leads to a question, “Kevin, what was it about that term that you don’t understand?”. Its a tricky question, not because I’m afraid of revealing my ignorance (I seem to be pretty good at that) but because its often difficult to judge what a user may or may not know at some point in the workflow. We get very little feedback on terminology; users seldom submit bugs saying, “I didn’t understand this word in this button”, maybe because they either assume they’re just not smart enough or maybe they get frustrated by their confusion.
Its extremely easy to overwhealm a new user. That’s why the terms we use are precious. I use “precious” in the sense that each has a cost and we must spend them frugaly. The cost is to the user in their mental load. Really what we’re talking about here is concepts, since as we introduce new concepts we make up terms to denote them, and each concept has a cost in learning/interpreting.
As developers we spend so much time on our particular application that we forget what its like not to know, what its like to be a newbie. We can’t pretend not to know because we, the authors, now know too much! And we have a tendency of either making up terms that seem self-evident to us (but perhaps not to others), or create a mountain of new and obscure terms for the user to have to climb.
One way to deal with this is by keeping track over the terms we introduce. This allows us to track the concepts.
When I was working on IBM WebSphere Integration Developer (WID), we tried to pay attention to:
- Which terms we used
- Where we used them
- When we introduced them
Why are these important? Lets look at each:
1. Which terms we used
Since each term costs the user in time to learn and mental memory, we wanted to ensure our word budget was being well spent. Some things we tried to keep in mind:
- Is a new term worth the cost, or can we provide variations (adjectives to nouns) on the same concept?
- Are the terms being applied consistently?
- Are we using the same term for two different meanings?
- Are we using two terms for the same thing?
- Do the terms as a whole work well together?
- Are we expecting the user to remember too many concepts for performing simple tasks?
2. Where we use them
Good UI’s, like good code, should be self-documenting. That’s not to say that you shouldn’t write doc (or comment your code). But many people don’t look at doc, or find it difficult to find what they need, or we don’t do a good job of documenting. By repeatedly and consistently using a smaller set of terms, we make the UI more self-evident.
3. When we introduced them
Some places in the UI provide more context for the introduction of a term, such as grouping with like commands, ability to undo to allow experimentation, explanatory banner text, etc. A good UI should introduce the concepts in a gradual manner, starting with the basics and building as the user learns more. This is tricky to do in practice though because it requires a clear understanding of the user task flows and these can be very difficult to know in open-ended applications.
If the user finds a term they’ve never seen before, say as a button in an important wizard, they’ll either learn to ignore it (and never try your wonderful feature) or be fearful of pressing it.
Conclusion
Keeping track of the “namespace” that your UI is creating is an important tool in combating complexity. A disciplined approach would be to physically keep a glossary. This allows you to see at a glance the total mental weight of the application. If you have a documentation team they’re likely already accumulating this. They’re a great source of usability feedback. But just the act of pretending in your mind to keep a glossary, thinking of consistency, will help simplify the user’s experience.
