About this eBook

This is a free eBook from Userfocus.

For the last 9 years, we’ve been publishing articles on user experience at our web site. We publish a new article every month and each one gets read by thousands of people.

But our older articles languish in an archive. Like the once popular girl at school who’s no longer fashionable, they hang around the bike shed touting for readers. They still get read, but they get nothing like the attention of our new articles.

We think this is a bit sad. They may not be new and shiny, but the vast majority of these articles still raise important and timely points about user experience.

In order to give these articles a second life, we’re curating eBooks like this one that focus on particular themes in user experience. Some people may say this is simply old wine in new bottles. Our retort is that it’s still a very nice wine — and what’s more it’s free. Free wine! What’s not to like?

The articles in this collection were published on our web site between June 2003 and October 2011. I hope this is long enough ago for those people who read them the first time to give them a second reading without experiencing too much of a sense of déja vu.

A quick word about the layout of this eBook. We have published this collection simultaneously as an ePub and as a PDF. Because our layout is aimed at making online reading an enjoyable experience, we’ve used a large font. But we’ve also made sure that printing remains a reasonable option. If you prefer to read a printed version, you’ll save paper and still find it very readable if you print this book as two pages per sheet.

Finally, if you enjoy this book and you’d like to hear about new collections the moment they’re published, sign up to receive our monthly newsletter by clicking on the link below.

— David Travis

Get the Userfocus newsletter (it’s free!).

What user researchers can learn from Sherlock Holmes

Philip Hodgson

The parallels between good research and good detective work are striking. In this article we take a close look at what user experience researchers can learn from the investigative methods used by detectives. And, in the spirit of all the best detective stories, we draw an important conclusion: if you want to become a better researcher you should learn to think like a detective.

The similarities between a good researcher and a good detective are quite striking. Maybe this is not a surprise as both disciplines involve investigation, both seek to establish a trail of evidence, and both aim to arrive at a solution. But it goes further. The knowledge required, the skills and experience needed, and the methods and techniques used also have much in common. In fact, it is not stretching things at all to say that detective work actually is research, and research actually is detective work.

So what can we learn about doing UX research from the greatest detective of them all — Sherlock Holmes? Holmes’s method comprised these five steps:

1.Understand the problem to be solved

2.Collect the facts

3.Develop hypotheses to explain the facts

4.Eliminate the least likely hypotheses to arrive at the solution

5.Act on the solution

We’ll alternate between wearing our deerstalker and our UX hat as we take a look at what each of these steps can teach us about doing good UX research.

Step 1. Understand the problem to be solved

“I never guess. It is a shocking habit — destructive to the logical faculty.”

— The Sign of Four (1890).

Which do you find most interesting, questions or answers?

It’s no contest — the question always wins. Even asking that simple question got you thinking — but as soon as you answered the interest is over. Answers are seldom exciting in the way that questions are and, like most researchers, Holmes was intrigued by the challenge of the problem.

So it’s puzzling that in the world of design so much prominence is given to “solutions” or answers. Solutions are the goal but they should never be the starting point. The cost of focusing too early on design solutions, as many development teams do, is that you easily lose sight of the problem you are trying to solve.

Sherlock Holmes resisted leaping to solutions, arguing:

“It is a capital mistake to theorise before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

He always started each case by focusing on the problem. The problem would sometimes arrive in the form of a letter, sometimes as an item in the newspaper, but most often it would announce itself by a knock at the door. The client would then present the mystery to Holmes and he would probe the client for salient information. He would also bring to bear his considerable knowledge on the topic, recalling prior cases and finding out all he could about the likely protagonists. Holmes never relied on guesswork or on assumptions. For Holmes, each new case was unique, and what mattered were reliable and verifiable facts about the case. These gave the investigation an initial focus and direction.

Here are some things we can learn from Holmes’s approach to help focus UX research:

•Move away from solutions.

•Create an explicit research question (actually write it down with a question mark at the end).

•Don’t start doing any research until you have this question.

•Don’t assume the question has never been asked before.

•Find out what your company already knows.

•Do an archival search — start by reading prior research reports.

•Interview team members and stakeholders.

•Use a checklist to collect background information in a systematic manner.

•Leave nothing to guesswork.

Step 2. Collect the facts

“Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.”

— The Adventure of the Copper Beeches (1892).

Although Holmes made skilful use of questioning, he knew that relying on people to accurately report what they may have seen or heard, or what they know and think, is an unreliable approach to investigation. Opinions are not facts, and speculation is not evidence. Instead, his primary method of collecting facts was careful observation:

“You know my method, Watson. It is founded upon the observation of trifles.”

For Holmes, the seemingly unimportant aspects of a crime scene, and the minutiae of the case were vital. From small clues, large inferences can often be drawn.

Observation is essential to innovation, and is an important technique for UX researchers. When used in field research and site visits, it can help us to understand the “messy reality” of how people work and what they really do (rather than what they say they do). It also helps us look at the minutiae of people’s work, and at the details of the workflow, in a way that users often cannot do themselves. This is the key to identifying latent user needs — things people can’t articulate because they don’t know what’s possible.

A good practice during an observation session is not to worry about the relevance of the information you are capturing. Don’t approach data collection with any kind of filter based on prior expectations, assumptions, or pet theories. Don’t judge or weight information at this stage. Don’t try to interpret the things you observe or fit things into a plan or a solution. All of that comes later. Reflecting on a successful case, Holmes reminds Watson:

“We approached the case, you remember, with an absolutely blank mind, which is always an advantage. We had formed no theories. We were simply there to observe.”

Right now you just need to be sure you catch everything. You can always discard items later, but it may be impossible to revisit the site and collect information that you missed.

You may not need to wear a disguise, or crawl on your hands and knees with a magnifying glass, but here are some things we can learn from Holmes to improve our data collection and observation skills:

•Watch people actually doing their work — don’t just get a demonstration.

•Remember that your participants are the experts, you are the “novice”.

•Focus on the most typical tasks; busiest days; typical days; critical incidents.

•Find out what activities precede and follow the task you are observing.

•Look for inconveniences, delays and frustrations.

•Shadow people: follow them wherever they go.

•Point to things and find out what they are for.

•Get copies or photos of artefacts, samples, forms, and documents.

•Make diagrams of the workspace.

•List the tools people are using.

•Note people dynamics and interactions.

•Be alert to things happening simultaneously.

•Record anything unusual about the scene you are looking at.

•Ask yourself if anything is missing.

•Observe behaviour at a low level of detail — watch what people touch and what they look at.

•Pay attention to the sequences and timing of events and actions.

•Remember to pay attention to trifles.

Step 3. Develop hypotheses to explain the facts

“Watson, you can see everything. You fail, however, to reason from what you see. You are too timid in drawing your inferences.”

— The Adventure of the Blue Carbuncle (1892).

Holmes formulated hypotheses by interpreting facts in light of his considerable knowledge and experience:

“As a rule, when I have heard of some slight indications of the course of events I am able to guide myself by the thousands of other similar cases which occur to my memory.”

His knowledge was very deep but it was also very narrow. He had unparalleled understanding of chemistry, footprints, various poisonous flowers (though not gardening), and bloodstains, and he was an accomplished violinist. His narrow focus is evidenced by his monograph on the distinction between 140 different forms of cigar, pipe and cigarette tobacco.

Similarly, we must bring to bear our knowledge of human behaviour, technology advances, market trends, and our company’s business goals, to help us formulate the models and solutions that best fit the facts we collected in our field research.

Our hypotheses now help us to identify the gaps in the way people work — a gap being the opportunity that emerges when we compare the way something is currently being done, and the improved way it might be possible to do it in the future. To help our innovation and design teams spot these gaps, this stage of our work must adequately answer questions about the user, the tasks and the environment of use (Who? Doing what? Under what circumstances?).

Our models, personas, scenarios and stories should include:

•The primary goals that people have.

•The workflow.

•The mental models people build.

•The tools they use.

•The environment they work in.

•The terminology they use to describe what they do.

When the analysis is completed, all of the salient facts should have been explained, and the gaps and opportunities should start to emerge, and we can — finally — begin to propose solutions.

Step 4. Eliminate the least likely hypotheses to arrive at the solution

“It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.”

— The Adventure of the Beryl Coronet (1892).

At this point the detective is faced with a number of possible suspects, and, if we have done our jobs well, we will be faced with a number of possible product ideas and solutions. In this step we begin eliminating the solutions least likely to succeed. The detective asks, “Does the theory fit the facts?” and we ask, “Does the solution fit the data we observed?” We start to drop the weaker solutions — those that don’t quite account for everything we observed; and we apply Occam’s Razor and drop the solutions that only fit the data by dint of being overly complex.

And we carry out tests. Holmes, remember, was a student of science. He carried out experiments.

Eliminating potential concepts is a high stakes game. The evidence put forward in favour of one solution versus another must be compelling. This is nothing new for detective work but strength of evidence seems to be rarely considered in UX research. I don’t mean statistical significance, I mean reliability and validly of data, and the ability for data to predict an outcome. Most of all I mean evidence that resists bias. Not all data are equal in this respect. Here’s a useful hierarchy:

•Strong evidence: Carefully designed and independently conducted usability tests; beta tests employing committed testers; archival research and meta-analyses of such studies.

•Moderate evidence: In-house usability tests; user testing with a company’s own employees; feedback from usability experts using the product.

•Weak evidence: Opinion-based data from focus groups and surveys; feedback from friends and colleagues; opinions of internal management; anecdotal evidence.

As we move into the actual design cycle, testing should continue as an iterative process, with the team prototyping their way towards success. James Dyson famously tested 5,127 prototypes before he achieved success with his Dual Cyclone bag-less vacuum cleaner. You may not need so many iterations, but you also should not expect to get there with a one-shot approach.

So what about the role of intuition? Doesn’t that fit in anywhere? Yes. But, first, let’s clear up a misconception.

Intuition is not guesswork. We only have intuition for things we’re familiar with. That’s what intuition is — familiarity. And familiarity means experience. So, yes there is a role for intuition because we bring our experience to bear on our decision-making. When we read of CEOs like Steve Jobs making intuitive judgment calls, he was, like Sherlock Holmes, drawing on his vast experience of previous similar situations. He knew what worked and what didn’t. But we are not talking here about a ‘shoot from the hip’, ‘seat of the pants’, ‘shot in the dark’ kind of intuition. And, frankly, if you are going to just guess, there’s no sensible reason for starting at this stage. You might as well use guesswork from the beginning.

Step 5. Act on the solution

“Nothing clears up a case so much as stating it to another person.”

— Silver Blaze (1892)

Once Holmes had solved a case, he would explain to the client, and to Watson and the police, how he had solved the crime. Then Inspector Lestrade of Scotland Yard would arrest the culprit and the case was closed. Holmes’s job was done. He archived the experience in his great mental storeroom and moved on to the next adventure.

Here are some recommendations that can help ensure the design team takes action on the results of your investigation:

•Conduct a one-day design workshop to transition the UX solutions to the design team.

•Present the team with specific and actionable design recommendations.

•Agree accountability for implementing your UX recommendations.

•Create and present a clear series of next steps — both tactical and strategic.

•Promote iterative design by arranging to test the new version of the design.

•Educate the team in UX and user-centred design methods.

•Don’t just attend design meetings, chair them.

Thinking like a detective

We set out to discover what it means to think like a detective. Have we got there?

Perhaps, but I still want to capture just the essence of the detective’s method, to make things even more striking — some kind of emblematic statement that we might put on a wall poster. Much as we may admire Sherlock Holmes, there’s no escaping the fact that he did have one characteristic that most detectives would consider a hindrance — he didn’t actually exist. So to get a real life perspective I decided to talk to a real life detective. I got in touch with an old school friend, recently of the West Yorkshire Criminal Investigation Department, and asked him, “If you had just one piece of advice to give to a novice researcher, what would it be?” He didn’t hesitate to reply:

“Never, ever, ever, act on assumptions. Search out the facts and act on those.”

Holmes himself could not have put it better. Facts and evidence, not guesswork and assumptions. That’s how to think like a detective.

The 4 questions to ask in a cognitive walkthrough

David Travis

Although the cognitive walkthrough gets less coverage than Nielsen’s heuristic evaluation, it’s just as effective at uncovering interaction problems. It’s also an ideal way to identify problems that users will have when they first use an interface, without training.

About the cognitive walkthrough

The cognitive walkthrough is a formalised way of imagining people’s thoughts and actions when they use an interface for the first time. Walkthroughs identify problems that new users will have when they first use an interface. You select one of the tasks that the design is intended to support and then you step through the task, action by action, seeing if you can identify any problems with the interface.

Although the technique was developed over 20 years ago (by Cathleen Wharton, John Rieman, Clayton Lewis and Peter Polson) it is much less widely used than heuristic-based expert reviews. This is a shame because the technique simulates the way real people use an interface: by exploration rather than by reading the manual.

Creating the happy path

Before you can start a cognitive walkthrough, you need a complete, written list of the actions needed to complete the task with the interface — the ‘happy path’. For example, here’s the happy path for creating a customised voicemail message on an iPhone:

1.Tap Voicemail.

2.Tap Greeting.

3.Tap Custom.

4.Tap Record and speak your greeting.

5.When you finish, tap Stop.

6.To listen to your greeting, tap Play.

7.To re-record, repeat steps 4 and 5.

8.Tap Save.

Sometimes, creating the happy path is all you need to do to realise there is a problem with the interface. For example, configuring email on a Nokia 6233 requires 78 separate steps. If your happy path has this many actions, there’s no need to continue with the review: you’ve found a serious problem already.

Once you have the happy path, you’re ready to start the walkthrough.

The 4 questions to ask in a cognitive walkthrough

The cognitive walkthrough is structured around 4 questions that you ask of every step in the task. You ask these questions before, during and after each step in the happy path. If you find a problem, you make a note and then move on to the next step of the task.

Q1: Will the customer realistically be trying to do this action?

This question finds problems with interfaces that make unrealistic assumptions about the level of knowledge or experience that users have. It also finds problems with systems where users expect to do a different action because of their experience with other interfaces or with life generally.

For example, my Sony Vaio laptop has two settings, ‘Stamina’ and ‘Speed’ (see Figure 1). The designers assume that I will switch to the ‘Stamina’ setting to save battery power and use the ‘Speed’ setting for graphics-intensive applications, such as games. Is this assumption reasonable?

Figure 1: Stamina or speed?

Q2: Is the control for the action visible?

This question identifies problems with hidden controls, like the gestural user interfaces required by an iPad where it’s not always obvious what you can do. It also highlights issues with context-sensitive menus or controls buried too deep within a navigation system. If the control for the action is non-standard or unintuitive then it will identify those as well.

The world of TV remote controls provides a familiar example. Remote controls often contain a flap to hide features that are rarely used (see Figure 2). The problem occurs when you need access to those functions but, because you rarely use them, you don’t realise you need to lift a flap to reveal them.

Figure 2: Hidden controls on a TV remote

Q3: Is there a strong link between the control and the action?

This question highlights problems with ambiguous or jargon terms, or with other controls that look like a better choice. It also finds problems with actions that are physically difficult to execute, such as when you need to press three keys on the keyboard at the same time (and stand on one leg).

Figure 3 shows an example from a car park machine at Stuttgart airport that has a weak link between the control and the action. I used this machine over a period of 18 months while on assignment in Germany. The first time I arrived at the airport and wanted to leave the car park, I was confronted by the barrier and the control shown in the picture. The barrier has a slot at the top and two buttons, a green one on top and a red one below. I didn’t have anything to put in the slot, so I guessed I had to press one of the buttons.

Figure 3: Green for Go or Red for Exit?

Question: Which button would you press to lift the barrier: the green one or the red one?

Convention dictates that you would press the green, upper button. In fact, this appeared to do nothing. Assuming that the barrier was broken, I pressed the red button, thinking that this would put me in intercom contact with the car park attendant who could then open it for me. To my surprise, the red button lifted the barrier.

Clearly, I was not the only person to experience this difficulty. When I returned some weeks later, the design had been upgraded (see Figure 4). As well as a large sign showing the correct button to push, some ‘help text’ had been added to the system (in both German and English) saying ‘Please press the red button’. To emphasise this, the designers had even printed the word ‘red’ in red ink. Which button would you press now?

Figure 4: Not the first time that documentation has been used to rescue bad design.

As if to prove that customers do not read documentation, when I returned some weeks later, the design had been changed again (see Figure 5).

Figure 5: When you’re in a hole, stop digging.

Presumably, customers had not been using the help system. The hint text, now flapping in the breeze, had been almost discarded and the design had been changed to include a series of (red) arrows, indicating which button to press.

This month’s rhetorical question: how many participants would have been needed in a usability test to spot this blooper?

Q4: Is feedback appropriate?

This question helps you find problems when feedback is missing, or easy to miss, or too brief, poorly worded, inappropriate or ambiguous. For example, does the system prompt users to take the next step in the task?

Figure 4 shows an example from a control panel for an electronic toilet door on a British train. What button would you press if you want some privacy?

Figure 4: A toilet door control panel that only a trainspotter could love.

With this system, you first need to press the ‘Door open / close’ button and then you need to press the ‘Door lock’ button. If, like many people, you forget to press the ‘Door lock’ button, you may find your privacy interrupted as someone on the other side of the door opens it to reveal you seated on the toilet like a prize in a game show. This problem occurs because the door fails to provide adequate feedback on whether it is locked or unlocked.

Try it yourself

The best way to get going with a cognitive walkthrough is to try it yourself. Start off by writing down the happy path for sending a message on your mobile phone. Then walkthrough each step in the process and ask the 4 questions of the interface.

Usability Test Data

Philip Hodgson

People often throw around the terms ‘objective’ and ‘subjective’ when talking about the results of a research study. These terms are frequently equated with the statistical terms ‘quantitative’ and ‘qualitative’. The analogy is false, and this misunderstanding can have consequences for the interpretations and conclusions of usability tests.

Some definitions

The terms ‘quantitative’ and ‘qualitative’ refer to kinds of data. The definitions of these terms are uncontroversial and can be found in any standard statistics text book. In their book, Statistics, Witte & Witte (2009), present the distinction concisely, defining quantitative data as follows:

“When, among a set of observations, any single observation is a number that represents an amount or a count, then the data are quantitative.”

So body weights reported by a group of students, or a collection of IQ scores, or a list of task durations in seconds, or Likert scale category responses, or magnitude rating scale responses, are quantitative data. Counts are also quantitative, so data showing size of family, or how many computers you own, are quantitative.

Witte & Witte define qualitative data as follows:

“When, among a set of observations, any single observation is a word, or a sentence, or a description, or a code that represents a category then the data are qualitative.”

So ‘yes-no’ responses, people’s ethnic backgrounds, or religious affiliations, or attitudes towards the death penalty, the presidential candidate you wish to vote for, or descriptions of events, speculations and stories, are all examples of qualitative data. Certainly, numerical codes can be assigned to qualitative responses (for example, ‘yes’ could be assigned 1 and ‘no’ could be assigned 2) but these numbers do not transform qualitative data into quantitative data.

The market researchers’ fallacy

The Market Research Society also uses these terms to refer to the kinds of research methods that are used to collect quantitative and qualitative data. This can sometimes create confusion because few methods used in behavioral research collect either type of data exclusively. In daily practice another tendency has emerged that creates even more confusion. Many practitioners (again, we notice this mostly in market research) informally use the term quantitative or “quant” to refer to a study that employs a large test sample, and qualitative or “qual” to refer to a study that employs a small test sample. The threshold between the two is unclear. This latter use of the terms is simply incorrect. Sample size does not determine whether data are quantitative or qualitative.

Read the definitions again, and note that the fail-safe way to distinguish between quantitative and qualitative data is to focus on the status of a single observation, or datum, rather than on an entire set of observations or data. When viewed as a whole, qualitative data can sometimes bear a striking resemblance to quantitative data. 57 ‘yes’ responses vs. 43 ‘no’ responses look like quantitative data, but they are not. Although these numbers are important (and essential for some statistical procedures) they do not transform the underlying qualitative data into quantitative data.

The case of rating scales

Rating scales present an interesting case because they are used to capture subjective opinions with numbers. The resulting data are often considered to be qualitative. However, rating scales are not designed to capture opinions, per se, but rather are designed to capture estimations of magnitude. Rating scales do not produce qualitative data, irrespective of what the end-point labels may be. Data from Likert scales and continuous (e.g. 1-10) rating scales are quantitative. These scales assume equal intervals between points. Furthermore they represent an ordering, from less of something to more of something — where that ‘something’ may be ease-of-use or satisfaction or some other construct that can be represented in an incremental manner. In short, rating scale data approximate interval data and so lend themselves to analysis by a range of statistical techniques including ANOVAs. Qualitative data do not have these properties, and cannot be ordered along a continuum, or compared in terms of magnitude (although qualitative data can still be analyzed statistically).

While quantitative studies are concerned with precise measurements, qualitative studies are concerned with verbal descriptions of people’s experiences, perceptions, opinions, feelings and knowledge. Whereas a quantitative method typically requires some precise measuring instrument, the qualitative method itself is the measuring instrument. Qualitative data are less about attempting to prove something than about attempting to understand something. Quantitative and qualitative data can be, and often are, collected in the same study. If we want to know how much people weigh, we use a weighing machine and record numbers. But if we want to know how they feel about they weight we need to ask questions, hear stories, and understand experiences. (See Patton, 2002, for a comprehensive discussion of qualitative data collection and analysis methods).

Subjective and objective data

Another frequent source of confusion — especially when used in the context of qualitative and quantitative data — is that of subjective and objective data. The ‘rule’ is that subjective data result from an individual’s personal opinion or judgement and not from some external measure. Objective data on the other hand are ‘external to the mind’ and concern facts and the precise measurement of things or concepts that actually exist.

For example, when I respond to the survey question “Do you own a computer?” my answer “Yes” represents qualitative data, but my response is not subjective. That I own a computer is an indisputable fact that is not open to subjectivity. So my response is both qualitative and objective. If I am asked to give my general opinion about the price of computers, then my response “I think they are too expensive” will be both qualitative and subjective. If I am asked to report the chip speed of my computer and I reply “2 GHz” then my response is both quantitative and objective. If I respond to the question “How easy is your computer to use on a scale of 1 to 10?”, my answer “seven” is quantitative, but it has resulted from my subjective opinion, so it is both quantitative and subjective.

Examples of qualitative and quantitative data

Quantitative

Qualitative

Objective

“The chip speed of my computer is 2 GHz”

“Yes, I own a computer”

Subjective

“On a scale of 1-10, my computer scores 7 in terms of its ease of use”

“I think computers are too expensive”

Confusion often arises when people assume that ‘qualitative’ is synonymous with ‘subjective’, and that ‘quantitative’ is synonymous with ‘objective’. As you can see in the above examples, this is not the case. Both quantitative and qualitative data can be objective or subjective.

Beware of smoke and mirrors

We could put all of this down to troublesome semantics and dismiss the matter as being purely academic, but clarity of thought and understanding in this area is critically important. Misunderstanding and misusing these terms can signal a poor grasp of one’s data, and may reduce the impact of any study results on product design decisions. It can result in the wrong analysis (or in no analysis at all) being conducted on data. For example, it is not uncommon for usability practitioners to collect subjective rating scale data, and then fail to apply the appropriate inferential statistical analyses. This is often because they have mistakenly assumed they are handling qualitative data and (again erroneously) assume that these data cannot be subjected to statistical analyses. It is also not uncommon for usability practitioners to collect nominal frequency counts and then to make claims and recommendations based solely on unanalyzed mean values.

Handling data in this casual way can reduce the value of a usability study, leaving an expensively staged study with a ‘smoke and mirrors’ outcome. Such outcomes are a waste of company money, they cause product managers to make the wrong decisions, and they can lead to costly design and manufacturing blunders. They also reduce people’s confidence in what usability studies can deliver.

The discipline of usability is concerned with prediction. Usability practitioners make predictions about how people will use a website or product; about interaction elements that may be problematic; about the consequences of not fixing usability problems; and, on the basis of carefully designed competitive usability tests, about which design a sponsor might wisely pursue. Predictions must go beyond the behaviour and opinions of a test sample. We care about the test sample only insofar as they are representative of our target market of interest. But we can have a known degree of confidence in the predictive value of our data only if we have applied appropriate analyses. To fail to apply inferential statistics can be a serious oversight. Such an approach could be justified only if we cared not to generalize our results beyond the specific sample tested. This would be a very rare event, and would apply only if our test participants were so specialized that they turned out to be the entire population of target users.

Power and understanding

Usability experts collect both qualitative data (usually during early contextual research and during formative usability testing when identifying usability problems) and quantitative data (usually during summative testing when measuring the usability of a system). In both cases they typically focus on collecting data that are objective and that result from observable user behavior. Is it better to collect one kind of data over another? Usually both are required to get a full understanding of a user’s experience with a product or system. But we like what the astronomer and author Carl Sagan had to say on the matter. It borders on the poetic, and it made us think. So we’ll leave the last word to him:

“If you know a thing only qualitatively, you know it no more than vaguely. If you know it quantitatively — grasping some numerical measure that distinguishes it from an infinite number of other possibilities — you are beginning to know it deeply. You comprehend some of its beauty and you gain access to its power and the understanding it provides.”

References

Sagan, C. (1997) Billions and Billions. Ballatine Books.

Patton, M. Q. (2002) Qualitative Research and Evaluation Methods (3rd Edition). Sage Publications.

Witte, R. S. & Witte, J. S. (2009) Statistics. John Wiley & Sons.

Red route usability: The key user journeys with your web site

David Travis

Important roads in London are known as ‘red routes’ and Transport for London do everything in their power to make sure passenger journeys on these routes are completed as smoothly and quickly as possible. Define the red routes for your web site and you’ll be able to identify and eliminate any usability obstacles on the key user journeys.

Because London has more cars than it has parking spaces, driving in London is like a huge game of musical chairs. The lucky few have parking spaces by their home or office but the majority of us are doomed to drive around and around in circles hopelessly searching for empty stretches of kerb. A while back, this got even more difficult: on certain main roads yellow lines indicating a parking ban were replaced by red lines. Unlike yellow lines, single and double red lines ban all stopping, parking and loading.

Red routes improve speed and effectiveness

Roads with red lines on them are known as red routes: these are the key road arteries in London. The idea is that these routes need to be kept clear in order for traffic to move smoothly through the capital (we’re told that just one driver can clog the roads). Transport for London is uncompromising in its enforcement of parking restrictions on red routes. Make the mistake of stopping your car on a red route to buy your daily paper and traffic wardens converge on you from nowhere.

The motorist’s loss proved to be the bus passenger’s gain. Research showed that bus journeys were 10% quicker and 27% more reliable. Journey time reliability improved by 20% and red routes led to a 6% reduction in accidents.

Improvements in speed and accuracy need not only apply to bus routes. We can get analogous gains by applying the red route philosophy to web sites. By adopting the role of enthusiastic traffic wardens and treating usability obstacles on red routes like badly behaved motorists, we can ruthlessly eradicate any usability obstacles on the key user journeys. To begin, we need to map out the red routes for our site.

Red routes describe frequent and critical activities

In defining red routes, it’s important to consider both the frequency and critical nature of the activity. Activities that customers carry out frequently are crucial to the success of the web site since they will determine customers’ perception of it. One example of a frequent activity might be search. In contrast, critical activities may be infrequent but users will hate your web site if these tasks are not well supported. An example of an infrequent but critical task might be editing my personal details stored on a web site. Finally, activities that are both frequent and critical are the web site’s bread and butter. Get these wrong and you may as well not be in business.

Red routes should reflect key business objectives

You probably already have an idea of some of your red routes from a business perspective. For example, if you run an e-commerce site, buying a product is a red route. If it’s a local authority site, paying council tax is a red route. If it’s a charity site, then showing people how they can support or donate to the charity is a red route. These red routes are clearly important from the perspective of the organisation: you need to make sure these routes are trouble-free to make money.

Red routes should reflect key customer objectives

But this list of red routes is only part of the story. Visitors to your site will have their own goals that your site needs to support. Some of these goals — like buying a product — will match your organisation’s goals. But there will be others that may not seem that important to your organisation but that are critical if customers are going to do business with you.

For example, if you run an e-commerce site, one of your customers’ goals will be to check that they are getting value for money. Making a decision to buy is difficult. There is always a nagging feeling that you can get the same product cheaper elsewhere, and that a different model might be a better fit for your needs. Consider the act of buying a new MP3 player. There’s always the risk that the device you have bought will have poorer battery life than another model, or the audio quality might not be as good, or the screen might be harder to read. As a seller of MP3 players, this isn’t a big deal for you (other than the risk of returns for truly awful products). But for a purchaser this is important information. So we also need to define ‘choosing’ a product as a red route, and this might include links to independent reviews, testimonials from other customers and even showing comparative prices from competitor sites.

What does a red route look like?

If you look at a map of London with the red routes superimposed upon it, there doesn’t appear to be an obvious visual logic to the design. This is because London’s archaic road system was never designed to handle the traffic that now runs through it, and just like water running downhill certain routes have just evolved based on usage. With a web site, we can be more proscriptive. To be useful, red routes should have the following five characteristics.

•Red routes must be complete activities, not simple tasks: they will probably require several web pages to complete.

•Red routes must imply an obvious measure of accomplishment: anyone should be able to describe what success looks like on a red route (in contrast to platitudes like “we want our site to be easy to use”).

•Red routes must be “portable” to competitor web sites: for example, we could attempt to carry out the ‘council tax’ activity on any local authority site.

•Red routes must focus on goals not procedural steps: they do not dictate any single implementation.

•Red routes must be accurate and realistic: they should focus on the most important goals for the customer and the organisation.

Base your red routes on real customer data

One way of defining red routes (admittedly, not a good one) is to simply make them up. We can all tell a good story as to why someone, somewhere, will want to do a certain activity at our web site. For example, when working with a recent client I was told that a typical customer red route was to “read the latest news about the company”. We could justify this red route by making up a story about a journalist on a particular slow news day that is casually surfing the web waiting for something interesting to turn up. And thanks to the benefit of groupthink we might even believe it for a while. But it’s unlikely this will ever be a red route from a real customer’s perspective.

A better way is to carry out some research with customers. This doesn’t mean hiring a market research company to run a focus group and it need not mean carrying a clipboard and stopping people in a shopping mall. This is because you probably already have a lot of customer data that you can mine for this activity. For example:

•Have a look at a month’s worth of search queries. (If your site doesn’t have its own search engine you can still look at the search queries that come to your site via search engines like Google). Group together common queries and see if you can determine what people are trying to achieve at your site.

•If you have a bricks and mortar office, speak to the people who work there. What questions do customers ask?

•If you have a call centre, spend a day listening into customer calls. Survey and classify the calls that come in.

•Look at what your competitors are doing. (But be careful, they might just have made it up too.)

The next step is to take these red routes and use them to evaluate your current design.

Measuring satisfaction: Beyond the usability questionnaire

David Travis

Most usability tests culminate with a short questionnaire that asks the participant to rate, usually on a 5- or 7-point scale, various characteristics of the system. Experience shows that participants are reluctant to be critical of a system, no matter how difficult they found the tasks. This article describes a guided interview technique that overcomes this problem based on a word list of over 100 adjectives.

Measuring user satisfaction

A common mistake made by novice usability test moderators is to think that the aim of a usability test is to elicit a participant’s reactions to a user interface. Experienced test moderators realise that a participant’s reaction is just one measure of usability. To get the complete usability picture, we also need to consider effectiveness (can people complete their tasks?) and efficiency (how long do people take?).

These dimensions of usability come from the International Standard, ISO 9241-11, which defines usability as:

“Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”

The ISO definition of usability makes it clear that user satisfaction is just one important dimension of usability. People may be well disposed to a system but fail to complete business-critical tasks with it, or do so in a roundabout way. The three measures of usability — effectiveness, efficiency and satisfaction — are independent and you need to measure all three to get a rounded measure of usability.

Importance of collecting satisfaction measures

A second mistake made by people new to the field of usability is to measure satisfaction by using a questionnaire only (either at the end of the session or on completion of each task). There are many issues to consider when designing a good questionnaire, and few usability questionnaires are up to scratch.

For example, we’ve known for over 60 years that you need to avoid the “acquiescence bias”: the fact that people are more likely to agree with a statement than disagree with it (Cronbach, 1946). This means that you need to balance positively-phrased statements (such as “I found this interface easy to use”) with negative ones (such as “I found this interface difficult to navigate”). So it’s surprising that two commonly used questionnaires in the field of usability — the Usefulness, Satisfaction, and Ease of use (USE) questionnaire and the Computer System Usability Questionnaire (CSUQ) — suffer from just this problem: every question in both of these questionnaires is positively phrased, which means the results from them are biased towards positive responding.

Questionnaires that avoid this source of bias often suffer from other sources of bias. For example, few undergo tests of reliability. This means that the same questionnaire may yield different results at different times (this can be checked by measuring the questionnaire’s test-retest reliability). Even fewer usability questionnaires are assessed for validity. This means that there is no guarantee that the questionnaire actually measures user satisfaction.

Problems with measuring satisfaction

In our studies, we notice that participants tend to rate an interface highly on a post-test questionnaire even when they fail to complete many of the tasks. I’ve spoken to enough of my colleagues at conferences and meetings to know that this problem is commonplace. Is this because we are about to give the participant £75 for taking part in a test session or is there something else at work? For example, one group of researchers makes this point:

“In studies such as this one, we have found subjects reluctant to be critical of designs when they are asked to assign a rating to the design. In our usability tests, we see the same phenomenon even when we encourage subjects to be critical. We speculate that the test subjects feel that giving a low rating to a product gives the impression that they are “negative” people, that the ratings reflect negatively on their ability to use computer-based technology, that some of the blame for a product’s poor performance falls on them, or that they don’t want to hurt the feelings of the person conducting the test.” - Wiklund et al (1992).

Once you ask participants to assign a number to their experience, their experience suddenly becomes better than it actually was. We need some way of controlling this tendency.

The Microsoft Desirability Toolkit

There are alternatives to measuring satisfaction with a questionnaire. A few years back, researchers at Microsoft developed the “Desirability Toolkit”. This comprised a series of 118 “product reaction cards”, containing words like “Consistent”, “Sophisticated” and “Useful”. On completion of a usability test, participants were asked to sort through the cards and select the five cards that most closely matched their personal reactions to the system they had just used.

The five selected cards then became the basis of a post-test guided interview. For example, the interviewer would pick one of the cards chosen by the participant and say, “I see that one of the cards you selected was ‘Consistent’. Tell me what was behind your choice of that word”.

I’ve used this approach in several usability studies and what has struck me is the fact that it helps elicit negative comments from participants. This methodology seems to give participants “permission” to be critical of the system. Not only do participants choose negative as well as positive adjectives, they may also place a “negative” spin on an otherwise “positive” adjective. For example, “Sophisticated” at first sounds positive but I have had participants choose this item to mean, “It’s a bit too sophisticated for my tastes”.

An alternative implementation

Asking people to sort through a set of product reaction cards adds a level of complexity to the implementation that’s not really necessary. In our studies, we now use a simple paper checklist of adjectives. We first ask people to read through the words and select as many as they like that they think apply to the interface. We then ask the participant to circle just 5 adjectives from those chosen, and these adjectives become the basis of the post-test guided interview.

Customising the word list

The precise adjectives are not set in stone — remember this is a technique to help participants categorise their reactions to an interface that you then explore in more depth in the post-test guided interview. This means that, for a particular study, you should replace some of the words with others that may be more relevant. For example, if we were usability testing a web site for a client whose brand values are “Fun, Value for Money, Quality and Innovation”, we would replace four of the existing adjectives with those. (This makes for an interesting discussion with the client when participants don’t select those terms. It gets even more interesting if participants choose antonyms to the brand values, such as “Boring”, “Expensive”, “Inferior” and “Traditional”). This is similar to Brand Tags: whatever people say a brand is, is what it is.

How to analyse the data

The real benefit of this approach is in the way it uncovers participant reactions and attitudes. You get a depth of understanding and an authenticity in participants’ reactions that just can’t be achieved with traditional questionnaires and surveys. So this approach is ideal as a qualitative approach to guide an interview.

But you can also derive metrics from these data. Here’s how.

Word cloud

The simplest measure is to count up the number of times a word was chosen by participants. In our studies, we find that we get a fair amount of consistency in the words chosen. For example, Figure 1 shows a word cloud from the results we obtained from a recent 12-participant usability test.

Figure 1: Example word cloud. The larger the font size and the greater the contrast, the more frequently participants selected the adjective.

Participants could choose from a corpus of 103 words but some words were selected more often (such as “Easy to use”, which was selected by half the participants). The font size of each item in the word cloud is directly proportional to the number of times the adjective was selected (the Figure also shows less frequently selected adjectives in lower contrast text). If you don’t feel comfortable hacking Word to create a word cloud, use the excellent Wordle, a web site that will make these word clouds for you and provides lots of control over the font used and the placement of text.

Verbal protocol analysis

A more robust statistic can be derived from carrying out a verbal protocol analysis of the guided interview where the participant discusses the reasons for his or her choice of words. This simply means listening to the post-test interview and coding each participant’s comments. The simplest way to do this is to divide a piece of paper into two columns and write “Positive” at the top of one column and “Negative” at the top of the other column. Listen to the interview (either live or recorded) and every time you hear the participant make a positive comment about the interface, place a mark in the “Positive” column. Every time you hear the participant make a negative comment about the interface, place a mark in the “Negative” column. At the end of the interview, you add up the positive and negative totals and compute the percentage of positive comments.

So for example, if there are 5 positive comments and 5 negative comments the percentage of positive comments is 50% (5 divided by 10). Similarly, if there are 9 positive comments and 3 negative comments the percentage of positive comments is 75% (9 divided by 12). This could be used as a satisfaction metric to compare interfaces.

Now you try

If you would like to try out this method in one of your own studies, we’ve developed an Excel spreadsheet that you can use to generate and randomise the word list. (Randomisation of the list prevents order effects). The spreadsheet also contains a worksheet that lets you analyse the data and generate a word cloud. We do this by using an advanced feature in Wordle. (It bothers us that Wordle applies colours randomly. We want the colour to convey information like the text size does, as in Figure 1 above. So we used some Excel tomfoolery to generate colour information for Wordle. This way, the most popular adjectives are also the darkest and the less popular comments fade into the distance). The Excel file contains macros; you can disable the macros if you want and still print the word list, but you’ll lose the randomisation and analysis functionality. I hope you find it useful to start collecting more in-depth measures of user satisfaction.

Download the spreadsheet from the Userfocus web site.

References

Benedek, J. and Miner, T. “Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting.” http://www.microsoft.com/usability/UEPostings/DesirabilityToolkit.doc Redmond, WA: Microsoft Corporation, 2002.

Cronbach, L.J. (1946) Response sets and test validity. Educational and Psychological Measurements 6, pp. 475-494.

Wiklund, M., Thurrott, C. and Dumas, J. (1992). “Does the Fidelity of Software Prototypes Affect the Perception of Usability?” Proc. Human Factors Society 36th Annual Meeting, 399-403.

Site visit interviews: from good to great

Anna-Gret Higgins

Site visits are the best method we have of gaining real insight into the way customers work — to understand what customers do, rather than what they say they do. But to get the most from a site visit you need to polish your interviewing skills. Great interviewers show 5 characteristics from which we can learn.

User interviews: beyond the basics

Field visits are unique in the way that they allow us to blend context, observation and interview: we’re able to observe a behaviour, probe for the motivations behind it and then interpret our analysis with the customer in the place where the behaviour happens. But how do you go beyond the basics of a conventional interview and really understand the user’s behaviour? Here are 5 characteristics that we’ve seen in great interviewers that led to deeper insights on our projects.

Good interviewers build rapport. Great interviewers realise that rapport involves more than meeting and greeting

Rapport is the ability to be on the same wavelength as your interviewee — to make a mental and emotional connection. But rapport isn’t just something you do when you first chat to someone over tea and biscuits. It’s a continual process of building a relationship based on trust and understanding. To develop real rapport you need to see the world the same way as your interviewee.

One effective way to do this is to match your interviewee on both a verbal and a non-verbal level. On a non-verbal level, look at the interviewee’s body language — their posture, movement, sitting position and gestures — and echo these behaviours. Time your mirroring behaviour so it’s not seen as too contrived. Note that you don’t have to do exactly the same as your interviewee: sometimes “cross matching” (making the same movement with another part of your body) is more effective.

On a verbal level, pay attention to the volume, tone and pitch of the interviewee’s voice as well as the choice of content and words themselves. For example, does your interviewee tend to use the phrase “I think” in preference to “I feel”? Depending on your own preference you may have to adapt the way you communicate to mirror these terms. Using the same preference as your interviewees will make them think — or feel — they are more understood and valued. This in turn means you’ll get richer information from them.

Good interviewers listen. Great interviewers realise that listening involves more than using our ears

“Hearing” and “listening” are two different activities. Really listening to someone is an active process: it’s about hearing what the person says both verbally and non—verbally. It’s about listening with your eyes as well as your ears, observing and responding to the interviewee’s body language. There are four key steps to active listening:

Begin by making a decision to become genuinely interested in what the interviewee thinks, feels and wants.

Then show interviewees that you are really attending to what they are saying through your body language: with an open posture and eye contact.

Next, listen for the meaning behind the words. What is the speaker trying to tell you? What do they want you to hear?

Finally, demonstrate you’ve listened to your interviewee by showing you are finding what they are saying interesting and encouraging the speaker to tell you more.

Good interviewers are sympathetic. Great interviewers are empathic

Good interviewers may be sympathetic to an interviewee’s plight but great interviewers use empathic responses to make people feel understood and valued. An “empathic reflection” is giving the speaker a verbal summary of what you consider he or she thinks, feels, and believes, without passing judgment. Empathic reflections sound like this:

“You feel...because...”

“I’m picking up that you...”

“So, from where you sit...”

“It seems as if...”

“I get the feeling...”

“What I hear you saying is...”

An empathic reflection allows you to validate your understanding and build a relationship with interviewees by demonstrating that you understand them. It also gives interviewees the opportunity to correct you if you have misunderstood them — one of the cornerstones of contextual inquiry. You may find this helps interviewees clarify their ideas, emotions, and needs. Using empathic responses also helps keep the conversation in the interviewee’s realm by preventing you from asking too many questions.

Good interviewers are aware they might be biased. Great interviewers use their self-awareness to uncover blocks to listening

Great interviewers are aware of two obstacles to active listening and use their self awareness to overcome these obstacles.

The first obstacle is your perceptual bias: the assumptions and beliefs that distort or block what you hear. For example, if you think an interface is awful, then you’ll find yourself seeking affirmation and ignoring evidence to the contrary. Some common forms of perceptual bias include:

“Evaluative listening” or judging what’s being said — you may tell people there’s no right or wrong answer but you truly need to believe there’s no right or wrong answer.

Seeking confirmation for your hypotheses or ignoring information that contradicts your hypotheses.

Being anxious or defensive about what the speaker is telling you.

A second obstacle to active listening is the fact that we all find some people easier to relate to than others. Building self-awareness of why you feel at ease with some people rather than others will improve your ability to be non-judgemental. This helps you stay empathetic and non-judgemental and ensures that you are less likely to display frustration, disagreement or criticism. To build this self-awareness, observe what’s going on in your conversations: ask yourself, “What am I thinking and feeling right now in reaction to this person?”

Good interviewers note inconsistencies between what someone says and what they observe. Great interviewers investigate these inconsistencies

You can learn a lot by offering a gentle challenge when you see a discrepancy between what interviewees say and what they do. For example, quite often participants in field studies will say they follow a specified process when carrying out a task even though you have observed them doing it a different way. Good interviewers simply make a note of the inconsistency but great interviewers will use a statement like, “You say you follow the process yet I noticed you seem to do things differently at two points.” This helps you gain more information on the interviewee’s experience.

Make sure you deliver your challenge in a genuine way, and not as a power game or a put down. The interviewee may not be lying to you; he or she may just have a “blind spot”. A good challenge is specific and non-accusatory. The purpose of a challenge is to stimulate discussion and help both of you understand more about the situation. Note the use of the word “yet” in the example above: this ensures you deliver the challenge in a tentative way: as a hunch rather than as a statement of fact.

If you think a challenge might be confrontational, you can soften it by sandwiching it between positive feedback. For example, you could precede the statement above with the statement, “I’m finding our meeting really interesting,” and then after the challenge say, “If we can discuss that, you’ll help me even more.”

Getting better value from your site visits

Most of us know the basics of good interviewing but basic interviews aren’t enough to get the most value out of the short time we spend visiting end users at their home or workplace. Next time, try some of the techniques in this article and see if you get richer data.

The 5 habits of highly effective field researchers

David Travis

You may not get many chances to visit and observe your customers at their place of work, so you want to make the most of the opportunity. But what’s the best way to run a site visit? Highly effective field researchers show 5 specific behaviours. They create a focus question, audio record the sessions, take photographs of the environment, take notes and write up a short summary of the observation immediately.

Visiting your customers at their place of work — sometimes called ethnography, shadowing, contextual inquiry or simply a site visit — is the best way to understand the way people do their job. This understanding is central to doing great design as it helps you really understand the needs, motivations and goals of your users.

But if you’re not careful, it’s easy to waste the opportunity and end up overwhelmed by what you’ve observed.

I’ve been fortunate to work with a number of user experience researchers, and I’ve noticed they all tend to be detail-oriented, highly motivated and conscientious. But when I think specifically about the field researchers I’ve worked with who have stood out from the crowd, there are a handful of particular behaviours I see in each of them:

•They create a focus question.

•They audio record the sessions.

•They take photographs of the environment.

•They take great notes.

•They write up a short summary of their observation immediately.

Create a focus question

When you make a field visit to a customer, there’s so much to observe that it’s been likened to drinking from a fire hose. So before carrying out the visit, highly effective field researchers create a focus question to zero in on the aims of the project. A focus question — sometimes called a hunt statement — is usually expressed in this form: “I am going to research [activity] so that I can [design a system].” An example of a focus question might be, “I am going to research how our customers use our support materials so that I can design an online troubleshooting tool.” The focus question helps you concentrate on the observations that matter and prevent you from treating every observation as equal in value.

Practical tip: I’ve noticed that highly effective field researchers don’t create the focus question in isolation but develop it by working with the project team. A simple and quick technique (first described by Teresa Brazen as a way of engaging school children in user research) is to use a sticky note activity, where you give the project team 5 minutes to brainstorm all of the questions they would like to ask their users. Tell them to write each question on a sticky note, one question per sticky note. After 5 minutes, all the sticky notes are placed on the wall and the team first arrange the questions into groups and then vote for the most important group. That group of questions then becomes the articulation of the focus question.

Record the session

You need to record the session because the participant’s verbal protocol is central to your later analysis. Unless you’re an expert at shorthand, you’ll miss comments, phrases and some of the technical language that the participants use. Even if you’re great at shorthand, you’ll still miss intonation. Recordings are so important for a proper, in-depth analysis that highly effective field researchers get the sessions transcribed. Typically this costs around £1 per minute of audio, so if you run 15, 1hr sessions it will cost you £900 (about $1400). This isn’t cheap, but you need to balance the price against the time you’ve spent setting up the field visit, travelling to the location and collecting the data. Reviewing the transcript in depth is the most important analysis step you’ll make.

Our friends at Adaptive Path like to video record their ethnographic observations. I’ve found that this is feasible in large, relatively anonymous spaces such as manufacturing plants and production lines, where you are able to set up a camera and film a large area in long shot (very much like the view of a ceiling-mounted surveillance camera). But in an office space — even a large office space such as a call centre — video recording participants is risky, for three reasons:

•To video record on business premises you need to ask for permission from a very senior person in the organisation — and this is often all it takes to have the whole visit cancelled. (”Why are they doing this anyway?”)

•Video recording draws attention to the observation and changes the behaviour in the workplace, with employees understandably anxious that management might use the videos to rate their performance.

•Commercial confidentiality and data protection issues mean that it just isn’t feasible in many situations (for example, when a customer’s personal data appears on the participant’s computer screen).

Audio recording on the other hand is usually possible in most environments. Because it’s more discreet, you don’t need to ask permission before your visit: you can wait until you start the observation. I ask permission by trying not to make too a big deal of it: “I’ll be taking notes during our interview, but if it’s OK with you I’d also like to record the session as I can’t take notes quickly enough.” I also make it clear how the recordings will be used: “The recording is just for my purposes and anything you tell me will be kept confidential”. It’s also easy to pause the recording if sensitive data gets discussed, like when a customer’s credit card details are read over the phone. When I get the transcriptions, I change the participant’s name along with any other information in the transcript that could identify the participant.

Practical tip: You can keep transcription costs low by supplying the transcriber with high quality audio recordings. We like the Olympus LS-11 PCM because the audio quality is outstanding — it’s like listening to a DAB radio broadcast.

Take photographs

When you enter a new environment, there’s often so much going on, you’re not sure what to record. The risk is that you’ll review your notes and transcripts later, only to realise that you can’t recall a key element of the environment. Highly effective field researchers tend to take three kinds of photograph:

•Pictures that show the overall context, such as photographs of the exterior of the building and pictures of the entire office.

•Pictures that show the participant alongside other people and objects in the environment.

•Close-up photographs of the participant interacting with specific objects in his or her environment.

Once again, you need to ask permission but in my experience people are quite happy for you to take photographs so long as they know how they will be used. It’s even easier to ask if you wait until the end of the session and give the participant a gift before asking (such as some chocolates).

Practical tip: If you really, really can’t take photographs, you can always make a sketch. These don’t need to be works of art, but useful prompts to remind you about the relations between people and things in the environment.

Take great notes

Although you’ll be audio recording the session, don’t use this as an excuse not to take notes. The audio recording saves you from having to write extensive verbatim quotations, but it won’t tell you about the participant’s behaviour and environment.

The challenge when you’re taking notes is to make sure that your note taking doesn’t disrupt your relationship with the participant. You need to choreograph your note taking so that it is balanced with appropriate eye contact, other signs that you’re attending (”uh-huh”) and behavioural observations. Despite these constraints, I’ve noticed that highly effective field researchers somehow manage to take around 4 pages of A5 notes (steno-pad pages in the US) for each 30-minute observation. They also reserve the first page of their notes for any abbreviations and jargon that they hear: this quickly builds into a useful glossary.

My experience working alongside less experienced researchers is that they try to write down everything people say — even when they have an audio-recorder running. The moment the respondent’s mouth opens you can hear them scribbling. Hiding behind a notebook is a sure way to miss observations and is very distracting for the participant. So knowing what to write in your notes is important. In addition to a few quotes (the ones that really strike you) you should jot down ideas, key themes as they start to form, and also questions that you want to ask later in the discussion.

Practical tip: If you find that your mind goes blank and you’re not sure what to write down, try the ‘AEIOU’ method. This acronym stands for Activities, Environments, Interactions, Objects and Users:

•Activities are goal directed sets of actions — things that people want to accomplish. What primary activities do users need to perform to meet their goals? What do users mention first? Which action words (verbs) do they use?

•Environments include the entire arena where activities take place. Take photographs or make a sketch of the environment where the action happens.

•Interactions are the exchanges between a person and someone or something else. What are the intermediate steps or tasks in the process? What steps does the user enjoy most? What are the user’s pet peeves? Who reviews or authorises the work?

•Objects are the artifacts that people interact with. What physical items does the participant interact with? What software does the participant use?

•Users are the people providing the behaviours, preferences and needs. What are the participant’s goals, attitudes and motivations? What are the participant’s capabilities with the product domain and with technology? What education and training do participants have?

AEIOU is just one of several frameworks for making ethnographic notes, but it’s the one I find most useful for user experience observations.

Summarise observations immediately

How often have you turned to your notes a week after taking them, only to realise that you can’t remember what on earth you were thinking?

This experience is even worse if you’ve observed 4-6 people in a single day, as they all begin to blend into one another. Because of this, highly effective field researchers always schedule around 15 minutes after each participant to summarise what they have learnt.

Practical tip: To make sure you create an accurate summary, try using a standardised form. You will customise this for each project, but in general it will include some demographic information (like gender and age), a description of the context, any stand-out observations or user stories and a description of similarities or differences with other observations that you’ve made (this last information is useful if you want to create personas as it helps you group participants). The image below shows an example of a form I use.

Figure 1: Use this form to summarise your observations like a pro

Try it yourself

Although a site visit may take just a few days, if you do it right you’ll find yourself returning to your recordings, photographs, notes, and summaries for months afterwards. It’s an activity that just keeps on giving. This is because it provides the key data that you need to generate red routes, build personas, create mental models, craft user stories and understand the context of use.

Next time you get the opportunity to visit a customer, behave like a highly effective field researcher and you’ll discover how much easier this makes your life as a designer.

Is Consumer Research Losing Its Focus?

Philip Hodgson

Focus groups continually fail to tell us what customers want. The fundamental problem is that, in spite of what conventional wisdom tells us, it is not the voice of the consumer that matters. What matters is the mind of the consumer. The big mistake is in believing that what the mind thinks, the voice speaks. It is time to start embracing methods that can deliver stronger predictive value.

If you listen carefully you can hear it. The sound of marketers and product developers bemoaning the usefulness of their focus group research data, and the stifled groans of companies falling on their metaphorical swords. These noises are not going unheeded. The ground swell of opinion among marketers and researchers alike is that all is not well with focus groups, and that something needs to be done about it.

A new consensus

In his Slate Magazine article, “Lies, Damn Lies and Focus Groups?” Daniel Gross strongly challenges the effectiveness and value of focus groups for informing product development and marketing. He draws attention to the widely documented mismatch between what people say about product concepts in focus groups, and the way they actually behave when it comes to making purchases — a mismatch that costs companies millions of dollars in misdirected product development efforts. Gross is not alone in his views on what is unquestionably the most widely used research method on the planet. Kay Polit, principal analyst at the global management consultant company A.T. Kearney, refers to focus groups as “a faulty process”. Mary Lou Quinlan, founder and CEO of Just Ask A Woman, calls focus groups “a dangerous way to get market intelligence”. Dev Patnaik of design strategy firm Jump Associates likens focus groups to:

…a customer terrarium, with people behind glass—taken out of their natural surroundings and observed for scientific purposes… Focus groups are the crack cocaine of market research. You get hooked on them and you’re afraid to make a move without them.

And authors Joseph Pine and James Gilmore refer to focus groups as “the great lie”. In their opinion, “The guidance from focus groups can be downright dangerous.”

Lies? Dangerous? A faulty process? These are not encouraging testimonials upon which to stake millions of dollars, or a company’s future. But how justified are these concerns?

Some real examples

•Over reliance on focus groups failed NBC whose sit-com, Coupling (a re-make of a Brit-com and intended to replace Friends), relied for direction, as most TV pilots do, on focus group responses. NBC had to pull the show from the air after only three disastrous episodes within less than a month of launch. Beryl Vertue, a lead writer on the original British show, says:

There’s a huge reliance on ratings and focus groups and far, far too little reliance on a gut instinct, and I think that’s a pity. And ultimately, I think it’s a mistake.

•Poor management of focus group data failed the Pontiac Aztek which is selling below original expectations. Its styling was poorly received by focus group respondents, and should have caused concern and a possible re-design, points out Kay Polit:

Ideally, GM should have stopped Aztek in its tracks when it did so poorly in clinics. They might have been able to save it if they changed a few pieces of sheet metal, but instead somebody edited the data they got and senior management was making decisions on some pretty intensive editorialization… selling the vehicle at this point is probably going to cost them more than it did to design and build it.

•Focus groups failed the Chrysler PT Cruiser even though its sales now exceed expectations. Focus group data led the Chrysler planners to believe that they had, not a mass-appeal vehicle, but a niche vehicle. They geared up accordingly, and … underestimated volume.

•Focus groups failed a company targeting products to teenage girls. MIT Professor, Justine Cassell, author of a thought-provoking piece entitled “What Women Want” reports her experience working with the company. Following a series of focus groups the company concluded that what teenage girls wanted was technologically-enhanced nail polish. This was a happy coincidence as technologically-enhanced nail polish was precisely what the company produced! However, in Cassell’s own research with 3,062 children (60% of whom were girls) in 139 countries, in which the children were invited to describe what they would like to use technology for, not a single one of them said technologically-enhanced nail polish!

•Reflecting what is now a well documented lack of positive correlation between what people say and what they actually do, the Yankelovich Minute Monitor recently provided data listing the top six attributes that respondents said will most strongly influence their purchase decisions for an SUV; and a list of the actual decision criteria used at the point of purchase. You can guess the punch line. Not one of the six attributes nominated actually played a role in the final purchase decision.

And so on and so forth. You get the picture. That these cases are not exceptional is evidenced by the fact that a staggering 80% of new products fail within the first six months of launch in spite of most of them going to market on the back of seemingly strong market research data. Data, incidentally, that cost $1.1 billion in 2001. An 80% failure rate?! This is not a subtle clue that something is wrong. It is like turning on the light and getting an electric shock eight times out of ten!

Why focus groups fail

So why do focus groups result in such costly blunders? After all, focus groups:

•Have a long history (they were first used over 60 years ago by US government sociologists investigating the effectiveness of WWII military propaganda movies);

•They are widely used;

•They have unquestionable face validity;

•They are quick and easy to design and use;

•They seem to be obviously in direct touch with “the voice of the consumer”.

Of course, like any research method, focus groups need to be used appropriately, and they need to be put in the hands of research experts. Focus groups, thoughtfully prepared and effectively conducted, can meet certain objectives very well. I have had success with focus group data on numerous occasions in the USA and in Europe; and I have seen them used well by others.

Focus groups used for the purpose of idea generation, rather than for market verification, can be particularly effective. Ideas are ideas, and all is grist to the mill. I have conducted focus groups with telecoms managers, engineers, surgeons, nurses, policemen, and firemen, and these very specific group sessions do have a genuine and explicit focus, and can provide real insights. These are typically complemented by actual in-the-field ride-alongs and work-alongs, so that behaviours discussed in the focus groups can then be experienced first hand.

But I have also experienced less useful outcomes, and less insightful data, from groups representing more general market segments, such as teenagers, home-makers, and general consumers.

There are a number of important reasons, familiar to most of us, why most focus groups do not fare as well as they could. It is easy to point to methodological design flaws, or badly moderated sessions. Fingers can be pointed at poor and unrepresentative sampling, or at misleading data interpretation or badly written reports, or at recommendations that are ignored. None of these things are conducive to good research, no matter what the method. But none of these are the fundamental problem. The fundamental problem is that, in spite of what conventional wisdom tells us, it is not the voice of the consumer that matters. What matters is the mind of the consumer. The big mistake is in believing that what the mind thinks, the voice speaks. On that thought, I am reminded of an experience in Newcastle — ironically one of the most useful focus groups I ever ran — where the participants were all mildly drunk. They had been waiting in the bar of a hotel for the focus group to begin and they all arrived at the room carrying a pint of beer in each hand! Now I am not advocating this as a technique — but I did get the distinct feeling that I was circumventing their conscious awareness and accessing their genuine thoughts and beliefs!

Insight or hindsight?

There is a reason why “unarticulated needs” go unarticulated. Behavioural researchers have long known that expert behaviours (consumers are nothing if not experts at their own daily behaviours) are all but impossible to introspect upon, and so difficult to reliably articulate. We have known for almost 30 years (see Nisbett and Wilson’s classic Psychological Review paper) that people have little, if any, reliable access to the cognitive reasoning that underlies decision-making; and that in most instances people are unaware of the factors that influence their responses. This does not mean that respondents cannot provide answers to the “Why?” questions by which most focus group moderators live and breathe. But it does mean that responses are not made on the basis of true introspection. Instead, responses frequently reflect a priori implicit causal theories about the extent to which particular stimuli may plausibly be associated with given responses. In other words, rather than reflecting deep and veritable cognitive processing, respondent’s explanations for their decisions are frequently created on the fly in order to fit the situation.

But, even if — which is not the case but let’s pretend it is — even if respondents could reliably access their own reasoning processes, and could reliably report on their decision making so that the researcher was indeed collecting bona fide data, we cannot escape the fact that most conventional focus groups actually measure the wrong thing. They do not measure what people think when making a purchase. They measure what people think when participating in a focus group. The psychological, sociological, neurological, and even pecuniary factors bearing on a person’s decision making while they are participating and responding in a focus group are not the same psychological, sociological, neurological, and pecuniary factors that bear on decision making when the same person makes an actual purchase. According to Harvard Business Professor, Gerald Zaltman, focus group methods can tap into only about 5% of people’s thought processes — the 5% that lies above the level of consciousness. But it is the 95% of cognition lying below the respondent’s level of awareness — the bit that is not visible to focus groups — that is largely responsible for decision making.

Beyond the voice of the consumer

So we need to start considering more effective and more reliable methods for discovering consumer needs and preferences. We need to put aside the simplistic and overt questioning that telegraphs the researcher’s intent, and approach the investigation (rather like a detective might proceed, in fact) from unexpected directions. Indeed, this is how Experimental Psychologists and Cognitive Scientists work. They do not tap into the complexities of human behaviour by simply asking people “what are you thinking?” and they seldom rely on people’s introspection and self-report. Instead they use indirect methods of tapping into cognition and behaviour. Consumer research can learn much from the methods and tools of the Experimental Psychologist.

The key is to try and actually bypass the direct voice of the consumer. As an industry we agree that what people say and what people do are seldom the same thing. So it remains somewhat puzzling that we keep basing major decisions on what people say, while paying far less attention to what people do. What we ultimately want to know is the consumer’s actual intent. This can be secured by methods other than expecting focus group respondents to inspect their cognitive machinery, understand what they find there, translate that into language, and then articulate unambiguously. It should come as no shock to learn that methods that directly exploit and capture the actual behaviour of consumers result in extremely strong predictions of … actual behaviour! Cultural or social anthropology and ethnography (in the hands of expert Anthropologists and Ethnographers), and structured methods (such as Beyer and Holtzblatt’s Contextual Design) are highly effective ways of revealing unarticulated consumer needs. Surely it is no coincidence that these methods actually observe people as they engage in daily activities. These findings can then drive the conception, development and marketing of real product solutions — solutions that actually solve something. Although the resource investment of this approach to consumer research is often high compared to the costs of a few focus groups, it is minimal compared to the cost of getting development and marketing decisions wrong.

Later in the development process, lab-based or in-home user tests with high-fidelity prototypes can be used to refine the understanding of needs and to validate a solution’s fit to a consumer’s problem. Although usability testing methods are typically employed to identify user-interaction problems, they can lend themselves effectively to understanding the extent to which a product is actually useful. These behavioural approaches are all effective by virtue of obviating the need for consumer introspection and conjecture. Methods such as Gerald Zaltman’s ZMET technique (which exploits the use of metaphors and thus bypasses explicit consumer awareness) is well grounded in established cognitive, psychological, and brain sciences, having emerged from work with the MIT Brain and Behaviour group. This method, and similar methods that employ known Experimental Psychology techniques, are essentially methods for “interviewing the brain”. They are designed to tap into that hidden 95% of cognition that focus groups cannot see.

Focus group methods are prime for a rethink. It is time to start embracing methods that can deliver stronger predictive value. Until the industry starts consistently adopting methods that get to the core of consumer behaviour, rather than depending so heavily on obvious top-of-mind consumer opinion, billions of dollars will continue to be invested each year in throwing that light switch, only to feel the shock of market failure.

Do you make these 4 mistakes when carrying out a usability review?

David Travis

When properly carried out, usability reviews are a very efficient way of finding the usability bloopers in an interface. But there are four common mistakes made by novice reviewers: failing to take the user’s perspective; using only a single reviewer, rather than collating the results from a team; using a generic set of usability principles rather than technology-specific guidelines; and lacking the experience to judge which problems are important.

Some people approach a usability review like a dogmatic movie critic, prepared to give their opinion on an interface’s strengths and weaknesses.

This is the wrong mind set.

A design review is not about opinions, it’s about predicting how users will interact with an interface.

Here are 4 problems that you’ll need to address to ensure your review avoids personal opinion and will lead to a better interface.

Problem #1: The reviewer fails to take the user’s perspective

The hardest part of being a good user experience practitioner seems, at first sight, to be the easiest: taking the user’s perspective. It’s an easy slogan to spout, but like most slogans it’s also easy to forget what it means. I often hear reviewers preface a ‘problem’ they have identified with a sentence like, “I really hate it when I see…” or “Personally, when I use this kind of system…”

Here’s the difficult truth: it doesn’t matter what you like.

The interface may offend your aesthetic sensibilities, look clichéd or old-fashioned. It doesn’t matter — because you are not the user. As Kim Vicente has said:

“Ironically, the strength of the Wizards — the often brilliant designers of high-tech products and systems today — is also partially responsible for their downfall: since they have so much scientific and engineering expertise, they tend to think that everyone knows as much about technology as they do.” — Kim Vicente, ‘The Human Factor: Revolutionizing the Way People Live with Technology’.

This means that if you’re a member of a UX design team, you’re unlikely to be representative of your users. And if you review the interface from your own perspective, you’ll do a very poor job of predicting the problems that real users will have.

So before even starting the review you need a firm idea of your users and their goals. (If you can’t do this, consider testing with real users rather than carrying out a review). This step isn’t just a formality — it really helps you steer the review because it enables you to predict the future. “Predict the future” sounds like a bold statement, but consider this:

•If you know the users’ goals, then you should be able to predict why the user is visiting the site.

•If you know why the user is visiting the site then you should be able to predict the specific tasks that the user will be carrying out.

•If you know the tasks, then you should be able to predict the most important features or functions that the user will be looking for to complete those tasks.

•Putting all this together: you should now be able to predict where users are most likely to look on the screen, what other screen elements might distract them, and even where they are likely to click first.

A good usability review will begin with a data-driven description of the users of the product and a detailed description of the users’ tasks. If your review omits these, you’re almost certainly evaluating the product from your own perspective and as a consequence your findings will lack the predictive validity that your client needs.

Problem #2: The review is based on the opinion of one reviewer

We carry out an exercise on our expert review training course where we have a shoot-out between a single reviewer and a team of three. We regularly find that the single reviewer finds only around 60% of the usability issues found by the team. This isn’t a new finding: researchers have known for some time that you need 3-5 reviewers to get adequate coverage of usability issues in an expert review.

Adding multiple reviewers helps find more problems for a number of reasons:

•Some reviewers have more domain knowledge than you (for example, they know a lot about finance if it’s a banking application), which means they can find problems you’ll miss.

•Some reviewers tend to be sensitive to a sub-set of usability issues — for example, they may be more sensitive to visual design issues or issues to do with information architecture — and they tend to over-report those issues at the expense of other, equally important ones (like task orientation or help and support).

•Some reviewers have had more exposure to users (either via usability tests or site visits) and this means they are better at identifying the usability issues that trip up people in the real world.

•Different people just see the world differently.

But ego is a terrible thing. It’s almost as if people think that by asking other people to collaborate in the review, they are diminishing their status as ‘the expert’. In fact, the opposite is true: involving extra reviewers demonstrates a wider knowledge of the literature. Despite this, the majority of expert reviews that I come across are still carried out by a single reviewer.

A good usability review will combine results from at least three reviewers. If your review is based on the work of a single reviewer, it’s likely that you’ve only spotted around 60% of the usability issues.

Problem #3: The review uses a generic set of usability principles

All reviewers have their favourite set of usability principles, such as Nielsen’s heuristics or ISO’s dialogue principles. These principles are based on decades of research into human psychology and behaviour, which is a good thing as you can be sure that — unlike technology — they won’t change over time.

But this strength is also a weakness.

By their very nature, these principles are fairly generic and may even seem a little vague when applied to a new technology, like mobile. This is why an experienced reviewer will develop a usability checklist to interpret the principle for the technology and domain under review.

For example, take a principle like ‘User control and freedom’. This is one of Nielsen’s principles, developed prior to the web, and is expressed as follows: “Users often choose system functions by mistake and will need a clearly marked ‘emergency exit’ to leave the unwanted state without having to go through an extended dialogue.” This principle was developed for the graphical user interfaces that were in existence at the time. As a reviewer, this would remind you to check (amongst other things) that dialog boxes had a cancel button and that the interface supported undo. Fast forward to the web and these checks aren’t relevant to most web pages. To re-interpret this principle for web pages, we’ll probably want to check (amongst other things) that the web site doesn’t disable the back button and that there’s a clearly marked route back to ‘Home’ from all pages in the site.

So the guideline is still relevant but the way we check for compliance is different.

It takes some effort to generate a checklist for a specific technology — I know, as I spent weeks developing a usability checklist for the web based on various generic guidelines and heuristics. But it’s time well spent because having a checklist to hand when you carry out a review will ensure that you get full coverage of the principles and ensure none get forgotten.

A good usability review will use a checklist to interpret the principles for the specific technology under test. If you use the high-level principles only, you risk missing important usability issues.

Problem #4: The reviewer lacks experience

Many user interfaces are so bad that finding usability problems with your checklist is simple. But a checklist does not an expert make. You now have to decide if the ‘problem’ is a genuine issue that will affect real users, or if it’s a false alarm that most users won’t notice.

Sadly, there’s no simple way to distinguish between these two choices. Here’s a relevant quotation from Nobel prizewinner, Eric Kandel (fro his book, In Search of Memory):

“Maturation as a scientist involves many components, but a key one for me was the development of taste, much as it is in the enjoyment of art, music, food or wine. One needs to learn what problems are important.”

This analogy with ‘connoisseurship’ is interesting and applies equally to the issue of identifying usability problems. You need to learn what problems are important.

I have a friend who is a ceramics artist who told me the following story. She was asked to judge the ceramics section of an art show (about 20 artists) but included in her section were about 5 ‘mixed-media’ artists (including media like wood, metalwork and glass). For the ceramicists she was able to evaluate their work thoroughly — the aesthetics, the skill involved, the originality of the work, the craftsmanship — and she was able to give a rigorous critique of their pieces. But for the mixed-media art she could only use her personal opinion of what she liked or didn’t like. When it came to judging the craftsmanship she had no knowledge of what is involved in, say, blowing glass, or welding metal. But here’s the punchline… because she was uncertain, she found herself giving the mixed-media artists the benefit of the doubt and rating them higher. Generalising from this story: if you don’t understand the domain or the technology, you may tend to be more lenient — perhaps because if you are very critical you may have to justify and explain your judgement, and that could expose your lack of experience with the domain.

The risk is that you’ll fail to report an important usability problem.

One way you can develop ‘taste’ in the field of user experience is to break down the wall that so often separates the design team from users. For example:

•Sit in on a usability test and observe the seemingly trivial user interface elements that stump test participants.

•Spend time with your customers in their home or place of work so you truly grok their goals, aspirations and irritations.

•Run a user research session, like a card sort, to appreciate how your users view the world.

•Be a test participant.

A good usability review needs to be led by someone with experience. Without this practical knowledge you won’t be able to reliably distinguish the critical show stoppers from the false alarms.

Conclusion

Usability expert reviews are an efficient way to weed out usability bloopers from an interface — but only if they avoid personal opinion. Pay attention to these 4 common mistakes and you’ll find your reviews are more objective, more persuasive and more useful.

How to create personas your design team will believe in

David Travis

Does your organisation use personas to describe users’ characteristics, goals, needs and behaviours? Although they are a popular tool for communicating knowledge about users, many personas are little more than anecdote, hearsay and rumour. These kind of fake personas rapidly fall into disuse. Make sure your own personas get used by validating them against this 7-item checklist.

Assumption personas are fake personas

It’s easy to create a set of plausible statements about the primary users of a product or web site. We can make assumptions about their goals, their background and their behaviours, find a suitable bit of clip art and voila, we have a persona. It’s much harder to create an accurate description of users that the design team will believe in and actually use to resolve design disputes.

How do we know if we have a real persona or something fake? Ask these 7 questions of your persona:

1.Is the persona based on contextual interviews with real customers?

2.Does the persona evoke empathy by including a name, a photograph and a product-relevant narrative?

3.Does the persona appear realistic to people who deal with customers day-to-day?

4.Is each persona unique, having little in common with other personas?

5.Does the persona include product-relevant high-level goals and include a quotation stating the key goal?

6.Is the number of personas small enough for the design team to remember the name of each one, with one of the personas identified as primary?

7.Can the development team use the persona as a practical tool to make design decisions?

If you have a great persona, you’ll be able to answer each question with a resounding “Yes”.

P-E-R-S-O-N-A

As a memory aid, we can take each letter in the word PERSONA and relate it to one of these criteria:

•P is for Primary research

•E is for Empathy

•R is for Realistic

•S is for Singular

•O is for Objectives

•N is for Number

•A is for Applicable

Let’s look at each of these in turn.

7 ways to identify fake personas

Primary research: Is the persona based on contextual interviews with real customers?

It’s easy to create a fake persona by inventing an imaginary character containing all of your assumptions about users. But if your assumptions are wrong then your persona is worthless and will mislead the development team. As Mark Twain once wrote, “Supposing is good, but finding out is better.” Every key element of your persona should be traceable to primary research with end users. For personas, “primary research” means observations of customer behaviour combined with interviews in the places where people actually use your product or web site. This means you should shun research methods like focus groups and instead use techniques like field visits.

Empathy: Does the persona evoke empathy by including a name, a photograph and a product-relevant narrative?

It’s a lot harder to ship a bad product if you know the individual who is going to have to use it. One of the key benefits of having a persona is that it helps the design team empathise with the user and appreciate the difficulties that the user faces. That’s why personas have a name and a photograph: to make them real, so the design team believes in the personas. People should refer to the persona by name and think of him or her as a real person. To achieve this, a good persona also has a compelling narrative: not simply a bulleted list of goals but an engaging story describing the persona, to help designers relate to the persona.

Realistic: Does the persona appear realistic to people who deal with customers day-to-day?

Once your persona has been created you need to sanity check your creation with people in the organisation who work with customers every day. Send your persona to front-line staff, people in customer support and to the sales team. Check that this is someone they recognise and that they believe in the persona’s goals and behaviours.

Singular: Is each persona unique, having little in common with other personas?

Each of the personas in your set should comprise a unique cluster of behaviours, motivations and goals. If you have personas that are too similar to each other it becomes difficult to remember who you are designing for. As Alan Cooper, the father of personas, writes: “It is the specificity and detail of personas that gives them their value.”

Objectives: Does the persona include product-relevant high-level goals and include a quotation stating the key goal?

Understanding the persona’s goals is the heart of great user experience design. So your persona needs to make these goals explicit, with the most important goal captured in a brief quotation. Part of the art in creating personas is pitching your goals at the right level. For example, “Keep in touch with friends and family” is probably too high-level a goal to be useful for a design team developing a web site that sells mobile phones. A tactical goal like, “Find a handset small enough for my jacket pocket” captures the user’s goal and also provides an appropriate design target.

Number: Is the number of personas small enough for the design team to remember the name of each one, with one of the personas identified as primary?

If you start heading into double figures, you’ve probably got too many personas. This is because the design team won’t be able to remember all of their names or keep them in mind when designing. A Forrester survey of consultancies showed that firms created around four personas per project (and these were based on an average of 21 user interviews per project). You also need to make sure that one of your personas is primary: this will be the persona whose needs won’t be met if you design the interface for someone else (whereas the other personas will accept the primary persona’s interface).

Applicable: Can the development team use the persona as a practical tool to make design decisions?

Personas are lots of fun to create but don’t lose sight of the fact that they are a design tool. This means that the content of your personas — the persona’s goals, behaviours and mental model — should help the design team make better design decisions. Invariably, this means you want your persona to focus on behaviours, motivations and goals rather than demographics. Whether your persona does or doesn’t own a dog is irrelevant to the use of your product (unless you’re designing a web site for the Kennel Club).

Avoiding fakes

Fake personas are easy to create but risk derailing your design effort. So remember the mantra: Primary research; Empathy; Realistic; Singular; Objectives; Number; Applicable.

If you want to find out more about personas, try our training course on Web Usability where you’ll learn the basics and also get some practice creating a real persona that your desgn team will believe in.

About the authors

Anna-Gret Higgins

Anna-Gret holds a BSc (Hons) degree in Psychology and an MSc in Counselling Psychology and she is a Chartered Psychologist. After managing a team of 17 psychologists at the Health and Safety Laboratory, Gret joined Userfocus to manage the usability testing team. Anna-Gret has logged hundreds of hours in usability tests of public and private sector web sites and specialises in the evaluation of e-commerce sites.

Philip Hodgson

Dr. Philip Hodgson (@bpusability on Twitter) holds a PhD in Experimental Psychology and is a member of the Usability Professionals’ Association, the Association for Psychological Science, and the Association for the Advancement of Medical Instrumentation. He has over twenty years of experience as a researcher, consultant, and trainer in product usability, user experience, human factors and experimental psychology.

David Travis

Dr. David Travis (@userfocus on Twitter) holds a BSc and a PhD in Psychology and he is a Chartered Psychologist. He has worked in the fields of human factors, usability and user experience since 1989 and has published two books on usability. David helps both large firms and start ups connect with their customers and bring business ideas to market.

More eBooks from Userfocus

The Fable of the User-Centered Designer

Follow a young man's journey as he discovers the three secrets of user-centred design. It's a small book that has big results — and it's free.

Bluffers’ Guide to ISO 9241

ISO 9241 is widely cited by user experience experts who would be hard pushed to name any other standard — but all most usability professionals know about the standard is its name. This eBook describes each of the published parts of ISO 9241 in detail. £9.

Usability Test Plan Toolkit

This eBook contains all you need to make sure that you're fully prepared for your next usability test. The document includes easy to customise usability test forms, such as screeners, a discussion guide, questionnaires and data logging sheets. £9.

Morae for Usability Practitioners

Targeted at both new and experienced users of Morae, Morae for Usability Practitioners is a step-by-step guide to using Morae to plan, execute and analyse usability tests. Packed with insider tips and expert advice, this guide will help you use Morae to its full potential. £9.