Documentation Doctor

Good UI design isn’t easy. Even the big boys get it wrong. It would be great if everybody had time to do a proper job of UI design. But the reality is that most of you guys are like me; “bootstrapping” in some corner of your home, using your enthusiasm and drive to turn your calender into a fractal time-line, and getting things done in the invisible squiggly bits.

To an extent, if the software does what the user wants, then a UI only has to be “good enough.”

However, there are one or two seemingly trivial UI oversights which – I think – can create a kind of mental friction… eating away at your user’s sense of certainty and security, leading them to make errors, or suspect errors.

Let me propose, as a rule of the thumb, that if it’s hard to document, then it’s probably also harder than necessary for a user to understand.

So, things which bug me  – your humble techwriter-for-hire - probably also bug your u$er. (And – if you’re not my client, please remember that I might well be your user… or would be, if your interface didn’t put me off .)

Here are six ways to avoid the most common UI issues. None of them are rocket science!

1. Name everything, including any groups of fields and lists. This makes it easier to describe the interface, and avoids sentences such as “Select a format (lower right group of fields), then, in the green list, select a file”.  It also makes the interface less intimidating for the new user.
2. Use names consistently throughout. If you call a spade a “spade”, don’t then call it an “implement”, and then a “digging tool”. A User Interface is not the place for elegant repetition, because it’s very easy to confuse synonyms with parent categories.
   In other words, the user may wonder whether perhaps the entity SPADE is a subset of “DIGGING TOOL”, itself a subset of “IMPLEMENT”. (And God-forbid you do then decide to add more entities, and forget to rationalise your terminology.) Get a lexicon dude, and stick to it!
3. Avoid …. like … -  You know what I mean? Those “friendly” fill-in-the-blanks sentence/field combos. They do look friendly, but what entities and parameters is the user dealing with? There’s nothing to hang the information on.
   Also, these are potentially (your) murder for non-native speakers. Which is easier to translate, a complex sentence, or a table of fields and noun field labels? How would the resulting support call go?
4. If it’s not a wizard, don’t pretend it is one! Repeat after me, “Wizards don’t need documenting. Wizards are linear.“ 
   If you have a complex set of options, don’t present them in a one-way fashion; users often want to go back to confirm their choices before pressing OK!
   Also, imagine a support call where you want to check their settings… 
5. If it looks a bit like a standard office application, make it work like one! I know you think you’ve written a clever time-management system, but to the user it’s either a calendar or a special spreadsheet, and they’ll expect it to be organised as such.
6. Don’t reinvent the wheel! Be honest – is your feature so very unique that no interface element created in the last ten years could handle it?