If you know me at all from my online presence, you’ll know I have a thing about good interface design.

I don’t mean the sort of fancy theoretical considerations they teach you in HCI courses. I mean just the basics:

• Make the interface reflect its real world domain.
• Keep navigation simple and consistent.

Late last year, I was lucky enough to work on documentation for a system that’s a good example of how to “do it right”.

FastMaint essentially turns your PC into the equivalent of a fully-staffed maintenance office. Not only does it handle work orders and the resulting workflow, among other things, it also tracks inventory, rostering, locations and equipment. It even warns you if you’re trying to do something impossible or unwise…

With so many different entities to manage, this could have been a horribly complex piece of software. However, the SMGlobal team managed to make the product so intuitive that even a deskbound techwriter such as myself quickly made sense of it.

They achieved this by putting in the hard work required to keep the interface consistent and convenient. Here’s an example:

• If you’re a maintenance professional, then all this should make sense to you, even if this is the first time you’ve seen FastMaint!
• If you’re looking at an entity or list of entities – here, equipment located in a building – then there’s a button to create or add a new one.

In short, you – the user – can concentrate on the task in hand, without wasting brain space on the software.

All this may not be rocket science, but it requires the sort of thoroughness you associate with building an actual rocket:

• Somebody must have gone to the trouble of learning the terminology used in maintenance departments, then made sure that the screens reflected it. (This probably meant acting as a sharp-eyed gatekeeper whenever developers became “creative”.)
• Somebody else had to slog through the UI, putting in all those buttons, creating all those editors…

When they graduate from college, most young coders dream of wrestling with algorithms and architectures, not putting in the kind of meticulous effort on display here. However, if this were a launch vehicle, then I’d cheerfully ride it to the stars.

If you don’t believe me, download the application and take a look for yourself.

If you do that, you’ll also see my streamlined documentation that builds on the application’s ease-of-use.

It’s usually harder to cut, rather than expand, text, and there’s always the fear of leaving out Something Important.

However, my contact at SMGlobal, Sanjay Murthi, pronounced himself “…happy that you have been able to reorganize and simplify the help documentation.”

So, I like to think I’ve turned out an online help worthy of the product.

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?