What is usability?

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?

Recently, 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

• Ingredients – dishes that can be made with certain pre-requisites
• Ease – dishes to be performed as the cook learns more
• Diet – dishes that don’t break dietary laws (whether religious or personal)
• National origin – dishes that fulfil a certain kind of theme

We could arrange help topics in similar ways, by

• Fulfilled pre-requisites: what to do in certain circumstances
• Simplicity: deferring some knowledge for advanced users
• Conditions: separate out tasks that could be hazardous for certain situations
• Themes: tasks which pertain to quite disparate uses of the application

Observation Four: Online recipes invite users to generate other deliverables

Specifically, I’m thinking of the ‘shopping list’ feature on the BBC Food recipe noted above. With ‘shopping list’, the page specially prepares a printable list of ingredients you can take shopping. It lets you disable ingredients you know you already have, and sometimes inserts suggestions for substitutions that aren’t listed in the original recipe. This is pretty exciting: inviting users to spool off different documents for the next stage in the overall process (ie getting the actual foodstuffs). Similarly, an online help article could let users –

• Print paper forms for collecting information to be input
• Prepare notifications for a customer they’re serving (for instance, a password-changing procedure could help me tell my users about their new details)
• Prepare a record of the action for a timekeeping / HR system

I’ll have to think more about this…

Observation Five: Online recipes engage users by comments, recommendations and repostings… not user-generated content

Recipes are probably the most popular sort of technical writing online. But their user engagement is limited to:

• Comments fields. These comments assess how well the recipe worked, and maybe augment it by detailing a few substitutions for particular ingredients.
• Recommendations / rating systems.
• Social media reposting tools. This includes Facebook ‘Like’ buttons, re-tweet links and the like.
• The ability to create personal folders / scrapbooks of favourite content, distributed (at most) to family and friends

I’ve never seen an online recipe that invites me to re-write the content. That’s an interesting counterpart to ‘proper’ technical communications, which is moving towards user-generated content as the norm. Again, there isn’t space to open the ‘wikis vs traditional content models’ argument, but there’s an argument that the consumer prefers being given content and maybe a chance to report problems / personal alternatives, rather than write the recipe themselves.

Thoughts? Any insights on how recipes have helped you think about help content? Disagree with my observations? Make yourself heard in the comments fields!

Confused at an electronics store – two lessons for naming components

When I recently went to buy a HDMI cable, I was confused. I saw what looked like a HDMI lead – same shape, right connectors – but the box was confusing. It called the cable a digital monitor lead. This wasn’t helpful – HDMI cables are used in monitors, and they’re digital to boot. If I hadn’t passed a store assistant, I’d have wasted £20 on a useless cable.

There are two lessons here. One comes from my (assumptions) about the way Maplins labelled their products. I suspected an engineer took a spreadsheet of products, and assigned a name to each. Knowing the names of each product, s/he knew another item was named a HDMI cable, so wouldn’t have seen how ‘monitor lead’ was ambiguous – all other cable types were accounted for with the other products. The key lesson: you already know the names of each function and component of your product, so for you, the name ‘X’ doesn’t have to specifically say ‘not Y’ – you already know Y is something else. Your reader, however, does not have that luxury.

The second: don’t always make a semantic-field-specific term resemble a natural language phrase. It’s counter-intuitive, but it’s sometimes better to call a cable an ‘RX-59’ than a ‘digital monitor lead’. Make it clear that you’re using a piece of jargon, a word that refers to one particular thing in one particular field. As a bonus, your term will now be unique enough to be searchable in Google and the like (if you intend to throw your online help to the spiders).

Reading Everyday Words 1: An Earplug Leaflet

It’s surprising how much we can discuss even the most mundane texts. In these posts, ‘Reading Everyday words’, I take a short, non-fiction document – a leaflet, or a manual – and discuss how it does and doesn’t work.

Struggling with a noisy housemate, I bought a box of earplugs. This box held ten, delicately-positioned wax-and-cotton cylinders, interwoven with a sliver of paper, an instructional leaflet.

Here’s an excerpt:

INSTRUCTIONS FOR USE

Disposable ear plugs in accordance with standard EN 352-2 : 1993

DIRECTIONS

– Soften the plug by rolling between the fingers and shape into a cone.

– Insert a plug firmly into each ear

Average weight: 2.10g

To ensure optimum performance, take care to position the ear plug correctly.

Noise reduction values:

[provides an F-shaped table of Decibel figures and their test source]

Please follow the recommendations given below:

– The ear plugs should be inserted, positioned and worn following the manufacturer’s recommendations

– The ear plugs may be worn constantly in noisy environments.

– Check the ear plugs regularly to ensure they are suitable for use.

– Keep in a cool, dry place below 25°C.

– Keep the ear plugs in their box prior to use.

– These plugs are designed for single use only.

– Keep out of the reach of children.

We can say much about this apparently mundane scrap of paper:

1. What’s going on with formatting in this leaflet? Formatting gives readers visual clues relating to the text’s structure, and each piece’s function. This texts marks up headers and section titles in either bold or capital-bold, but applies similar formatting to a piece of trivia (the average weight of an earplug). This means I can’t trust these emboldened titles as navigational guides.
2. The description (Disposable ear plugs…) is rather strange. As a consumer, don’t I already know I’ve bought ear plugs? And does the EN-353-2 really sit on my bedside table? Presumably, this product is repackaged for an industrial audience – at some point, a company will verify they’ve bought something that ticks their compliance boxes.
3. The syntax of the first Direction (‘Soften the plug by ____. Then insert into the ear’) is odd. It’s more common to describe the ‘end’ or ‘object’ of a task before the action. The idea is that readers can follow your instructions better if they’re given a sense of what each action ultimately leads to. We’ll talk about this next time. That said, users might recognize these rock-solid little cylinders as ordinary earplugs (they’re the same shape), and expect to push them right into the ear. Starting with ‘Soften’ instantly satisfies the confused and concerned user who takes one and finds it too hard to just shove into the head.
4. Various factoids are all listed as ‘recommendations’ (many, strictly speaking, aren’t). The title is verbose (wouldn’t “We recommend:” do?) and there’s no real classification or organization of the data provided. Important advice (‘these plugs are designed for single use’) mixes with material that readers just aren’t going to care about (‘Check the ear plugs regularly). The result’s an amorphous mass of information that readers will just write off as trivia.

Who would have thought a little leaflet could be so involving?

Think I’m being unfair? Make yourself heard in the comments below!