When asked about ‘usability’ in software, we usually talk about ‘easiness’:
- making interfaces ‘intuitive’,
- using ‘plain’ language
- making controls ‘easy to see’.
In short, we describe ‘usability’ as helping users interpret an interface. But to be ‘use-able’, a tool has to be more than ‘easy to interpret’ – it has to help users achieve their goals. Usability, then, is not just about ‘ease’, but about providing users power, and explaining how that power can enable certain goals.
This may seem unnecessary. With the rise of ‘apps’, single-purpose programs, it’s tempting to think the ‘goal’ any software achieves is already well-expressed. But ‘apps’ aren’t ubiquitious: many users still rely on multi-purpose, extensible tools that they can adapt to a variety of purposes. Think Microsoft Excel. Think Adobe Photoshop. Think GNU EMACS. For their most important tasks: finding information on the web, processing data and producing documents, users still rely on multi-use applications.
For this sort of software, functions are not bundled into ‘wizards’, with strictly-defined goals in sight, but split across multiple ‘tools’. Photoshop doesn’t give me a “textured text” function, but rather a variety of mask, opacity and text tools, that I must combine to achieve the effect I desire. Google doesn’t give me a “find interesting comics” wizard. It gives me a powerful search engine along with the ability to filter by keyword and content type. I have to employ lots of different tools, often in creative and individual ways.
As UX champions, our challenge is to communicate the unexpected ways our products can assist a user. It isn’t an easy one. Users rarely care about even the most specific, task-orientated documentation, so they simply won’t engage with vague, abstract discussions about the ‘sorts of problems’ we solve. They find it tricky to memorize the purpose behind hundreds of obscure buttons, hidden links and cryptically-named functions.
Over the next few weeks, I want to think about the ways we might respond to this challenge. About how we can keep help content relevant and concrete, but still hint at the cool and suprising ways our software can assist people. About explaining interfaces split across separate ‘tools’, rather than single-goal ‘wizards’. In short, about integrating our software with so many of the user’s everyday tasks, it becomes truly indispensible.
What can we learn from recipes?
19 June 2011Recently, I’ve been thinking about food recipes, and how they help us with documentation. The observation that recipes are another sort of technical writing isn’t new – it’s expressed in one of Tom Johnson’s blog posts and a recent TECHWR-L thread, for example. But what I don’t often see are many thoughts on how knowing this helps (Tom’s interesting analysis notwithstanding). That’s why I decided to compile a list of things I’ve noticed when reading food recipes on the web, and how we might want to emulate these in our own material:
Observation One: Recipes emphasise pre-requisites
By ‘pre-requisites’, I mean the ingredients, tools and time needed for a recipe. Look at this cake recipe on the BBC Food website – ingredients and equipment come right at the top, and time taken is prominent in the recipe’s sidebar. Now, it’s true that most people using our manuals don’t need any extra equipment besides their computer and the app they’re already using. But they might need time, privacy, information to fill in, or have other ‘soft’ requirements. Time might need to be uninterrupted, information might need to be pre-compiled… recipes show us how to effectively communicate pre-requisites, explain alternatives (like substitute ingredients) and how to match them.
Observation Two: Recipes use formatting for semantic value
In most cookbooks, page structure visually distinguishes certain classes of information. A recipe’s ‘ease’ rating might always come after its title, for instance. Similarly, we should try to give formatting semantic value – for instance, placing similar tasks in a distinctly formatted sidebar, or only bolding UI elements.
Observation Three: Recipes show us different ways of organizing content.
How might a cookbook arrange recipes? It could do so by
We could arrange help topics in similar ways, by