AODC day 2: What Kind of Assistance do Users Really Need?

This week I’m at AODC 2010, the Australasian Online Documentation and Content conference. We’re in Darwin, in the “top end” of Australia. This post is my summary of one of the sessions at the conference. The post is derived from my notes taken during the presentation. All the credit goes to Matthew Ellison, the presenter. Any mistakes or omissions are my own.

An aside, and a reflection of the fun nature of AODC conferences: At the beginning of this postprandial session, we noticed that quite a number of people were absent. “Good time for a prize draw!” exclaimed Tony Self. (You have to be present to claim your prize.) As usual though, even with such improved chances, I did not win the prize.

Matthew Ellison‘s presentation today asked the question, “What Kind of Assistance do Users Really Need?” He introducted his talk saying that it was a good follow-on from mine. (I had given the preprandial presentation, about engaging your readers in the documentation. I’ll blog about it soon.) Matthew now followed through with providing the kind of assistance that users really need. To do that, he says, we really need to understand our users.

AODC day 2: What Kind of Assistance do Users Really Need?

Matthew covered the following topics in this session:

• Background information and recent history that led Matthew to present this topic.
• Current trends in user assistance design — what we’re doing now and what we think our users need.
• Common traps for writers.
• Step-by-step instructions, and whether they are the best solution for users.
• A look at a research study that Matthew is involved in, and the results and recommendations coming from it.

Another aside: At this point Tony phoned Matthew on the mobile phone Matthew was using as a clicker! Hilarity broke out, as it so often does at AODC. Matthew, being an awesome presenter and well used to Tony’s antics, answered the phone with a grin and “Very funny, Tony” then returned to his presentation without breaking his stride.

Aims of UA

In this part of the session, Matthew took a look at the aims of UA (user assistance) or help. The principal aim is to solve problems and answer questions. Help can also make people aware of features and increase their efficiency in performing tasks.

At this point, Matthew asked us to think of the last time we had a question or problem and needed help.

I immediately thought of the problems I’d had with getting my internet connection to work at the hotel. “How do I get the hotel wi-fi broadband connection to work?”

The first 3 or 4 questions we came up with were all “how do I …”. Then a few different questions arose, such as “what is …”.

To illustrate the idea of cycles in design, Matthew showed some pretty cool pictures of bicycles 40 years ago, 20 years ago and today. The bikes of today share some design characteristics with the bikes of 40 years ago. In documentation and information design, ideas tend to cycle too. We looked at the recent trends towards FAQs and task-based help. Matthew thinks FAQs are a good thing. He showed us some examples of FAQs that work, including some from Twitter and YAHOO Groups.

Traps for technical writers

This may be a dangerous area, says Matthew. Some of the things he suggests are contrary to what he was originally taught about technical writing.

We should not:

• Just transcribe information given by developers and SMEs.
• Always give step-by-step instructions. Sometimes it’s enough to give just a simple hint or an answer to a single question.
• Explain the obvious. If it’s easy for us to understand, maybe we don’t need to document it.
• Blindly insist on consistency for its own sake.

Now there was another task for us: We had to write instructions telling people how to delete a file in Windows. Most of us chose to write step-by-step instructions. One group chose just a tip. Matthew suggested that you need a useful tip telling people to click Shift+Delete to remove the file permanently. You may also want to let people know that they can recover files deleted accidentally.

This simple exercise led to much animated debate, as might be expected from a group of technical writers. Is information ever redundant? 🙂

Matthew gave us an example of the way Apple have addressed the problem of explaining only the things that need explaining. See the iTunes help: “iTunes How To”. It contains a useful collection of tips people may need. For example, if you click “Buffer Sizes”, you get a page showing a screenshot of the buffer size dialogue and a short paragraph explaining what buffer sizes are and the implications of choosing a larger or smaller size.

Louise from PayPal

Louise is a PayPal “Virtual Agent”. You can type in questions and Louise will answer you.

Where do the responses come from? They’re composed by authors, based on typical questions asked by users. Tony Self, the organiser of the AODC conference,  has in the past signed up as a “virtual person” and helped to write such answers. As a virtual agent, you see the questions that people typically ask and then you write the answers. You can select the personality of your agent, e.g. humble and kind or quirky and arrogant.

Video tutorials

Some video tutorials are very bad, but some are good. As an example of a good one, Matthew showed us a video introducing Morae Observer. The voice is calm and make things sound simple. Each section is short. This video was created using Camtasia.

Study about the questions that people ask

Matthew has been taking part in a study at Portsmouth University in the UK. The reason for the study was the conviction that we should base our help on the questions that our users ask.

The study looks at when users ask questions and what types of questions they ask. It asks participants to tackle three tasks, each clearly explained. The explanation is about what the participant needs to do, rather than how to do it. There is a task in Word, a task using Google Maps (plan a route and view it in Street View) and a task using Flash.

The participants were not allowed to use the help. If they had questions, they had to ask the moderator sitting next to them. The moderator should answer only the question that was asked. This is known as the Wizard of Oz method.

Matthew and the university team used TechSmith Morae Observer to record everything that the participants did, including audio and video. This allowed them to analyse the participants’ actions and to draw conclusions.

The equipment they needed was simply a laptop with Morae installed, plus a webcam and microphone.

Results of the study

Note: Matthew explained that the results are only just becoming available. He can show us only partial, interim results at this stage. Also, I had to jot down the figures from Matthew’s live presentation, as they were not available at the time the slides were printed for our handbook. I’ve done my best to get them right. Matthew will publish the final results later.

The study classified the questions that users asked into 7 categories:

• Meaning (What does this mean)
• Reason (Why is this happening, or why should I do this)
• Confirmation (Is this what I should be doing)
• Location (Where do I go to do this)
• Task (What do I do now, or how do I do it)
• Response
• Identity

Based on 7 participants out of 20, here is the number of questions that fell into each category:

• Meaning: 8
• Reason: 3
• Confirmation: 74
• Location: 27
• Task: 49
• Response: 3
• Identity: 3

Participants often had trouble framing the question. Imagine how difficult it would be for them to ask the question online instead of to a person.

There was a surprisingly large number of questions in the “confirmation” category. Some participants often asked for confirmation or affirmation.

There were very few questions that fell into the reason, identity and response categories.

Conclusions — interim only:

• Tasks are the most common question type.
• Location is the key to solving the problems.
• Meaning and reason are not very important in this particular study.

Matthew will publish the final results when available.

Matthew strongly encourages us to do a similar exercise. It is hugely enlightening to see how people tackle a task and the questions they ask.

My conclusions

This session was a lot of fun, especially because of the interaction between us and Matthew, and because of the lively discussions that arose. I’m looking forward to seeing the full results of the study and will publish a link as soon as it’s available. Thank you Matthew for a very interesting session.