I’m getting royally fedup with a lot of what I read that is written in the name of usability. Maybe it’s just a personal loathing of the overly academic, or perhaps I lean towards simplicity a little too heavily but SHEESH, some of the better known experts can’t half prattle on…
I’m a member of the usability team at work, largely because I made a lot of noise about it when I joined the company, but also because as a technical communicator who is passionate about the entire experience of using a product, I realise that the interface is THE most important part of communication between user and product.
I’ll let that one sink in, shall I?
Despite our own protestations, we all know that while good documentation is crucial to a product, it’s the user interface that carries the bulk of the load of communicating the capabilities of the application. With that in mind it makes sense to be as involved as possible with the design of the interface for, as I read somewhere many moons ago, we [technical communicators] are “the interface to the interface”. So, if nothing else, getting involved in usability and screen (UI) design for your application should make the job of documenting the software a lot easier.
Now, I’ll happily admit I’m still very much a novice in this area, but I’ve picked up enough knowledge over the years to be dangerous. I’m very aware that my advice tends towards what I would consider common sense, but generally speaking I base my UI design comments, and generally usability thoughts, on the following processes:
- Simple task analysis – picking out the main usage of the application should be pretty straightforward, but sometimes narrowing that down into distinct tasks can be trickier, so I tend to mentally “step back” everytime I approach a new screen and ask myself what it is I would WANT to be able to achieve given where I am in the application. Often you will find that the flow of the UI isn’t quite right.
- Narrow your view – the next step is to pick out each control to make sure the label, text or icon make sense. It’s very easy to get caught up in the overall task and presume too much.
- Quick, write something! – this step can be done mentally, with pen and paper, or just start typing. I often find that it’s only when trying to “tell the story” of how to use an application that all the pieces finally fall into place… and then you realise that one is missing.
As I said, I’m no expert but my approach seems to give reasonable results. Yes with formal analysis, metrics and so on, you can always improve things but sometimes perhaps good enough is good enough?
I sometimes wonder if I’m actually doing more damage than good so I’m quite careful that my opinion isn’t the only one (ok ok, isn’t the LOUDEST one), and I try and keep up with things – Boxes and Arrows & Jakob Neilsen for example – and I’m convinced that there is a big enough overlap between the two professions that one day I’ll be hiring a “usability writer”. No… a “technical usabilitist”…