I called a DSL provider recently to cancel a 30-day trial. The first action the system demanded of me was to enter my “ten digit account number.” I frantically started looking for my shipping statement to see if it had my account number on it. It didn’t. The automated voice told me I hadn’t entered my account number yet and asked me for it again–time was ticking. I darted for my filing cabinet in search of my last phone bill; maybe they used the same account number since they were both provided by the same company. But, no, that couldn’t be it; my telephone account number was longer than ten digits. Then it dawned on me, the system was asking for my plain old phone number. I entered it, and the system recognized me.
Why didn’t it just ask me for my phone number in the first place?
Usability engineers promote the use of controlled vocabularies–consistent naming of items within products and services so that users quickly recognize the content being referenced. If there are two or more ways to name something, content authors should pick an authoritative descriptor and stick with it. Doing otherwise confuses readers and users. The goal is recognizable terms that lead to quick formation of concepts.
Several information architecture books cover the topic. My favorites are Information Architecture by Christina Wodtke, Hot Text, and Web Bloopers. All three suggest developing lexicons for site authors to use as the de-facto list of approved descriptors. Use of competing terms is prohibited.
Developing a lexicon upfront can be time-consuming, largely because you have to guess what terms will be necessary. Second, it’s an expensive process because you have to decide which terms win among the competitors. There are three ways to make the construction of a controlled vocabulary inexpensive and simple:
- Use a wiki or something else that doesn’t involve a lot of administrative overhead to store and disseminate the list of terms and the synonyms that lost the naming war.
- Debate and add words when authors and editors need to use them. This comes from a programming paradigm called lazy-loading. Don’t do the heavy-lifting unless or until you absolutely have to. You can experiment with letting authors decide which terms win when concepts are first encountered or having authors get help from the senior editor who is responsible for defining the appropriate lexicon. Obviously, whoever is making the decision needs to be informed and logical. Experiment until you identify the method that works best for your team.
- Save intra- and interpersonal debate time by using authoritative sources. Use websites on the topic or pull out your old college textbooks to get the wording right. Minimize the amount of time you spend determining which words your team will be using.
So that I can be as lazy and cheap as possible, and yet construct the appropriate lexicons for what I develop, I simply use Wikipedia whenever I can. The Wikipedia community is doing an excellent job creating a controlled vocabulary in a methodical way.
It’s okay to be lazy and cheap if you arrive at the right conclusion. It’s smarter than brute force.
(Speaking of laziness, the system could have just used Caller ID to identify me. But then I wouldn’t have anything to write about today.)
Ian Lotinsky 