A Button By Any Other Name
Suppose I say "I'm a high-level programmer." Many people would be impressed, because "high-level" often means advanced or complex. Programmers and other technical folks, however, would not think much of my skills. And rightly so. When it comes to programming, the "higher" the level of programming, the further one is from machine code (the Øs and 1s that comprise the "lowest" programming language). Thus, a descriptor that means one thing to the general populace can have a completely different meaning to certain specialists.
And that's why programmers should not be allowed to name screen elements nor write instructions.
Don't get me wrong. I have immense respect for programmers. Yet while they're amazing when it comes to writing code, they're usually not as adept at writing clear, concise English. Not to mention that they generally don't want to spend time doing that kind of writing.
Case in point: a button called "Manage Appointments." It's on the internal-use-only menu of a site that allows the public to schedule meetings with a professional by selecting a location and a time slot. (For confidentiality, I won't say what the appointments are for.) This site was produced by programmers with a few basic descriptions about the tasks needed, but not much else. In other words, the programmers were responsible for a lot more than programming.
Now, what do you think you'll be able to do if you click "Manage Appointments"?
- See which time slots are filled.
- Access information about who is scheduled.
- Adjust the time slots for future dates.
The answer in this case is "c." The real question then becomes "Is that the best name for the button?"
Once people know what the button is for, maybe they won't have trouble associating that button with that task. However, the task isn't performed often, so it may take an extra moment for them to recognize which button to use. Admittedly, it's not a major impediment to productivity. But that doesn't mean the button shouldn't be named more accurately. For example: "Adjust Time Slots." That's more precise and slightly shorter.
Of course, as a writer, I'd like to say that the only way to get clear-cut names and labels is to hire a writer (certainly an excellent option!). An alternative is to ask some users. Yes, I realize that is not a radical, new idea. Usability testing is always appropriate. But, sadly, it is often skipped, generally with an excuse about budgetary and/or time constraints. This brings to mind the adage: "If you don't have the time or money to do it right the first time, how are you going to find the time and money to fix it?"
The most efficient software development I've seen was accomplished by programmers working from detailed scripts. At the very least, they deserve a basic flow chart and a list of standards to follow, which might include instructions about:
- the use of screen titles
- the format to follow for dates, phone numbers, and similar multi-part fields
- the convention for naming various screen elements
When multiple programmers are involved, the more vital it is to be sure they're all following the same rules.
In other words, give programmers what they need so they can do what they do so well. Let them write code.