Over the past few days, I’ve been thinking about my animation system. I’ll get into the decisions made regarding that tomorrow, but I want to get into the process I used for making those decisions, and what it means to design something to be used. Usability is important for this animation system, along with essentially all the programming I’m doing on my game: Since I’m the one who’s going to be stuck using it, I want to be sure I get it right.
So, what makes a given tool useful?
Well, first and most obviously, it has to Do The Thing. What The Thing ends up being can actually be difficult to determine: Usually it starts off pretty small – for instance, showing a sequence of images with a set timing between them and then either looping or stopping upon reaching the end of the sequence – but often it ends up growing to encompass other related tasks – such as scaling and rotating those images, offsetting them in relation to each other, or synchronizing sound playback information to them. Whatever it is, though, it has to work, consistently, reliably. If it doesn’t work it has to not work for obvious and clearly understood reasons.
Which brings me to the next layer of usefulness: It has to be possible to tell it how to Do The Thing in unambiguous terms. Every control the user touches should have an obvious and intuitive connection to its functionality in the tool, which means using the most obvious and literal labels, means not anticipating your user’s needs and taking extra steps without notifying them, means keeping the external representation of what’s happening as close as possible to whatever’s happening internally. In other words, the KISS principle, “Keep It Simple, Stupid”.
Just as the first layer, has to be in place before you can create the second, that second layer, a clear and unambiguous interface, has to be firmly in place before you can make the tool easier to use. All of those ideas about automating the most common uses of your tool? They go in now. Essentially, now that your tool can Do The Thing, and the user can tell the tool to Do The Thing, you can create meta-tools that the user can tell to tell the tool to Do The Thing(s). If you want to, say, automatically create a templated document, that’s something you can do once and only once the first two layers are in place – though it still has to be clear to the user how the automated system is doing what it’s doing and what that means in relation to the second layer interface. It’s probably most helpful to communicate this as an external meta-tool helping them get going rather than something innately a part of the main tool, so that they understand that there’s nothing being done by the automated process they couldn’t do themselves – the metaphor of a configuration ‘wizard’ is a very clever one in this regard, communicating that it’s just a useful process asking what they want in plain language, rather than being the only way to access the desired functionality.Now all of this may seem obvious, or like an overly complex way of describing something simple, but I’m using this approach in order to describe something that I’ve seen go wrong with a lot of software design: It seems like a lot of developers like to try to skip over that second layer completely, disabling the user’s ability to tell the tool to Do The Thing, in favor of more ‘powerful’, but abstract, third-layer tools. However, that’s building on quicksand, asking a user to try to control something which they have no real idea what it’s doing. Sometimes, even worse, developers prioritize the third layer over even the first – so you end up with a tool that can’t even Do The Thing properly and, what’s more, because there’s no connection between the first and third layer you can’t even tell why The Thing isn’t getting Done.The purpose of tools is to be used, and anyone qualified to use the tools should be able to do so without any special meta-tools. These features, wizards and helpers and auto-fills and second-guessers and context-sensitives and so forth, are to introduce the unexperienced user and to expedite the experienced user, not to conceal the actual functionality of the tool. Don’t make your tool useless by making it presume to know what its use will be.