I promised this one to a friend some time ago but I've been procrastinating because it truly is a huge topic and I don't think I have the brain power to really do it justice. But I've been thinking that for the past few weeks whenever I thought about writing it, so that probably means now is as good a time as any.

My friend is in the middle of developing a software package, and the whole intent and purpose of said software is that it be simple and easy to use - it's not just an advantage of it, it's the whole point of that software existing. Because the software it's competing against has a monster of a learning curve. Creating software that's truly intuitive - especially for abstract concepts - is much, much harder than it sounds. But you can take steps towards it, steps that are (to me, at least) so bloody obvious, yet so few developers seem to bother with them. And they're based - hell, they're pretty much copied verbatim - from the principles of good technical writing.

Interface Bible

A while ago I covered some basic steps of techwriting - specifically the creation of some documents about the document you were about to create. A subject-matter thesauras and a style guide at the bare minimum, so that you can maintain consistency throughout the document, no matter who's working on it. (I'm not going to reiterate why consistency is so vital. Go read those articles. Or just wiat, because I'll probably cover it in a rant below). Consider these to form a document bible.

This isn't just for technical writers. Developers also need a bible -  for their interface.

Alright, I said I wasn't going to bugle about consistency, but it's vital. When you use your computer, how do you know how to open a program? How to select a group of things? How to bring up a pop-up menu? Because the operating system works consistently - the left-click always does the same thing, the right-click always does the same thing. To the point where, if it doesn't, you can be pretty sure your computer's crashed, or is at least thinking really hard about something.

Consistency in software goes further than this.

Terminology

In technical writing, there's a rule: one term per meaning, one meaning per term. It's kinda obvious, if you think about it for three seconds. If you're told to 'click' on something, you want to be sure whether I mean left click, right click, middle click, click-and-hold, or double click. If I use just the word 'click' to encompass all of those, using the documentation is going to get really frustrating while you try out every permutation of the meaning you can think of to make something happen.

The same goes for the terminology your software uses in its interface. Synonyms are not helpful. If you have a button with the label of 'Save' that saves the user's changes to the current file, then buttons that save the user's changes to the current file should always be called 'Save', wherever they are, and something that opens up a file choose window instead should not be called 'Save', but rather something different, lke 'Save Project'. If a user has to select a 'category' of something, it should always be called a 'category', even in different areas of the program, like a debtor category and an item category. If debtors have multiple categories, then acknowledge they're multiple categories. Don't start adding in extra words like groups or types for some, whilest using categories for the other.

It's hard to give more examples without getting myself into potential trouble with clients, but this rule should be applied to every piece of text in your interface. Every button, field label, title, check box - be consistent. Even if they're called something completely different in your code, if they look and act the same to your user, they should be called the same thing. You want to give your user as few things to understand as you can possibly get away with. Every new concept in your interface is something they have to learn and remember. Allowing them to re-use that information, by re-using your terminology consistently, means they'll learn faster, and feel that new aspects of your program are more intuitive. 

Decide what terms you're going to use - take a hard look at what terms you've currently got, and whether any of them should actually be the same thing, or a different thing. Do you have 'types' and 'categories'? Or perhaps 'items' used for different concepts? Do you use 'edit' alongside 'manage' or 'maintain'?

Create a subject matter thesaurus, both for your concepts (whatever your software is about - that'll come up in tooltips, etc) and your interface-commands and field labels.

Visual cues

What does it mean when you can see a button or a checkbox on a screen, but it's greyed out and doesn't respond when you press it? Pretty much everyone knows that - oh, I can't do that right now, there's something making that not possible. 

Consistency within your visual cues is perhaps the most important aspect of consistency. We navigate and understand a program far more by the implicit visual cues than the explicit text and directions.

If I see a table, can I edit the fields? All of them? Always? If a field is bold, does it mean something? Does it always mean the same thing when it's bolded? Are things grouped together or separated for the same reason?

I see so many programs where I can (for example) drag and drop table cells around on the debtor screen, but if I try to do the same on the creditor's screen or the item screen, it won't let me. Where I can bring up special actions on some buttons by right-clicking, but I get nothing  if I do it to others - not even a hovertip telling me no special actions are available for this button. Where fields are grouped together with a border because they do similar actions to the same object, like a set of filter fields for a report, but elsewhere fields are grouped with a border because they're vaguely related to tax information.

If two things look the same, they should behave the same.  If I see two grids, and I can edit the information in one but the other is read only, then they'd better look clearly different. Change the font colour, change the background, change something. Make them different so that:

• it's obvious to me that this is a new thing, something I have to learn and remember. See above paragraph about re-using learned knowledge.
• once I have learned this interface component, I can recognise it - I'll know that this type of grid isn't editable.

By the same logic, all things that behave the same should look the same. If some fields on a create-new-whatsit wizard screen are mandatory, you should:

• make it clear that they're mandatory - as an example, make them bold
• always use that specific indication for fields that are mandatory - they're always bold
• never make non-mandatory fields bold. Nothing else on your interface is ever bold unless it's mandatory. (Obviously, this excludes word-processing type things where a user can make bold text).

This is exactly the same as one-term-per-concept, one-concept-per-term, just translated into visual terms. And you should take the same approach - make note of each component you use and how, what its meaning is, each visual indication you use, including grouping and proximity, and what they mean. Put it in your interface bible with your thesaurus, and it's basically a visual dictionary. Whenever you go to create a new interface component, consult your dictionary: 

1. does it operate the same way as something already in there?
   1. If so, make it look the exactly same.
   2. If not, what's different about it - is it different in a way that you already have an indicator for in other areas? For example, is it a table where certain cells are mandatory?
      1. Then make those cells bold - use the visual cues that you have already taught to your user.
      2. If not, make it look different to every other indicator you already have.
      3. If it's not the same but close to an existing function, make it similar to that one but still different, if possible.

Obviously this requires some forethought - if you start just assigning visual cues to meaning without thinking through all the meanings you might have to convey, or how they might have to be combined, you'll end up with an eyesore. It's best to take note of all the various things you'll need to indicate (remember to future-proof this as much as possible) and then see how you can communicate those and their permutations efficiently and aesthetically.

Procedure

This one is often the trickiest to spot, and can be difficult to design, but it's one of the easiest ways to make your interface seem 'intuitive'. Once again, this is all about keeping things consistent so the user can re-use what they've already learned.

Say your software manages a wholesaler. They have debtors, creditors, items and staff at the very least. If I want to create a staff member, it should be the same procedure that I'd use to create an item, or a debtor, or a creditor. I should be able to:

• start from the same place - whether it's a Create New... menu option, or an identical button on each of the Sales/Items/Debtors/Creditors management screens
• have the same creation process or wizard pop up, which looks the same in all cases (obviously some field names may change, but it should be obvious it's a Create Something screen)
• put in information in roughly the same order as far as possible. For example, start with an ID number, name and description.
• have the program show me I've finished creating the whatever in the same way - for example, by opening the management screen for whatever I just created.

This can be difficult for developers, especially when you get to the more esoteric similarities, because it involves thinking about the processes of their code from a totally new and abstract viewpoint - broad categories of activities that aren't otherwise similar. And it's hard to create a feeling of similarity when there are extraneous extra steps or constraints for a certain process. But the basic rule still stands - try to keep the new things the user has to learn to a minimum. 

That can mean doubling up on your interface. For example, say when I create staff members, I have to set up some extra stuff - things like job positions and salaries and whatnot, which are usually managed in a separate screen. It's fairly natural to think "Oh, I should have the user set these up on the screen they're familiar with" and send them to that maintenance screen that you already coded. But that just broke your procedure consistency (bullet point two). Even though they're still dealing with things they've already learned, they instantly recognise that this procedure is different. It suddenly feels more complex, because you broke the flow. If, instead, you kept them within the wizard and had them enter in the job position and salary information in the wizard screens (which may well duplicate sections of the management screens), it stays the same process. They're not having to learn anything new. And it seems much easier and more straightforward.

Also - the order of things being created doesn't necessarily have to mimic the order they're required in. For example, say I have to create a new job position and pay category for my new staff member. The Create Staff wizard, written by your standard developer, may start with the pay category as the thing that everything else needs to know about. But that breaks procedural consistency - see the third point of the bullet list: put in information in roughly the same order as far as possible. From the user's point of view, they don't need to create a new pay category or job position until it's time to select the staff member's pay category and job position. Start with the ID, name and description, just like you do when you create anything in this software. When they have to select the pay category and job position, allow them to create those right there, within the Create Staff wizard before continuing with the regular process. All the while, you need to keep them aware that this is an 'extra' step to the normal staff creation process through some kind of cue.

I said it wasn't easy. Once again - a lot of forethought into your procedures, which should be grouped as similar, and what those similarities can be. 

Common Usage

Before you go setting up all these procedures and terms in your bible, you also need to consider how your client wants to use your software. A common mistake developers make is letting the structure of their code dictate how their interface works or is put together, instead of thinking how people actually work. (This is why, in my opinion, so many writing packages fail. They don't consider how writers like to work.) They group too many things together, stuff everything onto one screen, split it up by a category that means a user is using three different screens to do something that could be done with one, had it just been organised differently.

 This is especially important with structure, and can create a difficult balance between keeping your visual cues consistent (ie grouping things together for the same reason) and providing something that works the way the user wants it to work. But it's also important to consider in your naming conventions.

Often, tasks will involve a lot of steps. Maybe a user has a whole new staff department to add to their wholesaler, and so they have to add job positions, pay categories, award levels and salary rules before they can even start adding staff members. A lot of these steps require something else to happen first - you can't create award levels within job positions until you have the job positions and the pay categories. The interface should make it clear which stage of data creation the user is at, and which stage they should progress to next.

Depending on the size of your software, it's possible to manage this purely with wizards. But if your software's so large or of a type that you can no longer predict the full procedures users will be doing, you need to indicate to a user where they should start for any procedure - what depends on what. In my opinion, the easiest way to do this is to split your interface conceptually into levels, and name the components accordingly.

For example:

• the base layer, where all the basic stuff that everything else needs is managed, and generally things aren't edited too much once they're created. This is where you set up pay categories, item categories, staff categories. Nothing on this level requires anything else in order to be created. This could be called, for example, Configuration. All windows that manage these kinds of things are configurations. Pay Category (Configuration).
• the intermediate layer, where the stuff that relies on the configuration creations go. Things like award levels, salary rules that require pay categories. All windows that manage these kinds of things are maintenance. Award Level (Maintenance).
• the top layer, where most of the editing happens. This is your creditors, debtors, sales, items, staff members. This is the stuff that users play with regularly, use most often, and it relies on both maintenance and configuration stuff. This is management. 

Now, how you communicate these levels is another matter entirely - menu grouping, visual cues, naming scheme, whatever. But you need to give a clear path to a user of where to start looking to get anything done, even a task that you hadn't predicted.

This is really just scratching the surface, taking things I've noticed clients not doing that resulted in a lot of extra documentation they could have avoided. I haven't even touched on the basic usability rules, or the usability aspects of design. But the basics of technical writing apply perfectly to the act of designing the interface itself, and should be obeyed at all times:

• Consistency - one term per concept, one concept per term, re-use what the user has already learned
• Clarity - make the meaning as obvious as possible
• Conciseness - don't waste their time, keep things as brief as possible whilst still maintaining consistency and clarity
• Consideration - of your user. After all, they're the ones who're going to be using your software. Make it from their perspective, not yours.