A few of the artists I know use software for some aspect of their art. Every one of them is particular about the art program they use. Other art programs are hard for them to use, they say, because they can't find familiar features when they need them.
Now, it's a given that different interfaces will organize tools differently. What surprises these users is that the names for similar features are different on different programs. This is an old problem in computer software, and it doesn't just cause trouble at the application level: Very few people have reason to know the technical differences between a Microsoft®Windows® "shortcut," an Apple® Macintosh® "alias," and a UNIX® "symbolic link."
In fact, this problem isn't limited to software. Some might say it gets even worse once you start browsing the Web. If you're interested in working for a company, are you looking for a link labeled "Careers" or "Jobs"? Or say I want to talk to someone. Am I looking for customer service, customer relations, or customer support? Is there a difference? If you have more than one, which one do I need right now?
I think it's time for The cranky user to address that old question, "What's in a name?" As it turns out, a little caution in the naming of things goes a long way. At the least, a well-chosen name can make it easier for users to find the software features they need, or to locate information on the Web.
Separated by a common language
One of my artist friends recently switched from Corel PHOTO-PAINT to Corel Painter IX. The company has been producing both applications for a while now, so you might think they would use similar terminology. Unfortunately, as my friend has found, that isn't always the case. The past couple of months he has frequently complained of the things "Painter can't do." And yet it often turns out that Painter can do those things, just as soon as he learns the right terminology to describe what he wants. Another artist I know stayed with Corel PHOTO-PAINT 8 for a number of years simply to avoid having to learn a new interface. This was despite quirks like foreign-language dialog boxes coming up under Windows XP, mind you.
The point is, reorganization is hard on users, even when the results are positive. Users have to schedule downtime to learn a new interface, which can be hard to come by on a busy schedule. It's a frustrating trade-off, even for those who want the positive results.
What mystifies me is that most companies don't include cross-references
in manuals and indices. If the documentation cross references the various
(present day and archaic) names of features, users have some chance of
finding the terminology they need. Of course, cross-referencing requires
that the index itself be comprehensive, which seems a lot to hope for from
most software manuals. To this day, I tend to approach the index of a
software manual with a feeling of dread: Will it have all of seven
items, none of them what I am looking for? Probably. Will one of those
items be the error message "Warning: This cross-reference is invalid (-23)"? Probably.
So, how can you help users use your software? For starters, don't make up new names for your same old familiar features. If your graphics software has the most powerful and flexible layering system ever, so much that you want to give it a new name ... don't. And really don't give it a name that's in common usage for some completely different kind of feature. Just call your layers "layers" and explain why they're better than everyone else's. Similarly, when writing documentation, take the time to figure out the names commonly used for your feature. If you have the option, use the most common name for it, instead of one of the less common ones. No matter how clever you think it would be to rename the File menu to something like "Documents," don't do it. Users know that important functions like open, close, and save are always found in the File menu, and you don't want to mess with that.
Okay, I admit it. Even though I've been browsing the Web for years, I still tend to get lost. A major electronics retailer recently started sending me tons of junk mail at an address I used for a purchase in 2000. (It wasn't even a successful order, the company listed the product as back-ordered and then never came up with it.) It's bad enough that the company is spamming me; what makes it a problem, though, is that I can't find out who I need to contact to make it stop. I mean, I did eventually find the page that lists the e-mail address to write to if I want them to keep sending me junk mail. But I haven't had any luck finding the address to write to if I want the junk to actually stop; or even who I should contact if I want some indication that my e-mail has been received.
Probably 30% of the time when I come to a Web site I'm looking for contact information. Some companies simplify things by making "Contact us" a prominent link on their main page. Bravo! for these companies. Others have the link under "About us" or "Company info," or possibly just plain old "Company." Some have it under "Customer service" or "Support." It's hard to guess where you'll find the contact information you seek. Sometimes it requires navigating to the right section of a site and then looking for contact information.
Synonymity is one thing and poor information design is another. I'm particularly peeved by game companies whose downloads section consists exclusively of things like wallpaper files and collections of graphics for fan sites, while actual patches are hidden away on another machine with no obvious links to it. Downloads should mean "anything we have that you might want." I shouldn't have to look for a technical support page when what I really want is a download.
Naming products, features, and Web pages can be a challenge. Try browsing your logs to see what keywords users search for when they search on your product or page. If you find certain keywords especially common, use them on your main page. (Of course, if you find a lot of searches for anatomical things your site doesn't sell you might want to skip this exercise.)
Better navigation starts with a map
Ironically, some navigational aids that are helpful in paper documentation aren't so helpful on a Web site. In documentation, a "See also..." pointer in the index is useful to me. On a Web site, if "Customer service" turns out not to have the information I want, discovering that "Support" and "Contact us" go to the same useless page will just annoy me. The solution, in this case, is to make your pages more useful.
I can never stress enough that you simply must provide your users with contact information. That means a real e-mail address that is checked by a real human who will ensure that user messages reach the right destination. Yes, that means someone will have to sort through spam, but it's the only way to ensure that your customers can actually reach you. When a company doesn't provide any real contact information I assume that its representatives, if I can ever locate them, will be hostile. I also tend to assume that the company's products are problematic. After all, why else would they be hiding from me?
I personally think every Web site should have its contact information under a "Contact us" link on the main page. If your product uses or needs patches of any sort, call them "Patches" and have a link to them on the front page, too. Firmware upgrades, BIOS updates, who cares: Call them patches and make it easy to find and download them.
Ralph Waldo Emerson once said "A foolish consistency is the hobgoblin of little minds." (In a fit of irony, three people selected this as their personal quote in my high-school year book one year, and no two of them used the same wording.) Consistency of terminology in production software and Web pages is not foolish, however. Gratuitously renaming common features like cut, copy, and paste, or layering features in graphics software, in no way shows the world how daring and innovative you are. More likely, you will just leave people with the impression that your product or page doesn't have the feature, because they looked for it under the expected name and didn't find it.
Whatever you're producing, it probably bears some similarity to other products that have come before. Do some research on how those products described their features and components, then either use those names or make it easy for users to see how those names and concepts relate to your product. Familiarity is powerful. Failure to leverage it in some way creates a barrier to adoption by users accustomed to similar products.
This week's action item: Go to a few Web sites and try to locate the e-mail address for customer service. If you manage that, try finding the phone number for the front desk. Good luck!
Learn
- The cranky user: Who needs a virtual keyboard? (Peter Seebach, developerWorks, February 2007): Software shouldn't always imitate life.
- The cranky user: Ten ways to do better in 2007 (Peter Seebach, developerWorks, January 2007): A New Years to-do list for Web developers.
- Web Pages That Suck (Vincent Flanders): A thoroughly cranky approach to learning the difference between good Web design and bad.
- Get free stuff for Web design (Uche Ogbuji, developerWorks, July 2006): The title says it all; a good listing of freely available tools and other resources for Web designers.
Discuss
- developerWorks
blogs: Get involved in the developerWorks community!
