Transcript of Lectures - UX The Ultimate Guide To Usability

User Experience: The Ultimate Guide to Usability
David Travis
Lecture transcripts for User Experience: The Ultimate

Guide to Usability
David Travis
Contents
1-01 Why take this course?..................................................................................................................5
1-02 Welcome.......................................................................................................................................6
1-03 Objectives.....................................................................................................................................7
1-04 Whats new in this course?...........................................................................................................9
1-05 Resources...................................................................................................................................10
1-06 The business benefits of user experience...................................................................................12
1-07 What is Usability? Product evaluation activity..........................................................................14
1-08 Can openers - Demonstration.....................................................................................................15
1-09 Can openers - User Research.....................................................................................................16
1-10 Can openers - Debrief................................................................................................................18
1-11 The 6 Rules of Usability.............................................................................................................21
1-12 ISO 9241-210 - A standard for usability....................................................................................23
1-13 The Course Roadmap.................................................................................................................25
2-01 Introduction to the context of use..............................................................................................27
2-03 What do users want?..................................................................................................................30
2-04 Introduction to Contextual Inquiry............................................................................................32
2-05 The Remote Control - Activity...................................................................................................35
2-06 The Remote Control - Debrief...................................................................................................36
2-07 Practical site visits, step 1 - Users..............................................................................................37
2-08 Practical site visits, step 2 - Focus.............................................................................................38
2-09 Practical site visits, step 3 - Recording......................................................................................40
2-10 Practical site visits, step 4 - Notetaking.....................................................................................42
2-11 Practical site visits, step 5 - Affinity Diagramming and User Story Mapping...........................44
2-12 Presenting results as empathy maps and storyboards................................................................46
2-13 Guerrilla techniques for user research.......................................................................................47
2-14 Three myths about field visits....................................................................................................49
3-01 Why the average user doesnt exist............................................................................................50
3-02 Introduction to personas.............................................................................................................52
3-03 A persona case study..................................................................................................................55
3-04 A persona case study, continued.................................................................................................57
3-05 The benefits of personas.............................................................................................................59
3-06 The pitfalls of personas..............................................................................................................60
3-07 Publicising your personas..........................................................................................................62
3-08 The 7-step persona checklist......................................................................................................63
4-01 Introduction to the design activities...........................................................................................65
4-02 Find My Pet................................................................................................................................66
4-03 Citizen Journalist........................................................................................................................67
4-04 Digital Postcard..........................................................................................................................68
4-05 Gift Giver...................................................................................................................................69
4-06 Tomorrow's Shopping Cart........................................................................................................70
4-07 Design activity research briefing...............................................................................................71
4-08 Persona Groups Briefing............................................................................................................72
4-09 Persona Creation Briefing..........................................................................................................73
5-01 Red routes - Introduction...........................................................................................................75
5-02 Red Routes - What and why.......................................................................................................77
5-03 The Flexibility - Usability Trade off..........................................................................................80
5-04 Prioritising red routes.................................................................................................................82
5-05 Red Route activity......................................................................................................................84
5-06 Introduction to user stories.........................................................................................................85
5-07 Testing a user story.....................................................................................................................87
2
David Travis
6-01 Introduction to Lean UX............................................................................................................88

6-02 Problem and Solution Hypothesis Testing.................................................................................90
6-03 Defining and measuring usability..............................................................................................92
6-04 Measuring Effectiveness............................................................................................................93
6-05 Measuring Efficiency.................................................................................................................94
6-06 Measuring Satisfaction...............................................................................................................95
6-07 The Usability Dashboard............................................................................................................96
7-01 Introduction - The Elements of User Experience.......................................................................98
7-02 Introduction to Information Architecture...................................................................................99
7-03 LATCH - The 5 Hat Racks for organising information...........................................................101
7-04 LATCH - Case Study using BBC iPlayer................................................................................104
7-05 Introduction to card sorting......................................................................................................105
7-06 Card sorting demonstration......................................................................................................108
7-07 Card sorting data analysis........................................................................................................109
7-08 Card sorting analysis example.................................................................................................110
7-09 Semantic matches and faceted navigation................................................................................111
7-10 Trigger words...........................................................................................................................112
8-01 Mental models, conceptual models, affordances and signifiers...............................................114
8-02 Some examples of mental models............................................................................................116
8-03 Skeuomorphic versus Flat design.............................................................................................118
8-04 Design patterns.........................................................................................................................120
8-05 Progressive Disclosure.............................................................................................................122
8-06 Choosing the correct user interface control.............................................................................124
8-07 Checkboxes, radio buttons and Fitts Law...............................................................................126
8-08 The Drop Down Menu - The UI control of last resort?...........................................................129
8-09 Expectations about page layout................................................................................................131
8-10 The Aesthetic Usability Effect and the Contrast Principle.......................................................134
8-11 The Alignment Principle..........................................................................................................136
8-12 The Principles of Repetition and Proximity.............................................................................137
8-13 Form redesign - Alignment......................................................................................................138
8-14 Bluffers Guide to Eye Tracking...............................................................................................139
8-15 Form redesign - Labels............................................................................................................141
8-16 Form redesign - The Question Protocol...................................................................................142
8-17 Form redesign - Trigger words and finishing touches.............................................................144
8-18 Introduction to prototyping......................................................................................................145
8-19 Examples of paper prototypes..................................................................................................147
8-20 A paper prototype in action......................................................................................................148
8-21 Getting the design right and getting the right design...............................................................149
8-22 Paper prototypings strengths and weaknesses........................................................................150
8-23 Whats in a Paper Prototyping Pack?.......................................................................................151
8-24 Overview of electronic prototyping tools................................................................................153
8-25 Prototyping activity - Briefing.................................................................................................154
9-01 The two types of usability evaluation......................................................................................155
9-02 Formative and Summative Usability Testing...........................................................................157
9-03 Why 5 users is (usually) enough for a usability test................................................................159
9-04 In-person and remote usability testing.....................................................................................161
9-05 Welcoming the participant and giving instructions..................................................................162
9-06 Getting participants to think aloud...........................................................................................164
9-07 Creating good usability test scenarios......................................................................................165
9-08 Keeping a poker face and reminding participants to think aloud............................................167
9-09 Roles in a usability test - moderator, computer and observer..................................................168
9-10 Observations and interpretations..............................................................................................170
3
David Travis
9-11 Prioritising usability problems.................................................................................................171

9-12 Jakob Nielsens Usability Heuristics........................................................................................172
9-13 Visibility of system status........................................................................................................174
9-14 Match between system and the real world...............................................................................175
9-15 User control and freedom.........................................................................................................176
9-16 Consistency and standards.......................................................................................................177
9-17 Help users recognise, diagnose and recover from errors.........................................................178
9-18 Error prevention.......................................................................................................................179
9-19 Recognition rather than recall..................................................................................................180
9-20 Flexibility and efficiency of use...............................................................................................181
9-21 Aesthetic and minimalist design..............................................................................................182
9-22 Help and documentation..........................................................................................................183
9-23 Why you need more than one reviewer....................................................................................184
9-24 Web Accessibility Guidelines...................................................................................................185
10-01 How to convince your manager that UX matters...................................................................186
10-02 Getting users for your first user research activity..................................................................188
10-03 Building your UX career within your organisation................................................................189
10-04 Creating a UX Portfolio.........................................................................................................190
10-05 Putting your knowledge into practice....................................................................................192
12-01 Bonus Lecture: Persona analysis with multiple behavioural dimensions..............................194
David Travis
1-01 Why take this course?

Let me tell you a story about user experience. So, a few years ago I was a consultant working for
HP in Germany and I was travelling from the UK to Germany by plane in order to take part in the
work I was doing over there. I arrived at Stuttgart airport and I picked up a rental car so that I could
drive from Stuttgart airport to where HPs location was. And when I picked up the rental car and
drove it to the exit from the car park I was confronted with this car park barrier.
So my question for you is, which one of these buttons would you press in order to lift the barrier?
Well clearly if youre a sane person you would press the green button, that seems the obvious
choice to make. But I pressed the green button and nothing happened. I pressed it again, and still
nothing happened. Then I rifled amongst all the materials Id been given by the car rental company
to see if there was perhaps a plastic card or something I was meant to put inside the slot; but no,
there was no plastic card. So, after pressing he green button again, and noticing that I had a queue of
cars behind me that were trying to get out of the car park, I began to panic. But at that point, a
helpful German man came out of a box where hed been reading a copy of Der Spiegel, and shouted
at me, Nein! Nein! Press the red button!
So I pressed the red button. Lo and behold, the barrier lifted.
The story doesn't end there though. I was on a long term contract with HP and when I went back
next time and picked up my rental car and got to the car park barrier exit, I noticed that they had
made a change to the design. They had included a large sign, saying: STOP. Press the red button
And they had also included some help text, both in German and in English, encouraging you to
press the red button to exit. So my question for you now is, Which button would you press to leave
the car park?
Well, you would probably press the red button this time. However, the story doesn't end there either
because when I went back a few weeks later some people must have still been choosing the
incorrect green button because they had changed the design yet again and now they had made it
absolutely clear which button you should press to exit the car park.
I tell you this story, not just because its mildly humorous, but also because I wanted to make the
point that bad design has consequences. It has consequences not just for me slowing me down,
making me feel stupid it has consequences for the person who works in the car park and has to
help people get out o the car park. It also has consequences for the queue of people in cars behind
me who want to exit the car park.
We want to make sure that we come up with designs where the consequences of them are the kind
of consequences we want them to have. We want to make sure that people are choosing the correct
options, not the incorrect options. What Ill be covering on this course is a lifecycle for carrying out
user centred design activities, which will make sure people are choosing the right element in your
user interface. Come and join me, its going to be lots of fun.
David Travis
1-02 Welcome
OK so right now, youre my new best friend because youve signed up to take this training course. I
really appreciate it. Im going to do my best to make sure that you learn lots of useful, practical stuff
about user experience and at the same time Im going to make sure we have a bit of fun along the
way.
So, let me begin by telling you a little bit about who I am. So my name is David Travis. Ive worked
in the field of usability and user experience since 1989 so whats that? Over 25 years. My academic
background is as a psychologist. Ive a got a first degree and a PhD in psychology and I think that
will come across in the training because what Im going to emphasise is the fact that its
understanding your users that matters much more than understanding the technology. And theres
a good reason for that which is that users dont change very much over time whereas technology
changes enormously.
I spend most of my time doing consultancy, probably 75% of my time doing consultancy, the rest
doing training. Now that works quite well that balance I think because it ensures the consultancy I
do is theory driven and it also makes sure the training that I do is based on best practice.
Ive worked on the usability of loads of different stuff in the past. Websites, obviously, well talk a
lot about that on this training course. But Ive also carried out usability tests and usability studies
of mobile phones, X-box controllers, interactive voice response systems you know, the ones
where you press one for sales, two for customer support, and so on. Ive even looked at the usability
of microwave ovens and fridge freezers.
Ive also written a couple of books on usability. The latest one is called E-commerce Usability.
When it first came out, I planned to call it Web Usability, but the publisher said, Put eCommerce
in the title, and youll sell shedloads more copies, so I followed their advice. Now, Ive also been
tracking the sales rank on Amazon over time and I was interested to see, well, you know, where did
it appear? Did it get in the top 1,000? Maybe even the top 500? In fact, the best it ever did in
Amazons sales rank was it got to position 289,495! So I hate to think what would have happened if
I hadnt followed their advice.
But Ive learned from that mistake. My next book on usability will be called Harry Potter and the FPlan Usability Diet. Im sure that it will get in the top ten.
David Travis
1-03 Objectives
So lets move on and I wanted to start by telling you a bit about the objectives of the training and
what it is that were going to be covering.
So lets move on and I wanted to start by telling you a bit about the objectives of the training and
what it is that were going to be covering.
So first up, were going to be talking about a framework for user centred design, an overall process
that shows you how to do usability and user experience and how to apply it to design projects. This
is very important because a lot of people think that user experience is about requirements capture,
or they think its about usability testing. Well, of course, these are components of it, but its about
more than that. Its really about an end to end process and thats what were going to be covering
on the training.
Were also going to discuss how to plan field visits to interview and observe your users. Lets face it,
the most important thing that we need to do in the design of any product is to understand the
people who are going to be using it. So were going to be talking about a particular technique called
contextual inquiry that helps us get a long way to achieving that goal. Ill teach you how to use this
method and then youll cary out an exercise where you actually do it yourself.
Well then move on to explain how you can use the data from your field visits to drive design. You
do that by creating personas, user stories, red routes and user journey maps. This course will show
you how to create those things and youll create your own versions of these as part of the course.
One element of understanding your users is uncovering and describing their mental model: the way
they think of the application domain. So well cover that too.
Understanding your users mental model helps us choose appropriate schemes for classifying and
organising information. Ill teach you a simple method on this course for organising information in
your user interface that will automatically make you the most creative person in the room.
Seriously.
A related technique is card sorting. This is a wonderful way to rummage around inside your users
heads and discover the way they think about your product. On this course, youll learn how to
design and conduct online and offline card sorting sessions and youll actually get to practice a card
sorting session yourself.
Well also cover the rationale for selecting appropriate user interface design patterns. Choosing the
right design pattern gives you a turbo boost when creating user interfaces, and Ill introduce you to
the main patterns and show you where to go to find more.
Then well cover prototyping. Im going to teach you a method of developing throwaway prototypes,
prototypes that you can develop in a few hours and test with users very quickly. This type of
prototyping supports a central principle of user experience, which is iterative design. We want to
design and test and redesign and so on and to support that we need some way of quickly
prototyping our ideas. On this course, youll not just learn how to prototype but youll create a
prototype too.
Part of being able to prototype is learning about visual design. How can we create visual designs
that wow users? Or at the very least, dont make them puke when they look at our screens? Ill
introduce you to some universal principles of visual design and youll redesign a form so that it
looks good.
Well also discuss the design of usability tests. This is where you get real users to carry out real
tasks with your system and you watch them struggle. Youll learn how to measure time on task,
success rate and user satisfaction and discover why those metrics are so important.
7
David Travis
Youll also learn how to moderate a usability test and prioritise the observations. Youll then run a
usability test yourself with your end users.
And finally, well talk about usability principles or heuristics and youll see how you can apply these
principles, both to evaluate and to design user interfaces.
By the end of this course, youll have decided on a design activity if you dont have your own, Ill
give you the choice of 5 different ones then youll have carried out user interviews, analysed the
data, created a persona, developed red routes, prototyped your product and tested it with users.
Phew. Theres a lot there. We better get started.
Oh, just before we start, theres something Id like you to do.
In the download pack with the extra materials for this course, youll find the student workbook and
on page 3 of the workbook youll find this form that asks you to think about your objectives for the
training. It looks like the document you can see here.
Heres your first task. Id like you to locate this document and think about what it is you want to get
out of the training. I want you to think about your objectives for this course. If you just sit through
the course and listen to the lectures without having any objectives in mind, youll never know
whether you achieved your aims or not. So spend 5 minutes thinking about your goals.
By the way, if I havent met your objective at the end of the course, drop me an email and Ill
modify the course to make sure I meet it in future.
Right, lets get started!
David Travis
1-04 Whats new in this course?

So whats new in this edition of the course?
I want to tell you a little about the history of this course and some of the changes that have been
made.
When I put this course on Udemy a few years ago, I expected to get a 100 or so people sign up. I
knew it was a good course Id spent years developing it as a face-to-face course so I had user
feedback on what worked well and what needed to be improved. But even so I was blown away by
the popularity of the course and the student ratings.
Now, as youll discover, Im a very hands on instructor. The great thing about Udemy is that Im in
daily contact with students. And students asked for five changes to the course, which Ive now
added to this new version.
First, you asked for shorter lectures. In the first edition of the course, lectures were about 10-20
minutes in length. In this new version, no lecture is longer than 10 minutes and the average is
about 5 minutes. The course still has the same content, Ive just created more breaks. Hopefully,
this will allow you to just dip in and out when you have time.
Second, people wanted more quizzes to test their learning. So Ive added more quizzes and
peppered them throughout the course. Theres now a quiz after each section (50 questions in total)
plus an end of course quiz with another 40 questions. Thats 90 questions to test your learning.
Third, people asked for a design activity that they could use to try out all of the techniques we
discuss on the course. So Ive added not, not two, not three, not four, but FIVE different design
activities that you can play along with. Ill be showing examples of other students work and you
can use these activities as portfolio pieces in your user experience portfolio.
Next, students told me they got lost with the all of the course downloads. The course had lots of
templates to support user research and design, but they were spread over the various lectures. So
now Ive combined them into a proper handbook and included a series of written user experience
briefings as part of the handbook. This is now a really useful resource on its own so I hope you find
it useful.
Finally, people asked for a qualification. Now this was difficult because at the time, there wasnt
any. I know its amazing, but until very recently there was no industry-recognised, vendor
independent certificate that proved you knew about user experience.
So I spent time working with an independent organisation the BCS, The Chartered Institute for
IT to create one. Its taken a couple of years, but its finally here. You can now take an
examination to prove your competence and its called the BCS Foundation Certificate in User
Experience. This course covers the syllabus for that examination, but its important that you know I
dont have any vested interest in this qualification. I dont make any money from you taking the
examination. Its an independent scheme administered by an organisation who awards a whole
range of IT related qualifications. By the way, the test questions that Ive included in this course are
about the same standard as the ones in the BCS Foundation Certificate in User experience, so this
course acts as a really good primer for people that want to take that exam.
David Travis
1-05 Resources
I wanted to quickly draw your attention to a couple of important resources that you need to be
aware of to get the most out of the training course. And the first one is the Student Workbook. And
in the Workbook, Ive collected together the various templates and briefings that youll need to do
the various activities on the course. So let me go through some of the content in the handbook that
youve got.
Importantly, on page 3 youll find a form where you can define your goals and the questions that
you have and its worth doing that before you actually start the course because that way you can
know whether or not weve achieve what youve set out.
Youll also find things like the odd thing you can print out: like a poster to remind yourself about
what the steps are in the training. And youll also see several of these things peppered throughout
the workbook and these are activities that we cover on the course. So don't go through and start
doing these until youve actually covered the lectures because the lectures will refer out to these
particular activities.
Another thing that youll find in this workbook are a series of briefings from me. So there are
certain topics in this instance, to do with field research that I know people have asked for
more information on. So alongside the videos themselves, youll also find these written articles
from me that describe, in this instance, habits of effective field researchers.
Another thing youll find in the handbook is a description of the design activities. These are central
to the course itself and the purpose of the design activities is to help you practice all of the
techniques. And youll go from beginning to end, from user research to usability testing. And here
are the five design activities: Find my pet; Tomorrows shopping cart; Gift Giver; The Citizen
Journalist; and the Digital Postcard. And Ill review each of those in a lot of depth in the videos of
the course but here it provides the extra background that you might need.
In order to do certain activities, youre going to need templates and tools and youll find that these
are provided in your handbook and you can then print those out so that you can use them as part of
the session itself.
What else have we got here? Im scrolling through the sidebar on the left hand side. So another
thing Ill be asking you to do is to redesign a form. This is he form youll be redesigning. Don't start
the re-design yet, wait until you get to that particular part of the course. But you might find it useful
again to print it out because then you can annotate the form with pen and pencil as you go through.
Another thing youll find in your pack is stuff that will help you do the prototyping activity. As well
as the briefing itself, youll find other things you can print out, such as a 6-up template for sketching
on, and another template here that you can use to produce your final design. As well as, if you really
can't draw, you can cut out these bits if paper prototyping pack and you can stick those in your
interface.
The other thing youll find as part of the handbook is a cartoon. How many courses come with a
free cartoon? Well this is one: a cartoon guide to usability test moderation. And that will give you
the background you need in order to moderate a usability test, as well as an additional briefing
about good listening.
What else will you find in there? Well, youll find a glossary that you can use if you find theres any
terms that I use that youre not familiar with. Head to the glossary and youll get a definition of
10
David Travis
those. And finally, youll find a reading list in your notes so that you can work out what are the next
steps that you should take with your training. So: thats the first resource you need to be aware of:
the student handbook. Make sure you download the workbook and then that will give you a lot of
resources youll need in order to do many of the activities.
The second resource you need to be aware of is the Facebook group. So weve got over 1300 people
in that group at the moment, and the purpose of the group is to allow you to share the work you are
doing on the course. Now you can share it within the Udemy interface, the problem is its not quite
as usable. Now by all means, if you do that I will still comment on it. So don't feel you have to use
the Facebook group, its simply that it makes the whole thing easier for you if you do. So I
encourage you to sign up. Youll find the link to this group in the student handbook (in the Welcome
message) and the benefits of joining the group are well first of all youll notice that although I
post in the group, its not my group: theres a bunch of people who are often posting resources and
links and they also act as your peers: theyll help review the materials that you produce. And also
Ill comment on this. Im in this Facebook group every day, so if you post something here youll get
immediate feedback on it. If not from me, then from other people as well. And you can see here
weve got various people who have taken part in the design activities.
So Id encourage you to sign up for the Facebook group as well. So those two things: make sure
youve got the student workbook handy, that youve downloaded it. Youll find that in the
Downloads section of the course. And secondly Id encourage you to join the Facebook group too.
OK, lets get on with the course.
11
David Travis
1-06 The business benefits of user experience

OK before we do a deep dive into user experience, first of all I wanted to cover the reasons why user
experience matters so much at the moment. And really, there are two key arguments for it.
The first one is to do with increasing revenue. The way that a focus on user experience helps
increase revenue, is that first of all, people can find the products that theyre after. So, if the website
youre designing is usable, people can find the product that they want. Therefore they can add it to
their basket, therefore they can purchase it. Thats clearly going to increase your revenue.
But another way that it helps increase revenue is that it helps resolves sales obstacles. So, for
example, if you run an e-commerce site, you dont know why people arent buying your stuff. If you
run a transactional site, you may not know why people arent downloading documents or signing
up for your newsletter. The kind of methods were going to be talking about help you understand
what those obstacles are.
Also, people wont need as much help and support because your system will be intuitive to use. And
if they do need help and support, presumably, theyll use the website instead, because what youre
going to design is going to be so easy to use. And its also true that people will pay a premium
because you make their life easier. I know when Im buying stuff from Amazon that I could
probably get it a few pennies cheaper if I shop around, but I think, well, its so easy to buy it from
Amazon, I think: why bother? Now, obviously Im still going to shop around for big ticket items, so
theres obviously a limit to how far you can push this, but certainly, people are willing to pay a
premium if your site is usable.
The second main way that a focus on user experience helps you is in reducing your costs.
One reason it helps reduce your costs is because, as a development team, you only spend time
developing the functions your users want.
You can also detect and fix usability problems earlier in the development process. Research shows
that it costs five times as much to fix a problem in the design phase than in the requirements phase,
and it costs ten times as much if the same issue gets through to coding. And if this usability bug
gets through to deployment it can cost anything from 100x as much to fix. So, it makes sense to try
and trap those problems early and the techniques were going to cover help you do just that.
These techniques will also help reduce the risk of failure because you didnt understand
requirements properly. We know thats the number one cause of failure in software projects not
understanding requirements. Were going to make sure that the techniques we cover help you
capture requirements properly. Well also minimise or eliminate the need for documentation and
that will be another way that it help reduce your costs.
Proof that good user experience means good business is that the field of user experience is now
involved in billion dollar business decisions. Heres three great examples of that: the AppleSamsung patent trial, the Instagram acquisition, and iOS 6s maps.
Usability expert Jared Spool has recently pointed to these examples of top technology stories that
show the value of user experience in modern business. So with the Apple-Samsung patent trial,
Apple claimed that it patented a number of user interface elements used in the iPhone, such as the
rubber band effect. Thats the bounce you get when you try to scroll past the end of a list. Apple
claimed that Samsung infringed this patent. The Apple lawyers introduced a document into
evidence that the Samsung product quality team had produced and this showed how Samsung were
trying to copy many detailed elements of the iPhone design. And the jury awarded Apple a billion
dollars in that particular trial.
The second is the Instagram acquisition. Despite developing its own photo app, Facebook
camera, Facebook purchased Instagram for a billion dollars in stock. And there are several reasons
for them doing this, but most of them boil down to the fact that Instagrams user experience was so
12
David Travis
streamlined. And thats because Instagram didnt try to be everything to all people. Kevin Systrom,
one of the founders of Instagram, said he wanted to focus on being really good at one thing and he
saw mobile photos as the great opportunity.
My final example is iOS 6s maps. Apples original mapping application turned out to be a dismal
failure because people had got used to the quality of Google maps. Within minutes of the launch of
iOS 6, users were reporting odd things like:
London had been relocated to Ontario.

Paddington Station had vanished.
The Sears Tower in Chicago had shrunk.
And Helsinki railway station had been turned into a park.
Apples chief executive, Tim Cook, was forced into an embarrassing apology over the application.
This was a problem of Apple not meeting the same quality of user experience as Google.
So, user experience absolutely matters big-time now in the development of products and designs.
13
David Travis
1-07 What is Usability? Product evaluation activity

OK, lets kick things off with a quick design activity. If you thought this was going to be the kind of
course where you can sit there and listen to me lecture, then Im afraid its not. Its going to be a
course where you need to actually get involved and heres our first example of that.
So Id like you to imagine that you no longer work for whoever it is that you work for. Instead, you
work for a new Kickstarter: its a company that is creating he most easy to use can opener on the
market. And your job is to evaluate a range of competitor can openers to try and work out what are
the features that make some can openers usable and some can openers unusable. So Im going to
show you four tin openers, four can openers, to do an evaluation of.
Now, youre probably thinking, Id love to do this activity David, but unfortunately I don't know
much about user experience yet. Its why Im taking this course. Well, I;m going to help you with a
quick scale you can use, its called the Jakob-ometer. I don't know if youre familiar with this
particular chap. His name is Jakob Nielsen. His work is something well be coming across a few
times on this training course. Hes a man that includes photographs like this on his web site in just
this kind of activity, so I decided to do that. And I want you to give each of the tin openers a +1, -1
or a 0 depending on how you feel that can opener stacks up. -1 obviously being worst, +1 being best
and 0 meaning, Mmm, Im not particularly sure.
And Im also going to give you some criteria that you can use to do the evaluation. So first of all
weve got Functionality: so does the tin opener do what it says on the tin, is it something that
looks as if it will open a tin. If it doesnt have the utility of being able to open a tin, its obviously
not a very good can opener.
So, Learnability: is it the kind of can opener that you think people could get going with straight
away or is it something they would need to read the manual or perhaps find a YouTube video to se
how its used.
Flexibility: so flexibility means, can you do different things with it as long as they don't get in the
way of the key tasks. So for example, can you use it left-handed and right-handed? Can you use to
open bottles as well as tins, for example?
And finally, the other one weve got here is Industrial design. Does it have the iPhone factor? Is it
the kind of can opener that, when you have people round for a dinner party, you proudly display it
on your work surface or is it one of those items that you throw in that draw you have in the kitchen
with all of the rubbish in, just to get it out of the way.
So what Im going to do now is show you a video of each of those can openers in a bit more depth,
so you can see the way each of them look. So have a look over that video and then carry out the
evaluation using this kind of template and the Jakob Nielsen score sheet to try and work out which
is the best and worst and also remember I want you to work out why some are good and some are
bad. What are the components of a good can opener? What are the components of a poor can
opener?
14
David Travis
1-08 Can openers - Demonstration

So now let me give you a better look at these tin openers that we are going to be evaluating. This is
our first tin opener. You may have seen this if you have your own tin opener, its a tin opener that is
commonly seen in households.
This is our second tin opener. It contains a knife, a fork and a spoon. They are obviously not the
things you use to open the tin. The tin opener itself is the container there, its got an edge at the top
that you can use to open tins with.
This is the third tin opener. It works differently from some of the others. Its got a kind of a ratchetstyle action. You press that grey button down at the top to open it up to get it around the tin and you
use that ratchet on the right hand side to actually open the tin itself.
And heres the final tin opener. Its a Magican branded tin opener. Made of white plastic and you
can see the tin opening mechanisms there.
So there are our four tin openers and your job now is to evaluate them and decide which is the most
usable and importantly, why?
15
David Travis
1-09 Can openers - User Research

So before we go any further, I just need to check that youre not going to be one of these annoying
students who doesn't actually do the activities, are you? Because its going to be a very boring
course if you don't actually do the activities themselves because thats where you actually start
learning stuff. So if you havent done the activity, and youve just proceeded onto this video, then
stop for a second, look at these four can openers and decide which one you think is the most, and
which one you think is the least usable and also work out why. And also perhaps leave a
comment suggesting why you think the best is the best and why the worst is the worst. So if you
haven't done it, pause the video and then come back to where we are now.
Im not sure how you rated the can openers make sure you leave a comment in the course before
you go on. But here is an example of the kind of data that I got when I ran that in a workshop
recently.
I had a class of 18 people and they worked in four different groups. So there are four pairs of ticks
and crosses, one for each team. So each tick and cross on the flipchart shows the consensus from
the four groups. Ive run this activity dozens of times, and these kind of results are typical.
Lets take a look at the results.
Three of the groups seemed to like the first can opener. People told me that they thought this was
an iconic can opener: its the kind of can opener that most people have used at some point in their
lives.
One group liked the second can opener. They thought it had an attractive visual design.
When it comes to the third can opener, every group voted it the worst. People were concerned that
it might cause people to have an accident when they used it to open a can because it has a sharp
blade.
And the final can opener got no votes, either as the best or the worst.
How did you come up with your decision for what was the best and what was the worst? When I
asked the people on my course this question, they said that they based their decision on their own
experience with can openers like these. Was that the same with you? Imagine these were four
alternative designs for an interface you were developing. Is it appropriate that design teams often
make a decision on the best and worst design based on their own experience? Or is there a better
way?
So, to show you how we can do this, Im going to change the rules of the activity slightly. The
manufacturing company just found some user research on can opener users. There are four key
user groups: Parent, Landlord, Pensioner and Backpacker. And they are responsible for 80% of the
can openers that are bought in the market today. Your task is to identify the most usable and
least usable competitor products for each of the four user groups. Let me introduce you to those
four user groups and then you can make your decision.
First we have the parent. I live in Alderley Edge with my husband and two young children, aged 5
and 8. I give my eldest child some simple tasks when Im cooking because she likes to help me cook
meals for the family. We have a large dog who has been known to empty the contents of the kitchen
bin on the floor, and I dont want my children (or the dog) exposed to any sharp edges from badlyopened cans.
Next we have the landlord. My partner and I rent out a house in London lived in by four students.
The house is let fully furnished and we are expected to provide a set of basic kitchen appliances,
including a can opener. We have a fairly high turnover of tenants in our house and when we check
the inventory after somebody leaves there is always something missing.
16
David Travis
Then we have the pensioner. I live on my own in a village in Cheshire. I retired from my job in a
factory five years ago because of severe pains in my wrist. I still have the pains, although some days
are better than others. Sometimes I cant even hold a can properly, let alone a can opener. I find
activities where I need to twist or turn my hands especially painful.
Finally, we have the backpacker. Im an 18 year-old student planning a backpacking holiday
around Europe next Summer. I hope to spend most of my time in the Mediterranean, but I dont
have a lot of money so Ill be camping or staying in hostels. I expect to do some self-catering so Ill
need a can opener.
So now, use the same kind of score sheet as we used before. But now instead of functionality etc we
have the four user groups. And now Id like you to place one tick and one cross in each row of the
table indicating what is the best and worst for each of that user group. So for example, whats the
most usable tin opener for the parent and whats the least usable tin opener for the parent. One tick
and oce cross in that row. Same thing for the landlord, same thing for the pensioner, same thing for
the backpacker. And then well come back and Ill show you the results from a class activity tat I did
and then we can see if thats resolved that problem that we had before, the problem with variability.
17
David Travis
1-10 Can openers - Debrief

So here are the results from the class activity.
Remember, I had four groups on this course, so there will be four pairs of ticks and crosses for each
user type.
The first thing youll notice is that theres lots of different opinions now about which can openers
are best and worst. So it looks like this approach of having specific people in mind might help us
take another perspective when we do evaluations.
But something else is going on too.
Look at the second can opener along. That can opener seems to live in this quantum state of both
being the least usable for the backpacker and the landlord and the most usable for the
pensioner (and maybe even for the parent).
Similarly, the camping style tin opener may be the most usable for the backpacker but the least
usable for the parent and the pensioner.
Whats going on here? How can a product both be the most usable and the least usable at the same
time? This doesn't make sense. Isn't usability a quality of an object? How can it vary?
The answer is that its not about the product. Its about the experience of using the product. So we
need to consider different users, different environments and different tasks to make a decision on
whats usable and whats not usable.
Were your results, like this, different for the different groups? Or did you choose just one can
opener as the best for everyone? My guess is that you chose different can openers for each type of
user. In that case, how did you approach the evaluation the first time, when you didn't have these
user profiles?
My guess is that you evaluated them from your own perspective: what you personally like and
dislike. Heres an uncomfortable truth: it doesnt matter what you like. Your own likes and dislikes
are irrelevant: the key factor is what works and what doesn't work for your audience. Now, in
reality, I know that design teams throughout the world, right now, are making product design
decisions based on what they think is cool. This exercise shows the futility of that approach. If you
base your design decisions on what you personally like and dislike, the only thing youll achieve is a
design that works well for you. Since its unlikely that youre the target audience for the product
youre designing, thats a sure route to product failure.
Heres another way we could look at our results. I like to think of this as a kind of usability trinity
because it captures the three key things that matter when judging usability: the user, the users goal
and the users environment.
So if we understand the user and the users goals, but we don't understand the environment, then
we give the backpacker the chunky, wrench can opener or something thats too big for his
backpack. In the world of technology, environment means the equipment (the hardware,
software and materials), and the physical and social environment where the system will be used.
You obviously need to understand that.
Similarly, if we understand the goal and the environment, but we dont understand the user, we
might give the pensioner the camping can opener, or any can opener where she needs to twist or
turn her hands.
And thirdly, if we understand the user and the environment but not the users goal, we might end
up giving the android any expensive can opener.
18
David Travis
So clearly, where we want our system to sit is where all three of these circles in this Venn diagram
overlap: we want to make sure weve understood the user, weve understood the users goals and
weve understood the environment where its going to be used. That will allow us to get inside that
sweet spot in the usability trinity.
So I have some other questions for you as well.
First up, think about the pensioner. What issue does this raise about accessibility: in other words,
researching all the people who need to use our system?
Well, the key issue it raises I think is that we need to involve disabled people early. Requirements
gathering and conceptual design needs to be truly inclusive. And theres a good reason for this. The
reason is that its generally much easier and cheaper to meet user needs early in design rather than
trying to retrofit a solution later on. If you don't do this, and just release your product and wait for
someone to complain, youll find it extremely challenging to revise your design to meet the needs of
disabled people. For example, if youve designed an interface from Day 1 that can be used only by
someone with good vision, what will happen when a blind user tries to use it? Or even someone
whos just misplaced their reading glasses? Involving disabled people early makes lots of
commercial sense.
Heres a second question. If you wanted to measure usability, what explicit behaviours might you
measure? Imagine that outside the room youre in at the moment there are some pensioners, some
backpackers, some parents and they are going to come in and use the different can openers to
actually open some tins. What behaviours would you look at? How might you say that one can
opener was more usable than another?
When I ask students on my course that question, they usually point to three different behaviours.
The first behaviour they identify is the speed with which people can open the can. If someone can
open a can of food in 20s with one can opener but it takes two minutes with another can opener,
then the quicker-to-use can opener must have something about it that makes it quicker to use.
The second behaviour that people point to is the emotional behaviour that people have: whether or
not they like the product theyre using. You might not think thats an explicit behaviour but in fact
you could measure participants facial reaction or whether they swear when they are trying to use
it. Or you could give people a short survey after they have used the can opener and ask them to
judge, on a 7-point scale, how may or difficult they found the can opener to use. Yet another
method might be to say to participants, Thanks for coming in today. As a thank you, you can take
one of these can openers home with you. And you could use that choice as a measure of which is
most preferred. But we need to be careful with these kinds of opinion-based measures. For
example, we might find that the pensioner might choose the camping can opener. So wed need to
follow up to find out why. She might tell us, Well its not for me, but my grandson is going on a
camping trip next month and he might find this one useful. Im not being facetious: as a user
researcher you need to get behind peoples opinions and and out why.
The third behaviour we can point to is to ask: can people actually complete their task? Can they get
the food out of the tin? With that camping can opener its actually quite difficult to open a can, at
least without gouging a hole in your hand.
Those three measures speed of use, user satisfaction and task completion are important and
were going to come back to them later on in this course as ways that we can actually go about
measuring usability.
The third question I have for you is this: What is the difference between usability and user
experience? People often think of user experience as being some kind of special engagement that
people have with a system, the kind of thing that encourages people to have an Apple logo tattooed
on their bicep. In fact, is it even possible to have a user experience with a can opener?
19
David Travis
Well, why not? It has a user, who is having an experience. Rather than think of user experience as
some kind of theatrical, immersive experience like you might have with a computer game, you need
to realise that people often just want to use your system to complete a specific task. They want to
get in, do their task, and get out. No matter how great you think your system is, and no matter how
much *you* like using it, remember that your users would almost certainly prefer to be doing
something else with their time. People dont want an immersive experience when paying their taxes
online, or buying a book, or reading the news. They are driven by the need to complete a specific
objective or goal.
And this means you need to often think about the bigger context. The user experience of a can
opener is about more than a can opener: its about the packaging, the documentation, even being
able to recycle the product when it reaches the end of its life. All of those are part of the user
experience too.
20
David Travis
1-11 The 6 Rules of Usability

So now lets dive into some details to do with user experience and I wanted to begin by talking
about six rules of usability.
You might not think of a field like usability or user experience as having rules, but indeed it does.
Our first one is, The design is based upon an explicit understanding of users, tasks and
environments. And ask yourself the question, How does your organisation stack up against this
particular rule?
Let me explain whats meant by it. Note that word explicit. That word explicit means stated
clearly, leaving no room for confusion or doubt. You remove confusion and doubt by collecting real
data: you go out and visit users, you observe them while they do the thing that youre designing you
product to do.
This is very important because the secret sauce in UX is user involvement. The more user
involvement throughout the process, the more effective your final design will be.
So how does your organisation stack up against that particular rule of usability?
This is our second rule: Users are involved throughout design and development.
This is similar to our previous one, in the sense that users need to be involved, but now were
talking about involving them throughout design and development. Often, you might find projects
where they involve users at the very beginningmaybe they run a focus group or something.
Sometimes, users are involved at the very end: maybe people are running a user acceptance test.
But notice here that users need to be involved throughout design and development. So with this
second rule, my question for you is: how does your organisation stack up against that particular
rule of usability?
Our third rule of usability is The design is driven and refined by user-centred evaluation. This is
really about measuring usability. Its not about doing demos. So if you work in an organisation
where user interfaces are demoed to users or clients and theyre told, Well, this is how its meant
to work, well, youre not doing empirical measurement. Empirical measurement is really about
putting real users in front of the system and asking them to do real tasks and then you just sit back,
shut up and watch. Its about usability testing.
This requires you to acknowledge that the definition of done when you are designing a system can
only be determined by users. And since you are not the user, you cant judge done, only your users
can.
This rule also makes it clear that you cant wait until the end of a project to see if youve met user
requirements. Thats the waterfall way. If you work on a project that does user acceptance testing at
the end of design and calls it usability testing, youre doing it wrong. You cant just test at the end of
design.
So again, how would you say your organisation stacks up in terms of being driven by driven and
refined by user-centred evaluation?
The next rule of usability is about iterative design.
Weve already touched upon iterative design and its really to do with making sure that you go
through a process of design, testing, redesign, retesting, and so on until you meet user needs. And
the reason for that is because we just cant understand or predict what users want early on in
design whether its a piece of software, whether its a website, whatever it is, we need to make
sure users are involved to check that were designing something that meets a real user need. Our
first design will be a kind of a stake in the ground that says, well, this is roughly where we think
21
David Travis
were headed, but we need to acknowledge that the process is going to be iterative.
Again, how would you say your organisation stacks up in terms of following an iterative design
process?
In fact, the process that you use within your organisation iterative or waterfall actually tells
you something about the values that the organisation has.
If you follow a waterfall-based approach where basically requirements are nailed down on day one,
and they cant be changed through development, the values of your organisation are very much
focused on production.
Now, its not that waterfall methodologies are inherently flawed. If I was going to do a major
construction project, such as build a bridge over a river or a skyscraper, something like a waterfall
methodology would be a good one to use because we know what the problem is and we know how
to go about fixing it.
But with software we often dont know what the problem is and we also dont know how were
going to go about fixing it. So an iterative approach works much better here. And it also shows us
that the values of the organisation are more focused on users because we acknowledge that changes
to the spec are going to be inevitable. If you use Agile approaches within your organisation, youll
already be familiar with this and as well see later, UX and Agile play really nicely together. Theyre
a good combination to have.
So rule number 5 is about the whole user experience. This rule makes it clear that you need to
consider everything that affects the user experience, such as user support, the out-of-box
experience, maybe even re-engineering your company to better serve the user need.
Usability answers the question, Can the user accomplish their goal?
But user experience answers the question, Did the user have as delightful an experience as
possible?
Remember: its not about the product. Its about the experience of using the product.
Again, how would you say your organisation stacks up in terms of addressing the whole user
experience?
And then finally, rule number 6 is a bout the design team including multidisciplinary skills and
perspectives. Anyone who has worked in the field of user experience will know that there is a
dizzying array of job titles. Ive looked at various sources including job advertisements, surveys by
professional bodies, and I even carried out a poll with user experience people on Twitter. And I
discovered that job titles arent much use in deciding on the skills needed for a design team.
But its a fact that good design teams will have a range of skills: user researchers, interaction
designers, content designers and front-end developers as well as other technical people.
And again, how would you say your organisation stacks up in terms of having a multidisciplinary
team?
22
David Travis
1-12 ISO 9241-210 - A standard for usability

Now the interesting thing is, these rules weve been looking at havent come from some selfappointed guru in user experience.
They actually come from an international standard on usability.
Did you know that there was an international standard of usability and user experience?
Well, you do now.
Its called ISO 9241 and its not really a prescribed methodology, its more of a process.
Methodologies come and go. PRINCE2, UML, Agile, Lean programming. Tomorrow therell be
something new. But this process will apply regardless of the development methodology that you
use.
The approach recommended in this standard is that you should start off by planning the human
centred design process. In other words, you make sure that theres time and budget available for
doing user experience activities.
Then you do some work to understand and specify the context of use. Context of use is a jargon
phrase but it means we need to consider the environment that its going to be used in, the users and
the goals that they have with the system.
Then youre going to specify the user requirements.
And then well produce design solutions.
Then you evaluate what you have and if youve met the requirements, youre done.
Otherwise, you stay in that loop until you meet your usability and business goals. Ive taken this
particular image from the ISO standard actually, I redrew it slightly to make it a bit more
interesting.
Lets notice some points about it. First, you need to make the context of use explicit. That word
explicit again: remember, it means stated clearly, leaving no room for confusion or doubt.
Then, with the user requirements, you need to acknowledge that there is never just one viewpoint.
You need to include a range of user groups and stakeholders.
When it comes to design solutions, notice the plural there. The idea isnt that you just come up with
one design solution and then iterate on it. What you do is you come up with multiple design
solutions and work out which ones best before you start iterating.
And when it comes to evaluation, remember that this means proper user testing, not just a demo of
the system.
Finally, not that important iteration step. User experience is a lot about testing assumptions and
changing the design accordingly.
The key elements of this approach are:
It focuses on the users throughout development, by doing user research and by testing prototypes.
Its iterative: there is an implicit assumption that designs will change and evolve over time as our
thinking evolves and our testing reveals what actually works.
Its flexible: it applies to any technology and it can fit into more traditional linear development
processes, as well as highly iterative, agile approaches.
23
David Travis
Now I could have used this picture as the basis for the course, but I wanted a bit more detail for you
to hang on the various tools and techniques were going to discuss. So I want to introduce you to
another diagram that will become our roadmap for the training.
24
David Travis
1-13 The Course Roadmap

This is the same process but with a few more explanatory boxes. I think it works better for me to
hang the material on.
So, in the first phase were going to analyse the opportunity. We want to really understand this
thing that were developing in terms of all of the stakeholders who are involved in it.
Next we need to understand the user experience vision. So lets say that we were thinking five or
ten years ahead. How do we imagine people using our website in the future? Now, we may not be
able to achieve that right now, but at least we know where were headed, so that if we have to make
some kind of trade-offs, we know whether were getting closer or further from our goal.
We also need to segment the market, so at a high level, just understand who are the main groups of
user, and that helps us stop thinking in terms of just the user and instead think about specific
users.
Were now going to explore this in more depth when we move into building the context of use. So
weve already mentioned term context of use from the ISO standard. Here the aim to first of all
build some kind of user profiles, so weve got detailed understanding of who our users are. And this
is where Im going to talk specifically about personas, because its a great way for building those
user profiles.
Then were going to talk about building environment profiles. This is the context that its used in in
terms of the environment itself. So, for example, is the website going to be accessed mainly on a
mobile device, on a table device, on a laptop? Also what kind of lighting levels might be necessary
for where the products going to be used if its a handheld device for example.
And then were going to identify red routes. These are the key tasks, the absolutely critical things
that people want to do with the system. Now clearly people will want to do a range of things with
the website, but theres a handful of things they really, really, really want to do, the absolutely
critical things. We need to identify those so we can make sure we prioritise them during design.
Well then move into creating the user experience. Well being by talking about key performance
indicators, or usability metrics, which well use to steer the design, and make sure that we think of
usability as an objective, measurable attribute.
Well then talk about the information architecture. Well talk about ways of making sure people can
navigate the website properly. Well talk about ways of making sure we use the right kind of labels
and terminology and understand the mental model that users have when theyre using our system.
Then well turn to looking at screen layout and well look to see how we can design screens so at
least people dont vomit when they first launch the website itself. But that also includes things like,
you know, what do we know about iTracking, for example, and what can we learn from that to work
out where things should be placed in screen? Or do people have expectations about where certain
things should be? Thats the kind of thing were going to review in that part of the course. And then
well evaluate usability and were going to do that in two different ways. The first way is by thinking
in terms of expert reviews, so well have the main experts, or usability experts, using sets of
principles, rules, or guidelines to say whether or not somethings usable. But more importantly, the
gold standard is usability testing. Well ask real users to use our system and well find where the
obstacles are in achieving their goals.
Finally, the last step in this process is to drop out and track real work usage and continuously
improve the site, so we had some assumptions that weve built during this, were they appropriate?
If not well feedback into the overall model and then redesign it. Now, I quite like this model. Youd
expect that, of course because its from a book that I wrote, but the reason I like it is because it
emphasises user experience design is a process, so its not just about requirements capture. Of
course, you need to understand what customers want. But at the end of the day, a designer needs to
25
David Travis
create some kind of artefact to design something. But its also not just about having a kind of pretty
or engaging front end. And Ive run into arguments with a number of design agencies in the past
about this. Pretty design that doesnt meet business needs. Its a waste of time and money. And its
also not just about testing. Youll find that some usability agencies get stuck on this and just want to
test everything to 95% significance levels. Its not about any of those individual components. Its
about all of them. So, user experience design is a design process. Thats what were going to be
covering, and were going to dive into that model beginning with the next lecture.
26
David Travis
2-01 Introduction to the context of use

Ive already touched on this notion of context and the context of use, and its something that I
wanted to turn to now and talk in a bit more depth about. Let me show you first of all where we are
in the overall scheme of things.
Ive going to dive in to our roadmap in here, in the section titled, Build the context of use. Im not
going to talk about analysing the opportunity in the course, mainly because that step is often done
by another group within an organisation and much of it you can understand from reading business
books. Most of the stuff in analysing the opportunity isnt really UX specific, which is why I wanted
to start off with building the context of use.
So this is where were going to begin our route through user experience design. But before we dive
into any of those particular areas in depth user profiles, environment profiles and red routes
first of all, I want to talk about this notion of context.
This kind of stuff really matters because as UX professionals, the very best thing we can do is get
out the building and meet our users. Its our USP. Its what we do best.
Heres a definition of that term, context of use: A description of the users, tasks, equipment and
the physical and social environments in which a product is used. So: users, tasks, environments.
Thats our usability trinity.
To collect this data, this means you either go to where your users work or where they have fun or
wherever theyre using your particular system. And there are some techniques we can use to really
help us do that well. And I wanted to turn to talk about one of those specifically now. And let me
begin, as all presentations should, with a picture of a urinal.
Now, this is an example perhaps of why context matters.
Lets assume that you are a builder and youve got this particular lavatory layout that you want to
implement. Well, where do you recommend somebody actually installs this kind of lavatory design?
In a petrol station? In a shopping centre? How about your local pub?
You could imagine, couldnt you, that if it was in your local pub in a gents toilet you could imagine
some people at closing time, you can just see them choosing the wrong receptacle, cant you?
Heres another example as well not that Im obsessed with urinals or anything, but this is clearly
designed by someone who has got no concept of personal space. So, context matters.
Lets leave urinals behind and now let me give you an example of context in the electronic domain.
Imagine that youve gone to a restaurant where you have a booking. And you tell the waiter your
name and he turns to his computer screen to check his details. And he then gets out what you think
must be some kind of new electronic stylus and he moves it towards the screen.
Now, youre a tech savvy person and youre quite curious about what kind of new gadget theyre
using at this restaurant, so you lean in and you look a little closer and you suddenly realise that this
is a perfectly ordinary whiteboard felt-tip pen.
In other words, the head waiter just drew an X over your booking directly on the computer screen,
like this:
Thats very interesting, you say, how come you do that?
And heres a direct quotation from the waiter in this restaurant. He says this: Well, the guys that
create these kinds of systems, they have, well, you cant do things the way you want to do them. You
can check off a reservation in the system with a mouse. But its at least four clicks away from this
27
David Travis
screen. And you cant tell if the guests have been shown to their table or are waiting in the bar. So
its much easier just to draw on the screen. And when the evenings over, you just wipe the screen
with a cloth. Were very busy here and this works just fine.
So, lets unpack that example and think about what it tells us about context.
Well, the first thing it tells us is that users will adapt our system to match the way they work
whether we like it or not.
The second thing it tells us is a little bit about the behaviour of the development team that was
putting this system together.
Think for a moment about the context of the person that was designing this interface. The chances
are he (and he probably was a he) was in a relatively quiet office. The chances are that he didnt
have a long queue of people that wanted his time. The chances are that he had a desk with a mouse
on and it was easy for him to move the mouse around.
Now, thats a very different context to a waiter in a restaurant with a queue of people where
perhaps theres not enough room on his table for a mouse and hes trying to get people seated in
the restaurant.
The point is that just a short visit to a restaurant would have given the designer that kind of insight.
So the point of this is that the person that youre designing for whether its someone running a
restaurant or whether its someone using your mobile application you dont understand the way
they do things unless you do those things yourself.
Heres a T-shirt that I would like to get made and give away to everyone on this course. I just
mocked this up in Photoshop, sadly, you cant buy it. But the fact is, if youre a designer, youre not
the target audience.
This is for a number of reasons.
First, you know too much about the product. Whether its a website, an intranet, a mobile
application, or whatever.
Second, you probably care too much about your own baby. I mean, you cant imagine visitors
bouncing after scanning the home page for 30 seconds, but thats what a lot of users do.
Third, youre also probably the wrong age compared to large segments of your target audience. For
example, you probably dont know how teens use the web or the problems theyll have navigating
your design or the problems older people may have using your system.
And finally and importantly, youre probably much more skilled in using computers and the web in
general compared to your users. Of course your users may be familiar with computers, but your
level of expertise as someone who designs this stuff is way beyond the expertise of most
ordinary folk. You probably know how to troubleshoot problems with your computer. You may
even know how to program. In contrast, most users simply know how to click, tap and swipe.
Just to make that point, heres a quotation from a guy called Dan Russell whos got the best job title
in the world: the Uber Tech Lead for Search Quality and User Happiness at Google. And he says
this:
We have found that there are some surprisingly basic search techniques that people just dont
know about. I interviewed a bus driver who was searching for a transportation rule for a test. She
was scrolling line-by-line through a 100-page web document, so I asked her why she didnt use
CTRL-F to search by keyword. It turns out she didnt know about this absolutely basic browser
function. Amazed by this, we ran a survey that found 90 per cent of people dont know about it..
28
David Travis
Now, its interesting isnt it, because I dont remember anyone teaching me that Ctrl F was the way
to find things in a webpage. Its probably something that I tried based on knowledge of other
applications. But certainly its seems to be something that is not that obvious to many people.
And heres another example. Lets say that we asked 50 people this question. What is a browser?
How many people do you think would give us the correct answer? Really stop and think about this.
How many?
What if I told you the people were going to ask are going to be ordinary people, people were going
to meet on Times Square? How many out of 50 would be able to tell us what a browser is?
Well, instead of giving you the answer, Id like you to now look at the next video which is produced
by someone who did just this.
29
David Travis
2-03 What do users want?

So four people, or 8%. I wonder how that compares with your prediction? Now, I acknowledge that
that was filmed a few years ago. Its probably the case that more than 4 out of 50 people know what
a browser is today. But dont make the mistake of overestimating your users technical expertise.
Certainly in my experience, when I watch people in usability tests, I see users often make
fundamental mistakes, like entering a web address (a URL) into a search box. So, this kind of
confusion over technology is not unusual with ordinary people the type of ordinary people who
are our users.
Heres another example I came across a while back. It was an article that was published on the
Read Write Web website and they had an article titled Facebook wants to be your one true login.
The article was about the trend to use Facebook credentials as a way to authenticate at a web site
rather than asking users to create accounts with every web site they visit.
Being an interesting and timely article, it very quickly rose to the top of Google searches for the
query, Facebook login. So if youre the type of user that didnt bookmark Facebook, and instead
you just went to Google and typed Facebook login, this article would have been the first on your
list.
What happened next was quite interesting: people arrived at this page expecting to sign into
Facebook.
If this was you, youve done a search for Facebook login, clicked on the link, arrived on this page,
what would you do next? Most people that I ask say, Well, Id hit the back button.
But thats because most people I ask tend to be like you: people who are fairly technically
competent. What actually happened was that people started searching this web page for a way to
sign in, because they assumed that this was, indeed, Facebook.
You probably dont believe me. Well, the reason we know this is how people behaved is because the
article included an area for comments and people that were trying to sign in to this website
thinking it was Facebook left comments like, The new Facebook sucks, now let me in, Where can
we log in? and I want the old Fafebook back.
These are examples of people who thought this site was Facebook. Now, if you know the web, you
know this isnt Facebook. But these people who left these comments are users who dont have that
same level of expertise or competence. So the point of these examples is that people may not have
the level of technical competence that we have, and if we design from our perspective, assuming
that they have that level of competence, then our users may well struggle.
On the other hand, our users may know as much or more than us. Dont think Im saying users are
clueless. Your particular user group may know a lot more than you about technology or the domain
you are designing for. The point is, you dont know unless you find out. You need some data so that
you can make an intelligent decision.
So, how do we go about understanding users and their needs?
Its a bit like Fight Club: The first rule of finding out what people want is: Dont ask people what
they want.
And the second rule is: Dont ask people what they want.
The obvious way to find out about user needs is wrong.
When you ask people what they want, using tools like surveys and focus groups, you are asking
people to predict their future behaviour.
30
David Travis
People arent very good at this.

A second problem with techniques like focus groups and surveys is that they focus on opinions. As
a consequence, these techniques tend to uncover whats easy for users to articulate.
But whats easy to articulate is not necessarily whats important.
Generally, the important stuff is actually harder to articulate and thus remains hidden.
Now, its not that user researchers dont value what people think. Its just that its very risky to
make design decisions based on peoples opinions.
A third problem (with surveys in particular) is that you need to know the questions you want to ask
before you can start. Now its true that a survey will give you a larger sample size but sadly,
having a large number of respondents in a survey will never help you if you dont know the right
questions to ask.
Thats where site visits and customer interviews come in.
My definition of a successful user research study is one that give us actionable and testable insights
into users needs. Its no good asking users what they like or dislike, asking them to predict what
they would do in the future, or asking them to tell us what other people might do.
So the best way of conducting a successful user research study is not to ask, but to observe. Your
aim is to observe for long enough so that you can make a decent guess about whats going on.
Asking people what they want will encourage confabulation, not tell you what is actually going on.
This means youre much better off observing real behaviour: what people do, not what they say
they do.
There are two ways to observe. We can observe how people solve the problem now. Or we can
teleport people to the future and get them using your solution (a prototype) to see where the issues
will arise. Were going to cover both methods on this course. Right now, were going to look at the
first of these: observing how people solve the problem now.
The key point you need to remember is this: What people say is not as useful as what people do.
People are unreliable witnesses.
31
David Travis
2-04 Introduction to Contextual Inquiry

Heres how this approach helps us. Ive adapted this slide from Kathy Sierra who describes this
approach as creating badasss users. Thats a good rule to remember. How can you make you users
more badass?
The key attributes of a successful product dont live in the product. The key attributes are in the
users results.
Frankly, users dont care about your product.
They care about getting their job done the bigger context.
Your product is a tool.
Sustained success lives in the context, not in your tool.
People dont want to be amazing at your tool. They want to be amazing at the context.
People dont want to be good at Excel. They want to discover patterns in numbers.
People dont want to be good at Microsoft Word. They want to write better documents.
People dont want to be experts with your tool. So think for a second: what do they want to be
better at?
This means we need a research method that lets us understand the users bigger context.
Heres an interesting question: If a documentary crew spent a day following one of your users,
what would the camera see and hear? Its an interesting question, isnt it?
Just like a fly-on-the-wall documentary, youd end up with objective insight into the problems
users face day-to-day when doing their tasks.
Think for a moment about the characteristics of fly-on-the-wall documentaries:
The film-maker is a neutral observer.
The film-maker is normally out of shot so they cant influence anything.
Life is lived and observed.
Nothing is rehearsed or staged.
Wouldnt it be great if we could do research from this perspective? It would allow us to get
authentic, deep insights into our users and their behaviour. Stuff wouldnt be made up.
Well, we can do research like this.
Theres a technique that we can use called contextual inquiry.
To introduce it, heres a quotation from the author Jerome K Jerome, which I think summarises it
quite well, where he says, I like work, it fascinates me, I can sit and look at it for hours.
And often when Im doing this kind of work, thats how I feel. I turn up a clients premises. I dont
literally put my feet on the desk and start drinking coffee, but I do look around to look to see the
way people are working.
So this term contextual inquiry it sounds like a bit of UX jargon. In fact, it is. But really, you
probably know this stuff already. Because other terms that you might have heard that are
synonymous with contextual inquiry are words like field visit, ethnography and shadowing.
32
David Travis
The difference is that contextual inquiry dictates a particular way of doing the research. There is
basically one way of doing contextual inquiry whereas there are lots of different ways of doing field
visits, lots of different way of doing ethnography, and lots of different ways of doing shadowing
depending on who you read.
But theres one way of doing contextual inquiry, and thats why its worth learning this particular
technique, because then youre able to share your findings with other people in the organisation
who are doing similar work. And the main reason for doing it, as it says on this slide, is that its
useful for understanding the messy reality. In other words: it will tell us what people actually do,
rather than what they say they do.
One of the themes were going to keep returning to as we go through this course is the fact that
users will say one thing and do something else. So we need some way of dealing with that reality
and contextual inquiry is the tool that will help us achieve it.
So, lets review what contextual inquiry is about. In fact there are four key steps in doing a
contextual enquiry. And Im going to review those with you now.
The first up is context. So, in order to do contextual enquiry, you need to go where the action
happens. Now the action usually happens, perhaps, on a keyboard at someones desk, it may be a
mobile phone on the street, it may be a tablet on the sofa, but wherever that action happens, thats
where you need to go. If you interview someone in conference room in an office, or you stop
someone at a trade show and interview them there, youre not doing contextual enquiry. Im not
saying that those research techniques arent useful. You can certainly learn useful things from any
kind of interview situation. But theyre not contextual enquiry. Contextual enquiry has to happen
where the action is. So, you dont want your users to side-track you, take you to an office, you want
to go to their desk if thats where they do the work and speak with them there.
The second element is to do with partnership. And the idea there is often when youre doing this
kind of study, youll find that the person that youre observing tends to think of you as the expert
because youre doing this kind of research. And as a consequence what theyll do is youll find
theyll continually turn to you and say, Am I doing it right? Is this how Im meant to be doing it?
And theyll be asking you questions which convey the fact that they may lack confidence with a
particular programme or software that theyre using. Now the one thing that they are an expert in is
their job. So the idea is to try and subvert that way of thinking and treat the user as the expert. And
the user is an expert in one thing. The way they do their task with this particular system. So one
way you can achieve that is to say, Well, lets imagine that Im an apprentice trying to learn how to
do your job. Teach me how you go about your job. Tell me the way you go about doing it. And that
prevents you being seen as the kind of the white-coated expert and means you get more realistic
data from users.
The third step is to do with interpretation. Now, when youre observing in a contextual enquiry,
youre going to see lots of different things, and inevitably youre going to start jumping to
conclusions when you see thing. What you need to do is interpret what youve seen to check that
what youve understood is correct. So, for example, a while back I was working with a client
studying their intranet and there was a page of their website where people needed to fill in a form
in order to justify foreign travel. They needed to say, I dont know, a couple of hundred words to
explain why they needed to take a business trip to Paris. What was the business justification for it?
And I noticed that this one person would write the justification in and then when they got to the
end they would copy it and then theyd paste into Microsoft Word. And I was puzzled as to why
they did that. Why do you think they did that? My initial assumption was perhaps they were doing
a spellcheck or maybe a word count. So I made a note that it was probably a spellcheck but I need
to check that with the user afterwards. So afterwards I spoke to the user and said, I noticed when
you were doing the task that you pasted it into Microsoft Word. Was that to do a spellcheck? To
which the participant replied, Oh no, the system is so flaky, often Ill submit the form and the page
will hang and I wanted to make sure that I didnt lose my work, so I put it into Microsoft Word just
as a way of keeping it safe. So, I needed to interpret the observation I was making there.
33
David Travis
And the fourth step is to do with focus. Clearly theres lots of things you can observe when you go
into a users home, or a users workplace and in order to narrow down all of the possible things you
can look at, you need to define a point of view that youre going to take. So frequently this is done
with whats called a hunt statement, H-U-N-T, a hunt statement. It takes a form of something
like, Im going to research X so that I can do Y, for example, Im going to research how doctors
use laptops on the job so that I can design a handheld device for them.
34
David Travis
2-05 The Remote Control - Activity

So Im going to talk about these steps in a bit more detail, but now Id like to show you a video of a
contextual enquiry. Now, if I showed you a recording of an actual contextual inquiry, frankly you
would fall asleep because they tend to be fairly boring if youre not involved in the project.
It would show many hours of watching people sit in front of a computer or sit in their homes and
do stuff as they carry out their tasks.
So instead I thought I would show you something which is a bit more engaging that captures the
same essence of context. Its actually going to be a clip from the Osbournes.
Youll remember earlier that I asked you a question: If a documentary crew spent a day following
one of your users, what would the camera see and hear?
In this short video clip, we are going to do just that: youre going to see Ozzy trying to use a home
entertainment system. To set this up, lets imagine that we work for a firm where were trying to
redesign a home entertainment system.
What Id like you to do is to watch the video and identify at least five things that you learned from
observing Ozzy in context. Heres some questions to bear in mind:
What stuff did we learn that we probably wouldnt have picked up if wed interviewed him in the
street or even if we brought him into our office to run a usability test?
What specifically is it that we pick up by going into his home and observing the way that he works?
Before you start, grab a pack of sticky notes and a pen so you can write down your observations as
you go. And as you watch the video, write one observation per sticky note. Then come back and
well discuss the things that I observed and well see what commonalities we have.
By the way, were going to come back to this idea of making observations on sticky notes, so its
worth practising the method. The golden rule is to write down one observation per sticky note. If
you can, use a Sharpie or a marker pen rather than a pencil or a biro because then you can see your
observations from a distance. Thats important when you want to share your findings, as youll see
later.
35
David Travis
2-06 The Remote Control - Debrief

So how did you do? How did you find that activity? Well, I dont know which observations you
made, but heres some that I came across.
Note also how Ive expressed these as observations: an observation is something the participant
says or does. This is different from an interpretation, which is the your belief about the cause, no
matter how sure you are.
The first one was that the developer of the system seems to have an entirely different view of the
systems ease of use to Ozzy. One of the things he said was, We didnt give the owners any written
instructions. We give them the remote controls and then the owners figure out by themselves how
to work it. Thats how easy it is. Clearly Ozzy didnt share that kind of perspective.
I also noticed that Ozzy thumps the remote control, so obviously it needs to be robust. Its unlikely
he would have done that out of context, would he? Lets say that we got him into our office for a
usability test. I couldnt see him whacking the remote control, even with Ozzy being Ozzy.
Heres another one. When hes stuck with technology I notice that Ozzy calls on Jack for help. He
didnt try and troubleshoot it himself, read a manual, go on the internet. He called a local expert.
Thats an important observation again that we would have missed if we hadnt gone to context.
Heres a fourth one. At first Ozzy refers to the system as a computer not a television. And he says
you need computer knowledge to turn it on and off. So were getting some kind of insight into the
mental model that Ozzy has of the system that hes using.
And a fifth one that I observed was that when Jack comes to fix it, Ozzy didnt really listen. He
plays with a cat. Hes not interested in the technicalities of how these things work. He just wants a
system that works. So hes not got the kind of interest in technology that perhaps some of the
audience for this product might have.
And heres a sixth one, just as a bonus. The remote control I noticed was big and when Jack was
using it he tried to balance it on his knee. Now maybe it would benefit from a grooved base to make
that easier? I mean, ideally wed have a small device, maybe even a smartphone app, but if were
going to stick with this kind of product, as least we need to make sure that people can balance it on
their knee.
Another observations that I made was the Weak signal error. That was a real world error. Its
something we observed only by going onto context. I also noticed that Ozzy was drinking lots of
cans of soda near the device, so perhaps it needs to be waterproof. I also noticed that the system
seems to control other devices in the house, like a shower, but Ozzy thought of it as a TV remote,
not as a home controlling device.
So, I hope you got some of them and maybe you got some others as well. If you got some that I
didnt get, please share them in the discussion section of this lecture.
Finally, what would you say are the advantages and disadvantages of this approach to user
research?
You can see that its an approach that gives you rich and detailed data. A field visit lets you observe
realistic behaviour. You also arrive at an interpretive understanding, because the observer is
present in the same location. Its also cheap to carry out (theres no special equipment needed).
However, field visits tend to have small samples with no experimental control. Theres also a risk of
bias: observers may see what they want to see. And finally, field visits take time: you cant just pop
in and out.
36
David Travis
2-07 Practical site visits, step 1 - Users

In my experience, there are 5 habits that great user researchers engage in when they do site visits
like contextual inquiry.
Their first habit is that they make sure they visit the right users.
This diagram shows that the best users to involve are the people who really use the system.
Although its easier to ask people at the next desk, or people who say they speak for users, this
approach will come back to bite you later.
This is because you need to discover (not just validate) user needs. If you speak with stakeholders
or other non-users, theyll be complicit in making you believe you are working on the right thing.
Now you may get some user needs from stakeholders or managers, but you wont get them all. And
as weve already discussed, your design team never accurately represents your end users. So treat
any user needs you get from stakeholders or the design team as assumptions.
So you need to get to users, but how many?
If the people you want to interview divide into clear types, interview about 5 of each type.
If you dont know what different types of user there are, start by interviewing about 10 people, then
do a quick review of your data. Youll soon begin to see different types emerge based on peoples
different experiences.
Whatever you do, make sure you recruit a good mix of participants, and not just by age and gender
and what operating system they use. You need to get a mix of different circumstances. So take your
system and ask: what is it about my users circumstances and skills that might make the system
difficult for them to use?
This means you need to think about the different sorts of people who use your system. How might
their needs and behaviours vary? Thats where you want to focus.
Depending on the complexity of the experience, each interview can take between 60 and 90
minutes. You should be able to fit 4 interviews into a research day.
37
David Travis
2-08 Practical site visits, step 2 - Focus

The second habit I see in great user researchers is they agree the focus of the field visit long before
they leave the office.
The reason you need to do this is because, when you make a visit to a user in the users context,
theres a lot to observe. So much in fact that its sometimes likened to drinking from a fire hose. So
before you carry out the visit, you need to agree the focus you need to zero in on the goals of the
visit.
Heres a great technique for doing that. Get your design team in a room. Give each person a stack of
sticky notes and a pen and say, Imagine, outside the room, weve got a bunch of our users and they
have terrific insight into their needs, goals and behaviours. They will answer honestly any question
we ask of them. What Id like you to do is to take this stack of sticky notes, and on each sticky note
Id like you to write down one question that you are burning to ask the user. What question you
want them to answer for you?
I give the design team five minutes to do this and then Ill take each of those sticky notes, stick it on
the wall and then well arrange those sticky notes into groups that make sense.
The great thing about this approach is that I learn not just the focus, but I also get the specific
questions I need answers to because the design team have written them for me. This technique is a
great way to get consensus and to make sure youre asking the right kind of questions.
The point is, to create a focus for your research you need to imagine the most useful, actionable
research results possible.
What would the research tell you?

How would you use the research?
What are the key assumptions you need to validate?
What are the biggest risks to the success of your project?
What keeps you awake at night?
What information would help you make decisions or prioritise your efforts?
I mentioned that I arrange the sticky notes into groups that make sense. Heres how I then use that
information to actually structure my observation and interviewing sessions. Rather than write
down a long list of specific questions that I want answered, I use them to create prompts.
So, for example, say that one of my sticky note groups is to do with collaboration. Ill write that
word, collaboration, as one of these prompts as a reminder that I need to cover that area. That will
remind me to cover who they work with, if they work on their own and what they share with other
people.
This is a very different approach to going into an interview with a long list of survey-like questions
that you fire at the user, one after the other. That approach doesnt work for contextual inquiry
because you quickly hijack the session and turn it into an interview rather than an observation. By
listing these prompts as areas that you want to cover, you can more easily switch between
interviewing and observation.
Contextual inquiry is a skill that takes work to develop. Youll find that you start by obsessing over
the right questions to ask. But as you become more experienced, youll realise its more a way of
being. Dont think of contextual inquiry as a Q&A but as a framework for observation and for
eliciting stories.
Now its true that youll still need to ask some questions. The important point is to keep the
questions open. Dont ask questions that can give you a yes/no answer (unless you need to clarify
something specific). Instead, you want to ask questions like, Tell me about the last time you?
38
David Travis
Tell me about an experience youve had with? and so on. Things that allow users to talk broadly
about the way they achieve their goals.
Another story-elicitation technique that Ive found works quite well is to say to someone, Imagine
youre writing a manual for someone thats doing your job or doing this task, or whatever. What
would the main headings be in the manual that youd put together?
Feel free to inject some of these questions into your contextual inquiry but make sure that you also
focus on the bigger picture and spend time observing too.
39
David Travis
2-09 Practical site visits, step 3 - Recording

The next habit I see in great user researchers is that they record the sessions.
Unless youre an expert at shorthand, youll miss comments, phrases and some of the technical
language that the participants use. Even if youre great at shorthand, youll still miss intonation.
Recordings are so important for a proper, in-depth analysis that you should 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. This isnt cheap, but you need to balance the price against the time youve 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 youll make.
Some people like to video record their observations. Ive 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 ceilingmounted surveillance camera). But in an office space even a large office space such as a call
centre video recording participants is tricky.
First, 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. (The
senior manager may ask, Why are they doing this anyway?)
Second, video recording draws attention to the observation and changes the behaviour, with people
understandably anxious about how you might use the videos.
Third, commercial confidentiality and data protection issues mean that it just isnt feasible in some
situations, such as when a users personal data appears on screen.
Audio recording on the other hand is usually possible in most environments. Because its more
discreet, you dont 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: Ill be taking notes during
our interview, but if its OK with you Id also like to record the session as I cant take notes quickly
enough. I also make it clear how the recordings will be used. I tell people, The recording is just for
my purposes and anything you tell me will be kept confidential. Its also easy to pause the
recording if sensitive data gets discussed, like when a users credit card details are read over the
phone. When I get the transcriptions, I change the participants name along with any other
information in the transcript that could identify the participant.
The other important thing that great researchers do is to take photographs. So, for a second, what
Id like you to conjure up in your head is, what do you think Al Gores office looks like? Al Gore, the
ex-vice president of the United States. Try and imagine what his office looks like because Im going
to show you a photograph of it in a moment. For example, what does his computer look like? How
big is the screen that hes using? What about his desk? Whats on his desk? How about a book, is
there a bookcase there? If so, how are the books arranged in the bookcase? Any ideas? Well, now
let me show you the way it looks.
This probably challenged the initial idea you had about the way his office might look. Did you think
that we would have three monitors? Did you think that the desk would be covered in reports and
manuals and other documents? The point is that weve preconceptions about the way things will
be. Often theyre wrong. So when you do a contextual inquiry you want to get photographs to make
sure that you can communicate the context.
You should 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.
40
David Travis
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. One way I try to diffuse the question is
that Ill show the user a list like the one here. This makes it clear that my default position is that I
will be taking photographs I need to do this to do my job properly. But I allow the user to tell me
if there are any things that are off-limits.
If you really, really cant take photographs, you can always make a sketch. These dont need to be
works of art, but useful prompts to remind you about the relations between people and things in
the environment.
41
David Travis
2-10 Practical site visits, step 4 - Notetaking

The next habit I see in great user researchers is that they take great notes.
Now, although youre going to be audio recording the session, you cant use that as an excuse not to
take great notes. The audio recording saves you from having to write extensive verbatim
statements, but it wont tell you about the participants behaviour or their environment. Also, you
may be in an environment where you cant audio record the sessions. So youve got to get into the
habit of taking great notes.
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
respondents 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.
If you find that your mind goes blank and youre 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. As Ive mentioned, you
should 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 users pet peeves? Who else collaborates in the activity?
Objects are the artefacts that people interact with. What physical items does the participant
interact with? What software does the participant use?
Users of course are the people providing the behaviours, preferences and needs. What are
the participants goals, attitudes and motivations? What are the participants capabilities
with the domain and with technology? What education and training do participants have?
AEIOU is just one of several frameworks for making ethnographic notes, but its the one I find most
useful for user experience observations.
Heres another issue with notetaking.
How often have you turned to your notes a week after taking them, only to realise that you cant
remember what on earth you were thinking?
This experience is even worse if youve observed 4-6 people in a single day, as they all begin to
blend into one another. Because of this, you should always schedule around 15 minutes after each
participant to summarise what you have learnt.
So heres a practical tip. To make sure you create an accurate summary, try using a standardised
form. Youll probably 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 youve made. This image shows an example of a form I use and Ive provided a copy of this in
the download pack for you to use or copy as you see fit.
Obviously, youve got an area at the top for writing down some general stuff about the participant,
the date and so on. But heres the other things that are important to write down.
42
David Travis
An overall description of the participant and the environment: that will give you some clues to the
values, priorities of the participant and where he or she works.
On the top right youll list the main learning points, the stand out observations; say three of them.
At the bottom left and bottom right, what youll write down is the ways in which the participant is
similar to or different from other participants. And youll use that later, when youre trying to work
out where the groups are in the population in order for us to develop personas.
Finally, Ive already touched on this notion of observation, but as were talking about notetaking,
its worth making the point again. In your notes, you need to clearly distinguish between
observations things you saw or heard and your interpretations. An observation might be be a
direct quotation, a user goal, a user action, a pain point or anything that surprised you.
43
David Travis
2-11 Practical site visits, step 5 - Affinity Diagramming and User Story
Mapping
One final habit I see in great user researchers is that they know how to analyse the data.
Most people are familiar with the basics of analysing quantitative data: for example, calculating
averages and variance and so on. But the data you collect in a field visit is qualitative and needs a
very different approach. Theres an approach to this that I see great user researchers use time after
time. Heres what they do:
First, they get familiar with their data. They read through the transcripts. They look at the
photographs or drawings they made. They try to get back into the place they were in when they dod
the field visit.
Then, they identify the significant observations. They ask, What happened?
Now they move onto interpretation. They ask, Why did it happen?
The next step is to use a technique called affinity diagramming to identify and cluster the themes in
your research. Ill talk more about that in a second.
The finally, they develop some kind of description of their results. They summarise their data so the
design team can take action on it.
I mentioned a technique called affinity diagramming or affinity sorting that you can use to identify
and cluster the themes in your research.
This is such an important method for user experience designers than I want to turn to it now.
Typically, affinity diagramming is done in a room like this: each of the observations youve made
are written down on a sticky note. You then stick those notes on the wall and get the design team,
the other people that were part of the observation, and anyone whos interested to group them. The
aim is to try to get an understanding of the mental models people have, the tools theyre using, the
terminology theyre using, the user needs, the workflow. Youll get an overview of the way people
achieve their goals right now.
A good affinity sort is an incredibly valuable resource. Its something that youll go back to time and
again. One particular way you can organise your affinity sort is to present it as something called a
user journey map. Let me show you some examples.
This shows four different user journey maps. You may also hear these referred to as user story
maps. The precise term doesnt matter, but just dont get user story mapping mixed up with agile
user stories. Well be talking about those later in the course.
A user journey map shows the sequence of steps a user goes through to achieve their goal. You can
use them to display the current journey and you can also use them to show the new journey that
youre designing.
Also note that these user journey maps arent beautifully crafted deliverables. They dont need to
be. Their job is to make sure that everyone on the design team has a shared understanding of the
context of use. They will probably change over time as you collect more data, so this kind of
representation is in fact an advantage.
Heres another example.
This is from Lego of all people and its quite literally a user journey map. It shows the user journey
of someone flying from London to New York. Notice how they have not just arranged the steps in
44
David Travis
the journey but they have also added a kind of emoticon to show positive and negative emotions
related to those experiences.
So how do you go about building one of these user journey maps?
The process is fairly simple. Start with a set of sticky notes that contain the observations you made
during the site visit. Each sticky note contains a single observation.
Working as a team, group the observations into common tasks that people carry out.
Next, label each of the tasks with a shorthand name. This doesnt need to be the term that users use
to describe the task as its just your own shorthand.
Now organise the tasks in a set of vertical columns, showing tasks that occur early in the experience
and tasks that occur later.
As an optional step, you may want to group some of the tasks together into phases that make sense.
In this example, the stages of an online transaction have been defined as Anticipate, Enter,
Engage, Exit and Reflect.
The titles will be specific to your domain. So it could be:
Passive looking - Active looking - Deciding - Purchasing - Experiencing

Discover - Investigate - Prepare - Apply - Use
At this point, we have an overall view of the user experience that we can use to see the big picture.
This is often sufficient for the team to build a shared understanding of the user research.
45
David Travis
2-12 Presenting results as empathy maps and storyboards

The user journey map is just one way you can present your results. Lets quickly look at some other
methods.
The first is an Empathy Map.
Ask your design team to try to get inside the mind of your user and think about their sensory
experiences. What do users see when achieving their goals? What do they hear? What are the pain
points and what do users hope to gain? For some of the areas, particularly Think and Feel you
might have to infer a bit based on your notes and your recollection of the observation.
This kind of representation helps you go beyond a customers demographic characteristics and
develop a better understanding of their environment, behaviour, concerns and aspirations, and Ive
included a downloadable version of this that you can use to summarise you findings. You could
print this really big as a poster and use it as a way to organise the observations youve written on
sticky notes.
A related way of presenting your research is to develop personas. Ill be talking about that more in
the next section.
Yet another way to summarise the users journey is with a storyboard. The great thing about
storyboards is that they keep you focused on the users context.
Anyway, I hope this has give you some ideas of how you can present the data from your user
research.
46
David Travis
2-13 Guerrilla techniques for user research

If youre not able to do contextual inquiry for one reason or another, its going to be very hard for
you to do proper user-centred design. Its not absolutely critical that you do contextual inquiry the
way Ive described it: just so long as you visit your users in context, thats the key thing: you do
need to go and visit your users. You need to understand them better. You need to get face to face
with them.
But I do understand that there are some situations where that might be problematic, and I wanted
to talk about some other methods which arent replacements for contextual inquiry, but if you cant
do anything, you can at least do these.
So the first is a diary study. Do you know a few users (or potential users) who you can contact by
email? If so, give them a private link to a blog where they can record their thoughts, experiences
and impressions about the domain youre designing for. Send them a reminder email or a text
message at the same time every day as a prompt to complete the blog.
Similarly, you could ask people to use their camera phone to photo-document a workday or leisure
day and get them to upload their images to Flickr or a tumblr. For example, one client of ours who
runs a chain of clothing stores recently asked young women to photograph a typical week-end
shopping expedition. The photographs that were taken included images of the clothes but also
included images of their friends mugging for the camera, pictures showing what they had for lunch
and pictures of storefronts and the shopping mall itself. Many of these images emphasised the
social context of shopping. This approach can give great insights into what matters from your
customers perspective and help generate design ideas for meeting those needs.
By the way, the picture here, Mass Observation Day-Survey, Ive used that because actually, back in
the late 30s in the UK, a particular technique called mass observation was launched which was a
way that Government in the UK wanted to document the feelings and behaviours of the UK
population. It was just after King Edward VIIIs abdication and they wanted to collect anecdotes,
people in the street interviews and so on. And they asked ordinary people to keep a diary which
they then sent back to mandarins in Whitehall. And its a really interesting resource.
Mass Observation was a United Kingdom social research organisation founded in 1937. Their work
ended in the mid 1960s.
Mass Observation aimed to record everyday life in Britain through a panel of around 500 untrained
volunteer observers who either maintained diaries or replied to open-ended questionnaires.
Mass Observation began after King Edward VIIIs abdication in 1936. The projects founders
wanted to document the feelings of the population by collecting anecdotes, overheard comments,
and man-in-the-street interviews on and around the Coronation of George VI.
You still need a focus: e.g. giving special attention to moments when they integrated technology
into their routine. For example: How often during a week do people typically use the web browser
on their smart phones, and what situations drive that usage?
These techniques are helpful in gaining intimacy and probing matters of personal and emotional
relevancy.
What are the risks with these approaches?
People may not be conscientious
People may lie
If your product is screen-based, contact a few users and ask to set up screen sharing using a free
service like Skype or a paid service like GoToMeeting. Ask users to share their screen with you and
give you a tour of their desktop. Ask them about the common tasks they carry out and ask them to
47
David Travis
demonstrate how they do those tasks. If they have a web cam, see if you can get them to detach it
and give you a brief view of the office or home environment.
Pop-up research, sometimes called guerilla user research, works best with applications and
research topics that are relatively short and conceptually simple. Its also a useful approach to use
with applications that have a broad audience with lots of niche groups and edge cases.
You can run pop-up research nearly anywhere, such as a local library or coffee shop.
And heres yet more ideas.
Look at the questions and comments posted in your companys support forums and see if you can
detect any patterns. Can you identify a common set of goals across users? Does it look like there are
different groups of users with different kinds of goals? Are there parts of the system or product that
people frequently struggle with or complain about?
A second approach is to identify the customer-facing channels in your organisation like telephone
ordering lines, support lines or retail stores and listen in to the calls people make. How is their
issue handled? What are the key areas of improvement?
And you can always pretend youre not looking. If your company has a physical presence such as a
retail store, walk in and watch the way customers handle the product or talk about it. What features
do they mention? How do they talk about it being used? What other products do they compare it
against? For extra points, engage customers in conversation: tell them that youre interested in this
product too and ask them what they see as the strengths and weaknesses.
Just to emphasis, these arent replacements for actually getting face to face with your users, but if
youre really, really stuck and can do nothing else, then try these. But ultimately, Id like to think
that youre going get out of the building and find out more about your users.
48
David Travis
2-14 Three myths about field visits

I just want to wrap up by addressing three myths about this kind of user research that you might
hear.
The first is that you can discover user needs with surveys and focus groups. I hope Ive made it
clear in the earlier lectures why you cant do that. Its because what people say and what people do
are different things. Instead, we need to focus on behaviour and thats why you absolutely must do
field visits.
The second myth is that your job as a user researcher is to learn about users.
Its not.
Your job as a user researcher isnt to learn about users but to help your team learn about users. You
are a facilitator as much as a researcher. You want your research findings to travel through the
organisation.
An example of the consequences of this way of thinking is where firms delegate their user research
to an outside agency. When you do this, it prevents critical knowledge about users from being
embedded in the organisation. You really want to keep this stuff in-house.
One way you can prevent this from happening on your own project is to encourage everyone on the
team to get their exposure hours.
Jared Spool has introduced us to this notion. His research shows that the most effective design
teams spend at least two hours every six weeks observing users (for example, in field visits or
usability tests).
Ive recently been working with a really effective agile team and Ive encouraged them to adopt this
idea by collecting certain metrics.
That number on the right shows the percentage of the team who have observed a user session in
the last 6 weeks. This makes sure people are getting their exposure hours.
The other metrics here show the number of users tested since inception (this makes sure that there
is a continual focus on users) and the number of days elapsed since the last usability test (this
ensures that the project is practising iterative design).
The third myth is that field visits and usability tests are interchangeable.
They are not.
Some people confuse the two. I dont want you to be that person.
Well be talking about usability testing later in the course, but keep this information in mind.
A field study focuses on the big picture: how people currently solve the problem, the
workflow across multiple channels, their behaviours, needs, goals & pain points.
In contrast, a usability test focuses on how people do specific tasks and the problems they
experience when using a particular system.
49
David Travis
3-01 Why the average user doesnt exist

So now I wanted to show you some of the things that you can do with the results from your
contextual enquiry, how you can apply it to produce artefacts which will help you do design better.
Ive titled this part of the training, how to get niche quick.
So, here we are in the overall scheme of things. Were still in building the context of use. And now
Im zooming on that first box there, building a user profiles. And heres a question I have for you.
First of all, think about the organisation that you work for. How does it define its target audience
for its website, or the product that its creating? What kind of language does it use to refer to its
users? Does it call them users? Does it call them customers? Does it break them down into some
kind of marketing segments? What kind of terminologys used at the moment to describe who your
users are? Think especially about when youre in a design meeting; what kind of language is used?
Most frequently youll find design teams use the term user: sometimes customer or client.
Unfortunately these terms are a bit generic. And theres a problem with generic titles, because
when youve got a generic name for your end user, they can be stretched and pulled in lots of
different directions.
I dont know if any of you have got kids, but when my kids were young, they had a toy like this. Its
a kind of gel-filled toy called Stretch Armstrong and it can be pulled in all different directions.
Call me boring, but one day they were playing with this and I thought, Do you know, thats a good
metaphor for the user on a design project being pulled in all different directions.
Well, the fact is that real users arent elastic. Theyve got specific requirements based on their goals,
capabilities and contexts. Because eventually, if you keep pulling Stretch Armstrong too far
even Stretch Armstrongs head falls off. You can pull it too far.
And thats the same with users. You can stretch them so far to the point where theyre not
representative anymore of who it is youre designing for.
So, lets look at an alternative way of doing it. What would you get if you designed a car that pleased
every possible driver? Well, those of you that have seen that episode of the Simpsons might
recognise this as being very similar to the Homer.
To satisfy a diverse group of users, it might seem logical to design your system to be as broad as
possible in its functionality, because that way most people can use it.
Now that logic is flawed because it turns out the best way to design for a large, diverse group of
users is instead to design for a specific type of individuals who has got specific needs. Think for a
second: imagine that you extend the functionality of your system so that theres something in it for
everyone. A consequence of that is that any specific individual, any particular person is going to
find stuff in it thats not really relevant to them. That means there will be stuff thats going to
clutter the user interface for them and increase the cognitive load and navigational overhead.
So, heres a question for you. I want to ask you a series of questions about your own background
and tell me whether or not Im spot on.
So, are you 40 years old? Are you married with two children? Do you have a 37 inch waist? Do you
weigh 13 stone? Do you have size 10 feet? Do you have sex 8 times a month?
Maybe as I went through those statistics, some of them did apply to you or perhaps to someone
that you know. But I can be confident that most of them didnt apply to you and certainly, if I went
through this full list of the statistics of Mr Average, then wed find that no-one on this course ticks
all of these boxes.
50
David Travis
The reason I can be so confident is that Ive taken this particular clipping from a I nearly called it
a newspaper there, its actually the Daily Mail, which is a British tabloid newspaper. However, my
understanding is that the data is based on robust results from national statistics so the data is
reasonably accurate. But again, the reason I can be so confident is because the journalist that wrote
this article did try to find this person, Mr Average, who ticked all of these boxes, so that the Mail
could put a photograph of him against the article. But the journalist couldnt find anyone. Lets stop
for a minute. What were saying here is: the average person doesnt exist. These are the statistics of
the average person but it was very hard to find someone that ticks all of the boxes. In the same way
that the average person actually has 1.9999 legs, sometimes, averages like this arent useful in
helping use understand a population.
The reason for pointing this out is that if Mr Average doesnt exist, whats the point in designing for
him? Or for any average user? Whats the point in designing for some Frankenstein monster
thats some kind of amalgam of all the averages of all of the statistics that you have, when that
persons mythical? The average user is a myth. So, why not instead design for a specific user? A
specific user with specific goals? Specific interests? Specific motivations in a specific context?
In fact, theres a quotation from the comedian Richard Pryor where he says, I dont know the key
to success, but they key to failure is trying to please everybody, and Im sure that this is as true for
stand-up comedy as it is for design as well.
The problem with everybody is that in order to reach everybody or humour everybody or sell to
everybody, you need to so water down what youve got, that you end up with almost nothing. And
surprisingly, designs generated using a methodology called personas, which is what I want to talk
about now, have got a much wider appeal than designs that try to cater for everyone.
And the reason for this is that users are much more effective when all the tools they need for a task
are close at hand, and none of the tools that they dont need is in the way. Thats why you probably
keep your food mixer in the kitchen and your saw in the garage. Youd never use a food processor to
build shelves. And hopefully your baking efforts dont require a saw to cut through the bread that
youve created. The same basic idea is true with user interface design. People who have clearly
distinct tasks should have their own sets of tools and not be forced to stumble over everybody
elses.
51
David Travis
3-02 Introduction to personas

So if we go back to that analogy that I was drawing earlier which incidentally Ive taken from a
presentation of Alan Cooper, hes the grandfather of personas, hes the person that invented them.
What now if we picked several people and designed a car to meet their specific needs?
So, we might have Rosie, for example, she shares the school run with other mums, shed like
something like a people carrier where she can just slide open the door and the kids can come
tumbling out.
Weve got Phil, he runs his own landscape gardening business. Looks like he dresses up as a
cowboy in his spare time as well. But anyway, hed like a truck that he can use to throw bits of old
tree on the back and take those away from the landscaping premises
And then theres Nick, hes your kind of pre-recession, single, no kids, internet entrepreneur. He
likes to pose around town in a Porsche.
And so youll notice that these personas put a lot more constraints on our design and in fact,
theyre helpful because theyre constraining. In the same way that the user research we looked at in
the can opener evaluation helped us make easier decisions about what was best for each type of
user.
Personas clearly define who is and who isnt our target user for the product, and in doing that, they
make many of the design decisions for us. So for example, if our main persona doesnt have a Smart
TV, then weve got no choice. We cant create a design that will work only on a Smart TV.
So, lets summarise this personas approach.
Theyre short, engaging summaries of key customer groups.

They describe archetypes of customers, so theyre not averages.
Theyre not even a real customer. Theyre a stereotype of a customer.
And personas have spawned a real industry. They started as a chapter in a book by Alan Cooper
and now there are books, websites, even conference tracks devoted to them. And the reason for this
is because theyve proven to be incredibly useful. There are a handful of techniques in user-centred
design which tend to be used by virtually everyone that works in the field. Personas is one of them.
So theyre obviously worth examining in a bit more depth.
So, lets look at some examples of personas. What Im trying to do here is just give you a feel for the
genre, so, dont worry too much if you dont understand the detail of these particular personas for
now, just try and get an understanding of the way they feel and look. You can think of this as the
cast of characters for your product.
Take this particular set these are the Adam and Eve of personas. These were the first ever set of
personas created by Alan Cooper. Lets look at the key attributes.
So, first of all, youll notice theres a status designation. Obviously, a secondary persona is less
important than a primary persona.
Youll also notice weve got a photograph. The photograph acts as a shorthand so we can refer to
that particular user and should be reasonably representative of him. So, for example, this guy,
presumably spends a lot of time on the phone, otherwise there wouldnt be a photograph of him
with a phoned glued to his ear. Notice though these photographs arent pictures of real users. These
are perhaps ClipArt or actors that have got something in common with the way your users look.
You cant really use real photos of real users in personas because of data protection issues.
Weve also got a name. Now before you think, A name? This is bonkers! Why are you giving these
52
David Travis
people names? Well, to get some idea of valuable this is, play an exercise. Outlaw the word user
in all your next design discussion and insist that its replaced by the words my friend, my wife,
my daughter, my mother or myself. Suddenly it becomes a lot more difficult to say, It doesnt
matter that its crap, the userll have to put up with it, when you have to say, It doesnt matter if
its crap, my friend, my wife, or someone will have to put up with it. Unless of course youve had a
row with them that morning. And the reason is because adding a name, like adding a photograph,
helps us empathise with the user.
Youll also notice that weve got a quotation. The aim of the quotation is to capture the users key
objective, the key user need the essence of what that user is about. If we could summarise the
user in a single sentence, what would we do? What kind of phrase would we use? And we need to
do this using the language that the user would use.
Theres also a short narrative describing the user. The aim of the narrative is to capture some
background to the user so weve got a better understanding of who they are. It describes the users
context for us.
And finally, we have a list of key goals. And again, these are phrased in the words that the user
themselves would use. Now, its important that these goals are expressed from the users
perspective. First of all, notice that all of the goals begin with verbs, so theyre kind of doing
words. These are actions that the user is carrying out. But also, theyre expressed from the users
perspective. So if I was building some new software for a retail store, a feature of that system might
be: the system supports EAN13 barcodes. Well, that doesnt mean anything to the user. For the
user, their goal is to sell items at point of sale.
Theres an important difference here that I hope youre able to spot. The first approach describes
an attribute of an object. The second describes an activity done by a person.
Look for goals that start with or include an action verb; thats a good sign. When thinking about
how people will use your software, it helps to indicate how it will be used rather than how it might
look or the details of its implementation.
Well, lets zoom in on one of those personas. This is Eleanor Montgomery. Shes an HR
administrator. But lets look again at the details. Were looking at the high level. Weve got a
photograph, a quotation, weve got a narrative, weve got a list of key goals, and I guess one
important question here is, you know, what makes her the primary persona.
If I jump back to the previous slide, youll notice that weve got a series of personas here. What is it
that necessarily makes Eleanor the primary persona?
Well, imagine we had three personas. Lets call them, Harry, Hermione and Ron, for arguments
sake. If we design the interface for Harry, Hermione and Ron might not like it. If we design the
interface for Ron, Harry and Hermione wont like it. But if we designed the interface for Hermione,
Harry and Ron will be OK with it. In that instance, wed pick Hermione as our primary persona. So,
while the resulting design ultimately needs to satisfy all of the personas of the system, you should
start by trying to satisfy the needs of just one: thats your primary persona. So you should pick a
primary persona thats mainstream and has the customer behaviours that are hardest to satisfy. So
to discover our primary persona, heres some steps you could go through.
First of all, go through each of your personas and ask, Do I have to enable this person to succeed?
If this person cant always use my system successfully, is it a failure? If you answer Yes, to that,
the chances are this is going to be your primary. If not, you can discard them.
Then start comparing your personas in pairs. Consider their contexts of use, imagine that theres a
solution that works for each persona in their own context. You dont for the moment have to
visualise how your solution will work just yet, but simply ask, Would a solution designed for
persona A also let persona B achieve her goals? and vice versa. Or will a solution designed just for
B, also work for A?
53
David Travis
And if you find a solution for one persona that doesnt work for a different persona, but it will work
the other way round, you can discard the persona with the less widely useful solution. Theyre
clearly not a primary persona.
And if you find that neither solution is applicable to the other, keep both personas because they
might both be primary. The idea is you keep comparing different pairs until you can honestly say,
My solution must work for all of these, but none of them can succeed with an interface designed
for anyone else other than the primary persona that Ive chosen.
Now one common misconception is that having a primary persona means you exclude everyone
else whos not in that persona group. Thats not the case. The primary persona is simply the main
design target. Youll make sure that any design decisions consider their needs first, but youll still
try to accommodate the other users, as long as it doesnt affect the user experience of the primary
persona. And after creating a design that satisfies the needs of the primary persona, you can layer
on support for the unmet needs of secondary personas.
54
David Travis
3-03 A persona case study

So, so far weve covered a lot of the theory to do with personas. What I wanted to do now was cover
the practice of developing personas. And to do that I want to go through a case study to show you
how we derive a persona from doing all of the user research and so on that weve been talking about
so far.
So, to do that, lets have a case study.
Lets imagine that were designing a mobile app thats aimed at walkers, people that go hiking. And
our initial thoughts are that this apps going to allow users to do a couple of things, such as
download walking directions and share their route on Facebook or other social media.
We may discover other things as we do the research, of course, but initially thats what were
looking at.
And we speak with our marketing department, and they say, Well, based on the research that
weve done, we reckon there are two groups of users: Treksperts, these are experienced walkers
who want to discover new routes; and active retirees, these are keen to stay fit and visit new
places.
Now, theres something important about this information that weve got from marketing that we
need to consider, which is that on first glance you might think that marketing and user experience
are actually very similar because theyre both interested users. But really, thats about as far as it
goes. If you work in marketing, youre interested in selling to people: you want to know how to
influence people to buy your stuff. But if you work in user experience, youre interested in the way
people actually use your product. This is a not-so subtle difference and so dont be surprised if find
differences in the eventual user groups that we have when we do our persona analysis.
To begin with though, lets go out and well speak with some people who fit these two particular
categories: Treksperts and active retirees.
Im kind of smirking as I use that word Treksperts and thats partly because it kind of fits the
marketing terms that they come up with. For example, I once had a marketing guy with me on a
home visit. I was doing some research for an organisation and it was interesting because he seemed
incapable of not thinking like a marketing person. So, for example, they had a very unusual kind of
dog in the house and Id never seen that kind of dog before. It was actually called a Blue Heeler and
the marketing guy said, Oh, thats an unusual dog, what brand of dog is it? So I had to point out,
actually, its not a brand, its a breed of dog.
This is what I was saying about market research being very different from user research. Market
research confirms users want something. But user research determines how users want that
something to work.
So, for example, market research with car buyers might well show you that 10% of people who buy
a 4x4 have two children under the age of ten, or that safety is an important attribute. But we need
user research to tell us what a typical family uses their car for, what knobs theyre most likely to
fiddle with when driving, and what things they bring along to keep the kids entertained in the back.
So market research answers the question, Who are our users? but user research answers the
questions, What motivates our users? and What critical functionality do they need? The
traditional customer segmentation models from marketeers dont provide the key information
about users goals, attitudes and behaviour that is required for eective interaction design but
user research does.
At the end of the day, to be honest, marketing people dont really care whether people use the
products or not. What theyre interested in is if they can sell more of the product. So long as people
come back and keep buying it, then theyre quite happy. But in contrast, if you work in user
55
David Travis
experience, you would have been a complete failure if people dont end up using your system after
youve deployed it.
So, weve gone out and weve initially used our two marketing segments to recruit participants. And
Ive put some simple demographics about those people on this particular slide. In this case study
Ive put together, there are a relatively small number of participants that weve included. We would
want to include more than that in a typical persona study. Ill give you an actual number in a
moment. But the reason Ive got a small number here is simply to make the exercise easy to
explain. With more than about 10 people on the slide, the text gets too small to read.
So, we go off, we do our contextual inquiry, we do our site visits. We go out with them as they go
hiking. We literally go out walking with them. In the process, we look at the way they use their
current technology, which could just be a map, or it could be some kind of smartphone app that
they use. But were with them, we are actually in their context.
The next step is to return to the office and do some analysis on the data.
56
David Travis
3-04 A persona case study, continued

So we return to the office and we do some analysis on the data and we discover that there are two
key dimensions that seem to matter.
One dimension is their experience with rambling and hiking. We get some people who are
experts, obviously, theyre our treksperts that we identified earlier. And we also get people that are
novices. But theres a wide range of novice behaviour. Some people are almost complete novices,
like P8 the P here stands for participant, by the way. And weve got P6, whos close to being an
expert in terms of his experience with rambling and hiking.
And then we notice another dimension which is familiarity with technology. And we notice we get
some people that are tech experts and some people that are tech novices. Now, the absolute
precision of a users location on these dimensions isnt that important. What matters is their
relative position to other users.
What I could do is plot this on a 2x2 diagram instead, so using the same data as before, with the
same axes experience with rambling and hiking and familiarity with technology and now what
Ive done is Ive plotted them against each other. And its not too farfetched to say that it looks like
theres four user groups here.
One group thats got low familiarity with the technology and low experience with rambling and
hiking.
One group with low familiarity with technology but a lot of experience with rambling and hiking.
Another group has got a lot of familiarity with technology, but not a lot of experience with rambling
and hiking.
And then a fourth group who are high on both dimensions.
The point is that now, with a persona analysis, well convert these into real people.
So now weve got four different user groups that will become our personas. Note how each persona
here isnt a single participant in our study. The persona is based on a cluster of participants.
So, lets start off at the top right. Lets start off with someone were going to call Jennifer Wright.
Jennifer takes part in geocaching and about once a month she and her friends walk in locations like
Exmoor or Wales and she uses her GPS enabled phone to navigate to a specific location to find a
hidden container. She has an iPhone and has been universally disappointed with the apps that
claim to support geocachers.
Weve also got a list of goals, like see a map of her location, even in areas without mobile coverage,
which often happens in places like Exmoor or Wales. And save tracks and paths with information
of distances, speed and other details. And she wants to share walks with friends over the web.
Weve also got a quotation for Jennifer which is, Whats the most interesting route to this GC
code? I dont really understand what that means, but Jennifer clearly does and its about her and
thats what matters.
And youll also notice that this is based on real data. Its based on data from participants 4 and
participant 2. So everything thats written in this persona is traceable to real data that weve
observed. Its not made up. And that is an absolutely critical component of personas. If you find
yourself making stuff up in a persona, youre doing it wrong. The stuff that you write in a persona
has to be based on a real data otherwise its useless. Its no different to designing for yourself.
Our second persona, were going to call him Michael Armstrong. Michaels been a keen walker
since he was a teenager. Hes particularly interested in ancient history and likes to take walks
57
David Travis
where he can explore historical sites, like an ancient burial mound or a stone circle.
So weve got a couple of goals for him. Discover out of the way sites with an interesting history and
annotate walks with notes and photographs that he can review afterwards.
His quotation, his key user need is, Whats the story behind this location? And again, youll notice
that this persona is based on real users. One, three, five and six. We can trace all of the claims in
this persona back to those users.
Our next persona is Robert Clapham. Hes based on seven and nine. His quotation, Where are
some great photo spots near me? captures the essence of what Roberts about. He took early
retirement last year from his job in tech support at a software company and hes taken up walking
partly to keep fit and partly to give him something interesting to photograph with is digital SLR.
Robert likes to explore product features and will spend time tailoring a device so that it suits his
needs. Weve also got a list of goals for him as well. Hes more of an expert tech user, and as a
consequence things like tailoring and personalising the devices functionality matters more for him
than it might do for other people, such as for example, our next persona, Kathleen McCrae.
Her quotation, Where am I and how do I get back to the car park? captures her user need.
Kathleen began walking with friends after her husband died and really enjoyed the social contact
that this provides. However, she gets frustrated with the people in her circle because no-one seems
to know how to read a map, herself included. She has an up-to-date phone but needs help from her
daughter when installing new apps. So her goals are to have alerts to let her know if shes following
the path properly and share walk with friends. And again we notice shes based on real data that
weve collected.
Compare those four personas with how people often talk about the user on a design project. I bet
you were a little more engaged than if Id just listed a table of data about user characteristics. Thats
because personas are data with soul.
58
David Travis
3-05 The benefits of personas

So, lets summarise some of the benefits of personas.
First of all, they make assumptions about our users explicit. Every design teams got assumptions
about who their users are. At least this way we can get those assumptions out in the open.
They also place emphasis on specific users rather than everyone: this notion of designing for
everyone or an average user doesnt help us do design as weve discussed.
And also in limiting our choices, they help us make better design decisions because we work better
when were designing within a constrained space than if we can do absolutely everything.
Most importantly though, I think, they engage the design development team. It makes everybody
aware of who the users are so theres no ambiguity anymore. Everybody can talk about who their
users are in an intelligent way, even for example, using their names.
Finally, I just wanted to say why I think personas are so powerful. And I think its because they
combine the nomothetic and the ideographic. Hold on a second, let me explain what I mean by
those terms. So, nomothetic and ideographic are terms coined by a philosopher called Wilhelm
Windelband to describe two distinct approaches to knowledge.
So with a nomothetic approach we derive laws or principles that explain objective phenomena. Its
what we mean by the scientific method.
But with an ideographic approach, we specify the specific situation to understand the effects of
context and often subjective phenomena. Its what we mean when we talk about a case study
method.
So for example, saying that 250,000 people died in some natural disaster, like an earthquake, is a
nomothetic description. But describing the consequences for a young boy whos lost his family in
the disaster, well thats an ideographic description.
So ideographic descriptions influence the heart whereas nomothetic descriptions influence the
head. Its why journalists use case studies to describe news articles and its why Stalin once said,
The death of one man is a tragedy, the death of millions is a statistic.
The reason I think personas work so well is because they combine both of these kinds of
approaches. Its a case study, but at the same time, its based on some laws or principles or
commonalities that weve discovered across users.
59
David Travis
3-06 The pitfalls of personas

I wanted to turn now to look at some of the pitfalls to avoid when were developing personas.
The first one is to make sure that the differences between your personas reflect the differences that
matter. Now, from a user experience perspective, the differences that matter are the behaviours
people have: their goals and their motivations.
Demographics is a lot less important. For example, age isnt really that important other than
adding a little bit of colour to the persona. Now, clearly, a very old person will have certain
challenges using a system compared to a very young person, but again, its not so much age thats
the important factor, its the fact that perhaps their vision isnt what it used to be, or their motor
dexterity isnt what it used to be. So the focus has got to be very much on behaviour.
Another example might be gender. Whether or not your user is a man or a woman will not have a
lot of impact on the way they will use your interface. There arent any gender differences that I
know of that indicate why we should design differently for men versus women. So demographics is
less important. As it says on this slide, whether your persona does or doesnt own a dog is irrelevant
to the use of your website, even though it may add a little bit of colour to the context. Now, of
course, if its a web site aimed at dog owners then perhaps it does matter. In which case, youd want
to know that your persona owned a Blue Heeler.
The second problem to avoid is to not have too many personas. So you want a relatively small
number because then that makes design decisions easier. If youre having to juggle a dozen
personas its going to become hard for you to make a design decision. And Ill give you a number in
a moment about how many personas I think you should have.
You also want to make sure personas are based on research. So, weve already talked a little bit
about this when I went through the worked example. But if you dont have research, then your
personas are meaningless. Theyve got to be based on real user interviews and observation. Not on
surveys, anecdotal evidence, or things that youve made up.
Now, having said that, I would be drummed out of the User Experience Trainers Club if I didnt
confess that some people that work in the field do think its OK to create assumption personas. And
these personas arent based on any research, but on the beliefs and the preconceptions that the
design team have of their users. There are some risks and benefits with that approach.
So, the benefits. First of all, preconceptions exist. Assumption personas get those beliefs out in the
open. At least then you can question them. And also assumption personas will highlight any
conflicting assumptions, like the elastic user we talked about earlier. And so that might act as a
kind of a catalyst to do some field research.
But theres some risks with creating assumption personas. One risk is that the team get even more
blinkered in their thinking. They start thinking that theyre on the right track because theyre
coming up with some kind of consensus, but its a consensus based on group think. Another risk is
that the design team may lose enthusiasm to develop personas if theyve got assumption personas.
Especially because real personas take time and money to develop.
So my advice is to only create assumption personas if you promise to then test out those
assumptions with real users. So its OK if assumption personas are the first step to doing real field
research but they should never be your end goal.
Now, I mentioned I was going to give you some numbers about how many people you should
observe or interview and how many personas you should end up with. And here are the numbers
Im going to recommend to you.
Now, these two numbers, 21 interviews and four personas, theyre obviously not cast in stone. What
I wanted to do was use this to give you a feel for the order of magnitude that youre looking at.
60
David Travis
These particular numbers come from some research that Forrester, the business consultancy firm,
came up with after interviewing a range of companies that develop personas.
So this number 21 interviews you should read this as saying youll probably need to engage
with about 20 or so users in total. You may find that its 25 or 30. The point is that its unlikely that
itll be 90 or 100. The approach I use is to keep seeing users until I get to the point of least
astonishment. So Ill be observing users and after I get to a certain number Ill find that every
additional person that I observe is just like somebody else that I observed earlier. At that point its
probably the time to stop. And in my experience, that happens somewhere around 20 or so users,
so 21 seems to me a reasonable number.
The other number is four personas. And again, treat that as a rough estimate of the number of
personas that you should end up with. If you end with six, thats fine. If you end up with a couple,
thats fine too. But if you end up with a dozen, youve probably got too many personas. Its going to
be hard for you to then work out which is primary and start doing design properly.
How about the time you need to invest? What data do we have on that?
Heres some more data. These come from the Nielsen Norman Group who carried out a survey in
2015 with companies who develop personas. They divided the companies into two groups: Large
companies and Small companies (depending on if they had more or less than 500 employees).
Small companies spend about 9 days creating personas and large companies spend about 13 days.
So I hope this gives you a feel for the amount of work that companies put in when creating
personas. Youre looking at about 2-3 weeks worth of effort.
61
David Travis
3-07 Publicising your personas

Another pitfall to avoid when youre developing personas is to make sure theyre formatted as a
story about a real person. So, they should feel and read as being very genuine. You should be able
to share your personas with people that have direct customer contact and they should resonate
with them.
I wanted to now show you some ways that Ive seen personas publicised within organisations, so
that you can decide which approach would work well for you and your organisation.
So, heres one example where weve got some personas that have been printed on A4 sheets of
paper, landscape and theyve been put up on a project noticeboard.
You can see the personas are there for the project team to have a look to gain a shared
understanding of users.
You can obviously print them as posters or print them on A3 paper if you want them to be bigger.
You get the idea. Its a very straightforward and very simple way of publicising your personas.
Heres another example. This one comes from Yahoo. This is a threefold card, obviously that works
if youve got three personas. If youve got more than three, youll have to find something else
instead. But it works well for threefold personas and I think this one was being used during a sprint
at Yahoo and the idea was to have their personas to hand so that they could consult them.
Heres another approach that Ive seen where personas are printed on card. These are a bit like top
trumps cards. And if you have several personas, they could be grouped on a key ring to help people
keep them together. So on the front one, on the top here weve got the photograph, the quotation,
the name of the person on the back, weve got the contextual information, and the goals as well.
Heres some other examples. The ones at the top right, the kind of persona action men, theyre
from Cisco. The ones at the bottom left are from Icon Medialab in Sweden where they had life-sized
images made out of cardboard and on the back they had the persona details pasted and team
members got to adopt a persona and arrange the persona in their workspace.
The ones at the bottom right these kind of persona cut-outs the idea is you bring them along to
a meeting with you when you are discussing your design work to remind yourself to make sure you
focus on the user. I dont know who that one is on the right-hand side. I dont know what her name
is, lets call her Jane for arguments sake. The idea is you would say, Well I wonder what Janes
going to think of this? Youd turn to Jane and she would just look back at you with a disappointed
expression and you know youve got to go back and rework that design.
That reminds me of an important point. None of these examples Ive shown you are personas.
These things are persona documents. Personas describes a complete activity where you do
contextual research, analyse it with affinity diagramming and develop pen portraits of your users.
Although these documents are fun and engaging, dont lose sight of the fact that the real value in
developing personas is in the process, not in the document itself.
Think of the persona document as like a final certificate that youre awarded after youve visited
users, discussed the findings, and analysed the data.
These persona documents are like the final proof that you did the work, but remember that theyre
not the work itself. In the same way that if someone said to me, Look, Im way too busy to get
myself a university degree at the moment, Ive like you to go to university for me, do the studying,
pass the exam, then give me the certificate afterwards. Well, theyve not achieved anything, have
they? Theyve not had the experience. Its about the experience of being with your users that
matters. Its not about the artefact itself.
62
David Travis
3-08 The 7-step persona checklist

In a moment Im going to give the opportunity to develop your own personas, and heres a checklist
you can use to decide whether or not your persona cuts the mustard.
So, Ive cleverly used the acronym PERSONA to remind you about the things that you should focus
on.
The P stands for Primary research: Is the persona based on contextual interviews with real users?
Its 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. 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 system.
This means you should shun research methods like focus groups and instead use techniques like
field visits.
E stands for Empathy: Does the persona evoke empathy by including a name, a photograph and a
product-relevant narrative?
Its 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. Thats 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.
R stands for Realistic: Does the persona appear realistic to people who deal with users 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 personas goals and behaviours.
S stands for Singular: Is each persona unique, having little in common with other personas?
I actually wanted to use the word unique, but persona doesnt have a U. Ha ha, Ive just realised
that the statement, Theres no U in persona, sounds a bit like, Theres no I in team. Anyway, I
was stuck with an S. Singular got me close. The point here is you want the persona to be 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.
O stands for Objectives: Does the persona include product-relevant high-level goals and include a
quotation stating the key goal?
Understanding the personas 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 users goal and also provides an appropriate design target.
N stands for 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?
63
David Travis
If you start heading into double figures, youve probably got too many personas. This is because the
design team wont be able to remember all of their names or keep them in mind when designing.
Finally, A stands for Applicable: Can the development team use the persona as a practical tool to
make design decisions?
Personas are lots of fun to create but dont lose sight of the fact that they are a design tool. This
means that the content of your personas the personas goals, behaviours and so on 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.
64
David Travis
4-01 Introduction to the design activities

If youre trying to get a job in user experience, or if youre trying to get promotion in the field, you
would have discovered that one of the key things you need to provide to your employer, or potential
employer, is a portfolio showing the work that youve done in the field.
Now, if youve not had a lot of experience in the field, thats going to be difficult for you to do
because you may not have done any design work. The purpose of this course is to help you bridge
that gap. What the course provides is five separate design activities then you can engage in. You can
either do one of those or you can do all five if you're an overachiever. And what you'll be doing as
you go through each of those activities is well go through each stage of the user experience design
process.
So for example well begin by looking at the appropriate user research that you should do. You will
go out and do user research for one of these activities. You'll then come back and we'll talk about
the way you are going to analyse that data. Youll then do the analysis: youll identify the users of
the system, you'll discover if there is a real user need for system, and you will identify the main
tasks that are carried out. You'll then go on to measure usability objectives for the system, to
develop hypotheses about what's the system should have, what it shouldn't have, and so on. You will
then create the information architecture for your product; youll look at the interaction design; you'll
then create prototypes; and then you will carry out a usability test.
And after each phase, what you will do is you will come back here, well look at what good looks
like, I'll show you some examples from other students who have done the same activities. You will
be able to compare your work against theirs. And then, what you'll find, as you have gone through
this whole processit's a very practical process, it's very hands-onwhat you'll find is youll end
up with a great entry into your user experience portfolio. This is the same kind of advice I would
give to people if they were working alongside me at work, and I want you to think of it that way.
Imagine that you're following along with me, as we carry out particular design activities, and I'm
coaching you through the process. So come and join me on this project, it's going to be great fun.
65
David Travis
4-02 Find My Pet

This particular design activity is called Find my pet.
Now, you work for a new start up in your hometown and they have developed a new product called
Find my pet. It's a system that allows people to locate wayward pets that have run off, been
dognapped or kidnapped or whatever. Essentially, the system has two key components to it: the first
component is a dog collar which has a dog tag on it. The dog tag has a very small GPS device
which is continually transmitting its location. That element of the design is pretty much complete
already: the design team know how that will look.
The second part of the interface hasn't been put together yet and that's where you come in.
The idea behind this is that it will be some kind of mapping system which will allow owners of pets
to locate them. They will be able to find their pet based on this particular system that they are using.
Now the design team is thinking that it is going to work best as a mobile phone application because
presumably people are going to be out in the open trying to track their pets down. But they are open
to other ideas. So if your research shows that it might work better on a tablet or that it might work
better on a laptop computer, that's fine, they will go with whatever your user research shows to be
the case.
And that's where we are at the moment: the user research phase. Here is what you need to do: first
you need to identify, Is there are real user need for this system? If there's not, you may need to
modify it slightly. So for example, the founder of the company has already said to you, This could
even be used to track down wayward teenagers. It may well be that find my lost teenager is a
better product idea than find my pet. But that's for you to uncover. Youll then identify the key
users of the service. You will identify the key tasks that people want to carry out and then you are
going to identify some usability objectives that your system will meet. Then you will move on to
develop the information architecture for whatever platform you develop it for. You will then look at
the interaction design, and you will mock up some prototypes: some systems that you can put in
front of users and test to check whether or not your hypotheses have been validated. At that point,
you will probably have to go back and make some iterations to improve upon the design.
Best of luck.
66
David Travis
4-03 Citizen Journalist

This particular design activity is called The Citizen Journalist.
Now, youre a user experience consultant and youve been called to a meeting with the editor of a
national newspaper in your hometown. He has said to you, The days of national newspapers are
over. What we really need these days is a newspaper that crowd sources the news from information
provided by citizens.
Now the editor has come up with a radical new idea. In his idea, citizens will film eventsnot just
news events that are happening in their hometown, these also could be theatre events, book reviews,
it could be sporting events. And the idea behind this system is that they will then, not just take
videos of the events, not just take photographs of the event, but actually write the story that goes
along with the event. And then they will file it for consideration in publication in his new crowd
sourced newspaper.
Now, the editor envisions that the system will almost certainly have some kind of mobile
component, because there is an element of videography for example involved. But he is open to the
idea that there may also need to be a desktop application where people write the copy and file
stories. Basically, hes leaving that up to you. If you come back and say its going to work best as a
standalone product or as a desktop application or as a mobile application, hell support whatever
recommendation you come up with. The key thing is to identify that there is a real user need for this
particular service. So thats your first job: your first job is to go out and identify if theres a user
need for the citizen journalist project. If theres not, you may need to modify it into something that
has a definite user need.
And the kind of things youll be doing are: first of all, once you have identified the user need, youll
go out and you will identify the key user groups for the service. Youll identify the key tasks they
want to carry out. Youll also identify the key usability objectives and then youll move onto
develop the information architecture for the system. Then youll look at the interaction design and
youll mock up some prototypes that you will then usability test. Finally, youll put your product in
front of users and youll see whether or not your initial hypotheses were correct and then youll
modify your system so that it is.
Best of luck.
67
David Travis
4-04 Digital Postcard

This particular design project is called the Digital Postcard.
Now, when I was a kid, no particular holiday was complete until you sent postcards to people at the
end of your holiday: postcards making them realise what a great time you were having and how
they were missing out on what a great holiday it was. However, with the rise of technology, this has
all changed. People now don't tend to send physical postcards. But thats all set to change. And
thats because you have just joined a new start-up that is working on the Digital Postcard project.
The idea behind the Digital Postcard project is really quite simple. Rather than send physical cards,
people will produce a digital version of their postcard, which then gets printed onto a physical card
and then sent off to the person who is the recipient of it. It will work something like this: youll be
on holiday, youll get out your mobile phone, take a photograph of an interesting site. Youll then
annotate the picture you have produced with some kind of graphics, but on the back of the card
youll actually write the message you want to send to your friend or colleague. Youll then enter
their postal address, upload it to the cloud, and then it will be printed in thats persons local
country. At that point, it will be dropped in the post-box and then it will arrive at their home just like
a real physical postcard would. So they are combining in this project the virtual and the physical
worlds.
Well, thats the idea anyway. Your job is to check that this particular system really is serving a
particular user need: that its actually going to be successful. So heres your task: first you are going
to check that there is a user need for this particular system. Youll be dong the research to check
thats the case. And if theres not, then you may well have to modify the product so that there is a
user need for this system that you come up with. Once you have done that you are going to identify
the key user groups for the digital postcard project: who are they, what are their backgrounds, what
are their characteristics. Youll also identify their key goals: what are they trying to do with system.
Youll then move onto look at the usability objectives that this particular system should have, and
then youll design the information architecture and youll look at the interaction design of the
product. Finally, youll come up with prototypes which youll usability test. And then youll modify
the system based on the feedback.
Remember, the concept at the moment is as a mobile phone application, but if your research shows
that it might work better perhaps as a kiosk system in a holiday resort, then that will be fine too. The
idea is for you to meet the user need, not necessarily focus on the technology.
Best of luck.
68
David Travis
4-05 Gift Giver

This design project is called Gift Giver.
Now, you work for a new start-up that has developed a radical new kind of technology that allows
systems to make product recommendations to people. Its a little but like Amazons, People who
bought X also bought Y kind of thing but this is actually much more detailed and much more
accurate. And thats because it is based on lots of lots of data from peoples purchasing behaviour,
not just their purchasing behaviour from one particular store. Its a very complex algorithm, but all
you really need to know about it is that it is astonishingly accurate. So for example, if you enter
your previous five purchases, its able to predict, with about 95% accuracy, what you are going to
buy next. In fact, in early testing of the algorithm, one woman that came in discovered that her next
purchase was going to be some childrens nappies (diapers). She didn't even know that she was
pregnant. Its spookily accurate.
Now, you can image that the company is creating various products based on this technology but you
have been brought in to work on one specific potential application and its called Gift Giver.
Now the idea behind it is that it will be a system that allows you or allows users to get gift
recommendations for their significant others: for their spouse, for their parents, for their children,
for their friends and so on. What youll do, or what the user will do, is enter some gifts or some
products that he or she knows that the person they are buying the gift for likes, and then the system
will recommend what you should get them next.
But it is more than just about giving gifts. What the design team are thinking is this could also
provide a reminder system. So you could enter, say, the dates of the birthdays of the people you buy
gifts for, enter the gifts or the products you know they like, and then it will remind you closer to the
time that here is the particular gift that would be good for that particular person.
Its not clear yet how they are going to make money from this: maybe it will be from some kind of
affiliate scheme, maybe it will be they will sell their own products, nobody knows for sure. But we
are a long way form that point at the moment. The first thing to check is: is there a real user need
for this particular system? And thats what you are going to do: you are going to find out if thats the
case. You are going to carry out research to check there is a user need. If theres not, you are going
to modify the product so that it is appropriate for people. You are going to design something that
people actually want. Also, you need to actually decide what platform it will run on. Will this thing
run on a mobile phone? Will it run on a desktop computer? A laptop computer? Will it be part of a
web site? How is it going to work? Thats something youll need to uncover with your user
research.
Youll identify the key user groups, and youll identify the key tasks and goals that they have.
Youll then move on to identify the main usability objectives that the system should have. Youll
then look at the information architecture, youll look at the interaction design and youll create
some prototypes. Then youll put those prototypes in front of users and youll see where your
assumptions were correct and where they were wrong. Finally, you will modify your system
youll iterateand come up with something that people actually want.
Best of luck.
69
David Travis
4-06 Tomorrow's Shopping Cart

This particular design activity is called, Tomorrows Shopping Cart.
So you have been called to a meeting with the Head of Retail for a large supermarket chain located
in your home town. And the Head of Retail has mentioned to you a new idea that she has and she
wants you to develop it through to the prototype phase. And this idea is called the intelligent
shopping cart: Tomorrows Shopping Cart. The idea behind it is that it will allow people to find
things in the supermarket with a kind of built-in satnav system. But it is more than just a satnav for
supermarkets. Oh no: its actually a lot more complex than that. The kind of things that the Head of
Retail envisages that this system will offer are, for example: you could enter your shopping list and
what the system will then do is navigate you to each of the items on your shopping list. She also has
another idea that perhaps it could also come up with recipes of the week, or it could come up with
recipes for healthy eating or whatever, and it will then navigate you to the appropriate aisle to buy
all of the right ingredients in order to supply those meals. Another thing that she is particularly
excited about, is that it could even have a barcode reader built in, and that barcode reader could then
scan each of the products and then the person could check out without needing to use a checkout
operator, saving on costs at the checkout till.
Well, thats the idea anyway. You need to do some user research behind it. There is one constraint
though: the Head of Retail really wants this to be a differentiator for her chain of supermarkets. She
doesn't want you to come up with a system that any old supermarket can use. She wants it to be
unique to her particular supermarket. Now, because of that, shes thinking that the system should
really be a physical product connected to a shopping trolley, which is where the idea of Tomorrows
Shopping Cart comes in. So for example, the idea of a mobile phone app that might do the same
thing, thats not going to meet the business objectives that she has: because she wants something
that encourages people to shop in her supermarket.
Well, you need to do some user research to find out how people might use a system like this. Your
first job is to identify: is there a user need for this particular system? If theres not, you may need to
modify or change it, you may need to discuss and decide whether or not you need to modify the
platform that its on or whatever in order to meet the user need. Then youll identify the key groups
of users of this particular system and then youll start identifying the key goals. Youll then move on
to identify the usability objectives that the system should meet and youll develop the information
architecture. Youll identify the interaction design and youll identify or create some prototypes so
that you can test out your design ideas. Youll then run a usability test to see if your hypotheses are
correct and then youll come back and modify the system so that it really meets the needs of users.
Best of luck.
70
David Travis
4-07 Design activity research briefing

So right now you need to choose which of those design activities youd most like to take part in.
Just to remind you, these are the five design activities we talked about (see pages 13-18 of the
Student Workbook). And let me point out a couple of things.
The first thing is that what I would like you to do is to pick one of the five that most appeals to you.
So don't use any complex algorithms, like which one might have the most business success, or
anything like that. Instead, theres one of those five, when you went through the videos, you
thought, Oh, that sounds interesting, and thats probably the one to focus on. Because if you find
it interesting, youre probably going to do a pretty good job of it.
The second thing to remember is that these various design activities give you the opportunity to
design a mobile device, a desktop device, a standalone device, you could even design a physical
product for some of them if you wanted to. So don't think these need to be a particular kind of
solution, particularly based on the user research that you do.
So the phase were at now is, you need to go ahead and do some research. Now, if you are currently
working in a company, and you have a real-life design activity that you are working on, then of
course you can use that design activity instead. You don't have to use one of these five. But in either
casewhether you choose one of these five or you do one that youre currently working on in your
jobheres the briefing for the next phase of the project.
So you need to go out and Id like you to speak with a minimum of 5 users of this particular system
that youve chosen. Now, all of the design activities, it shouldn't be difficult for you to find users:
even friends and family. You should be able to source people who those products are aimed at. They
have been deliberately chosen so that they are broad in their user base.
So the things to find out:
Is there a need for this system?

If not, how can you change it so that it meets a need?
Who are the main user groups? So theyll be more than one user group: what are they?
What day-to-day activities do they engage in thats related to the product? What do they do
at the moment thats related to that product? Go out and observe them; go out into the real
world, where they do this activity now.
What is the workflow (the sequence of activities)?
And importantly, you need to actually observe people, not just interview them. Interview them as
well, by all means ask them questions, don't think you can't interview people. As I said in the
contextual inquiry section where I was talking about field visits, interviewing is a component as
well, but its also about observation. Its not just about asking people what they want, its also about
observing people as they do the activity at the moment.
And the most important thing: just get out of the building and start observing people. Don't
overthink it, over plan it, and spend ages at it. You could do the research phase of this activity very
easily in a day. Maybe even half a day. So dont overthink this activity and spend too much time
planning. The quicker you get your feet wet and jump in, the easier youll find it to come up with
hypotheses to test as we move onto the subsequent phases. So before you move on in the course,
you need to do some user research. Because the next step, Ill be explaining to you how you then
take your research data and then use it to come up with the kind of descriptions that weve been
talking about so far.
71
David Travis
4-08 Persona Groups Briefing

So, youve done your user research. Or at least, I hope you have. Really, if you havent done any
research, go out and do some. Youll get a lot more from the course that way.
Id now like you to think about the different groups of users you observed in your research and note
them down in the worksheet that I have provided for you. The worksheet looks like this
and what Id like you to do here is to think about all of the different groups of users that you
spotted in your research.
First of all, give the group of users a name. Then write down why they need to use the thing youre
developing. Remember to think of this from the users perspective. Dont write down the functions
theyll use, but instead think of the goals that theyre trying to complete. In other words, think of
the user need that youre serving, or the problem that youre solving for this user.
In the next box, Id like you to think about the kind of information that the user needs to achieve
those goals. This is where you can start to think about possible functions or features they may need.
Dont go overboard on thinking of an implementation right now, just think of this at a high level.
Do this for all of the different groups you observed and then after that Id like you to write down
how you think the groups differ from each other. What is it that makes that group a group? What is
it that kind of binds them together?
So take about 15 minutes and complete that form, and then return back here and well use that
information to create a persona.
72
David Travis
4-09 Persona Creation Briefing

So now youre going to take the table youve just created and develop one of those user groups into
a persona. This will become your primary persona. Were just going to create one persona: you can
return to this activity and create secondary personas if you want, but right now well just create the
primary persona.
Heres what your persona will contain:
A sketch: Show the personas context, with a quotation stating the main user need.
Facts: Descriptive demographic information about your persona.
Behaviours: How is the persona solving their problem now?
Needs and goals: What does your persona want to accomplish?
Let me take you through this step-by-step.

This is where were going to end up. I call this kind of persona a 2-and-a-half-D sketch. It doesnt
look as beautiful as some of the personas we were looking at, but its a great first draft.
Now, you need to get prepared. Youll need a sheet of flip chart paper, some Sharpies and a pack of
sticky notes.
Arrange the flip chart paper in landscape format and split it into four quadrants.
Label the top left quadrant with a name for this user type. Draw a sketch showing this user type in a
context having some thought thats relevant to your product. This should be some expression of the
main user need.
Label the bottom left quadrant Facts. Using sticky notes, list the facts you know to be true about
this user type (such as gender, age, job title) Put one fact per sticky note. Try to come up with
about 10 sticky notes, and afterwards refine this to just 5.
Label the top right quadrant, Behaviours. In this section, youll state what this user type wants to
do with the product. What do they currently do thats related to usage of the product? How are they
attempting to solve the problem now? What motivates people to use the service? Put one behaviour
per sticky note. Again, try to come up with about 10 sticky notes, and afterwards refine this to just
5.
If youre stuck, heres a tip. Behaviours are actions so they should start with a verb: an action word.
Label the bottom right quadrant, Needs and goals. In this section, youll state what users want to
achieve with the system. What is this user types deep drives and motivations? How would users
satisfy their goals if your system didnt exist? How do users want to feel when using the system?
Put one need/goal per sticky note. Once again, try to come up with about 10 sticky notes, and
afterwards refine this to just 5.
If youre stuck, heres a couple of tips. You could take one of the behaviours youve already listed
and ask: why would someone do that?
Another tip is that needs and goals start with key words like wants, wishes that, would like,
hopes for, needs.
Heres some examples of the kind of personas that students have created using this approach on
my face to face courses.
Its true that they dont look beautiful, but remember that its the data that matters, not the way it
looks.
73
David Travis
Personas is the research method, not a glossy deliverable at the end.

So take about 15 minutes to craft your primary persona, and then return back here so we can move
on to the next phase.
74
David Travis
5-01 Red routes - Introduction

So now I want to move from thinking about personas to thinking about the tasks and the goals your
users have and Ive titled this section of the course, What can a London bus teach us about
usability? Well, stay with me, and youll find out.
Heres where we are in the roadmap of this course. Were still in building the context of use and
now Im going to look specifically at an area that Ive called Identify Red Routes.
And if we were to use a medical metaphor, we could say that personas are the operating room
lights. Once you know who youre designing for, its like someones turned the lights on. And red
routes, well, theyre like the surgeons scalpel. They provide us with an incredible insight into what
it is people want to do.
To begin with let me show you a picture.
Lets say that youve time travelled 20 years in the future. Youve picked up a rental car and youre
driving down the freeway. You now have a heads up display.
If I asked you, Whats wrong with this design? let me zoom in on that a bit so you can see
better what would you say?
Im hoping that one of the things that youd point out is that theres a lot going on on the
windshield and it may affect your ability to drive the car. Because if I asked you, whats the key task
when youre driving?, clearly the key task when youre driving is to, well, not to crash, isnt it really?
To be able to see the road in front of you.
If this was an actual design its not really, Ive taken it from an edition of Wired magazine. Its a
diagram by a guy called Chris Baker called Artefacts from the Future. But if it was a real system,
youd have to say, well, the designers havent really thought about the users tasks. Mind you, its
got some interesting things, such as like a drunk driver ahead indicator, in-car video chat, a live
GPS map with directions and a coupon for the Starbucks at the next exit. And he even seems to
have a multi blink interface: that calendar appointment at the top right says blink three times to
reschedule.
Well, theyre cool features, perhaps, but not in this place in this context. The problem is that these
cool features are getting in the way of the users key task.
Heres another example and I think its the problem that we often face as designers. So we do some
user research and weve got this initial idea for a system. Then we get talking to marketing and they
want to add features. The CEO wants to add features. And pretty soon you end up with something
like this and this isnt Photoshopped, by the way, this is an actual product that you can buy from
Amazon, although how you would use it to get stones out of horses hooves, Ive no idea.
Well, the point is every system has got a small set of really, really, really important tasks. Im going
to call them blockbuster tasks, and theyre the tasks that deliver a huge amount of value to users.
But systems have also got less important tasks and they can destroy value because they can in the
way of the more important tasks. So if youre going to be a successful development team, you want
to focus on the customers critical tasks.
Heres an example from a successful development team: Dropbox. When file sharing service
Dropbox started, there were many other similar services available.
But rather than compete on features, Dropbox focused on the most important features to make
sharing files easier.
It wasnt the number of features that made Dropbox great, it was focusing on fewer features and
building them right that did.
75
David Travis
So you achieve this focus on users goals with three simple steps.
First of all, you identify your users goals. Then you express those goals as user stories. Im going to
use user stories in the Agile sense, but you dont need to be using Agile to benefit from this
approach.
And then a third step is to design the software around the user stories.
Let me give you a feel for why that kind of approach matters. Id like you to take a blank piece of
paper for me. What Id like you to do is sketch a vase on that blank piece of paper, and then Id like
you to come back to the presentation. So, pause the video for a moment and then design a vase.
76
David Travis
5-02 Red Routes - What and why

I hope you actually did this and youre not one of those students who think they dont need to do
the activities. If you are, Ill hunt you down and make you do them twice.
Have a look at the drawing of the vase that youve got in front of you and admire it for a moment.
However, Im now going to tell you that you werent very creative. Because what you designed looks
like a vase. Well, thats fair enough because thats what I asked you to design, but what instead if Id
said: Design a way a people to enjoy flowers in their home.
Well, you might have said, a vase would be one way of doing it. You might also have said, well, you
could have a window box, or you could have a window onto the garden so you can see flowers
outside. Or you might have said, well, I could have a picture of flowers on the wall, a Van Gogh
reproduction of sunflowers, for example. Or you might have pot pourri in the house so that you can
get the aroma of flowers. Or if youre particularly romantic like I am, you might spread rose petals
through the house so that your wife can come in and walk over rose petals when she comes home
from work, only to say, I hope youre going to clear that bloody mess up afterwards.
Well, the point is, there are lots of different ways of meeting this user need: the need to enjoy
flowers in your home. But the problem with the way I posed the first question when I asked you to
design a vase was that it was implementation focused. Whereas designing a way for people to enjoy
flowers in their home, thats a focus on the user experience.
And heres another example. If I asked you to design a better search engine results page, thats a
very implementation focused solution. But what if I asked you to design a better way to learn about
topic X? A search results page is one way of doing it, but Im sure you can think of many others.
So thinking in terms of the users need helps us design much better user interfaces because they
prevent us from becoming too implementation focused in our thinking.
I wanted to develop that idea now by introducing a term I call red routes.
Now, there are certain roads in London that have red lines on them. There are also roads in
London with yellow lines on them, single and double yellow lines, and they mean the same kind
thing that they mean wherever you go in the world.
But the red lines are pretty much unique to London. Ive not seen them in any other city. And the
point of them is that the people that organise the public transit system in London, an organisation
called Transport for London, theyve discovered that there are certain routes through the capital
that have to be kept clear. If someone parks on Bankside, for example, in South London and they
leave their car there for a few minutes, before you know it, theres a traffic jam at Elephant and
Castle or somewhere else around that area of town.
The point is, theres certain roads, certain routes, that need to be kept clear. Now, you can think of
red routes as an analogy with the system youre developing. Your system has certain key routes too,
certain important user journeys that need to be kept obstacle-free so that people can complete their
tasks as quickly as possible.
There are a couple of advantages in thinking about red routes.
First, it helps us solve a common problem that some design teams face. Often theyll say, Weve
got so many users, they want to do so many things, how can I possibly understand everything?
Well, what were saying with a red route approach is, you dont need to do that. Instead were going
to focus on the most important scenarios enacted by the primary persona. So, make the easy things
easy, make the hard things possible. Design for the most common use case.
77
David Travis
The user interface doesnt need to make users aware of all the edge cases and the rare use cases that
the server and the back end need to handle.
A second great thing about red routes is they produce actionable results. What we can do is put a
user down in front of our system, ask them to complete a particular goal with our system which
is the beginning of a red route and then see how they do. Where do they trip up along the way?
What are the obstacles that they face? What errors do they make as theyre trying to complete that
task? Fixing those will make the system much easier to use.
Now, every presentation on user experience obviously needs a quotation from Steve Jobs. Heres
mine. I know you have a thousand ideas for all the cool features iTunes could have. So do we. But
we dont want a thousand features. That would be ugly. Innovation is not about saying Yes to
everything. Its about saying No to all but the most crucial features.
Of course, Steve Jobs died and then iTunes turned into a dogs breakfast. Here are some examples
of common searches that people carry out on Google related to iTunes.
But honestly, iTunes was good once.
But the point is that Steve Jobs summarises in that quotation what red routes are about. Think
about your companys intranet. If your intranets typical, most of the contents probably low
priority. Somes going to be out of date. Some will have no owner or author. Probably there are
pages and contents no one even knows are there. Some pages are never accessed, some contents
never read, some content supports tasks that no one ever does. The bulk of most intranet content
supports infrequent, low priority tasks.
This red route approach enables us to turn that on its head and now say, what is it that we need to
focus on?
Now, if you dont focus on red routes you run into problems.
One of the first problems is that you end up warping the information architecture.
Well, OK, this picture has been Photoshopped, but you get the idea. If you start adding lots of new
content to support lots of new tasks, that requires lots of new navigation links from other pages,
lots of noise in the navigation system, and that makes it difficult for users to find the content that
they need. So, I guess the point of this is: dont be a Yes Man. Make each feature work hard to be
implemented. You should only consider features if theyre willing to wait outside in the rain for
three days waiting to be let in.
Now often at this point people stop me and say that theres a problem with this red route idea. If
you limit the features in a user interface, you reduce its flexibility.
In fact, this focus on flexibility is a common design mistake. Flexibility has costs. It has costs in
terms of decreased efficiency, added complexity, increased time, and money for development. And
in contrast, a couple of thoughtful options is better than providing every possible choice to your
users. The more choices you give someone, the more time it takes them to decide. People cant
make a mistake if you only give them one choice.
Now theres a law in psychology known as Hicks Law. Theres not many laws but this is one of
them. And it states that the time taken to make a decision increases as the number of choices is
expanded. In fact, you can use it to estimate how long it will take for people to make a decision
when you present them with multiple choices. And it predicts that the greater the number of
alternative choices, the longer its going to take the user to make a decision and select the correct
one.
Focusing on red routes helps us focus on what the important decisions are and reduces the number
of choices.
78
David Travis
Lets see if you have the idea. Imagine were designing a television remote control. What are the red
routes that we need to support?
79
David Travis
5-03 The Flexibility - Usability Trade off

So, the ones that youve probably come up with is perhaps increase the volume, change the
channel, turn the television on or off. Really you dont need to get very far before you dry up and
thats a feature of red routes. The red routes are usually very quick to identify.
Let me show you a photograph of another television handset, actually this is Microsofts remote
control for Windows Media Player. Now, those key tasks we talked about increasing the volume,
changing channel, turning the TV on or off well, you can do those key tasks, but theyve also
shoehorned in many other controls which means its actually harder to do the key tasks. I dont
particularly mean to pick on Microsoft in this example. I probably could have taken any television
remote control and I could have made the same point. But the reason for using the Microsoft
example is then I can directly compare it with the Apple remote.
And notice this is an active design decision: Apple have actively chosen to remove a lot of the
functionality from the handset. You can still get to those functions but you have to get to them
through software. So, for example, with the Window remote control, Im not too sure what some of
those buttons do above the numeric keypad at the bottom. Lets say for arguments sake one of
them changes the aspect ratio. Well, thats something that most people wont want to do very often.
Apple has decided to remove that option and place it in an on-screen menu system. This means
they can keep their remote control extremely simple.
Theres an interesting issue here which is to with a trade-off between flexibility and usability. So,
the flexibility usability trade-off is exemplified by that well known maxim, Jack of all trades, master
of none. So flexible designs, like the Microsoft remote, can perform more functions than specialist
designs, like the Apple remote, but they perform the key functions less efficiently.
Flexible designs are, by definition, more complex that inflexible designs. And as a result they are
generally more difficult to use. So, for example, a Swiss army knife has many tools that increase its
flexibility, but these tools are less usable and less efficient than a specialised device that just has the
individual tool.
So that flexibility usability trade-off exists and coming coming down on the side of flexibility means
you need to satisfy a larger set of design requirements. And that invariably means not only more
compromises, but also more complexity in the design.
Heres another example of the benefit of focusing on red routes. Ive taken this from a website
called whichtestwon. Ive strongly recommend you visit that website if youre interested in A/B
testing, but this is an example of a test they had a while back. If youre not familiar with A/B testing
or multivariate testing, the way it works is that when a user arrives at the website, theyre shown
one of two alternative designs, either version A or version B.
Theres a small difference between each of the versions and users are randomly assigned to one
group or the other. After a number of users have used both designs, you then do some statistics to
see if one is converts more people than another, or whatever your key business metric is. In this
instance the key metric is to with downloading a piece of software and one of these two designs got
twice as many trial downloads as the other. Which one won, do you think?
Well, the answer to this is version B. Its important to know that its impossible to say why one
version beats another in an A/B test: it could be that the image of the box in Version B is bigger
than the box in Version A. We dont really know. And thats not helped by the fact that in this
particular example, the designers have changed several things at the same time. But one key
change here is that theyve removed the top navigation. And this is another example of simple
being a better way to achieve business goals. So, by getting rid of the top navigation, theyre
focusing more on the red route, which in this instance is downloading the software, and stopping
people getting distracted.
Another problem if you dont focus on red routes is that site maintenance increases. I mean every
80
David Travis
time you say yes to a feature, its like adopting a child. You have to take this child of yours through
a whole chain of events like design, implementation, testing and so on. And once that features out
there youre stuck with it, just like youre stuck with an unruly child. So, before you say yes to a
feature, make sure that it really needs to be added. Make sure its part of a red route.
81
David Travis
5-04 Prioritising red routes

So how do you go about identifying red routes?
One approach is to identify the frequent and critical tasks. I want to explore that one in a bit more
depth. And to do that I want to ask you another question.
What would you say are the red routes for an in-car navigation system? Something like a TomTom
device or a Garmin, something that allows you to navigate your car from A to B?
When I ask people this question they tend to give me various answers which essentially boil down
to one task: planning a route. People tell me, I want to travel from A to B.
I examined a Tom Tom in-car satellite navigation system to classify the various functions that it
supports according to two dimensions. For each function, I first asked: How often is this function
used? I classified my answer using four categories: All of the time; Most of the time; Some of
the time; and Very little of the time.
I then asked, How many people use that function?, and classified this as Few of the people,
Some of the people, Most of the people and All of the people.
The answer to these two questions determines where the function will plot in the table. For
example, Plan a route is a function that all of the people want to do all of the time indeed, why
else would you have a sat nav? Similarly, Add a favourite is a function that all of the people would
want to do most of the time, and find an alternative route is a function that most of the people
would want to do all of the time. So these functions plot towards the top right of the table, which
Ive colour coded red.
But then there are some other functions, like Set flight mode. This function allows you to turn off
the systems GPS. Ive thought long and hard why you would want to do this, and I must admit to
being somewhat puzzled. Who would want to take their sat nav on an aeroplane and turn off the
GPS? (It might be quite interesting to leave the GPS connected and observe the flight plan unfold
before your eyes, but a sat nav is a fairly useless product without a GPS signal). So I figured that
function would be of interest to only a few people, very little of the time and I placed at at the
bottom left corner.
As another example, lets consider the function, Upload photos. Did you know you could upload
photos to a Tom Tom sat nav system? Im not sure when you would take the time to view your
photographs, however. Its true that traffic congestion is a way of life but its not quite so bad that
drivers are searching for in-car distractions. So I figured that this function would be one that some
of the people would want to use very little of the time and plotted it down towards the bottom left.
(As a side note, thinking about these two functions made me re-think the use case. Maybe the
engineers at Tom Tom had this idea in mind: youre travelling on an aeroplane and want to view
some photographs of your family. You put your small smartphone away in the luggage
compartment and instead retrieve your bulky Tom Tom from your carry-on bag. You then proceed
to look over the images. Hmm. Still not convinced).
The point is: To identify red routes, look at how many of your users will carry out the task, and how
often. This gives you a sense of whats valuable.
So, lets take break. And over the break, heres what Id like to you do. In five minutes, Id like you
to brainstorm five red routes for one of the following. So, pick one of these and then create a series
of red routes for it.
An application that lets you back up your computer over the Internet
A presentation app (like PowerPoint) that runs on a mobile phone
82
David Travis
An application to help you calculate your taxes

An application that lets you read online magazines on a tablet device, like an iPad
Pick one of those and generate five red routes for it and then well return and well discuss your
findings.
83
David Travis
5-05 Red Route activity

So Im curious how you found that. Did you manage to come up with five red routes for one of
those?
When I went through that myself the kind of ideas I came up with, well, thinking of the first one, a
website that helps you manage your finances. The kind of things that occurred to me that would be
red routes would be things like entering details of income or expenses Ive made, creating a budget,
I want to see how Im doing against my savings goals. I want to get a report of my net worth and I
want to get ideas for cutting my costs.
For a presentation app, like PowerPoint that runs on a mobile phone, I think the key thing there is
it runs on a mobile phone, so its unlikely Im going to want to create a presentation from scratch.
Thats something that Im probably going to want to do on a laptop or tablet device. So what I
would expect that kind of application to support would be editing a presentation I made earlier: for
example, adding or deleting slides. Connecting the phone to a projector to show my presentation.
Changing transitions between slides. Maybe the opportunity to practise my presentation and to
share the presentation on a website like Slideshare.
Now, an application that lets you read online magazines on a tablet device, like an iPad. I think
typical red routes for that would be things like seeing a list of magazines that I can read. Setting up
a subscription to a new magazine. Downloading the magazine so I can read it offline. Bookmarking
pages in the magazine. And sharing snippets with friends on Facebook.
And finally a website that lets you back up your computer over the internet, I think typical red
routes for an application like that would be creating a list of items to be backed up, maybe
encrypting the back up so that it cant be hacked into. Restoring one or two files from a previous
back up. Initiating an immediate back up. And verifying that the back-up was successful.
OK, hopefully youve got the idea now and youve got a good view of what red routes are about.
Now lets do it on your design project.
Look over the data you collected for your design activity. Now Id like you to brainstorm 10 red
routes that describe your personas key tasks when using your application.
This should take you about 10 minutes. Do that, and then return to the course.
84
David Travis
5-06 Introduction to user stories

So I have a question for you.
What would be the red routes would you say for a site that enabled you to make hotel and flight
bookings, something like Expedia? What would you say?
I mean the chances are you probably said book a room, book a flight, and indeed, that gets us so
far.
But youll remember weve been talking a lot in this course about context. And people approach
tasks differently based on the context of use. So, things like booking a flight, booking a hotel, will be
different depending on the context.
Heres an example of what I mean by that. Imagine you need to book a flight and a hotel in Paris for
a two day trip with your partner. So impressed was she by the rose petals youd strewn through the
house earlier, youre now going away for a romantic weekend.
Now what matters when you do this task of booking a flight and hotel? And just to make sure, for
the men listening to this, notice that the emphasis here is romantic. This is a romantic trip. So
dont dare say price, OK. This is a romantic weekend with your partner, so what matters when
youre booking a flight and a hotel?
Im thinking things like, you know, whats the room like? Can I see pictures of the room so that I
can see if its romantic enough. Can I get maybe a bottle of champagne in the room delivered for
when we arrive? Does the hotel organise trips to local attractions? Im also wondering if I can
reserve seats on the flight in advance and avoid the Easyjet scramble. And can I get a flight that
leaves at a sociable time of day, so I dont have to leave first thing in the morning?
Now lets change the context. Now lets imagine that you need to book a flight and a hotel in Paris
for a two day business trip. What is that youre looking for now that was less important before?
Well perhaps youre curious if the hotel has got has got broadband because you want to VPN back
in to the business network. Maybe you want to know if theres a business centre? You want to know
what your limit is for hand luggage so that perhaps you dont have to check bags. In fact, do you
even need to stay over at all? Maybe you could leave very early in the morning and leave late at
night and that way you wouldnt have to spend a night away from home.
The point is that the red routes are the same but the context of use alters the way we carry out
these tasks. So we need to capture the context and were going to do this with user stories.
So, user stories are a key component of Agile development but you dont need to be using Agile to
benefit from them. User stories have got a particular structure: as a user I want to, so that I can.
And this format was first suggested by Mike Cohen in his book User Stories Applied. And
traditionally these stories are written on index cards so youll hear people on the team talk about
story cards.
Now, for our purposes, a great thing about user stories is that you need to embed some context
within the story. You do that with the so that I can element. So in this example, saving the
princess is the goal. Slaying the dragon is a step towards that goal, the task I need to carry out.
Here are some other examples. As a business traveller, I want to see hotels with a business centre
so that I can work remotely. In contrast, as a tourist I want to see pictures of bedrooms so that I can
have a romantic weekend with my partner. And as a travel agent I want to export my past booking
so that I can invoice my clients.
And now weve got the context which feeds into this important red route that we have.
And now lets see how we can go from red routes to user stories with some specific examples.
85
David Travis
Manage my diabetes: that might be a red route for an application that is aimed at people with
diabetes.
Heres the user story were going to have. Jane says and note that Ive added a persona name to
this user story. I picked up this idea from Anders Ramsay and its a great way to make your user
story even more grounded. Anders Ramsay writes about UX and Agile on his blog
andersramsay.com. So now, instead of thinking of generic segments, were thinking of the needs
and goals of a specific persona. I mean many projects mistakenly assume that theres only one user
so they write all stories from one users perspective and assume all users have the same goals. The
advantage of specifying a persona is that users become tangible. This means we start thinking of
our designs as solving the needs of real people.
So lets go back to our user story. Jane says, As a patient, I want to track my blood glucose
readings so that I can find out if there are any specific periods of the day when I am having
difficulty controlling my glucose levels. And now weve got a really rich context behind that red
route that we can design around.
Heres another example. Deal with a goods not arrived enquiry. The user story is John says. So
John again is a specific persona. We know about John. Weve done research with people like John.
As a call centre worker, thats his role, I want to trace an order when I only have a partial address so
that I can tell the customer when his order will arrive. This came about because some work we were
doing with a warehousing systems, customers would ring up, they didnt know their postcode,
believe it or not, as a consequence the whole system ground to a halt and it couldnt move forward.
Now, on your own projects you can get users to write these stories. Theyll then phrase the story in
their own domain specific language.
Writing user stories looks easy, but its a skill you need to develop. Let me show you that with a bad
example.
The red route here is for a Government service: Check Im paying the right amount of tax. That is
a genuine need that all citizens have in al countries of the world.
Now lets turn that into a user story.
Ryan says, As a PAYE taxpayer, I want to understand how to calculate my tax code so I can make
sure Im on the right tax code
How accurate is that story? Would Ryan really say this?
Lets deconstruct this example so you can see why its bad.
Lets start with goal. so I can make sure Im on the right tax code. Is that accurate? Really, whos
bothered? Surely the goal is actually, so that I can keep as much money as I can and avoid an
unexpected tax bill.
Now look at the task. Do people really want to understand how to calculate their tax code? Or do
they actually want to pay the right amount of tax?
So lets look at the improved wording for this user story
Version 2 is now a much more genuine, user centred description. The point is you need to work
hard to make sure these user stories are accurate. Check that you really have specified an accurate
user goal and an accurate user task.
86
David Travis
5-07 Testing a user story

So, how do you test a user story to see if its any good? Heres four questions you can ask of your
user story.
First up ask, Is it something a real user would say? User stories should use the words, language
and concepts that your users would use. That previous bad example I just showed, to do with tax, is
an example of a user story that would fail this test. It wasnt something that a real user would say.
The second question youll ask is: Does it help you design and prioritise? You want your user
stories to be actionable and hat means they need to be written at the right level. You dont want
user stories that are so aspirational you cant design around them or use them to choose between
potential design solutions.
The third question youll ask is: Does it unnecessarily constrain possible solutions? User stories
need to focus on goals, not procedural steps, so they dont dictate any single implementation. A
user story like, as a user I want a vase so I can enjoy flowers in my home: well, its telling us how
we expect that to be implemented, with a vase.
The fourth question to ask is: Do you have good evidence? This is a sanity check really to prevent
you from just making up a user story. Like the personas we created, your user stories need to be
based on contextual interviews with real users.
Now its your turn.
Return to your design activity and sort the red routes you created into two piles: 7 less important
and 3 more important.
Important means most relevant to your user and reflects your vision for the system.
Use the 3 important red routes to create user stories on index cards.
87
David Travis
6-01 Introduction to Lean UX

I wanted to turn now to look at an issue to do with measuring usability, because often, I think when
we think about usability, we tend to think of it as something that we know what it is when we see it,
but we wouldnt really think about putting numbers on it. But in fact, usability can be measured
just like any other engineering attribute. I wanted to talk a little bit about that now.
Heres where we are in the overall scheme of things in the course roadmap. Were on the righthand side now looking at creating the user experience and I want to talk specifically about setting
key performance indicators.
To begin with, I wanted to introduce you to a book that you may or may not have come across. Its
called The Lean Start Up by Eric Ries.
Its a very interesting book and I think that initially when you look at it you might be taken to
believe that its really only relevant if youre involved in a start-up. Its kind of something about the
title I think that probably would convince you of that, but in fact its not just about people that are
involved in start-ups. Really the stuff that he covers in this book will apply to anyone whether you
work in a long established company or even if you work in a government organisation.
Heres the digested read.
He argues that designing new products or services is risky because there are so many uncertainties.
And he argues that the design team has a set of hypotheses for example, about users, their goals
and what they will pay for and to reduce uncertainty, these hypotheses need to be tested.
So, we identify these hypotheses and then design experiments to test them out. We run these tests
on minimal versions of the product with limited functionality because these minimal systems are
quick and easy to create.
Based on the test results, we continue to develop the idea or we pivot (change direction) and
develop a product that has more value for customers.
Lean StartUps principles are simple and profound at the same time: the idea is not to wait for
perfection when creating something new, but just to get a minimum viable product (the most
basic workable version) in front of a customer as quickly as you can.
The idea is to get customer feedback based on actual observed behaviour (a concept known as
validated learning) then continually iterate your product and market strategy based on that
feedback until you hone in on exactly what customers want.
Its like a science of design.
This leads us to an interesting conclusion.
It means that the best design teams arent the ones who ship quickest.
The best design teams are the ones who learn quickest.
The quicker that you get through this loop of build - measure - learn where you build products,
measure data and learn new ideas the more effective you are.
I mentioned this concept called validated learning. Notice the two words:
Validated: Its based on data you collect from experiments.

Learning: Its stuff that helps you move the project forward.
88
David Travis
The point behind this is the notion of generating hypotheses because weve all got them, havent
we, about our users and what they want to carry out? and then testing out what those hypotheses
are.
So lets look at a specific example.
89
David Travis
6-02 Problem and Solution Hypothesis Testing

I want to distinguish between two kinds of hypothesis.
The first is the problem hypothesis. Its our assumption about the user need. We need to check
this.
The second is the solution hypothesis. This is our design that we think meets the user need. We
need to check this too.
Lets begin with the problem hypothesis.
I came across this website recently, which she enables people to pay for car parking with a mobile
application and I thought it would serve as an interesting example. So when we look at this
particular page if I asked you, What do you think the user need is behind this service?, What
problem is this solving? How do you think the design team behind this organisation might
respond? What user need is being solved?
Its probably this: We believe motorists dont always have cash to pay for parking.
OK, so now we need to work out the quickest and cheapest way to test this problem hypothesis.
This is because, if it turns out not to be a problem, theres no point wasting time designing a
system. We would pivot, to use the terminology of the Lean people, and design something else. In
other words, we would develop a product that has more value for customers.
So we could:
- Spend an hour observing people at a city centre car park and observe how many people dont have
cash to pay.
- Or we could interview people in a shopping centre parking area and ask them to rate how serious
a problem this is: a minor issue or a major inconvenience.
Are there any other ways that occur to you that we could test this idea?
Lets assume we do this research and we validate our problem hypothesis. It really is a problem.
People say, Oh, yes, its such a pain in the neck when I don't have cash to pay for parking! OK, we
have validated that; now we can go on to test possible solutions.
So lets follow this example through.
Now theres going to be a business objective behind this system: an overarching goal. Thats
probably something like, the number of people who use the app to pay for parking. If that number
goes up, the business makes money. There may be other business objectives too, but I reckon thats
a critical one.
Now we can look at ways of moving the needle on the business objective by improving the user
experience. For example, my first guess is that Ease of setting up an online account, Ease of
entering parking information and Ease of updating vehicle details are three key things we could
focus on. There are probably others too but these three stand out I think.
But theres a difference here between the business objective and the user experience attributes Ive
listed.
The business objective is a fact.
The user experience attributes, well, they are assumptions. In my opinion, they will probably affect
task completion and therefore the business objective the number of people who use the app to
90
David Travis
pay for parking. But throughout this course, what Im encouraging you to do is not to listen to
peoples opinion. As the old adage goes, In God we trust. Everyone else needs to bring data.
So in order to learn quickly, were going to identify the riskiest assumption and test that first. In
this example, Ive picked Ease of entering parking information as the riskiest assumption but of
course you would want to discuss this with your design team.
We now need to turn that assumption into a testable hypothesis.
Ease of entering parking information is a bit non-specific. So Ive turned it into a solution
hypothesis, which reads as follows: Motorists will find it easy to use an app that requires them to
enter their car reg and a 5-digit code on each parking meter.
But is that testable?
What does easy to use actually mean?
Here are some questions that a project manager might realistically pose about your system. Im
curious if you can answer any of them. So thinking of a system you are working on at the moment,
can you answer these questions?
How usable is this software?

What will qualify as usable enough?
Is the software usable enough to release now?
How much more usable must the software be?
How much more usable is this release compared to the last one?
Is our software more or less usable than the competition?
If not, how much will it cost me to make it more usable?
I think all of those questions are valid questions but theyre extremely difficult to answer because
you end up answering them by waving your arms around and saying, Oh, well I think its more
usable than the competition, but if you dont have any data to back up your assertions, you are
making it up.
We could resolve this issue if we had a definition of usability: something that made this thing
measurable.
So heres a statement Id like you to complete for me: One thing that makes a product or website
usable is What would you say it is? How would you complete this sentence. Just one thing. So
think about that and then well return.
91
David Travis
6-03 Defining and measuring usability

Im curious what you came up with as your definition of one thing that makes a product or website
usable is.
Maybe you used words like intuitive or simple to use.
Or maybe you said, quick to complete tasks or whatever.
Well, whatever you said, although it may have been good, I can do better. And the reason I can do
better is because I can point to a definition in and international standard on usability.
The definition is from ISO 9241 the same standard we have been talking about on this course,
but its actually from a different part. This is from part 11 whereas we have so far been talking about
part 210. Anyway, they have a definition of usability within that standard. We can use that to
operationalise usability and the user experience and find some way then of measuring it. Heres
their definition. Take a deep breath. The 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. Well, OK, it contains a bit of jargon, and maybe thats what youd expect from a standards
body. But if we unpack that definition, theres three attributes that stand out.
The first attribute is effectiveness.
Effectiveness means basically, can people complete their tasks? Can they complete the goals that
we set them?
A second attribute we can pick out is efficiency. This means how much effort or workload is
required, such as time.
And the third attribute we can pick out is satisfaction: this means, after users have finished their
tasks, how do they feel about the experience? Sometimes people say to me, Satisfaction? I want
people to be more than satisfied with my user interface. But if you look at the dictionary definition
of satisfaction, it says, the feeling of pleasure when a need of desire if fulfilled and I think thats
the thing that were aiming for.
Whats important about that definition is that there are three components. And the fact that there
are three components means you cant just focus on one. In order to capture this thing that were
trying to measure, usability, user experience, we need to think about all three of them. So theres no
point in just measuring effectiveness, we need to measure effectiveness and efficiency and
satisfaction. Its like a three legged stool.
And the amazing thing is, we can do that. We can actually put some kind of numbers on these
attributes. Let me show you how.
92
David Travis
6-04 Measuring Effectiveness

Lets look at that first measure, effectiveness.
What we can do to measure effectiveness is look at, for example, the success rate: the percentage of
participants who correctly and completely achieve each goal unassisted by a test moderator.
Now there are other measures we take as well, for example, we could look at the disaster rate. That
is, the number of people who think they were successful, but they actually failed. They think they
clicked the submit button, they think the product theyve ordered is winging its way to them but in
fact they forgot to enter a shipping address. The website gave them poor feedback and implied the
task was completed, when it wasnt.
And there are other possible metrics here as well. But youll notice that Ive put one of them in bold.
The reason Ive put it in bold is because theres another standards body, a US standards body called
NIST, and theyve adopted the ISO definition of usability as has virtually everyone that works in
the field of user experience. But rather than just taking the definition as is, theyve also said, We
love the ISO definition of usability but we think you should measure this metric if youre going to
measure effectiveness. And its actually quite a good one to pick, this percentage of participants
who correctly and completely achieve each goal. Most people that work in the field would say that
was a good measure to collect.
Lets look at how that might work in a usability test.
So here Im showing you the results from a usability test that had four users and four tasks, and
each of the cells in this table shows whether or a user was successful on the task or failed on the
task.
So, for example, lets say that task one is ease of entering parking information task, you can see
that only 50% of people complete this task successfully. And now we can set a realistic target for
improvement. For example, we can say, Well, we expect 75% of users to be able to complete this
task.
There are other measures you can take from this table, of course. So task one looks like it needs a
bit a work, whereas task two looks like its doing well. We could also calculate the overall task
completion score by dividing 12, the number of successful task completions, by 16, the total
number of tasks and get a percentage of 75%.
So let me who you where Im headed with this. This shows you some real data from a usability
session that I carried out with a clients intranet, and we set our users a number of specific tasks.
Heres one of them, find out your current salary band.
The diagram at the top left that looks like a tube map, that shows you the various routes that people
took. The green line shows the ideal route: the user should have started at Home, then picked
human resources, pay and benefits, pay, pay information and salary ranges. In fact, many people
got a bit lost when they got to human resources. Some picked HR direct rather than pay and
benefits. And when they got to pay, some people picked, for example, your salary rather than pay
information. Im curious actually the difference between your salary and salary. I wonder if
theres a difference?
But the point is, people made errors when they were trying to achieve their goal and were not
successful. If you look at the graph at the very top where it says success rate, you can see that just
14% of people were successful on that task. Now this was with a big sample size as well, 202 users.
Thats a huge sample for a usability test. We managed that because we ran it online. But notice
importantly how were actually measuring usability. Weve got numbers now that were assigning to
this measure were calling effectiveness.
So weve discussed effectiveness. Can you remember the other components of usability?
93
David Travis
6-05 Measuring Efficiency

Well, our second component of usability is efficiency.
Lets look at how we can measure efficiency.
Now, for example, we could look at the average time taken to complete each task together with
some statistical measures, range and standard deviation.
But we could also look at time taken on first attempt, time spend relearning functions and so on.
That one Ive put in bold again, thats the one thats advocated by NIST, the US standards body.
So here we have our four users and four tasks. Again, this is the same usability test as before, but
now each of the cells shows the amount of time taken to complete each of those tasks. So lets
assume that task one is our ease of entering parking information task. Heres a question for you.
Why are some of the cells in that table blank?
We can see that this takes an average of 302 seconds, or about five minutes. And we can now set a
realistic target for improving it. For example, lets see if we can speed up the search process so its
completed in three minutes.
Each cell shows the time take to complete the task. Why are some cells blank?
Im hoping that you said theyre blank because in the earlier slide I showed you people didnt
complete the task. So it wouldnt make any sense to collect a time on task measure if users were
unsuccessful.
Youll also notice that if you look at task two and user three, youll notice theres a very large
number there, 1,230 seconds. Now, task time has got a strong tendency to be positively skewed.
What that means is some users take a long time to complete a task. And if we calculated the average
time on that task, that particular user would skew the results. And that arises because you get large
individual differences between users. Some users just use computers slower as they complete tasks.
A few long task times pull the mean task time up, making it no longer the typical task time.
Instead it overstates the middle value. One way you can get around that is by calculating not the
arithmetic mean, but the geometric mean which is what Ive calculated on this slide. You can easily
calculate the geometric mean in something like Excel, but for those statistics wonks out there,
effectively what you do is you convert each number first to the base e and then you compute the
average of those. Then you convert back from base e to the normal numbering system and then you
end up with a number as weve got here, 575 seconds for Task 2. And that removes the bias that
would be caused by that one users long task time.
If what I just said sounded like, blah blah blah, all you need to know is that the geometric mean is
just a kind of average measure.
94
David Travis
6-06 Measuring Satisfaction

Now, the third component of usability is satisfaction. How do you measure user satisfaction?
Heres some metrics we can use. For example the mean score on a questionnaire. Another thing
you can do is just listen to an interview with participants afterwards and note down the number of
positive versus the number of negative things each participant said. And there are others here too.
Now, compared to effectiveness and efficiency data, self-reported measures are a lot more variable,
but theyre obviously critical to the success of a system. Because it doesnt matter how quick your
system is to use or how straightforward it is to complete tasks, if users dont like it theyll go
somewhere else. So we need some way of measuring satisfaction.
Youll notice that none of these are in bold. NIST have basically said none of these measures is that
good at measuring satisfaction, so they cant recommend one. But we need some way of doing it
and they acknowledge that you still need to measure satisfaction scores.
So heres what Id recommend: the system usability scale.
This is a simple ten item attitude Lickert scale that gives a global view of subjective assessments of
usability.
It was developed by a guy called John Brook at Digital Equipment Corporation in the UK in 1986
and its been used for a long time since then as a tool for measuring the usability of systems. The
great thing about this particular tool for measuring satisfaction is that its been shown to correlate
very strongly with lots of other measures of usability and in fact is one of the best measures we
have.
Theres also a lot of comparative data online that you can use to compare your system against.
So how do you come up with a score? Well, you compute a number from the responses you get
from the participant. This slide shows you how you would go about doing that. And the number
that you get varies between zero and 100. However, its not a percentage scale. The number that
you get in fact is very non-linear. Any scores below about 60 are actually pretty rubbish so you want
to make sure that your systems scoring above that. And theres a lot of material online thatll help
you interpret the score that you get.
Again, lets assume that this score 55 is the average we get in a usability test. We can now set a
more challenging objective say 70 and work out what we need to do to achieve that.
95
David Travis
6-07 The Usability Dashboard

OK, maybe you are suffering from theory overload at this point, so let me show you a real example
from a project that I worked on where we can put our usability measures together and create a
dashboard that we can use to measure progress.
And you can see, without having to go too deeply into the details, there are real numbers on this
usability dashboard. Theres an overall benchmark, an overall UX score if you like, and thats
shown at the top left, and its about 61%. And thats based on a task completion or an effectiveness
measure, a speed of use or an efficiency measure, and a desirability or a satisfaction measure. In
this particular study, I used the word desirability because I thought it was a bit more sexy than
satisfaction and it made the client happy to use that word instead (but it was based on the System
Usability Scale). These measures were collected in a usability test by asking participants to carry
out particular tasks, particular red routes.
You can drill down to the next level of that dashboard and you can see that the tasks were around
buying particular phones in an online phone store. And we can get below that and ask how
competitors were doing, and we can go below that and look at the specific strengths and
weaknesses that the different system have.
One interesting thing about this, is that when I put this report together, it was aimed at a human
factors team in an organisation where our big fat reports werent being read and I thought, Well,
what if we created a short report for them. How short could we get? Whats the shortest report we
could provide? And I thought: one page. What could we do with a one-page report. And this is
what we came up with.
What was interesting was that it very quickly went from the human factors team to broad
members. In fact, it started getting shown at board level in the organisation (which wasn;t
Vodafone, by the way: it was one of their competitors who we were working for. If I showed you the
report for the organisation we were working for Id have to shoot you after you finish the course).
In this particular one, it ended up at board level. And it just shows you, when you start measuring
this kind of stuff, senior people start paying attention.
So lets return to our example. Heres our solution hypothesis: Motorists will find it easy to use an
app that requires them to enter their car reg and a 5-digit code on each parking meter. Now we
know how to operationalise that term easy: we can measure effectiveness, efficiency and
satisfaction.
Now heres an interesting thing. Just like in George Orwells 1984, all measures of usability are
equal, but some are more equal than others. For some systems, efficiency may be the most
important metric: imagine for example a system aimed at expert users, people who use the system
every day. Their system needs to be effective people need to be able to complete their tasks
and it needs to be satisfying to use, but it better be efficient and quick to use or the system will be a
failure. So systems aimed at expert users, you want to make sure that you focus on efficiency as an
important component.
So looking at our car parking payment machine, would you say that one of the three measures of
usability are more important than the others? Do you think the design team should focus more on
effectiveness, more on efficiency or more on satisfaction?
You need to make this decision on a per-project basis. Theres no answer that will apply to every
situation. But in this example, I reckon that effectiveness is probably the most important: what
matters is that people who may have never used the machine before should be able to successfully
use it to pay for parking. So we prioritise effectiveness in this situation. We obviously dont want
people to take hours over it, or hate the system, but we wouldnt prioritise efficiency and
satisfaction over effectiveness.
And heres another question. So lets assume we did agree to prioritise effectiveness and decide to
96
David Travis
measure task completion. What task completion rate would be a strong signal of success or failure?
50%? 70%? 90%?
Again, these are decisions that you need to make on a per project basis.
So let me leave you with this quotation from the Nobel-prize winning physicist, Richard Feynman.
If it disagrees with experiment it is wrong, he says. In that simple statement is the key to science.
It does not make any difference how beautiful your guess is. It does not make any difference how
smart you are, who made the guess, or what his name is if it disagrees with experiment it is
wrong. That is all there is to it.
And this is one reason I think why this technique is so powerful. Its like a science of design. It takes
the decision out of the hands of the HIPPO the highest paid persons personal opinion and
instead it allows you make these decisions based on data.
Its an incredibly powerful technique and I hope youre able to use it.
97
David Travis
7-01 Introduction - The Elements of User Experience

So I wanted to turn now to looking at navigating your system and organising functions in a
particular way so that people can find the information they are after. And to begin, lets look at the
course roadmap.
So were still in creating the user experience and were in this section, develop the information
architecture.
Now let me introduce you to a diagram thats been very influential in the field of user experience. It
was created by Jesse James Garrett.
This diagram challenges a preconception that many people new to the field have that user
experience is about the way things look. As you can see from this diagram, Visual Design is just
one part of the jigsaw. But visual design is just the surface layer of your system.
Below that, youll see other, increasingly important, areas of design. At the lowest level, we have the
strategy: the user needs and the objectives of the system. Above that, we have the scope of the
system, such as the functional specification. One layer up from that we have the structure of the
system: interaction design and information architecture. And above that we have the skeleton,
which includes the information design.
Right now, I want to talk about the middle layers of this diagram: interaction design and
information architecture. And Ill start with information architecture.
Now, that term, information architecture, I dont know, sometimes I think of it as a bit of a
pretentious term. Theres a British comedian called Alexei Sayle and he used to do a skit where he
would say things like: "Anyone who uses the word 'workshop' who isn't connected with light
engineering is a tosser. To follow on from that, Im tempted to say, Anyone who uses the word
'architect' who doesnt work with bricks, mortar and blueprints is a tosser."
But nevertheless its a term thats certainly got a lot of traction in the field, so its a term that well
be using.
98
David Travis
7-02 Introduction to Information Architecture

To help you get a better handle on what information architecture covers, I wanted to show you
another picture. This diagram won a competition sponsored by the Information Architecture
Institute.
They ran a competition for people to create a diagram that explained what information architecture
was. And this was the winning entry.
And the reason for showing you this is that sometimes people think information architecture
means a lot of the stuff weve already covered, to do with field visits, and stuff were going to cover
later, such as usability testing. In fact, its a subset of the user experience field and its really
focused on helping people get access to the kind of information that theyre after, such as the kind
of things that are shown on this particular diagram.
So, effectively information architecture is the means by which we get from a pile of disorganised
random content to something thats more structured.
Note that information architecture is about recognising the way information flows between a
person and a product or service.
Think for a moment about the range of information seeking behaviours you engage in.
Sometimes, youll hear people say that there are two types of user: search dominant and browse
dominant. In other words, there are people who just want a search box and there are other people
who want a good navigation scheme so they can have a look around.
This is way too simplified. People dont have an in-built preference to search or browse. Instead,
the way they go about finding information depends on the type of task they are doing at the time.
Think for a moment about the behaviours you engage in with information. Youve almost certainly
spent time finding a known item. Imagine using your intranet to get an expense form, or using your
phone to find someones contact details. With this type of task, you know what you want and you
have the words to describe it.
Youve probably also spend time exploring information. When exploring, you have some idea of
what you are looking for, but you may not have the terminology to explain it. You may be doing
research into a new kind of product, or researching a medical condition. You may also do this
behaviour when you are trying to discover unknown, but related things.
Perhaps youve spend time refining and narrowing information. This happens when you have a
large number of items to choose from and you want to narrow down the list to just the ones you are
interested in. Imagine looking for a particular photograph that you took last Summer, or imagine
that you know whats important in your next television but youre not sure what brand or model
you want.
Maybe youve also spent time comparing information. You engage in this behaviour when you have
a small number of items that you are interested in and you want to look at the similarities and
differences to help you choose between them. Shopping for a product is an obvious example:
imagine you are comparing two different kinds of tablet device and want to choose between them,
or imagine youve moved to a new area and you want to compare different medical practices.
And then theres that annoying behaviour we engage in when we need to re-find something. This
behaviour is when youre looking for something youve seen in the past. You may or may not
remember the place you saw it last. Your webs browser history is an example of an implementation
that tries to help you with that behaviour.
So dont fall into a simplistic way of thinking and repeat the myth that people only search or only
99
David Travis
browse. Our behaviour is much more nuanced than this.

Heres a quotation from Richard Saul Wurman, who actually coined the term information
architect and isnt a tosser. In fact, hes the person who first set up the TED conferences, so if
youve ever watched a TED video, hes the person to thank. Anyway, heres a quotation from him
where I think he captures the purpose or need for information architecture really quite well.
The Library of Congress wouldnt be of much value if all the books were piled randomly on the
floor. The way information is presented and organized is as important as the content.
Think for a moment. How do you organise your books at home? Most people do it in a fairly
predictable way by subject, genre or author. But some people organise their books according to size
or even colour. Now can you imagine trying to find a particular book in someone elses bookshelf if
theyve organised their books by size or colour? I mean what if youd never actually seen the book
before? Effectively it would be like having a random organisation.
So what Richard Saul Wurman is saying here is really quite profound. What hes saying is that the
way content is organised tells you more than the content itself. So, for example, if you popped into
your local bookstore looking for Jakob Nielsens book on web usability or whatever, then you might
notice as youre looking at it on the shelf that a few books further along theres a much slimmer
volume entitled eCommerce Usability by David Travis. You look at it and it looks like great value
and you decide to buy it. What a great idea. Well, the point is, you probably wouldnt have gone in
looking for that book, but because of the way the information was organised within the book store
it enabled you to find other stuff that was close by and related.
So in other words, information is more than the sum of its parts. The way its organised tells you
something.
OK, time for a quick break.
Heres a quick activity for you. Imagine you work for a design team and you are creating a new kind
of address book that will run on a mobile phone.
Your job is to come up with various ideas about how to organise the contacts. So obviously, by
alphabet is one way. How many others can you think of?
Take a few minutes to come up with an idea, and then return here to learn about a great technique
that will allow you to generate dozens of ideas to this kind of design problem.
100
David Travis
7-03 LATCH - The 5 Hat Racks for organising information

So lets turn now to some specific ways of organising information within a system. And again I
wanted to show you a quotation from Richard Saul Wurman who we heard from earlier.
In this quotation, he says:
Information may be infinite, however...The organization of information is finite as it can only be
organized by LATCH: Location, Alphabet, Time, Category, or Hierarchy.
Ive tried a thousand times to find other ways to organize, but I always end up using one of these
five.
Now, Richard Saul Wurman wrote a book called Information Anxiety and in it he introduced this
idea of what he called five hat racks: the five ways you can organise any kind of information.
These five organisational schemes are: location, alphabet, time, category and hierarchy.
And what I wanted to do now was step through each of those items and show you how you can use
them as a way of organising the content in your system. If nothing else, youll find this approach
acts as a really great creativity booster. So next time youre in a meeting and someone says to you,
Well how can we organise this type of information? youll find most people in the meeting might
come up with one or two, different ideas. With this particular approach using LATCH, you can
often come up with quite literally dozens of different ideas for how you should organise content.
So lets go through them one by one.
So first up we have location. And thats chosen when the information youre comparing comes from
several different sources or localities.
So, if you were creating a website to help lay people self-diagnose a medical problem you might use
different locations on the body to organise medical conditions.
Or if it was an industry you might want to know where in the world goods are distributed.
This particular example shows a map of France. Now this isnt just a pretty map of France. For
example, imagine you go out for a meal and have a bottle of wine from the Dordogne region.
If I like the wine, I might be curious what other regions are geographically close by, because
presumably the wines will taste similar since they will have a similar climate and similar soil. So
that means the Gironde may have comparable wines.
In other words, it tells us something extra about the information that we wouldnt have got if the
wines had just been organised alphabetically.
Location based schemes are everywhere at the moment. Last time you downloaded an app to you
phone, I bet it asked for permission to use your location, perhaps to offer a location-based discount
or to help you find other like-minded people nearby.
So, Location was our first stop on the LATCH acronym. Alphabet is the second.
An alphabetical scheme is probably never the only kind of scheme youll use to organise
information, but it often makes a a good secondary scheme. This is because everyone is familiar
with the alphabet so they can use the alphabet to narrow down their search for information.
The important point is that when you create your A to Z, make sure youre using the words that
people actually use to describe the content that theyre after, not just the words that either you or
your organisation prefers. For example, if youre designing a web site that sells sweaters, dont just
101
David Travis
list your product under the letter S for Sweater. People may also use terms like pullovers or
jumpers, so you should use those synonyms in your alphabetical list too.
And alphabets best used when you have a large amount of data, like products or names in a phone
book. And as everybody is familiar with the alphabet, categorising by alphabet is useful when not
all of your audience is familiar with some of the other kinds of groupings or categories that youre
using. So, as another example, thinking of our organising wines, we could organise a list of wines
alphabetically by grape or by vineyard.
So, Location, Alphabet and now Time.
Time is a obviously a good way to categorise events that happen over fixed durations. So, meeting
schedules on a calendar would be one example. The contribution of a scientist might be displayed
on a timeline as well. And time is an easy framework to observe changes and make comparisons as
well. Heres an example of organising wines by vintage or by best drinking date.
OK, lets turn to the fourth letter in the LATCH scheme: category.
Category is probably the most prevalent way of organising information, especially on the web. I
came across that quite fun billboard for OfficeMax a while back and I thought it made the point in
quite an interesting way.
Theyre not real birds you know on top, theyre plastic birds. Theyve not actually flown down and
organised themselves. Unless theyre very clever.
he number of categories is pretty much infinite, but some common examples include:
Format: Where you organise your content around the format of the file. For example, Google
organises its search around web pages, images, videos etc. This works when people are looking for
a specific format of something.
Organisational structure: This sometimes makes sense for intranets but rarely makes sense for
external facing web sites.
Task categorisation: For example, PayPal organises its web site around tasks like Send money and
Request money. Task-based schemes tend to work best when a system has a small set of possible
tasks and there are clear boundaries between the tasks.
Audience categorisation: This type of scheme works well when you can split your audience into
very clear groups and importantly when users can identify which group they belong to. Dells web
site does this with its Home, Small Business and Enterprise categories.
Subject or topic categorisation scheme: This is probably the category scheme youll use most often.
A subject or topic scheme groups similar things together depending on what theyre about. For
example, news articles on a web site might be organised by World news, UK news, Sport,
Politics, etc.
Were going to talk a lot more about organising by category in a moment when we get onto card
sorting.
The fifth and final hat rack in Richard Saul Wurman LATCH acronym is hierarchy.
Now, I prefer to think of it as magnitude rather than hierarchy. I think hierarchy makes you think
of a strict taxonomy, like an organisational chart in a company. But in fact its really about size or
magnitude.
He probably would have used magnitude in his hat rack model, except that he would have acronym
that went LATCM rather than LATCH, so I guess thats why he chose H for hierarchy instead.
In either case, its about organising things from small to large, least expensive to most expensive,
order of importance and so on. And its useful when you want to assign weight or value to the
ordered information.
102
David Travis
Remember, that whats important about these different organisational schemes is that every time
you use a different scheme, you start seeing new information about the relationships. So if we look
at our wine example here, in this particular example theyre being organised by price in this
particular photograph. But we might find, if we organise them by popularity, that the most popular
wines are the white wines, or the most expensive wines come from France, or that vintage wines
are more likely to be red than white.
The point is, by organising the information in different ways, you get to see different information
about the relationships too.
103
David Travis
7-04 LATCH - Case Study using BBC iPlayer

Well, lets look at how theyve been applied on a particular website. So this is an example from
BBCs iPlayer. This serves as a good case study because they actually use of all these organisational
schemes in their interface. Ive described these classifications schemes as if theyre independent of
each other but as this example shows, in reality, youll find designers tend to combine them.
On the bottom left of the screen you can see how theyre organising television channels by location,
for example with the London schedule thats shown there at the moment.
Now alphabet. This shows an alphabetical list of television programmes, and of course you can
search for your programme as well at the top right.
Theyve also organised their content by time, so in this example you can go backwards and
forwards in time to find the programme you are after.
And this screen shows how they organise the content by category. In this example, I have the Arts
category selected.
And finally, theyre using hierarchy or magnitude to organise content too, in this example showing
programmes by popularity.
Now Im not saying you should use all of these organisational schemes when you plan the
information architecture of the system. But hopefully, thats given you a good background in what
the main organisational schemes are about.
So now I have a quick exercise for you to carry out.
Heres the same question I asked you before. Now go through the exercise again, but this time see if
you can generate more ideas using the 5 hat racks.
Or alternatively, think about the design project youre working on, like Find My Pet.
What would it mean to use LATCH to organise the content in that application?
Take a break and try this activity before continuing. That way youll get a better understanding of
what the LATCH model is all about and how useful it can be.
104
David Travis
7-05 Introduction to card sorting

So its clear that structuring, managing, organising, labelling and finding information is really
critical to the design of our system. So what tools can we use to better understand how our users
think of the content that we have? Lets say that we are going to ask users to get involved. How
could we get them to structure the content or us?
Well, theres a technique I wanted to talk to you about called card sorting. And its really useful for
organising the most common kind of way we organise information, which is the category
information. The reason its problematic to organise things by categories is we dont always know
the categories people are using. And this technique, card sorting, is a great method to help us
uncover what those underlying categories are. Card sorting allows us to rummage around inside
our users heads.
Heres how it works. We take a bunch of disorganised stuff and the stuff here, each of these cards
represents the title of a function in our system or a page in our website with a short description of
what its about. And then we give those cards to our users, and we say, Put them into groups that
make sense to you.
In this particular example the participant has created three groups.
Then I give participants some sticky notes and I say, What is it that makes those three groups a
group?
They can either write a sentence or a short word. Whatever it is that captures what it is that makes
them a group. I then collect the data from about 15 or so users and then from that data, I analyse it,
work out where the common groups are and then create an information architecture which
structures the information.
So the top example shows a strict hierarchy where you can only access a lower level page via its
parent. The bottom example shows a hub and spoke pattern which is useful for multiple distinct
linear workflows like an email application on the web, where you might return to your inbox at
several points after reading a message, sending a message, adding a new contact and so on.
But card sorting doesnt predetermine what kind of organisation scheme you would use. What it
tells you is the categories people have in their heads for this kind of information.
If we were going to do a card sort, heres an example of how it might work. Our participant has
turned up for a card sort and weve given her a stack of cards to organise. So she starts putting
them into different groups. She might start by creating a few big groups. And then perhaps she
splits some of the groups up. She might combine some of the groups. Eventually she ends up with a
number of groups that shes happy with and then I give her some blank cards and on each of those
blank cards, I ask her to write down what it is that makes those items in the group go together?
What is it that binds them together, as a group?
Ideally shell write a short sentence which we can then use to put within our navigation structure,
but its not her job to design the interface. Thats why youre paid so much.
Her job is simply to tell us what is it that makes them go together. So she can write a sentence if she
wants. She can write a paragraph. What were trying to get from her is what is it conceptually
that makes these things go together?
If we looked at it from her perspective, this is what she would have seen when she first came in to
the session.
You can see here weve got some practice cards at the bottom right. In this example theyre TV
programmes. Theres about 12 of them. And the reason for having these practice cards is it makes
sure that when users start on the task of sorting your own content, they at least know what theyre
105
David Travis
meant to do. The reason for using these practice cards is people can organise them in any way they
want. They can organise them by channel, BBC1, BBC2 etc. They can organise them by genre,
comedy, soap opera and so on. They could organise them by the time of day that theyre on. Just
like in the iPlayer example we showed earlier.
So theres various ways that they can organise the content according to what makes sense to them.
And then that helps participants realise that theres no right or wrong answer. I tell people that this
will be for a system that will be used by people like them they obviously shouldnt come up with a
scheme that makes sense only to them and not to anyone else, for example, Programmes I like and
programmes I dont like. That kind of scheme wouldnt be very useful.
Weve also got here a statement of informed consent. That just tells the participant how were going
to store their personal data. Whenever you do user research, you need to obtain informed consent
from your participants so they know they are under no obligation to take part.
And then we have some blank cards. You may not be able to see but thats a piece of card thats
perforated into four and the user would tear that into four separate cards and use those blank cards
for naming the groups.
And finally weve got the cards themselves. Again, theyve been printed on A4 card. That just makes
the printing process easier. But before the user starts the session, shell separate those into
individual cards.
Youll also notice that the cards have barcodes printed on them. This is simply because it makes
data entry easier. Lets say youve got 15 participants. Lets say you ask each participant to sort 100
cards. And then lets say that you type the answers into Excel afterwards. Even if your data entry
error is as low as 1%, which is a bit of a challenge, youre still going to mistype 15 data points.
Barcoding means you can remove that error entirely and although you do feel like you work on a
checkout when youre adding the data to your system, it does mean that you reduce any problems
through poor data entry.
Heres an example of the real card sort in progress.
This photo shows 5 participants who are taking part in a card sort that I ran for an online retailer.
Now, I need to make an important point here: these people are doing the card sort independently.
Theyre not working as a group. The only reason they are co-present in the room is to reduce the
amount of time taken to collect the data.
For example, imagine I ran these sorting sessions as 1-1 sessions. Our participant would turn up,
Id need to welcome them, make them a tea or coffee, then Id need to explain what the session is
about. Id need to go through the practice activity. Id need to do the statement of informed
consent. Then I would give them the cards themselves. And then afterwards Id need to debrief
them and find out about the groupings that theyve created.
Theres lots of stuff in there that I would then need to repeat for the next participant: the
welcoming, the statement of informed consent and so on. By running people as a group, what
youre able to do is get all that kind of administrivia out of the way early on. So you can get all of
those things done early. And that means you get them done once for everyone and then you can get
straight into the card sort. In practice, that means you can typically run 15 people in a single day. If
instead you chose to run each person individually, it might take you say two or three days to collect
the same data. So, Id recommend you run people as a group. You dont have to, but my
recommendation is you do that simply because its much more efficient.
But just to remind you, people dont sort the cards as a group. People sort cards independently.
They dont discuss their findings with each other until the end when well have a discussion about
the groupings that theyve put together.
106
David Travis
What I wanted to do now was show you an example of an alternative way of running a card sorting
session. Ive talked about card sorts where participants are in the room with you. What I wanted to
do now was show you that you can actually do these online as well. So lets look at what an online
card sort might look like.
So now you have an idea of the process, Id like you to take a break and do a card sort.
Youll find the link in your notes or you can type it in to your browser.
Heres your briefing.
You are part of a design team developing a web site that sells financial products.
Each of the main web pages have been written onto an index card.
Sort the cards into groups that seem logical to you. You can use as many or as few groups as you
wish.
Go ahead and do that now, and then return here.
107
David Travis
7-06 Card sorting demonstration

So I wanted to show you an example of an online card sort you can carry out. Youll find the link to
this particular study in your notes and I show it on a slide at the end of this video as well. But I
would encourage you to actually do this yourself, because when you do a card sort you get a very
good feel for what the experience is like from the participants perspective. So its worth doing.
So in this particular online tool, imagine Ive been sent an email or Ive followed a link from
Twitter or whatever and Ive landed on this particular page. So now Im going to be like the user in
this particular card sorting study. So first of all, its asking for my email address. I click on continue
there, and then it gives me some instructions. My task is to organise a list of items into groups that
belong together, Im going to OK that. Youll notice on the left-hand side we have a series here of
effectively what these are, are cards. They are the same cards that we just had with our physical
card sort. And if I hover over them you can see a description of each particular one. So this is the
card with the description on it.
So lets say for example Im doing this card sort. The way I tend to do this is that I tend to pull
across six items without really thinking about it. Just like if I had physical cards and I dealt out six
cards. And then I look at these and I say, Do any of these obviously go together? And I notice that
there is a couple here to do with loans. There is one, Best selling loans and there is one, Best
loans guide. The way I think of it, they kind of go together, but none of the others do here. And
then Ill pull another one across: Rate Alert. Im not sure what that is: Im going to hover over it.
Register now for up-to-date news on the cheapest loans and financial deals. OK, that still doesn't
go with any of the ones here. Ive definitely got this one here to do with loans. So Im going to go
over here and I can see another one, which is loans, and Im going to put that into that group.
Im also going to look at the other options here. Are there any others that are obviously to do with
loans? Well, theres one here that is to do with mortgages; thats not really to do with loans. Ill pull
that one actually into Best Mortgage Deals instead. And now I have a couple of groups that are
already emerging. Im going to call this group, Loans. Im going to call this group, Mortgages.
And you can see how you can go through the whole process of carrying out a card sort.
Now, I don't want to do that here because I don't want to influence you, because Im going to ask
you to do the same sort in a moment,. But this will give you an idea of the way that particular
approach works. So you get a feel for the way an online version of card sorting can be carried out.
OK, so now you have an idea of the process. Id like you to take a break and do a card sort for me.
Youll find the link in your notes (p40) or you can type it into your browser
(https://demo.optimalworkshop.com/optimalsort/webusability). I've got it on this particular slide.
Heres your briefing: You are part of a design team developing a web site that sells financial
products. Each of the main web pages has been written onto an index card. I want you to sort the
cards into groups that seem logical to you. You can use as many or as few groups as you wish.
Go ahead and do that now and then return here.
108
David Travis
7-07 Card sorting data analysis

If you do in-person card sorts, then you wont be able to analyse them using the Optimal Sort
system. So here are some alternatives.
First up, I dont recommend you try to do this analysis from scratch. It uses a technique called
agglomerative monothetic clustering. I find that phrase is worth about five grand when I include it
in a proposal. Now, conceptually I understand what its about but in practice I cant do an
agglomerative monothetic clustered card sort analysis to save my life. I need to use software to do
it.
If Excel is your thing, youll find a free spreadsheet you can use.
If youre more of a statistics wonk, then youll be familiar with the stats tool, R. So Ive linked here
to a great tutorial that explains how to use R to do the analysis.
Both of those tools are free.
If youre willing to spend money, then one piece of software that I use is called SynCaps. Its the
Windows based card sorting analysis tool that Ive listed here.
And there is also the web based tool that I mentioned earlier from Optimal Sort.
The main advantage of web based card sort over an in-person card sorts is, of course, that you dont
need to have your participants co-present. Another advantage is you can easily get very large
samples. Its pretty trivial to get 100 or so people to do a card sort for you. You might think because
of that the data will be much more reliable, but in fact, in my experience, when Im physical present
with users doing the card sort, they tend to be very diligent when theyre doing the card sort. Im in
the room with them, they concentrate, theyre away from their desk, theyre not distracted. When
people do online card sorts, frankly theyre probably checking Facebook, theyre on Twitter, theyre
checking email and then theyre dipping in and out of doing the card sort.
As a consequence theyre probably not concentrating as much so you need the larger samples to
balance the variability that youre going to get with an online card sort. Nevertheless, theyre
equally useful. Id recommend both to you. It really depends whether or not your users are easy to
get to. If its difficult to get to your users, run a web based card sort. If you can get to your users, do
an in-person card sort.
109
David Travis
7-08 Card sorting analysis example

So I wanted to very briefly go over the kind of results that you get with an online card sort and give
you a feel for the kind of analysis that you do. Its pretty much the same as you do with an in-person
card sort or an online card sort and this enables me to give you a feel for what its like. Now, this
isn't going to be a extensive tutorial, Id encourage you to go to the Optimal Workshop web site and
read their help and support if you are going to do this for real, but this should give you a feel for
what its about. You can actually look at these results yourself and you can play around with them
by using the link that you will find included in your notes. So here, for example, when you first land
on the results page, it gives us an overview.
We can see here that we have had nearly 400 people complete the card sort. And about just under
200 actually abandoned. So altogether we are getting close to 600 people who have taken part in
this card sort. So a fairly large sample size really. And its also telling us down here how long
people take. So depending on what average you like it looks like its about 8 minutes that it is taking
people to do this particular card sort.
Im now going to jump into this analysis tab. Im actually going to go straight to a thing called the
Similarity Matrix. And what this shows us is the way people have grouped together, or the number
of people who have grouped together the different cards. So let me take a specific example. If I
hover over her, on this number 82, what you can see is that 82% of participants groups together
Unsecured Personal Loans with Compare Loans. Youll also notice over here that 95% of people
so basically nearly everyone has placed together Best Selling Savings Accounts and Best
Savings Accounts. And what this is telling us is the kind of things that people are grouping
together. It tells us we can take any pairing, another example might be over here: Mortgage
Protection and Poor credit history. Nobody ever puts those together, 0% of people (actually it
says in the pop-up I can see here, 2 times, which has been rounded down to 0%, so basically very
rarely) people put those items together. Another example here: Mortgage Quick Search and
Refused Credit Guide, actually 3 of our participant placed that together but rounded down that
comes up as 0%. So basically some items don't get placed together and some items do, quite
robustly, and that gives us a good feel for what things are being grouped.
We can also look at something called a dendogram representation. And in this dendogram
representation we can even look at the kind of group names we have. So for example, what this is
showing us, its kind of like a tree based view, so the things down here, that are close to each other
are very strongly related to each other, they are most often placed with each other in a card sort and
the things that are further away, so Compare Credit Card and Find a Mortgage are not close to
each other on this tree. You can think of it as a branch with twigs and leaves and everything else,
and the closer the leaves are to each other the more strongly they are related. But if, for example, we
hover over one particular branch of our tree, that first one here, we can see Compare Credit Cards,
Best Selling Credit Cards and Best Credit Card Design are quite strongly placed with each other.
And in the pop-up there, you can see that the words that people tend to use for that group are
Credit cards, Credit Card or Credit [space] Credit card with a small c. There are ways in
Optimal Sort that you can group these different ones together because obviously they are the same
terms. But because of small typographic differences they have not been placed as one, into one bin.
But you can fix that when doing youre doing your analysis. But if we go over here to these next
three: Debt consolidation tool, Refused Credit Guide and Poor Credit History, they also tend to
be placed together and the kind of labels people use is Poor Credit or Debt or Debt
Management. So that givers you a feel for how you can use that tool to get an understanding of
where your groups are and I encourage you to have a look at the demo of the analysis so you can
actually play with this yourself and get a feel for an understanding of the groupings that participants
came up with in this particular study.
110
David Travis
7-09 Semantic matches and faceted navigation

One of the things that might have occurred to you when you were carrying out the activity is that
there are some superficial similarities that may make you put cards together.
For example, you notice in the previous cards how I put everything to do with the loans together.
Well, that worked quite well because they were all kind of relevant to do with loans. But theres a
risk with card sorting: sometimes, youll find people put cards together simply because they share a
common word but that really they dont go together in terms of the underlying concept.
Heres an example of where they might happen. Lets say youre doing a card sort of an intranet and
you had three cards, manage absence and holidays, manage difficult colleges and change
management. It may well be that people put these together simply because theyve got the word
manage in, because theres lots of cards and they just cant be bothered to do the card sort
properly.
So to overcome this obvious source of bias you might want to think about modifying the item
names, for example, to absence and holidays, coping with difficult colleagues and change
management. Because now, if somebody puts these three together, they really are conceptually
related and theyre not just doing a superficial lexical match.
This particular example is taken from an article on card sorting from the Encyclopaedia of HCI. Its
a free article you can download. Ive included the link on the slide here. I recommend that you have
a look at that. Its by a guy called William Hudson whos a world expert on card sorting.
One issue that you might find when you run a card sort is that your card sorting results are quite
variable. You find that theres no common groups amongst people. Lots of people seem to have lots
of different groups. The reasons for this is that there are many types of ways of organising
information (as weve seen with the LATCH model) and it may well be that for some forms of
content, theres not a single, dominant way of organising the information.
So for example, lets say I was asking you to organise clothing on a web site that sells fashion. You
could organise the content by garment type, by season, by colour, by whether its evening wear or
day wear etc. And in a corporate intranet, you could organise content by topic, team, the date it was
last updated and so on.
Heres an example of a screen from Epicurious, which is a recipe website, and it shows that there
are many ways to find a recipe, by dietary need, main ingredient, cuisine etc. And if you find that
youre getting very variable results in your card sort, that theres no real pattern from your different
users, you might want to try faceted navigation instead, like Ive shown in the Epicurious
screenshot here. Faceted navigation is a way to improve the findability of information in many
systems, particularly those with large collections of products or documents.
Faceted navigation can be quite powerful for users, but of course it adds an interaction cost: users
are shown many more options that they need to understand and select from.
Talking of faceted navigation leads me onto talking about trigger words.
111
David Travis
7-10 Trigger words

Trigger words are the words and phrases that make people click on links. Information architecture
is also about labelling remember: the labels that we use for things in our interface.
Trigger words really matter. For example, researchers carried out a study where participants were
first interviewed about what they hoped to find on a number of large websites. And when the
participants were successful in finding their target content, the words that they had used in the
interviews appeared nearly three-quarters of the time on the sites front page.
But when they were unsuccessful, their words appeared only about six per cent of the time. So
using these trigger words has an impact. If you use trigger words your users use they will find
content.
You get trigger words by interviewing your users and discovering the words that they use
spontaneously to describe stuff in the domain youre designing for. You can also elicit trigger words
in a card sort by asking participants to cross out the words you have used on the cards and replace
them with words or phrases that the participants would use.
This also applies to things like your CTA buttons, your calls to action. You need to make sure your
calls to action are easy to read, easy to find on the page and very explicit. You need to tell your users
exactly what you want them to do.
Theres a simple formula you can follow with call to action buttons: tell the customer what action to
take, and then describe the benefit of taking the action. So a weak call to action is, Wont you
please call today for more information? A better one might be Call today to learn how my fivestep programme can save you money.
Another weak call to action would be, Dont hesitate to email us if you have any questions. A
better one might be, Email enews@userfocus.co.uk to discover if usability can double your
business.
Another weak call to action might be, We hope youll consider referring us to your friends and
family. A better call to action might be, Refer us to your friends and family and receive a 20% off
coupon for your next purchase.
So, trigger words matter. They encourage people to actually click. So its a critical component of
your call to action.
Heres an example of where I dont think that was done particularly well. Heres an example of
some labelling from the RSPB site. This is a UK charity that aims to protect wildlife and the
environment. RSPB stands for The Royal Society for the Protection of Birds. This screen shot
shows an older version of their site. Theyve since changed it, but I wanted to show you this as its a
particular good example of the point I want to make.
Imagine that you wanted to buy that blackbird some bird food. Now, you want to buy that bird
some bird food. Youve got five buttons there. Birds, gardens, countryside, reserves, support the
RSPB and then theres a search box. Im going to tell you that the search box is broken so you cant
use it. So which of those five buttons would you pick?
Well, usually when I ask that question most people say, Well, Id pick birds, because thats where
Id expect to find bird food, or they might say, Id pick gardens because I put bird food in the
garden.
Some people, but not many, say, Well maybe Id choose support the RSPB because by buying food
thats what Im doing. Im providing some support for them. In fact that is the correct answer. You
should choose support the RSPB. But for most people, thats kind of counterintuitive because,
although youre kind of supporting the RSPB, thats a side effect of really what youre doing. You
112
David Travis
really want bird food to feed birds or to put food in the garden.
So thats an example of an organisation-centred way of thinking about the labels in your interface.
Now, Im not saying that if they had stuck with this old scheme of organising information they
would have lost millions and millions of pounds, that people wouldnt have been able to use the
website and so on. Im expressly not saying that. But each one of these things makes it more
difficult to use the site and if you have too many of them, it becomes like death through a thousand
cuts. And if there are lots and lots and lots of these bad examples, eventually it will become too
difficult for people to use.
Lets follow that example with another one.
These are five different web sites you might go to buy a mans watch. And the question I have for
you is looking at those top level terms, which ones seem better to you, given your task is to find a
mans watch?
So at Argos we choose jewellery and watches,

at Debenhams we chose mens then watches,
at Littlewoods we choose gifts and jewellery and then watches,
at M&S we choose men, accessories and watches,
at John Lewis its gifts and flowers, then for him and then mens watches,
and from Boots its gift for him, designer gift.
So some of those top level terms Id argue are better than others. So, for example at Argos,
jewellery and watches, what a great trigger word. I want to buy a watch, its got the world watch
in, its almost mindless to work out which to click. If instead we look at say John Lewis, gifts and
flowers, well, what if its a present for me, what if Im buying myself a watch? Its not really a gift.
And also that word flowers, it kind of gives a feminine spin to what this topics about which
makes it less likely perhaps that people might chose it in order to buy a mans watch. The point is
that the language that we use makes it easier or more difficult for people to find the content that
they want.
And that brings me onto one of the many myths in user experience: the so called 3-click rule or 2tap rule.
In that previous example, the problem isnt the number of clicks, its the words that are presented
to users.
Contrary to popular belief, people wont quit your web site if theyve clicked 3 times and still not
found what they are after. Usability tests show that the number of clicks has no effect on user
satisfaction or success rate.
Thats right: fewer clicks dont make users happier and dont make users perceive the system as
faster.
What really counts is ease of navigation: the constant scent of information along the users path. If
you dont make the user think about the clicks, they wont mind having to make them. So a link
with the word watch in it, well thats perfect. I dont need to think.
In Steve Krugs words, Its a mindless, unambiguous choice.
113
David Travis
8-01 Mental models, conceptual models, affordances and signifiers

OK, so weve covered the big picture thinking about your design in the section on information
architecture. Lets now zero in on some detail and start talking about screen design.
So this is where we are in the course roadmap. Were still in Create the User Experience but now
Im in this section titled, Design the Interaction.
In this section, Ill be talking about three broad areas.
First of all Im going to talk about user interface idioms or design patters that we can use to
organise the content in our user interface.
Then Im going to talk about how to use specific design elements like checkboxes and pull-down
menus.
Finally, well review ways of throwing all the stuff on the screen so it looks good.
First of all, let me make sure youve got the right definitions in your head.
Information Architecture what weve been talking about is the discipline that ensures users
can find the functions, features or content they need to achieve their tasks.
Interaction Design what Im turning to now is the process of identifying design solutions and
creating prototype user interfaces.
To begin, I wanted to talk about something called a mental model.
Youve probably heard this term mental model before. A mental model is the representation that
someone has in their minds about an object that theyre interacting with.
The term Mental Model was first used by the psychologist Kenneth Craik. I did my PhD in a lab
in Cambridge named after Kenneth Craik so I know a little about him. For example, not only was
he very bright but he died in his early 30s after getting knocked off his cycle in Cambridge.
Anyway, Kenneth Craik was the first person to propose the term Mental Models. He believed that
our mind constructs small-scale models of reality that it uses to explain and anticipate the world
we live in.
Psychologist and all round usability guru, Don Norman, adopted this idea to help explain the way
people use technology. He points out that a users mental model is based on belief, not facts. So
peoples mental models may be incomplete or even incorrect.
Heres a question for you that might help you understand this notion of mental models.
Imagine that the heatings just come on but the room is cold. The room thermostat is set where you
normally have it (and this is higher than the current temperature). Do you, number one, turn it up,
hoping that the room will heat faster? Or number two, leave it where it is and just wait?
Well, if you picked number one, thats because your mental model is that a thermostats like a tap:
the further you turn it, the faster the heat comes out. But that doesnt match the implementation
model. A room thermostat is actually like a switch. So, mental models are a great way for us to
understand the way users think about the domain.
This example was described by William Kempton in 1986. Kempton asked people how they thought
a heating thermostat worked. He found the world was divided into two kinds of people: those who
think of it as like a tap (The further I turn it, the quicker it will warm up) and those who think of
it as a switch (Ill set it to 21-degrees and itll stop once it gets there). The first group of people
114
David Travis
turn the dial to its maximum setting, the second group choose a specific temperature. Both groups
have their own mental model of the way the heating system works but the people with the tap
model waste energy and end up getting too hot.
Theres also a related term: conceptual model. This is the actual model that we give to the user
through the design of the the products controls. A conceptual model is the way the designer of a
system has planned the system to work.
OK, lets make this a bit less theoretical.
Imagine that youve never seen an iPad. Well, actually, you probably have. So imagine that youve
never seen a Kindle. You probably have as well, so OK, lets imagine youve never seen a Nexus
tablet. OK, you probably have Right, Ive invented a tablet. Youve never seen it before because
Ive just invented it. In fact, I have my own Kickstarter, so there. You really should check it out.
Anyway, Ive just handed you my newly invented tablet and told you that you can read books on it.
Now, before you turn on this new device Ive invented, before you use it, youve got a preconception
in your head a model if you like of how youll read a book on it. Youve got certain
assumptions about how the pages will appear on screen, the actions youll be able to take with this
electronic book, and crucially how youll do those actions. Probably things like turning a page
or using a bookmark. In other words, youve got a mental model of how youll read a book on my
newly invented tablet even though youve never even seen it before.
Now, when you think about it, thats interesting, isnt it? Lets take turning a page. Thats
something that obviously we need to be able to do with a physical book but on a virtual book you
dont need to turn pages. You could have an infinite scroll that you could use instead. But clearly, if
I had a design which was an infinite scroll rather than a design that matched the pagination model
in your head, youre probably going to find it harder to use at least at first.
Youll sometimes hear this kind of thing referred to as an affordance. For example, pages have the
affordance of being turned.
An affordance is the way something can be interacted with based on its traits and characteristics. A
touch screen can be swiped, tapped and pushed.
Similarly, a door handle can be pulled. Thats why its so annoying when you try to pull a door only
to find out that the door handle needs be pushed.
Another term you may hear is Signifier - this is an indicator of how something is designed to be
interacted with to get an intended result. So for example, a form field signifies typing can happen
here. A hover state over a rectangle signifies an actionable area.
When it comes to software, you should really be talking about signifiers, not affordances.
Affordances refer to physical objects and signifiers refer to virtual ones. Most people tend to mix
the two up and only talk about affordances. Now, you wont get drummed out of the UX club if you
do this, but if you want to feel superior to your less educated colleagues, make sure that you talk
about affordances only when referring to physical objects and use the term signifier when talking
about virtual ones.
115
David Travis
8-02 Some examples of mental models

Heres an example of an implementation model for how you choose colour in the Mac OS. There
are three sliders, a red, green and a blue slider, and by adjusting those you change the colour. Now
thats an implementation model because thats the way a colour display works. There are three
primaries on a display and adjusting the brightness of each one, the display produces the millions
of different colours that we can see.
But most people dont think of colour in terms of red, green and blue. If I asked you to adjust these
sliders to get, I dont know, a silver, youd probably find it quite difficult to do. As a consequence,
Apple also provides some conceptual models to help users work out how to choose colour in the
Mac OS.
So on the far left weve got a colour wheel where you can choose the colour that you want. Weve
then got hue saturation and brightness sliders that you can use, if thats your bag. Then theres
colour names; and finally on the right-hand side, theres even coloured crayons that you can use to
try and find the silver that youre after.
Lets look at this another way. On the bottom of this slide, on the right-hand side, weve got the
mental model that the user has, this nice circle.
At the other extreme, on the left hand side, weve got the implementation model. This is how we, as
developers, think of the software, all of the sub-routines, the elements of it that work the way we
think it should work, but its mainly from a functionality or implementation perspective. Youd
never show this to the user.
And in between weve got a series of conceptual models. These are the ways we decide to explain
how the system works to the user so that they can quickly learn how to use it. Clearly, the closer our
conceptual model is to the users mental model, the quicker theyre going to get started learning
how to use it.
So now, let me quickly interview you so I can uncover your mental model of the way an ATM
machine works.
Are you ready? OK, here goes.
What information is stored on your bank card?

Is your current balance stored on the card? How about your overdraft limit or credit limit?
Your PIN? How about your name?
Where is the information stored? Is it stored on the magnetic strip? Or it stored on the chip,
if you have a chip and pin card?
What happens to the card when you place it in the machine? Does the ATM read the chip or
the magnetic strip?
Why are there sometimes pauses after you enter information?
Why doesnt the machine give you your card back once youve entered your PIN? Why does
it stay in the machine?
How do you think the machine counts out the money? For example, lets say you withdraw
50 in you local currency, 50 pounds, 50 dollars, 50 Euros or whatever, and lets say the cash
comes out as a 10 and two 20s. How is the money counted? Whats happening inside the
machine? How is it dispensed?
Do you count the money? Why? If you dont trust it, why not?
Now, Im not an expert with cash machines. But I like this example because I doubt you were 100%
confident about every one of your answers. Yet you can still use a cash machine OK, even though
your model of how it works may not be absolutely correct.
116
David Travis
Im sure youre curious to know how these machines actually work, so heres the answer.
Theres actually a man inside
Who would have thought it?
Now, this idea of mental models brings me on to talk about the use of metaphors in design. This is
because metaphors are a good way to teach novice users how a system works: its a way for us to
teach them our conceptual model.
Do you recognise this system? It kind of looks familiar doesnt it? It looks a bit like an early version
of the Mac operating system.
In fact, this is The Xerox Star desktop. It was introduced by Xerox in 1981. Steve Jobs saw this at a
demo and allegedly decided to er, copy, it in the design of the Mac OS. Youll notice its got a
wastebasket, windows, the kind of thing were family with today. And look up there at the very top
of the screen.
Its the hamburger menu! The menu that people argue about ad infinitum on mobile.
Anyway, the point is, this is a metaphor. Its a metaphor of the desktop. Even though you may be a
road warrior and not have a real desktop of your own, you still appreciate whats going on here.
Mind you, its a little disappointing I think that this was 35 or so years ago and here we are using
essentially the same metaphor on our computers. I hope that in 35 years time we have something a
little more imaginative. Like jet packs, flying cars and hoverboards. Or maybe thats just me.
117
David Travis
8-03 Skeuomorphic versus Flat design

This whole idea of metaphors really took off with mobile.
So, for example, on Apples iOS6, people instantly knew what the voice memos app did and how to
use it because it presented a rendered image of a microphone with realistic controls. Notice that
this kind of design approach screams, I know how to use this, instead of, Hmm, looks like Im
going to spend a bit of time working out how to use this.
It led, in fact, to a criticism of Apple: many of their designs were ridiculed for (hold your breath):
skeuomorphism. This is a special kind of visual metaphor. A skeuomorph is a virtual design
element that retains certain aspects of the physical interface that its based on. So, for example, if
youve got an iPad running iOS 6, call up the keypad on it and youll notice that on the F and J keys
theres a raised nipple, a dot. Now, those raised nipples are quite useful on a physical keyboard
because you can use them to touch type. But Ive got an old iPad and Ive tried rubbing that F and J
key and I cant feel any raised dots underneath my finger! They are just being used because that
object in the real world has those raised nipples and what theyre doing here is reproducing it, even
though it has no function.
With iOS7 and beyond, Apple responded to the criticism of skeuomorphic design by redesigning
the interface using a more flat aesthetic. The argument is that digital constructs have, in many
cases, become more culturally relevant than analog ones, so people may actually learn them more
quickly.
This is the same application - the Voice Memos app. Its now a more authentic digital
representation, because it doesnt show a physical microphone and a VDU meter. Ill leave it to you
to decide if you think this is a step forward or a step back in usability.
Actually, I wont leave it to you. Let me rant for a second.
There has been a lot of debate about Apples rejection of skeuomorphism.
Youll hear people well, visual designers mainly discuss the benefits of flat design vs.
skeuomorphic design. Youll find designers arguing that skeuomorphism patronises users
whereas flat design is more authentic. Indeed, right now, flat design is the new black.
But I think the pendulum has swung too far.
Visual metaphors arent always useless decoration. Maybe the iPad keyboard with its raised
nipples is useless decoration, along with the stitching on the faux leather binder in iOS 6s notes
application. But in other cases, visual metaphors provide context to your design. They can provide
design clues signifiers about how something should be used. Signifiers communicate
possibilities for action in your design. Its closely linked to the concept of an affordance: if I gave
you a hammer: youd know which was the business end immediately: its obvious in the way you
hold the tool.
We shouldnt abandon these signifiers just because some designers find them unfashionable. This
is the very definition of throwing out the baby with the bathwater.
For example, with many flat designs, it becomes increasingly difficult to work out whats clickable
and whats a label. Buttons used to look like buttons but now they look like text. With flat design,
its not always obvious whats clickable, because the design is so subtle.
Designers get these subtleties because its their job. Im sure weve all met designers who have
ridiculed a page of text because its been set in Comic Sans, or designers who feel compelled to
point out bad kerning on a street sign. Because they see it, they think everyone sees it. But my
experience from usability testing flat designs is that ordinary users dont always see the signifiers.
They are too subtle.
118
David Travis
Anyway, rant over.

So, to summarise, good metaphors provide clues about how something works, they make users
comfortable with the unfamiliar and they can make a site memorable. But you need to remember
that metaphors are only helpful for inexperienced users and they can be taken too far.
So, as an example, its easy to say a word processor is like a typewriter but you shouldnt really
use it like a typewriter. Pressing enter every time the cursor gets close to the right margin as a
typewriter would demand that would wreak havoc with a word processors automatic word
wrapping system.
And similarly the iCal interface from iOS6 that Ive shown here with its torn paper at the top left,
that came under really harsh criticism and it was dismissed as an unnecessary gimmick and
mocked for being hideous, even infantile.
So, when youre using visual metaphors in your interface, think them through and make sure youre
using them in a considered way in a way that actually helps people use your interface.
119
David Travis
8-04 Design patterns

You know whats kind of wild? We can identify products by their container designs. Youd know a
bottle of toilet bleach, even if it was empty and unlabeled, no matter what the brand. Youd know a
milk bottle, or a jar of mustard, or a cereal box just by their container shapes.
Same goes for the big software categories. Youd know a spreadsheet anywhere formula bar at
the top, grid below no matter what company made it. Or an e-mail program, a word processor or
a Web browser.
Im going to call these things idioms or if you prefer design patterns.
Idioms are important because if they match the users mental model, they help people work more
quickly.
Idioms include text editors, forms, spreadsheets and command-line interfaces.
I wanted to quickly run through some examples of design patterns with you, and then point you to
some resources where you can find out more.
Heres an example of a design pattern: parallel workspaces. This is useful when your users perform
distinct sets of tasks or when a lot of controls or information is spread across the UI.
Finally -- and this is important -- users dont need to see more than one workspace at a time.
This idiom works because the labeled workspaces structure the content into easily-digestible
chunks, each of which is now understandable at a glance. Also, tabs the most common form of
parallel workspace are very familiar to users.
The Windows 8 examples shows that tabs may not always look like tabs.
Heres another example of a design pattern: the wizard. Sometimes called a tunnel.
Use this pattern when you are designing a UI for a task that is long or complicated, and that will be
novel for the user -- its not something that they do often or want much fine-grained control over.
Use when youre certain that you know more than the user does about how best to get the task
done.
The catch is that the user must be willing to surrender control over what happens when. In many
contexts, that works out fine, since making decisions is an unwelcome burden for people doing
certain things: Dont make me think, just tell me what to do next.
Think about moving through an unfamiliar airport -- its often easier to follow a series of signs than
it is to figure out the airports overall structure. You dont get to learn much about how the airport
is designed, but you dont care about that.
But in other contexts, it backfires. Expert users often find Wizards frustratingly rigid and limiting.
This is particularly true for software that supports creative processes -- writing, art, or coding. Its
also true for users who actually do want to learn the software; wizards dont show users what their
actions really do, nor what application state is changed as choices are made. That can be infuriating
to some people.
The organiser workspace is another common design pattern. Use this when youre presenting a list
of objects, categories, or even actions. Messages in a mailbox, sections of a web site, songs or
images in a library, database records, files -- all are good candidates.
Each item has interesting content associated with it, such as the text of an email message or details
about a files size or date.
120
David Travis
You want the user to see the overall structure of the list, but you also want the user to walk through
the items at his own pace, in an order of his choosing.
Physically, the display you work with must be large enough to show two separate panels at once.
Small mobile phone displays cannot cope with this pattern.
A hub and spoke is a common design pattern used by kiosks and ATM machines. Use this when you
are designing a UI that contains several discrete tasks or content elements: forms, demos, games,
articles, transactions even entire applications.
All are reachable from one central page or window. But you dont want to link all the sections or
spokes to every other one, because of space constraints or to avoid clutter or to restrict the
workflow to force the completion (or explicit cancellation) of a task.
Ive just explored the tip of the iceberg here.
There are many web sites that collect together examples of these different patterns, often
specifically for mobile, web or desktop software. Heres one example of a web site that does just
this.
This shows just some of the design patterns on the site.
So for example, lets say that were interested in account registration
The site provides a lot of detail for every design pattern.
The content of the page is a lot longer than this. It contains examples, a detailed solution, the
rationale and a discussion about if account registration is even needed!
121
David Travis
8-05 Progressive Disclosure

Now I wanted to briefly mention a design technique called progressive disclosure. The reason its
an interesting technique is because as designers we often face a dilemma and the dilemma is that
users tell us they want all of the features and options that are available to them but they also want it
to be dead easy as well, so they dont get confused.
Well, obviously these two things act against each other. But its progressive disclosure that comes
to our rescue.
I like to think of progressive disclosure as like a reverse striptease. By the way, you wont believe
how difficult it is to find a piece of ClipArt that you can use to illustrate striptease. I think I was on
page 40 of Google before this was suitable. It was a very long afternoon. But someone had to do it,
so I suffered so you didnt have to.
Examples of progressive disclosure that you might have come across before on the web include
things like a learn more link, a related topics link, even an advanced search link would be an
example of progressive disclosure. Progressive disclosure is commonly used in desktop software
too, such as a triangle disclosure widget that you can turn down to get more information about a
file or folder.
The idea is that initially you only show users a few of the most important options and then you
move on and show all of the options that they need on request.
Progressive disclosure exploits that law of psychology that weve mentioned in an earlier lecture,
Hicks Law. Hicks Law, which is named after a British psychologist called William Edmund Hick,
states that the more items you have to choose from, the longer it takes to make your choice. And
theres even a mathematical relationship.
Progressive disclosure is powerful because it embraces several good design principles. For example,
it helps you support both novice and experienced users. It helps you limit what you show on screen.
It encourages you to think about the important stuff, which you show to users, and you deemphasise parts of the interface that support only infrequent tasks.
It also encourages us to only show users what they need, when they need it. This encourages
designers to focus the interface on making the user successful at the start.
Heres a quotation from Marissa Meyer.
Marissa Meyer was employee number 20 at Google and she oversaw the layout of Googles wellknown, uncluttered search page. Among many other things, she was Googles most senior usability
person. She left Google in 2012 to become president and CEO of Yahoo!
She says:
Google has the functionality of a really complicated Swiss Army knife, but the home page is our
way of approaching it closed. Its simple, its elegant, you can slip it in your pocket, but its got the
great doodad when you need it. A lot of our competitors are like a Swiss Army knife open and
that can be intimidating and occasionally harmful.
Marissa Meyers quotation really captures what progessive disclosure is about: Its an interaction
design technique that helps maintain the focus of a users attention by reducing clutter, confusion,
and cognitive workload. This improves usability by presenting only the minimum information
required for the task at hand.
Let me show you a specific example of progressive disclosure.
This one comes from Google maps.
122
David Travis
If you want to get directions from A to B, youve got a very simple interface for doing just that.
Youve got two textboxes, you enter your leaving place and you enter your destination. But what if
you wanted to avoid toll roads or you wanted the results in kilometres rather than miles or you
wanted to avoid motorways?
Well, Google maps also offers you the opportunity to do that, but you need to click on the options
link to get it. Clicking on the options link reveals those extra choices.
Now, notice that this one on the right-hand side, its not that complicated, is it really? Its not like
youd look at that one on the right and think, Whoa! you know, How am I meant to complete
this? Its way too complicated. Its not. Its a fairly simply interface. But the Google engineers have
made a specific decision and theyve decided that well, most people arent really bothered about
avoiding highways, avoiding toll roads and most people want their results in miles. So were going
to stick with those defaults, and not make every user have to make the decision to leave things as
they are or to change them. Instead were going to use progressive disclosure to hide them away.
So, progressive disclosure, its a great technique for removing complexity from your interface. But
there are a couple of rules.
First of all, you want to get the right split between the initial and secondary features.
So clearly in the Google Maps example, if the destination field was hidden behind the progressive
disclosure link, it would be very frustrating. The most important information needs to be shown
immediately. So, doing a contextual inquiry as some kind of analysis of users tasks is going to help
you there.
The second rule of progressive disclosure is make it obvious about how you get from the primary to
the secondary disclosure levels, so you want to make the disclosure control simple and obvious, so
label the button or link in a way that makes it obvious to users what theyre going to get when they
click on it.
123
David Travis
8-06 Choosing the correct user interface control

OK, so weve looked at user interface idioms or design patterns that we can use to organise the
content in our user interface. Now Im going to talk about how to use specific design elements like
checkboxes and pull-down menus.
Radio buttons, checkboxes, submit buttons, scroll bars, hyperlinks These are the fundamental
components of a user interface. When users see these standard controls in a user interface, they
usually know what to do with them (even if they dont always know what theyre called).
Heres a problem that I commonly see in usability testing. Users struggle with interfaces where
designers have felt the need to redesign or customise these standard controls. These basic user
interface widgets command buttons, radio buttons, check boxes, scroll bars, close boxes they
are the lexical units that form an interfaces vocabulary. If you change the appearance or behaviour
of those units, its like suddenly injecting some kind of foreign word into your conversation. Now,
some of the worlds best interaction designers have refined the standard look and feel of these
controls over decades. And they have been refined over thousands of user testing hours. Its really
unlikely that youll invent a better button over the weekend. So you users will probably fail if you
deviate from their expectations on something as basic as the controls to operate a user interface.
And even if users do manage to use your new finagled widget, they are going to waste a lot of brain
power trying to operate something that shouldnt require a second thought. A users brainpower is
better spent understanding how your applications features could help them achieve their goals.
So, dont redesign the standard user interface controls.
Now, there are LOTS of controls you can choose from. In fact, the folks at ISO tell us there are 51
different types of user interface element. This slide shows the controls listed in ISO 9241 part 161.
Youll be pleased to know that Im not going to make you sit through a description of each of these
controls. But I do want to review HOW the main types of control should, and shouldnt, be used.
The most common mistake that people make is that they use these controls in the wrong way.
For example, you would (hopefully) never use a set of drop downs to get someone to enter their
phone number
Or use a set of radio buttons to get someone to enter their county or state.
So what controls should the designer use here? How should someone enter a phone number?
Whats the right control for someone to enter their county or state?
Lets go through how you should, and shouldnt use the main types of control.
Lets start with text fields.
Text fields are easy to implement and users know what to do when they come across them. Youll
almost certainly use a lot of text fields in your interface.
But just because they are easy to implement doesnt mean you can use them without thinking too
hard. A text field isnt always the right choice.
So before you implement a text field, check that the data really is unstructured, free-form text (such
as names of people, passwords and comments). If you use text fields for structured data, you will
waste time checking that users enter data in the correct format.
In other words, instead of text fields, use datatype-specific controls that match the datas structure
124
David Travis
and constrain the input to valid values.

Here is an example of a text field being used incorrectly.
There are a couple of things wrong here.
Clearly dogs doesnt have an apostrophe and the person that did that should be shot.
But theres another particular issue as well: a text field is the wrong control here. It looks like it
wants me to enter text, so can I write two, T-W-O, or even, could I write the word several in there?
Or should I write, I have one dog called Fido.
The problem is that by using a text field, the designers now need to check for erroneous input.
So how should they have implemented this? A better design would be to have had a series of radio
buttons with options like one, two, three, four and then five or more.
Heres a quick question for you. Here Ive quickly mocked up a form that you might use to track
bugs with a system. But Ive used lots of text fields when other controls might have been better
choices.
I want you to take a break and decide how you would have designed this form. Just think about the
different possible controls for now: which inputs here must be text fields and which inputs could or
should use a different kind of control? Do the exercise, then return here for a discussion.
125
David Travis
8-07 Checkboxes, radio buttons and Fitts Law

So Im not saying this is a perfect redesign. Im sure there are lots wrong with this form other than
the controls, but I just wanted to get you thinking about the controls.
Heres some changes I made.
The first two questions must be text fields, because they contain unstructured, free form text. At a
push, I guess you might be able to use a drop down for Where did you find it? if there is a small
number of pages in the system, but I decided to leave that as a text field.
The next four questions though all have a finite number of options:
Operating system will presumably have the various flavours of the Mac, Windows and Linux
operating systems. So we could show that as a drop down list.
Browser is the same. Although maybe there will be fewer of these, so perhaps radio buttons might
be better than a drop down here.
Assign to: we dont know how long this will be, so if there are a couple of dozen developers then
maybe a drop down is the correct choice.
Severity: Ive shown that as a drop down but with hind sight that should probably be a set of
radio buttons. After all, there should only be 3 or 4 choices.
And then for Fixed I used a radio button, although I could have also used a single checkbox I
guess.
So I dont think my redesign is that good here: Ive used drop downs when radio buttons might be
better. But I hope you get the idea that we shouldnt be using text fields indiscriminately.
Lets move onto checkboxes.
One big advantage that checkboxes and radio buttons have over text fields is that they make all of
the possible choices explicit. As a user, you dont have to rack your brains or click on anything to
work out what to write in.
The top example here comes from Windows 8 and the middle from Mac OS X.
And the final example there is called a latching butcon. Butcon is an ugly word, but there you
go. It may not look like a checkbox, but functionally it is the same. Think of it as an example of a
graphical checkbox.
The key point about check boxes is that you can make multiple choices from a set of check boxes.
Lets look at some good and bad examples.
Heres a fairly standard implementation of checkboxes. I can clearly choose more than one from
the list.
Heres another example. Now they may not look like checkboxes, but they behave in the same way:
notice I can use both bold and italic at the same time, so just like check boxes I can use multiple
choices.
This is a poor example. If you ever find yourself putting together a pull-down menu with just two
options in it like yes and now, instead think, Can I implement that another way?, for example, by
using a check box to indicate affirmation or radio buttons to indicate the yes/no choice. Im not
saying that people wouldnt be able to use the interface if you use pull-down menus here, but its
126
David Travis
just bad practice. Its like bad grammar.

Heres an example of check boxes being used incorrectly. This is a survey site thats asked me, At
what level do you think its more acceptable for an employee to work from home? Theyve allowed
me to choose two options that seem to contradict each other: It is acceptable at any level and It
is not acceptable at any level. If the choices are mutually exclusive the designer should have used
radio buttons instead.
And earlier, I mentioned that you dont want to redesign the standard controls. This is a example of
some check boxes that have been created using some fancy Javascript. Now the problem with it is
that often people look at this and dont realise that theyre check boxes at all because they dont
look like check boxes people think theyre actually status indicators instead. In other words,
subscribe to our newsletter can be misinterpreted as a choice that youve made in the past and
the cross indicates you will not receive promotional emails. People dont realise they can toggle
these things on and off. So dont redesign the standard controls. Use the standard controls
wherever you can.
Now onto radio buttons.
A radio buttons tells users that they can only pick one option from the list.
The top example here is from the Mac OS.
The middle example from Windows 8.
Note also the radio button at the bottom. Again, they may not look like radio buttons but they are
functionally the same.
Here are some more examples of radio buttons in use.
Heres a good example of radio buttons used from eBay and one of the reasons I like this particular
example is because theres a default selection for the radio button: I will leave feedback later.
Sometimes youll see radio buttons implemented where theres no default selection. So, for
example, somebody might come into this screen, click on Positive but then they are unable to
deselect the positive without making another choice? How do they get back to the neutral state?
Well, you cant if theres not a default seeing. So this is a good example of having that default
setting.
Heres another example of radio buttons used incorrectly. Here, the designers using radio buttons
as check boxes, or theyve just made a mistake in the wiring of them, but here I can choose both
personal and self-employed or small business as my choice of site. If I can choose both they
should be check boxes not radio buttons. Remember, with radio buttons you can only select one
from N.
This example shows another issue you need to be aware of when using radio buttons: and that is
the distance between the radio button and the control. So if I quickly ask you to say which card has
been selected here, you might say Mastercard at first glance. In fact, its Visa thats been selected
but because the gap between the radio button and the Visa label is bigger than the gap between the
radio button and the Mastercard label, its easy to misread. An easy fix here would be to organise
the choices vertically and that would prevent the issue from occurring.
Now these may not look like radio buttons, but in fact they are. Ive taken this screen shot from
Basecamp. Although they dont look like radio buttons, they behave in exactly the same way and its
allowing users to choose one from a handful.
Heres another example of allowing users to choose one from a handful. Here we have more
buttcons, and these are from a blog posting platform. Note that the bulleted list and the numbered
list are mutually exclusive, just like radio buttons.
127
David Travis
And a final example here: this shows various authentication options for signing into a site. And
again these are functionally equivalent to radio buttons in the way theyre used here.
Another control that Im sure youve come across is the spin box or sometimes called a stepper.
These are flexible and they dont consume much screen space.
But one of the problems with these small controls is that they fall foul of Fitts Law.
According to Fitts law (named after the psychologist Paul M Fitts), the time required to rapidly
move to a target is a function of the distance to and the size of the target.
In practice, this doesnt just mean you should make big buttons. it means you should increase the
clickable area: for example, dont just make the arrow itself clickable but make the area around it
clickable too. Fittss Law tells us that we should use every available pixel to enlarge the clickable
area.
Fittss Law also leads to a notion of what I like to call Prime Pixels. Some pixels on a computer
screen are faster to mouse to than others. For example, corners and edges of the screen are
especially fast to access. So make sure that the very top of the screen, above the menu bar, is part of
your clickable area.
But the fastest-to-acquire pixel in any situation is simply the pixel at the current cursor position
which has lead to the introduction of the right-click as a context menu. Can you imagine if, in order
to get to the context menu, you always had to move your mouse to a particular location on screen?
We can thank Paul Fitts for that.
So, Fitts Law. Notice where the apostrophe is. Its not before the s, but after it, because his name
was Paul Fitts not Paul Fitt.
128
David Travis
8-08 The Drop Down Menu - The UI control of last resort?

Another common control is the ubiquitous drop down menu. These are so flexible they are used
everywhere but like text fields, they can often be overused.
One issue with drop downs is that users need to click to open the menu, then scroll to the correct
item in the list, and then make a selection. Compare that to radio buttons and checkboxes where
people can just click once, without the overhead of scrolling. This means that checkboxes and radio
buttons are much more efficient controls: they require less effort on the users behalf.
Drop down menus are often used incorrectly.
Heres one example. This is from a web site where you can buy life insurance.
How should they have designed this?
They should have used a text field or separate pull-downs for Stones and Pounds.
Another common use of the drop down menu is to help people select their country.
Heres one way of doing that. I came across this example a while ago because there was a letter sent
to New Scientist which Ive reproduced on the right-hand side. The screenshot is taken from
Blackwells online the letter reads: Are penguins fond of reading books? Reader John Grey
ordered a book from Blackwells online and was asked to click his country of abode in a dropdown
box. Among the options he could choose was Bouvet Island. Bouvet Island situated in the South
Atlantic belongs to Norway. Ive actually been there during a Norwegian Antarctic expedition in
1978, Grey tells us, its small, only a couple of kilometres long, its rocky with very steep cliffs. Its
snow and ice-capped and is the most remote island in the world. The only inhabitants are penguins
and seals.
So, the point is that often designers will copy an ISO list of countries which then theyll the paste
thoughtlessly without thinking, well, do people actually live there? Often when you use these
drop down menus, the first country is Afghanistan. Now Im not saying that people in Afghanistan
shouldnt be able to buy books or whatever, but if some alien visited from outer space and all it had
to go one was e-commerce web sites, it would probably think that these Afghans are the richest
people in the world because they always seem to be favoured when asking for your country.
Including places like Bouvet Island arent really helping people choose their country.
In fact, although that example was some time ago, Ive come across this on other websites as well.
Heres an example of one I came across when I was carrying out an expert review a while back. If
youre every reviewing someones website, have a quick look to see if theyve got Bouvet Island in
the list and if they have, theyve clearly not thought very hard about the list of countries.
So here are two alternatives.
In the example on the left, the most common countries have been filtered to appear at the top.
In the example on the right, the drop down menu has been shortened so that it includes the main
countries 30 or so that apply for Applecare. And if youre from Afghanistan, you need to
choose the final option in the list, Show complete country list.
Now, after telling you that drop downs are ubiquitous and flexible, Im now going to tell you to curb
your enthusiasm for the use of this control. Youll remember that I mentioned earlier that the drop
down is a less efficient control than a radio button and a checkbox. You probably thought at the
time, Oh come on David, its just a click! Get over it! Thats true if youre using a computer, but
what if youre using a mobile device? Heres a quotation from forms guru Luke Wroblewski.
129
David Travis
Interacting with dropdown menus on mobile and the desktop is a multi-step process: first you tap
the control, then you have to scroll (often more than once), find and select your target, and finally
move on. Its actually a lot of effort on mobile.
So heres my suggestion. Whenever you feel tempted to use a drop down menu:
First, explore your data to find the most frequent choices (generally about 5)
Then offer them as radio buttons with an other choice available
If someone chooses other, offer the next most frequent choices, generally about 10.
Using this approach, you may never need to use a drop down menu again and your mobile users
will love you!
130
David Travis
8-09 Expectations about page layout

OK, so weve looked at user interface design patterns to organise the content in our user interface
and how to use specific design elements like checkboxes and pull-down menus. Now well review
ways of throwing all the stuff on the screen so it looks good.
A quick questionIf you wanted to search this website, where would you click?
Although you may have managed to stop yourself, I wonder how many people sign up for their
newsletter by typing in a product name? Definitely more than 1, thats for sure.
Why did you automatically go to the top right of the page? The reason is because we have
expectations about where different controls will be in a user interface.
Just to show you, heres a study that was carried out back in 2006 where researchers asked users to
indicate where they would expect certain information to appear on screen. This was about 10 years
ago, but even then people had these expectations.
They gave people a schematic view of a browser, as you can see here, and they overlaid a grid on it.
And then researchers asked people various questions about where they would expect to find
various functions.
So, for example, where do you think back to home should appear? Well, in this study, the
majority of people (44%) said, top left.
How about search engine?
Well, based on what weve just said, you probably said top right and indeed that was the most
popular choice in this study too.
Now they also looked at adverts, but this was back in 2006.
Where would you expect adverts to appear on a webpage in this particular study
Well people thought towards the top, at least about one in four people felt that.
How about internal navigation links? Where would you expect those to be?
Well, in this particular study it was the left-hand side where people expected to find them: nearly
half of the people thought they would find them there.
About us, where would you expect to find that?
In this particular study again, one in five people said towards the bottom.
The fact is that people have got certain expectations about where things are.
This study was carried out in 2010, so a bit more recently, and the findings from the previous study
131
David Travis
were validated.
In this study, they asked 516 participants to carry out the same task but they actually used three
kinds of webpage. An online shop, a news portal and a company website thats the one that Ive
reproduced here.
There were some small differences between the different sites. For example, for an online shop, the
search box was expected to cover the full width at the top of the page, pretty much like it does on
Amazon.
But otherwise, peoples expectations about page layout were very similar.
So, the point is, it makes sense to emulate the locations of where most web sites put this stuff
because people are then going to find it more easily. Im not saying that people cant use your
website if you put search at the bottom and you put about us at the top right, or if you put a back
to home page link at the bottom of the left-hand margin. People will still get there in the end. Its
not completely unusable. Its simply that people have got these expectations so it makes a bit of
sense to cash in on them.
But what happens when people expect stuff to be in the same location? For example, what should
get priority at the top right on an ecommerce site, the search field or the checkout link? How do you
answer that question?
Well, the answer is: you test it.
Heres an interesting A/B test that was carried out. The designers were trying to answer just this
question: what should get priority at the top right on an ecommerce site, the search field or the
checkout link? The test was conducted on an ecommerce site for camping and hiking equipment,
and they ran an A/B test for three weeks and then compared the results.
So, if I just point out the differences between the two, in version A the checkout is at the very top
right and search is just below that but still in the top right area of the screen. In version B they
swapped the location of those two items. Which one do you think performed best in terms of
increasing revenue?
Actually, version A increased revenue by 12%. And they measured how many visitors reached the
sales confirmation page after making a purchase and used this to estimate the increase in annual
revenue and the result showed that the site made $2.3 million just by switching the position of the
shopping cart and checkout links.
So the placement of things actually matters.
When it comes to actually putting stuff in the content of a page theres a lot of research now which
shows that people tend to read webpages in a kind of an F shape.
So in an eye tracking study that Jakob Nielsen and his colleagues carried out, they recorded how
232 users looked at thousands of webpages and they found that reading behaviour was fairly
consistent across many different sites and with many different tasks.
This picture shows a heat map: this is a visualisation of where users looked on the screen. The red
areas show the most looked at parts of the display, the yellow show the next most looked at areas,
and so on.
The read pattern looked somewhat like the letter F and it had the following components.
First of all, users read in a horizontal movement across the upper part of the content area. Thats
that top part of the F bar. And then users moved down the page a bit and read across in a
horizontal movement that typically covered a shorter area than the first eye movement. So that
forms the Fs lower bar.
132
David Travis
And finally, users scanned the left side in a vertical movement. Sometimes that was fairly slow and
systematic and it appeared as a solid stripe on these kind of eye tracking heat maps. Other times
users moved a bit faster and it caused a more spottier heat map, but in either case, it formed the Fs
stem.
Now, this tells us something.
First of all (and frankly like a lot of eye tracking research) it tells us stuff that we already know:
people dont read webpages from the top to the bottom.
But this also gives us some clues about how we can get a users attention when theyre looking at
content pages. For example, the most important information, put that first, because its much more
likely to be read there than anywhere else. So you want to keep important content above the fold as
weve already discussed.
But also, things like subheads, paragraphs, bullet points start those with trigger words, because
theyre the things that people are going to be attracted to when theyre scanning down the left-hand
margin. If you break up your content with bullets and so on, people are going to see those and stop
and scan them.
And theres another implication: theres no point putting important information on the right-hand
side of the page, unless you want it to be pretty much ignored.
In fact, in another study of users interacting with over 65,000 webpages, researchers found that
45% of all clicks happen in the top left quadrant of the page when seen above the fold. So it seems
that people generally decided whether or not a page was relevant to them in two to three seconds,
and over 50% of pages were viewed for less than ten seconds.
So it just goes to show, youve got a very short amount of time to make a good impression.
133
David Travis
8-10 The Aesthetic Usability Effect and the Contrast Principle

So you can think of interaction design as unpeeling layers of an onion. Youll remember that we
talked about mental models, about the use of metaphors in design; we talked about design
patterns; then we talked about the various controls we can use in our interface; and weve just
talked about peoples expectations about page layout. Now lets talk about visual design: making
stuff look good on screen.
The aesthetic usability effect describes a phenomenon in which people perceive more aesthetic
designs as easier to use than less aesthetic designs whether they are not. The effect has been
observed in several experiments, and has significant implications regarding the acceptance, use,
and performance of the design.
Aesthetic designs look easy-to-use and have a higher probability of being used, whether or not they
actually are easier to use. More usable but less aesthetic designs may suffer a lack of acceptance
that renders issues of usability moot. These perceptions bias subsequent interactions and are
resistant to change. For example, in a study of how people use computers, researchers found early
impressions influenced long-term attitudes about the quality and use. A similar phenomenon is
well documented with regard to human attractiveness: first impressions of people influence
attitude formation and measurably affect how people are perceived and treated.
The purpose of contrast in a visual design is to create focus.
To adequately create focus you must make the object of attention very different from the other
elements that surround it. If you do not, it will simply blend in with the other aspects of the web
page.
Contrast is one of the most powerful design concepts of them all because really any design element
can be contrasted with another. You can achieve contrast in many waysfor example, through the
manipulation of white space, through color choices (cool and warm), by text selection (bold and
narrow), by positioning of elements (top and bottom), and so on.
In this example, the primary action associated with a form (most commonly submit or save)
needs to carry a stronger visual weight (in the example above bright color, bold font, background
color, etc.) than the other form elements.
Every single element of a design such as line, shape, color, texture, size, space, type, and so on can
be manipulated to create contrast.
Contrast is what we notice, and its what our eyes go to first. Step back and look at your design:
where does your eye go to first? Where does it go next? What path does your eye take through the
design? Sometimes blurring the design helps. Lets see an example.
Where do you think the contrast is in this design?
Sometimes its hard to say for sure. You could spend thousands of dollars on an eye tracker to find
out, but heres a cheaper way. Lets blur the image and see if it helps.
This is a 50px Gaussian blur in Photoshop.
What we see is a blurred figure, a green blob and a blue blob. And some black at the top. This is
where the contrast is in this design.
We know from studies of human vision that our contrast sensitivity is actually better with blurred
images than with sharp images. So what this simulation is doing is removing all of the distracting
high frequency information which stops us focusing on the contrast alone.
Im not saying this is as comprehensive as eye tracking, but its a lot cheaper and gets you 80% of
134
David Travis
the way there.

Depending on your design and how far you are from the screen, you may need more or less blur to
get the effect. Lets step through the effects of different blurring.
Somewhere amongst those blurred designs you should have begun to notice where the contrast is
in this interface. Its a simple and really effective way to find out where your users attention will go
when they look at a visual design.
The Anschluss is the term given to the 1938 annexation of Austria into Greater Germany by the
Nazi regime.
The image shows a voting paper from a ballot held in Austria on 10 April 1938.
Just in case anyone was in any doubt which way to vote, officials were present directly beside the
voting booths and received the voting ballot by hand (in contrast to a secret vote where the voting
ballot is inserted into a closed box).
The election officially recorded a support of 99.73% of the voters.
135
David Travis
8-11 The Alignment Principle

The whole point of the alignment principle is that nothing in your design should look as if it were
placed there randomly. Every element is connected visually via an invisible line.
To practice good alignment habits is to create strong lines that keep the viewer focused and cause
the page to look elegant. Good alignment helps create a clean, sophisticated, fresh look.
This is a paper from the butterfly ballot used in Florida in the 2000 US Presidential election. Its
called a butterfly ballot because the paper has names down both sides, with a single column of
punch holes in the centre. Alignment issues caused a lot of people to vote for the wrong candidate.
Aligning elements in a user interface to a simple, consistent grid, will go great lengths in reducing
the appearance of complexity. The use of strict alignment and a thoughtfully laid out grid can turn
an interface from chaotic and overwhelming to harmonious and appealing.
Which of these 2 forms looks more complicated to you? Im interested in your immediate
impression, so dont spend more than a couple of seconds making your decision.
Most people say the form on the top looks more complicated than the one on the bottom. The only
difference between the two forms is the fact that the form on the top has lots of small
misalignments.
136
David Travis
8-12 The Principles of Repetition and Proximity

The principle of repetition simply means reusing the same or similar elements throughout your
design. Where contrast is about showing differences, repetition is about subtly using elements to
make sure the design is viewed as being part of a larger whole.
So repetition means ensuring your screens or applications have a family resemblance.
But repetition also means consistency, for example in using the same kind of fonts. Visual elements
that repeat are pleasing to eye; they are the visual equivalent of a good rhyme scheme in a poem.
In addition, the unified look of a good web page causes readers to automatically think that the sites
message is unified. That is, a unified look makes people think you what you are talking about.
Think of the example of a newspaper: the repeating typescript, alignment, and headings make the
paper easy to read and easy to trust.
The principle of proximity is about moving things closer or farther apart to achieve a more
organised look. The principle says that related items should be grouped together so that they will
be viewed as a group, rather than as several unrelated elements. Users will assume that items that
are not near each other in a design are not closely related. And they will naturally tend to group
similar items that are near to each other into a single unit.
There are two important reasons for this principle. First, it helps users search for the option or
function that they need. If youre looking for the delivery costs, its easier to find if its in an area of
the screen with the label Delivery options then if its one of hundreds of choices randomly
distributed over the page.
Second, grouping functions together helps the user acquire a conceptual model about the way the
web site is organised. Netvibes demonstrates this.
Obviously, this navigation list needs some formatting to make it understandable. But the biggest
problem with this list is that everything is close to everything else, so there is no way to see the
relationships or the organisation.
The same list has now been formed into visual groups. Im sure you already do this automatically
Im just suggesting that you now do it consciously and with more strength. Notice I added some
contrast to the headlines and repeated that contrast.
Before you say, No-one would design a from like that, take a look at these examples of contact us
forms.
This is from Epsom & Ewell Borough Council. Note the checkboxes: I can be both a Mrs and a Mr!
So I dont think this is a straw man.
137
David Travis
8-13 Form redesign - Alignment

So how did you find that activity?
If you just skipped ahead to this lecture without actually trying the activity, take a break and do the
redesign. Honestly, youll learn a lot more if you try this out for yourself before looking at the
changes I made. Ill still be here when you get back!
So the first thing I did was use the alignment principle to line up the labels, fields and buttons.
This is always my first step when improving a visual design. Its related to this idea of seeing a
painting on the wall thats hanging at an angle: I just cant move forward until Ive fixed this.
I aligned the components of the form using a 20px grid. Youll find that there are lots of freelyavailable grids you can download and use in your drawing package of choice and I strongly
encourage you to make sure that you always start your visual designs by using a rid to lay out the
components.
Now we still have a long way to go. That Title field for example looks ridiculous: its way too long.
But now I can concentrate better because Ive got rid of the annoying lack of alignment.
Youll also notice that Ive got the reset and submit buttons aligned.
People often ask me, Should the submit button be on the right or on the left?
People who argue that submit should be on the left tend to use one of three kinds of argument.
First, they say its like having a yes/no question. You never say, Do you want fries with that? No or
yes? So, they argue that you should have the yes button (OK, or Submit in our example) placed
first. Another argument I hear is that people read from left to right, so you should put the most
important action first. And Ive also heard people say, Well, in Windows, OK is on the left, so
thats where your Submit button should be.
People who argue that submit should be on the right have got their own arguments too. These
people say that Submit should be on the right because its like a Next button and Reset is like a
Cancel button. Since people read from left to right, you can order the buttons in order of
importance with the Submit button the most important one coming second. A second
argument I hear is that thats how it is on a Mac. OK is on the right. Another argument Ive heard
is that if you put submit on the left users have to read all of the other buttons to check what their
options are before choosing the submit button, but if you put Submit on the right, users have
already read the other buttons by the time they get to it.
In fact, all of these arguments are just specious. You can forget them all. It doesnt matter whether
you put it on the left or on the right, theres no data to show one is better than the other. All you
need to do is be consistent. If you put in on the left on one form on your site, put it on the left on all
of the forms on your site. Just make sure youre consistent across forms or make sure you follow
the conventions on the platform youre design for.
138
David Travis
8-14 Bluffers Guide to Eye Tracking

So let me give you a bluffers guide to eye tracking.
Eye tracking is the process of determining where someone is looking. It can also measure how
someone moves their eye when scanning an object or looking at a web page.
To conduct eye tracking, you need special equipment called an eye tracker. This is a piece of
hardware that records your eye movements as you look at a computer screen, an object, or even as
you look around the environment.
Some eye trackers are attached to a pair of glasses, so your participant has to wear them; and
others can be built into computer monitors.
The first thing to say about eye tracking is that it tells us where someone is looking this is their
foveal vision, the area of the visual field that has the best acuity.
But foveal vision is not necessarily where the person has their attention focused. We often direct
our attention to the peripheral visual field. Do that now. While looking at this video, move your
attention to the world outside the screen. Maybe theres someone in the room with you and you can
direct your attention to them, even though you are looking at the screen. Its easy to do isnt it? But
an eye tracker wouldnt be able to pick that up, because thats not where your looking.
The second thing you should know about eye tracking is that it is very rarely the best way to answer
user research questions. There is nearly always a simpler, cheaper and quicker method you can use.
But as well see, it does have the wow factor!
So with those provisos, how does eye tracking work?
Take a look at this picture and notice the corneal reflection: the small, white circular light. This
thing here.
As this person moves their eye around, notice that the corneal reflection doesnt move. But now
look at the persons pupil. That does move.
The critical thing here is that the relationship between the pupil centre and corneal reflection
changes as the person moves their eye.
This is essentially how an eye tracker works. The eye tracker shines infrared light on your eye, and
then it records two things: the position of your pupil and the corneal reflection.
OK, now youre becoming an expert at eye tracking, there are two further terms you need to know
about: a saccade and a fixation.
A saccade is simply the scientific term for the movement of the eye. Interestingly, saccades are the
fastest movements produced by the human body.
To prevent blurring, your brain tends to ignore your vision during saccades. Visual information is
only extracted during fixations, which is when the eyes are still and focusing on something.
Fixations tend to last between one-tenth and one-half of a second, after which the eye moves (via a
saccade) to the next part of the visual field.
So how do saccades and fixations appear in eye tracking results?
Good question.
They appear as gaze plots and heat maps.
139
David Travis
A gaze plot is a moment-by-moment representation of a users eye movement across the screen.
Look at the picture on the left. Youll notice that some of the blobs are bigger that others. Thats
because the size of the blob is proportional to the length of time the person looked at that spot on
the screen. In other words, big blobs mean longer fixations. Imagine its a bit like placing an ink
pen on blotting paper. The longer you hold it down, the bigger the puddle of ink. The numbers on
the blobs allow you to replay the sequence of the gaze: so number 1 means is the first fixation,
number 2 is the second fixation and so on.
A heatmap on the other hand is a kind of average visualisation that shows where the user has spent
the most time looking. The eye tracking measure is displayed as colours, and the amount of heat
is proportional to the level of the measure. Although heatmaps can be created based on data from
one individual, they are much more useful when averaged across multiple participants.
OK, now you know about eye tracking, we can look at one of the areas where eye tracking has made
a good contribution to user interface design: the design of forms.
140
David Travis
8-15 Form redesign - Labels

OK, now you know about the basics of eye tracking, let me show you some research on eye tracking
and form design.
Heres a quick question: is this a heat map or a gaze plot?
Im hoping you remembered that this is a gaze plot. One way you can identify it as a gaze plot is it
has those numbers on it so you can replay the sequence of fixations. A gaze plot is a moment-bymoment representation of a users eye movement across the form. Remember that the size of the
blob is proportional to the length of the fixation.
So here is an eye tracking study carried out a while back by a guy called Matteo Penzo. What he did
was he asked users to use a form with just four field: your address, your city, company you work for
and number of colleagues. He placed the labels to the left of the fields and compared the effects of
left aligning and right aligning the labels.
Remember that the number of blobs represent the number of different fixations that the user made
when looking at the forms. And the size of the blobs represents how long the user spent looking at
that spot. Now, you can see that the top form, it looks like it was a bit harder work than the bottom
form. There are more fixations and bigger blobs. So it looks like right aligned labels are better than
left aligned labels.
So then he tried placing the labels above the fields, this time on a form that asks for name,
surname, age and city. And he tested two conditions, ordinary text for the labels and bold text. And
he found that placing the labels above the fields reduced the saccade time that is the time taken
for the eyes to move from the label to the input fields.
But theres a problem. The plonker used a different form here compared to the earlier one. The
labels in this condition are slightly simpler and that may explain the results.
However, more recent research shows that theres no difference between labels above the fields and
right aligned labels. So basically, the guideline is that you should right align your labels or top align
your labels. The main exception is when youve got very long sentences for labels: lets say you have
questions which contain 20 or 30 words. In that case, its almost certain the sentence will wrap and
if its right aligned youll get a ragged left margin, which will make it harder to read. But generally,
you want forms to have right aligned labels or top aligned labels.
So just to summarise, there are advantages and disadvantages to where you place your labels. Ive
taken this summary slide from an excellent book on form design by Luke Wroblewski and I
recommend you take a look at it if youre designing forms.
Its worth bearing in mind that slower completion times might not always be a bad thing. In fact, if
you want people to slow down and consider each input in a form more carefully, left-aligned labels
may be a good way to go, especially for forms with lots of optional fields or unfamiliar data like
advanced settings.
So I went for top-aligned labels in my redesign.
Now top-aligned labels arent necessarily the best solution because placing the label above the
input fields will increase the length of the form. And some labels may be too long to be top aligned,
for example if the label is a long question. So its not always the best solution. But for the simple
form that were looking at, I decided to go with top aligned labels.
So what other changes would you suggest we make to this design? Take a break and think about it.
141
David Travis
8-16 Form redesign - The Question Protocol

Well, one thing we might want to change is the case of the text. You can see its all in shouty text:
its in upper case. When everything is in upper case, we lose the opportunity to create contrast with
text.
So, Ive now used contrast to change the text to title case or camel case as its sometimes called.
Ive also added a bit of contrast with the title of the form. Ive also rationalised the fields. Instead of
title, first name, surname I now have a single name field. Why did I do this?
I did this to follow a good, general principle about form design. Whenever you design a form, you
need to make each question work hard to be admitted. For each question on your form, you should
ask:
Why do we need that information?

Who uses the information and what for?
Which users need to provide the information?
How will you check that the information is accurate?
How will you keep the information up to date?
This is called a question protocol; its different from the form itself, because its about how you use
the answers.
So I did that for this form and youll notice Ive got rid of the Title field entirely. I did this for a
couple of reasons. First, sometimes when Ive asked people to redesign this form who arent in the
UK they think title means their job title, not Mr, Mrs, Dr and so on. So theres an ambiguity there.
And second, it seems particularly British and class conscious to insist on someones title. Why does
it matter? This is just a contact us form, people arent applying for a passport.
When I remove the title field, sometimes people say, Oh, no, youve got to keep the title field in
there so that we can know the persons gender. Well, if you need to know someones gender,
theres a very simple question to ask: you ask, Are you male or female? In this instance I really
dont think we need to know someones title so Ive got rid of it. The fewer fields we have, the more
likely someone is to complete the form.
In fact, a researcher at HubSpot examined 40,000 contact forms and found that conversion rate
improved by almost half when the number of form fields was reduced from four fields to three. Let
me say that again: eliminating one form field increased conversion by 50%. So the very best way to
get people to complete your form is to have less of it.
But why did I go for a single Name field, rather than two fields: first name and surname? Well, a
single field is a lot more flexible than a first name and surname field. So it handles my name, David
Travis.
But is also handles an American name like Dick van Dyke or William Gates III.
It also works for Paul Intoot(?) (he runs a football stats website in Holland).
It also handles a name like Jose Luis Rodriguez Zapatero (he used to be the Spanish Prime
Minister). His name is even more complicated: Jose Luis is his first name and Rodriguez Zapatero
is his surname. Because Rodriguez is such a common surname in Spain, people use Zapatero
instead to refer to him, even though thats his mothers family name.
Anyway, very confusing, but the point is having a single name field solves all of these problems.
Another reason, for rationalising the fields is that over one fifth of the worlds population write
their surname first (including China and Japan). Having two fields does not allow you to
142
David Travis
concatenate them in the correct order, whereas asking someone to enter their full name uses their
preferences rather than your assumptions. With one field you can easily accommodate all
nationalities, naming preferences, name orders, suffixes, and titles.
Youll also notice Ive added a bit of contrast to the submit button to make it stand out against the
reset button.
But in fact, why do we have that reset button at all? I actually think that when the HTML spec was
put together some usability people got involved and they said, I know, lets shove a reset button in
there and then that gives us something to complain about when we do expert reviews. Because
there seems to be no purpose in having a reset button. You may as well rename it, Please delete all
of the careful work that Ive been doing up until now. If somebody really wants to clear the field,
they can reload the page, or they can click the back button and then choose the link again.
Now I acknowledge there is a case where perhaps you do want to have a reset button. Lets say that
you are designing an application for a call centre. CSRs are getting lots of dropped calls, theyre
getting halfway through the form and callers hang up or get disconnected. Well, maybe having a
reset button in that specific example helps rather than having to refresh the page, but this is an
edge case.
If we have a reset button in this specific contact us form, then perhaps one in a hundred people
will press it by mistake. Thats just 1% but even so if we remove it, thats one in a hundred people
whos lives weve managed to make a little bit better. Its Hicks law again: fewer buttons, fewer
choices.
So, lets burn the reset button.
And perhaps now we dont need such heavy contrast on the submit button so Im going to reduce
the contrast there.
But what about the label on the Submit button? Remember our discussion about trigger words?
143
David Travis
8-17 Form redesign - Trigger words and finishing touches

Heres an example from an A/B test where the designers wanted to test out two alternative labels
for a submit button: Send my free report and Start my free subscription. Which one do you think
was best, and why?
In the test results, version A was the winner. Version B decreased conversions by over 20% within
just two days.
You probably have a few ideas why this might be the case. Did the word subscription in version B
make people think there might be a long term commitment? Or maybe its because the word Free
in version A starts with a capital letter, and so it stands out more. Or maybe its something to do
with the fact that the buttons are a different size.
The point is, you never know why one design beats another in an A/B test. You only know that its
better. Thats important, because it means we cant use A/B tests to answer why questions in our
user research. To answer why questions we need to do qualitative research, like field visits and
usability tests.
A/B testing sometimes called multivariate testing is a really useful research technique but
remember that it doesnt tell us why one design beats another, just that it does.
So as a general rule, avoid just having the word Submit on your submit button. Instead, use a
trigger word or phrase that explains whats going to happen when the form is submitted.
So I changed the label to Send feedback. I think thats more of a trigger word.
I also used the principle of proximity to group items: youll notice I have field sets around the first
three fields and around the comments field.
They also add a nice repetition to the design, so Im using the principle of repetition too.
I also formatted the telephone number. Now Ive done this to follow on from the point I made
earlier about making sure that you dont use text fields unthinkingly. A phone number has a
particular structure: an area code followed by a number. When you have an underlying structure to
the data, it makes sense to reflect that structure in the input fields.
However, I can also see a case for keeping this as a single field. Splitting the fields the way Ive done
it here will cause problems for people who want to enter a mobile number. So Ive done this just to
emphasise the point about thinking about the text field you use.
Finally, I added some hint text for the phone number field and I also distinguished required and
optional fields.
Are there any more changes you think we could make to this form to improve it? Remember, Im
not presenting this as the best designed form in the world. Im simply showing how we use
contrast, alignment, repetition and proximity to improve the form that we started with. So if you
have any further improvements, let me know in the comments.
144
David Travis
8-18 Introduction to prototyping

A key skill that every interaction designer needs under their belt is prototyping.
Heres a quotation from Fred Brooks which I think captures the need for prototypes quite well. In
most projects, he says, the first system build is barely usable. The only question is whether to
plan in advance to build a throwaway, or promise to deliver the throwaway to customers.
I think that quotation captures the need for prototypes quite well: eventually, if you dont prototype
early and test early, eventually you are going to show the user something which you may think is
the final design but as far as theyre concerned, its a prototype. It will be the first time theyve ever
seen the interface. We can do better than that.
First of all Ill begin with defining what I think a prototype is. So, Im going to define a prototype as
a concrete representation of a design idea that serves the purpose of asking and answering design
questions. Let me say that again: a prototype is a concrete representation of a design idea that
serves the purpose of asking and answering design questions.
In other words, a prototype is going to help us work out whether were closer to or further from
meeting the needs of our users. Its going to allow us to test out our solution hypotheses. Thinking
without doing leads to trouble. You need to quickly turn your ideas into something that can be
shared. The idea is to start rough to speed up learning, show it to people and see how they behave
with it.
When I say you need to start rough, what I mean is you should prototype in a way that allows you
to design and test something quickly. In fact, Im going to encourage you to use paper.
Now, give me a moment. Before you say, Oh come on paper! Thats so twentieth century, you
know, we can use electronic tools these days, let me talk through some of the arguments for why
its worth prototyping with paper, at least in the early stages of design.
This particular picture shows some prototypes that were developed of Concorde.
Concorde engineers really did make paper aircraft at their drawing boards and workbenches,
testing them presumably outside the British Aircraft Corporation workshops that used to be in
Bristol during their lunch hours.
Now, these were made out of any piece of scrap paper or card that was available and these
primitive hand propelled Concordes, they did their bit in the design process of the most famous
airliner of all.
So, if its good enough for Concorde, it might be worth considering whether or not its good enough
for a user interface.
But when I talk about paper interfaces people tend to think I mean this. They think I mean wire
frames. But Im not talking about wire frames. Wire frames arent useful for prototyping user
interfaces. Theyre OK for demonstrating user interfaces, but to be honest, I work on design
projects these days and theres not a wire frame in sight, so you may never have to see another wire
frame again. Certainly this isnt what I mean by paper prototyping.
So then people think I mean something like this. Beautifully drawn, handcrafted user interfaces.
And people say to me, Well, I cant draw, so I cant do paper prototypes.
But you dont need to be artistic to create paper prototypes. You just need to be able to write
legibly. So long as people can read your handwriting when you write slowly, you can create a paper
prototype.
Lets look at some examples of paper interfaces.
145
David Travis
So, here weve got four examples, the one at the top left is an iPhone app thats being prototyped.
The one at the top right is a tablet device. At the bottom left we have a form filling interface. At the
bottom right weve got a kiosk based system.
Now. it may look like people are designing these interfaces. But in fact, theyre using them, theyre
interacting with them. These paper interfaces are responding to the touch of the users finger and
allowing people to write in the text boxes.
The key point is that you can create really dynamic interactive prototypes with paper. Let me show
you how.
146
David Travis
8-19 Examples of paper prototypes

Heres another example of a paper interface thats been mocked up of an in-car entertainment
system. The researchers have even created a view through the windscreen on paper too! Notice the
camera at the bottom left that;s recording where the user clicks on the paper interface.
Here are some more examples.
Here weve got a tablet application. Youll notice theres a couple of switches in the interface, on
and off switches, and theyve been drawn on removable tape. That means that if the user decides to
move the switch from on to off, you simply need to lift off that piece of sticky tape and now the
other label is revealed underneath. Its a way of toggling the control.
You can also prototype dialogue boxes quite easily. Here a large index card is being used to create
one part of the interface and a seller card shows the content of that part of the dialog. Youll also
notice on the left-hand side the privacy option has been highlighted to indicate thats where you
are in the user interface. So you can use this kind of interface to test navigation too.
You can also use paper to prototype text based interfaces. Heres an example of a Twitter client
thats been mocked up for a tablet device. You can use Greeking or squiggly lines to indicate some
text will appear here, its just not important to the use of the interface. It also stops people getting
too sucked into the content so they can focus more clearly on the user interface itself.
You can mock up quite interactive systems with paper.
Heres a web 2.0 calendar called myCal. Clicking on a date on the calendar with your finger causes
a dialogue box to appear. You can use removable tape for text fields to enter an appointment that is
then used elsewhere in the interface.
Youll also notice that theres a pull-down menu here thats written on a separate piece of paper or a
piece of card.
You can also create tabbed interfaces: what we called parallel workspaces in the section on design
patterns. Heres an example. Youve got four tabs here, general, network, update and
encryption. If the user touches the update tab with their finger, then that index card gets
shuffled to the front so that the user can interact with it.
You can also have greyed out menus. Heres an example of a greyed out menu. Its written in a
dotted font and when that option becomes available, it gets revealed in the user interface by the
person running the test who will then tear it off and revealed it underneath.
You can also have highlighting. You cant see it, but theres a piece of transparency placed over the
top of this interface and highlighting has been used in order to indicate which things have been
preselected in the interface.
The point is that what youre able to create very interactive systems with paper.
And what Id like you to do is to watch the next video which Ive brought in from YouTube: this
shows a paper prototype usability test in action. It will give you a feel for the interactivity thats
achievable.
147
David Travis
8-20 A paper prototype in action

This video about paper prototyping should give you a good idea of what some of the benefits are.
First of all, as a design team, it helps you clarify the concept. What is this thing that weve
developing? Sometimes when things are drawn, pictured, envisioned, it makes it easier for people
to then understand what its about.
It also helps tease out requirements. What is it that the user needs? This technique helps you
uncover that.
Also, if youre not a coder its brilliant because you can design interfaces with no coding skills
whatsoever.
And if you are a coder, as you see, it also allows you to test your design out with users before youve
done any coding whatsoever.
Another reason paper prototyping helps you is that it stops you being too invested in the design.
Because theres no code behind it, theres no cost to throwing it in the wastebasket and starting
again.
Paper prototyping also helps avoid pedantic comments. People wont say things like, I though your
corporate font was 12 point Helvetica? or whatever it is because its not relevant at that particular
point.
Other ways that paper prototyping helps is that it encourages you to be creative and it helps you
work fast.
This whole process of sketching is a very powerful way to communicate your ideas. This is partly
because people unconsciously react differently to sketches than they do to computer generated
drawings. Its true that some computer-based prototyping tools allow you to create sketchy style
interfaces, but theres a difference: they are always precisely rough, while hand sketches are
roughly rough. People naturally pick up on the imperfections of sketches and because of that they
understand its far from a finished design.
148
David Travis
8-21 Getting the design right and getting the right design
Most importantly though, paper prototyping helps support this approach to design that weve
already discussed, this iterative design approach. And this approach works because by prototyping
youre adopting three principles.
First of all you recognise that no design is sacred no matter how great it seems on paper or on
screen.
Second, you acknowledge that its your user that defines the success or failure of your design.
And the third reason prototyping works is because it enables you to react quickly when something
doesnt work and iterate until your users tell you its right.
Another way that paper prototyping helps us is it prevents us from latching onto an early design
solution. It encourages us to get the right design before you get the design right. Design helps to
frame possibilities and suggest behaviours.
All too often we tend to latch onto a particular solution and begin the process of incremental
improvement without properly exploring the possibility space. But if you freeze an idea too quickly,
you fall in love with it. If you refine it too quickly, you become attached to it and it becomes very
hard to keep exploring, to keep looking for better. Paper encourages you to think divergently.
So lets sketch four completely different design concepts, just to explore them as possibilities.
Then take the best ideas and come up with a paper prototype that we can test with users.
Well iterate around this point until we get the design right.
Then well produce electronic prototypes and iterate again.
Paper works best in the early phase of design because it lets you make small bets with your users.
These small bets minimize your losses and produce design insights you can gain only by watching
people use the prototype. Ultimately small bets allow you to fail fast so you can win bigger.
Clearly from this slide it looks as if were talking about lots of prototypes. How many, you might
ask.
149
David Travis
8-22 Paper prototypings strengths and weaknesses

Heres a quotation from a journalist whos followed Apple closely. Before Steve Jobs died, the
journalist studied Apples approach to design. The journalist says, Its a process where they
discover the product through constantly creating new iterations. A lot of companies will do six or
seven prototypes of a product because each one takes time and money. Apple will do a hundred
thats how many they did of the MacBook. Steve Jobs doesnt wake up one morning and theres a
vision of an iPhone floating in front of his face. He and his team discovered it through this
exhaustive process of building prototype after prototype.
This this clearly contradicts the misconception that great ideas spring fully formed from the minds
of great designers. Although it takes someone having that first spark of inspiration, great products
are really a culmination of the thousands of smaller, good ideas that came together to create a
smooth, comprehendible, and compelling user experience.
Let me quickly distinguish between a paper prototype and a sketch. Since they can often look
similar to each other, its worth noting the differences.
You probably sketch design ideas already, perhaps on paper or on a whiteboard with colleagues.
Sketching is what you do when youre playing with ideas. Sketching is a process where you explore
and refine ideas in a quick, iterative and visual manner. Its about ideas its not about how well
you can sketch them out.
A paper prototype on the other hand is about turning your sketch into something that can be tested
with users. It may still be hand-drawn and sketch-like, but there will be some kind of interactive
components to it.
Paper prototyping is great for where we are at the moment with the prototype that youre
developing.
Its good for testing concepts and terminology, navigation and workflow, content, rough page
layout and functionality.
Its not so good for testing the things on the right. So technical feasibility, you can do anything with
a paper prototype. You can do speech recognition perfectly. Its not good for testing that.
Download or response times. Actually, Ive been in some paper prototype tests where the
administrator has refused to give the user the next screen until, I dont know, ten seconds have
elapsed, but its a little bit artificial.
Its also not so good for testing scrolling, although once again, Ive seen paper prototypes tested
with big Roman scrolls, but if your interface requires lots of scrolling, you might be better off
testing that element of it electronically.
Its also not good for testing colours, fonts and icons because the interface is not finalised yet.
And finally, its not good for testing intricate or unfamiliar interactions, things like fly out menus,
pinching and zooming on a tablet device, or panning and zooming with Google maps, that kind of
thing.
150
David Travis
8-23 Whats in a Paper Prototyping Pack?

So I wanted to talk to you briefly about paper prototyping and tell you about the materials that you
need. All you really need from a paper prototyping pack is felt tip pen like a Sharpie, and some
paper. And then you can get sketching. The reason for using a Sharpie this particular one is
called a fine nib Sharpie, although thats always seemed a misnomer to me because its quite thick
but the reason for using a Sharpie is it means that you can sketch things out and you sketch them
out so theyre a bit rough and it stops you being too perfect when youre putting your sketches
together. So, that could really be on its own a complete paper prototyping pack. But people
sometimes feel that they want to add extra stuff and let me go through some extra stuff that you
might find useful.
One thing that you might find useful is a grey marker pen. This particular grey marker comes in
two, its got two nibs, a chisel nib at this end, and it enables you to add a bit of depth to your user
interface and that kind of adds a little bit of structure to it when youre showing it to users and
theres also a fine nib as well. And sometimes with the fine nib, what I find myself doing is using
that to come up with my initial sketch for a user interface and then I go over it with a Sharpie.
Another kind of Sharpie that you might find useful is the fine nib Sharpie and thats quite useful for
adding a bit more detail to your user interface and putting your user interface together.
So basically, Sharpies and paper are the main thing that you need.
Other things that you might find useful as well though, include these. A couple of templates you can
use. This template is for a web page. You can use it for sketching out our user interface. That means
you dont have to spend time designing the frame of the interface itself. And also what Ive got here
is a series of six-up templates so when youre initially coming up with the ideas, thats quite a useful
template to use to come up with different ideas for the way it could look. Related to that another
series of templates you might find useful, and again Ive produced a PDF that you can download
both with those templates but also this template as well. This is for people that really hate the idea
of sketching and just want to have pre-printed templates. The idea here is you just cut out the bit
that youre interested in and stick it in your interface. These are actually reproduced on post-it tape
so they are restickable. But you could print yours out on paper or on card and that would work fine.
So if you dont know how to do a checkbox, cut them out instead.
Other things you might find useful in a paper prototyping pack would be a piece of transparency.
Now the transparencys useful because you can place it over the prototype that youve designed and
then you can go over it with something like a highlighter pen, you can indicate parts of the interface
that has been highlighted, for example, so that can be quite useful too.
I mentioned glue for sticking things down. Theres another type of glue that you might find useful.
Its this, its restickable glue and it turns anything into a post-it note. So for example, you could cut
out a piece of card with a pull down menu on, put this on the back and then you can reposition it
anywhere in the interface. So, thats a useful item to have. Also some Tippex correction pen. If you
make small changes to the interface you dont want to redraw it. You can just go over it with a bit of
Tippex correction fluid. I mentioned cutting things out, so scissors are going to be useful. You also
going to want to stick things down so things like Sellotape or Blutack are going to be useful too.
Also, some people prefer not to use just paper but to use card as well, so heres a couple of different
sizes of index card. I often include these in a paper prototyping pack, partly because cards a bit
more solid than paper. So that means that when someone opens the door the pack doesnt fly
everywhere. But also because the card can be cut up into different sizes more easily. You can use it
for drop down menus, dialogue boxes, and so on. So index cards can be useful as well.
Oh, one final thing as well that you might find useful. Theres a, I actually find this very hard to get
in the UK. Its easy in the US where you can just get it any stationery shop but anyway, what it is, is,
its like post-it tape on a reel. Its just a sticky end of post-it tape turned into a reel and thats quite
useful because then you can tear this off and you can stick it down on your interface just like a piece
151
David Travis
of Sellotape or whatever, but the advantage is that its repositionable. So you can use that for text
fields for example, or you can use it for text that varies or changes elsewhere in the interface.
But remember, the main thing that you need to do paper prototyping is a Sharpie. So as long as
youve got one of these and some paper, then youre all set. So good luck and get sketching.
152
David Travis
8-24 Overview of electronic prototyping tools

At some point, you are of course going to want to move onto electronic prototyping tools. In my
enthusiasm for paper prototyping, I don't want you to lose sight of the fact that youve got to do
electronic prototyping. I just want to discourage you from doing to too early. Youre better off
starting with paper.
When you do move on to electronic tools you are very lucky. Because we live in a kind of
renaissance for electronic prototyping tools. There are so many around. Not a week goes by without
somebody introducing their new web-based tool that you can use to prototype user interfaces. So by
all means whatever youve got thats available to you, try them out. What Ive listed on this slide
are some common ones that I have come across in the past.
There are also some on here you would have heard of but you may not have used, or thought you
could use for prototyping: for example, PowerPoint or Apples equivalent program, Keynote. Now
you can actually introduce a lot of interactivity into those programs. You can actually get people to
click on things and you can go to different slides and so on. So if you are a bit of a whizz with
PowerPoint or Keynote and not really comfortable with code, then start with those. They are a great
way for you to produce interactive systems, or interactive prototypes.
There are also some others Ive got here. If you are looking for one to add to your portfolio or to
your CV, then one Ive got at the top there Axure thats kind of become an industry standard
for doing prototyping and Id recommend you check that out. You can create protoypes that look
and feel exactly like the final thing. And if you are also a bit of a coder, then you can actually
introduce things like variables and other things and so on so that the interface kind of remembers
stuff from one screen to another. So its a very powerful prototyping tool.
Another one I have got highlighted here is Balsamiq. Balsamiq is a tool for creating kind of sketchy,
hand-drawn interfaces, and its a good way to mock up an interface quickly, you can almost think
live while you are using Balsamiq. And youll also see Ive got Bootstrap there, which is a coding
scheme where you can product HTML prototypes. Its got a lot of functions in there which means
you can out together a prototype quite quickly. You need to know HTML fairly well to be able to do
it but nevertheless, you can get prototypes up and running quickly with that particular tool. So what
Ill do is I would encourage you to explore the various electronic tools that are available and don't
forget there are some simple ones that you have probably already got on your computer that you can
use to mock something up.
153
David Travis
8-25 Prototyping activity - Briefing

So its time to take a break and do some prototyping. Here is what I would like you to do. I want
you to develop a paper interface, a paper prototype, for the design activity that you are working on.
And it should be based on one of your user stories and also your primary persona. Remember you
are going to be designing something for someone that is going to be a perfect solution to their
needs.
And my first tip is: think about the design idiom that you want to come up with before launching
into screen design. Maybe sketch out a few possible ideas. Come up with this notion of exploring
multiple ideas before you focus on one which will be the prototype that you develop and test with
users.
Another suggestion as well is that the design you come up with, it should comprise a sequence of
about 4-6 screens. You can have more than that if you want, but that would be the minimum
number of screens really. And then you can test out your design later on with users. So I'm going to
be giving you a briefing on how to run a usability test and to do the usability test you are going to
need a prototype that has got a number of screens that can be tested with users so they can achieve
their task. So if you end up with a prototype with just one screen it is not going to work. It has got
be something that people can interact with.
If you are not sure exactly what element of it to prototype, remember: you dont need to prototype
the whole application. Think about your riskiest hypothesis and prototype that. What are you most
unsure about? What could you learn the most from? And also, rather than prototype what you
know is going to be OK, prototype what you think might cause problems because youll learn more
that way.
So, this is a very important step. Take a break right now and spend the next few hours, maybe, it
could even be the next couple of days. But spend some time developing this paper prototype for
your design activity.
Best of luck.
154
David Travis
9-01 The two types of usability evaluation

I now want to turn to evaluating the thing that weve designed and Ive titled this section of the
training course And I have the data to prove it: How to evaluate usability.
Let me show you where we are in the overall scheme of things by returning to the course roadmap.
Were still in Creating the user experience and now were on the bottom of that iterative loop,
evaluating usability.
Im going to begin by showing you a photograph of a car park machine. As youve probably
gathered by now, Im a little obsessed by car park payment machines.
Now I found this particular machine in the town of Buxton in Derbyshire. You may have used this
kind of machine yourself. You have to use the keyboard to enter your car registration number. This
is so you cant pass on your ticket to someone else if you leave the car park early. Very annoying, I
know. In fact, there are many annoying things about this machine.
Theres one blooper in particular that is to do with the keyboard. Whoever laid out this interface
decided that they needed to have a vertical keyboard. Maybe that was so they could fit on all of the
labels that theyve got there. And as a consequence, they had to use a non-standard keyboard. Now,
to appreciate why this is such a pain, try entering your car registration number or if you dont have
a car, enter your surname and date of birth. Go on, do it now. See what its like.
What kind of problems did you experience? Is it because its a vertical keyboard? Is it because its
not a QWERTY layout? Whatever, Im sure you found it difficult to use. I came across this machine
because there was a long queue of elderly people trying to use it. You get a lot of elderly people
living in Buxton. And the elderly people had formed a sort of self-help group to try to help each
other to use this machine and buy a parking ticket. This is what I mean when I say bad design has
consequences. Although theres a funny side to this story, at the same time its not fair that badly
designed technology excludes certain user groups. Thats not the sort of world I want to live in.
Well, you obviously wouldnt have needed to test too many people to spot problems with this
particular system. And thats what were going to turn to now.
ity inspections.
Im going to talking about two different types of method for doing usability evaluation. If you do a
search on Google for usability test methods, youll find lots and lots of search results. Firms try to
distinguish themselves: some consultancies will say that they do usability evaluations entirely
differently from anybody else. Were very unique, they will claim.
In fact, there are really only two types of evaluation method.
One is called a usability inspection. With a usability inspection, a usability expert (or actually a
handful of experts working independently) use the interface and try and find problems with it.
These experts will use a set of usability principles or guidelines to evaluate the interface.
The other way of carrying out a usability evaluation is with a usability test. With a usability test,
you involve real users. You ask real users to sit down in front of the system and you ask them to real
tasks. You watch them, you find out where they struggle.
Now, usability testing is the gold standard. If youre following a user-centred design process, you
absolutely must run usability tests.
Usability inspections on the other hand, theyre kind of nice to have. They may help you do extra
cycles through the iterative design loop. They are also a sensible activity to carry out prior to
running a usability test, since it makes sense to fix the obvious bloopers before you put the system
in front of test participants. But ultimately, its usability testing that you absolutely must carry out
155
David Travis
as part of your user experience work. Usability inspections are optional.
156
David Travis
9-02 Formative and Summative Usability Testing

Im going to be talking about both of these methods: so at the end of this course, youll be able to
run a usability inspection and a usability test.
Lets first look at usability testing.
Heres one view of usability testing. I came across this Dilbert cartoon that captures one view of the
approach.
The guy with the eye patch (his name is Sven) says, Sure we could bring some strangers in to test
our product for ease of use. But that could take all afternoon and cost at least $100. And all it
proves is strangers are stupid.
Sometimes the have good candy, says the pointy haired boss.
Honestly, thats not such an unusual view. Not about the candy, but about the fact that strangers
are stupid. Ive run more than one usability test where the developers have been watching a user
struggle with their system as they watch the test through a one way mirror only to say to me,
Where did you get such stupid users from.
Thats when I tell them that these are their customers: these stupid users own the current version
of the system. That usually makes the developers shut up and start to realise that it could actually
be their system thats at fault.
So there are a few flavours of usability testing, but there are two main ones that I want to tease out:
These are formative tests and summative tests.
The main characteristic of a formative test is that the participant thinks aloud as he or she works.
The moderator may be sitting next to the participant, or you could run this kind of test over the
Internet and watch the participant via screen sharing.
The main characteristic of a summative test is that the participant works alone. The moderator may
observe via a one-way mirror or a video link. In some cases, the moderator may not even be present
at all for example, you could use software to administer the test tasks.
With a formative test, we want to find problems problems with a system so they can be fixed.
With a summative test, we aim to measure usability metrics, such as effectiveness, efficiency and
satisfaction. These are the kind of measures I talked about earlier in the course when I showed you
the various dashboards that you can use to present the data.
In this part of the course, Im going to talk about formative testing since that covers probably 80%
of the ends of usability test that happen today.
So here are the steps in running a formative usability test.
In terms of the how, youre going to get a participant to use your website and ask him or her to
carry out a set of pre-defined tasks. Youll ask the participant to think aloud as he or she works.
In terms of participants, you can get away with what seems like a ridiculously small number, just a
handful. Five in fact. You also need a test moderator to run the test and ideally an observer as well,
although often the test moderator and observer roles are combined. The difference between the two
roles is that the moderator actually runs the test, welcomes the participant, and administers the
tasks. The observers role is to spot the usability problems and note them down.
In terms of materials, you can do it with any kind of prototype. So, something like a paper
157
David Travis
prototype would be fine. You can also do it with an electronic system or even a finished product if
thats what you wanted to test. Youll also need some kind of task scenarios that will be tasks you
want the participant to carry out with the system. These will be based around the red routes we
discussed earlier. And you also need some way of taking notes. Things you dont need that arent
critical include a one-way mirror, a usability lab and screen recording software. All of those things
are nice to have, they certainly help the process go a bit more smoothly but dont think you need
those to run a usability test. You can run a test without those things.
Now, I wanted to turn to this number five. Jakob Nielsens been widely quoted as saying that you
only need to test with five participants to find most of the usability problems with an interface. As
well see in a moment, that is basically true, but you need to be aware of the context of that claim.
158
David Travis
9-03 Why 5 users is (usually) enough for a usability test

So, when is it OK to test with 5 users?
First, theres a difference between testing an awful interface with many, many problems and
finding subtle flaws in a relatively simple interface which works correctly for most users. This five
user rule is simply not good enough for some applications such as, for example, an electronic
voting booth. Although the majority of people may not struggle with it, a small percentage will so
you need to make sure they are included in your test sample. This means you may need to test more
that 5 users to make sure you find them.
Second, if you are developing a product where a usability problem might end up killing someone
such as a medical product, a nuclear power plant or an aircraft cockpit you want to test with
more than 5 users.
And third, the 5 user rule is based on an assumption that you are following an iterative design
process where each successive revision is going to be retested with another handful of users. If
thats not the case, 5 users wont be enough.
However, in the majority of situations, 5 users is enough.
In fact, Steve Krug, who has written a great book on usability called Dont Make Me Think, captures
it quite well in this quotation: Testing one user early in the project is better than testing 50 near
the end.
That makes the point that youre much better off testing early and often, as we said at the very
beginning of the training, rather than doing big budget test with a large sample just before release.
But this number five. Let me give you a feel for why you can get away with 5 users in a formative
usability test.
Lets say that I had recently designed this kitchen hob. If this was market research, Id ask for your
opinions on the hob. Id ask, does it have enough burners for your family meal, do you think the
design would fit in your kitchen, how much would you expect to pay for it?
Now, I need a lot of people to answer those questions to get a reliable answer.
But with usability, were interested in behaviour rather than opinions, so we ask if people can
actually use it. So, for example, which of those knobs on the right-hand side would you use to light
the gas under the back right hob?
Would you use number one, number two, number three or number four?
And usually when I ask that question, most people vote for number one or number two. They seem
to be the most likely candidates because people assume they will be numbered starting from the
back left or the back right.
In fact the correct choice is number four.
Now, that may seem illogical, but in fact there is a logic to it. The front right is number one, the
front left is number two, the back left is number three and the back right is number four. So its
clockwise from the front right. Now this might make sense if youre an engineer. But it doesnt
really make sense to a human being.
I dont need to test many people to know thats a problem with the design. We dont need to now
say, oh, we need to get statistical significance by testing, I dont know, 200 people in order to check
that that wasnt a fluke. In the same way that if I see somebody trip over a carpet, I dont need to
say, Well, I need to watch another 100 people trip over that carpet before I decide if it needs to be
159
David Travis
fixed. Youve found a problem. Thats what you do with formative usability testing. And then you
can use that insight to come up with alternative designs.
So, for example, heres another design of a kitchen hob.
If I ask you the same question, Which one of those knobs would you use to light the gas under the
back right hob? its obvious. Its so straightforward because the mapping between the knobs and
the gas hobs in so clear.
So usability testing gives you kinds of insights to iteratively improve designs and thats why we can
get away with small samples.
160
David Travis
9-04 In-person and remote usability testing

Now, before reviewing how to moderate a usability test, I wanted to mention the different ways that
people tend to carry out formative usability tests.
This is because people often get hung up with running tests in a usability lab. Thats certainly one
way to run a formative usability test, but its not the only way. Heres an example of a lab-based
test: if you look through that window (which is actually a one-way mirroR), you can see the
participant and the person running the test together in the same room.
But you dont need all of the paraphernalia of a one-way mirror and the video equipment to run a
formative usability test.
Ive often run tests in a conference room, where its just me and the participant.
Another flavour of this kind of test is the pop-up or guerilla usability test where you set up camp
in a coffee shop, local library or staff canteen, or wherever your users congregate. You speak to
people nearby and ask them to take part in a short evaluation.
And you could even take your test to the participants home or workplace, and run it there.
What all of these have in common is that the moderator and the participant are co-present: youre
sitting next to each other. Now obviously, if youre testing a physical product or a mobile app, thats
what you have to do.
But if the thing that youre testing is a screen-based system, you could also run the usability test
remotely: you can use screen sharing to view your participants screen and then moderate the test
over the telephone. These tests can work really well, because the participant naturally keeps up a
good flow of comments since people dont like silence on the telephone. However, youre not able to
see the participants body language you wont be able to see if they are confused or
uncomfortable and participants may also get distracted.
For example, I ran a remote test once where I discovered the participant was paying more attention
to Facebook on his mobile phone than to the system that we were supposed be testing. I found out
because there were lots of odd pauses and I could hear Facebook Messenger beeps in the
background.
Nevertheless, a bit like online card sorts, these kinds of remote test can be really useful when your
users are hard to get to.
161
David Travis
9-05 Welcoming the participant and giving instructions

One of the first steps in running a usability test is to explain to the participant about thinking
aloud.
You want participants to keep up a narrative that explains what they are looking for, where they are
confused and any decisions they are making.
The next step is to give the participant your test scenarios. Then you sit back, shut up, and observe.
Lets go through that process.
So Ive created a cartoon to explain the instruction process. This cartoon metaphor is important
because your role as a usability test administrator is to make invisible the thought bubbles above
your participants head.
So, Im going to play the geeky guy with the specs, and I say, In this evaluation I need you to think
out loud when you carry out the tasks. This means that I want you to tell me what youre thinking
about as you use the website.
I then say For example, Id like you to say what it is youre trying to do, what youre looking for,
and any decisions youre making. If you get stuck or feel confused Id like to hear that too.
If it helps pretend youre alone in the room, or alternatively that you have a colleague sitting
behind you who youre teaching to use the website.
And the reason I do that is to give users permission to think out loud because frankly, thinking out
loud is a bit weird.
I than say, My role is to communicate what you say and do to the software developers. At that
point I like to give a nice cheesy grin to the camera.
I point out that I wont be able to provide help or answer any questions.
This is because we want to create the most realistic situation possible.
Even though I say I wont be able to answer your questions, please ask them anyway. Its very
important that I hear all your questions and comments.
Now, I cant emphasise how important this is.
Its absolutely critical that you get users to ask you questions in a usability test but its equally
critical you dont answer them.
So, for example, when a participant says to you, Whats this button for?, you dont tell them.
Instead you answer the question with a question. So a good response might be, What do you think
its for? Similarly, if a participant asks, What happens if I click that option?, youll respond with,
Whats your expectation?. Now obviously, if the participant asks you, Where is the toilet?, you
dont say, Where do you think the toilet is?, but otherwise, reflect all of the participants
questions back. So youll use an expression like, Whats your expectation?, What do you think
would happen?, Would you like to go ahead and find out?. But you dont want to actually answer
the question itself.
I think this is one of the most challenging things about being a usability test moderator. Your
participants will ask you questions so you have to act like a counsellor, where you answer a
question with a question. You might also hear people refer to this as the boomerang technique.
Then I go on to say, I dont want to bias you toward liking or disliking the software.
162
David Travis
And notice how I balance that, with the phrase, liking or disliking. If Id said, I dont want to bias
you to liking the software, then the implication of that is, well, actually, I do want to bias you
toward liking it. So by balancing the expression, it makes it clear that Im independent.
I then say, So dont be surprised if sometimes I dont say anything in response to your comments
or if my response is something neutral like thats great feedback.
And for most tests, thats about as far as I need to go with the initial instructions. But if Im running
a test of something like a paper prototype, then theres clearly some extra instructions I need to
give.
So, if its a paper prototype, Ill say something like, Now Janet will be playing the computer, Janet
says, Hi.
And then Janet says, Ill be showing you the screens just like a computer would, but since
machines cant talk, Im not allowed to explain anything.
And she then says, If you want to do something youll need to interact with the prototype just as
you would on a computer.
I point out that to enter text on the screen, the participant will need a keyboard
at which point I hand her a pencil and Janet clarifies its OK to write on the prototype.
Janet also says, Even though its a paper prototype, assume you can do all the things you can do
with a real computer like drag and drop and right mouse menus.
163
David Travis
9-06 Getting participants to think aloud

The final part of the instructions is to demonstrate thinking aloud and getting the participant to
practice.
Thinking aloud comes easily to many people but some people struggle with the idea. For some
people, thinking aloud is an odd thing to do, so I recommend that you get each participant to
practice to check they understand the process. This is a bit like giving participants the practice
cards in a card sorting session. I might ask people to do a search on Google as a practice task, just
to check they get the idea of thinking aloud. Or you could get them to adjust the height of their
chair. You want a simple task that takes less than a minute to complete.
I like to demonstrate the process of thinking aloud to the participant. So let me do that now. I have
an iPhone and what Im going to do is add a contact to my address book. So here is me thinking
aloud. So, my phones asleep so Im going to press the circular button at the bottom to wake it up.
Im now going to slide to unlock and the phone has asked for my passcode, so Ill now enter that.
Now, in order for me to enter a contact, I need to find the contacts app and I know thats at the
bottom o the screen because I use it often so I moved it there. So Ive now selected the Contacts app
and now I need to find a way of entering the contact. At the top right of the Contacts app theres a
plus button. Im going to tap that and I now get the details for entering a new contact. With my
thumb Im going to click in the field thats labelled First and Ill enter the persons first name
and so on.
Im sure youve got the idea about what it is Im trying to do here. And the participant as this point
normally begins to nod and she understands what it is Im trying to do and then shes happy to
proceed.
But I wont let her loose on my system until I know she can think out loud too.
So Ill get her to demonstrate as well. I might ask her to do the same thing with her phone. If
theyve got an iPhone I might ask them to do a different task, so she doesnt just copy me. So maybe
Ill ask her to adjust the height of her chair. If its a computer chair, you know, with those levers at
the side that you can move or down, thats quite a good one to do because its quite straightforward
but its sometimes a little confusing as to which lever does what part of it and sometimes the user
adjusts the chair, falls off and lands on the floor and we all laugh. Ha ha ha. But whatever, it makes
everybody feel relaxed.
The point is, make sure that your practice tasks relatively easy because you want the user to be able
to be successful. If the user does a rubbish job of thinking aloud, Ill give the user another task to do
in order to think out loud. Perhaps Ill start them at Google and Ill say, Find out where the
President of the United States was born, for example. And I will ask them to use Google and think
out loud as they do the task. And I wont let them use my system until Im convinced they can think
aloud because if they cant think out loud and I allow them to carry on, I end up being complicit in
the fact that theyre not thinking aloud properly. And if theyre not thinking aloud properly Im not
getting any real data. So its important that you really do demonstrate and get your participant to
practice.
164
David Travis
9-07 Creating good usability test scenarios

Now the participant is properly briefed for the test, we give the participant some test tasks to carry
out. These are known a test scenarios.
You need to spend time making sure that your test scenarios are well crafted. If you give the
participant poor test scenarios, youre unlikely to learn much of interest.
Your test scenarios should be based around your red routes. Then you know that people are
carrying out tasks with the system that are important to them.
Heres an example of a test scenario. Its for a burglar alarm. The red route is, Set the burglar
alarm, but we cant just give this to our participant as it is. This is because the participant may
simply press a couple of buttons on the burglar alarm, especially if one of them is labelled Set, and
then say that theyre done.
Instead, we need to turn this into a scenario so that we can properly motivate the participant and
so we can make sure that we provide all f the context information that matters so much to design.
So here, we say, Youre about to go to bed and you want to set the burglar alarm. Your pet dog
moves around the kitchen in the night and you dont want him setting off the alarm. Set the alarm,
making sure that the kitchen detectors are turned off.
This is a much more appropriate scenario. This is because people dont always use the default
settings. People need to customise the system based on their situation. You wouldnt get this from
the original red route which doesnt have the contextual information.
With your test scenarios, it takes some practice balancing not leading users on the one hand and
not making the task too difficult on the other. This checklist will help you. Here are four questions
you can ask of your test scenarios to see if they are any good.
Good test scenarios are expressed in the users language (they avoid system-specific jargon).
You want to make sure that you use the language of your users and avoid technical jargon. For
example, do users really use the term asset when referring to their kids university fund? Will a
user know what you mean by a product configurator?
Good test scenarios are realistic, i.e. they describe things that the user would normally expect to do.
If your test scenarios are based on red routes, then youll be fine here. But as a sanity check, its
worth asking this question. Sometimes we ask users to do things that they would never normally
expect to do. Dont make that mistake.
Good test scenarios dont hint at the correct path (a usability test is not a user acceptance test).
A usability test is not a user acceptance test. Dont walk the users through every step. Leading a
user too much will provide biased results. For example, instead of saying Click on the small check
box at the bottom of the screen to add GPS, just say Add GPS to your rental car. Note how
different this approach is to a user acceptance test. A user acceptance test asks: does the system
work? Even if it requires the user to hold down 3 keys and type a 4th with their nose. A usability
test asks: can the user use it naturally? Its important that you run usability tests, not user
acceptance tests.
Good test scenarios have a correct solution (so you know if the task was successfully completed).
You want to give participants a measurable end goal. Instead of giving generalities like find a new
kitchen appliance, ask them to find a mixer for under 75 that has high customer ratings. This
makes the task more straightforward for the user but also allows you to more easily know if a task
165
David Travis
was or wasnt successfully completed.

OK, heres your briefing.
Create a test scenario for your usability test

Read over your user story the one your prototype is based on and review your
prototype.
Create a usability testing scenario that you could give to a test participant that will put your
prototype through its paces.
Make sure your scenario passes the criteria on the previous slide.
Finally, share your test scenario in the discussion so you can get feedback on its strengths and
weaknesses.
166
David Travis
9-08 Keeping a poker face and reminding participants to think aloud

So now we have explained thinking aloud, weve got the participant to practice, weve given the
participant the first task what do we do next?
We shut up.
We let the participant work.
Now the participant doesnt need to be speaking for every second of the test: sometimes people
need to pause and read something on screen. Its OK to be silent when this happens. With
experience, you will get a good feel for the trade-off between keeping them talking and interrupting
their train of thought.
But if the silent behaviour is going on for too long, then you need to remind the participant to think
aloud. I find that expressions like this help:
Keep talking.
What are you thinking right now?
So?
So, youre thinking . . .?
What are you seeing here?
Tell me what is happening.
Tell me a little more about
You get the idea. The golden rule is to keep your prompts very short. The participant should be
doing all of the talking, not you.
One of the things you may have noticed from the material Ive just covered is that one of the key
things to being a good usability test moderator is keeping a poker face. Participants often do
unexpected things when youre sitting next to them, things that you hadnt expected but with
hindsight seem entirely logical. You need to keep a poker face during that process and make sure
you empathise with what theyre doing. You dont want to make or pass any judgement or any
comment. You want to be entirely neutral.
In fact, theres a great video that I came across on Reddit which covers just that. Im going to
include that next for you to take a short humorous break. The video is only about 90 seconds and it
will give you a good insight into this idea of keeping a poker face.
167
David Travis
9-09 Roles in a usability test - moderator, computer and observer

Now, I want to give you some further tips on running a usability test of a paper prototype because
in a moment Im going to ask you to do just that. Youre going to test the prototype you created
earlier.
Running a test of a paper prototype is a little different from running a test of an electronic system
because you need someone to play the role of the computer for you. So there are two roles in a
paper prototype usability test: The Moderator; and The Computer.
You will play the role of the moderator, and youll ask a colleague or friend to play the role of the
computer.
As the moderator, you want to actually get people using the prototype, not just saying what they
would do. In other words, dont demonstrate the interface to your participants or show them how it
works: participants should actually use your prototype to do tasks.
However, you can clarify elements in your prototype. It may be that its not particularly well drawn
so you may need to tell people, That buttons greyed out for example. But make sure you dont
provide any hints, for example, by saying, That buttons greyed out because you havent selected a
record yet. That kind of comment indicates to participants what they need to do, and you want to
avoid leading your users.
Also, look out for computer mistakes: your colleague may show the wrong screen. And if the
paper prototype crashes if midway through a task you realise that theres stuff youve not
implemented that you should have you can take a break.
Now, heres how you need to brief your colleague who will playtime computer. Probably the most
important thing is to tell them to shut up. Their job is to control the screens and not to talk. Tell
your colleague to think of themselves as a machine. They can only do what the computer has been
programmed to do.
The Computer can provide verbal error messages if the user takes a wrong turn, but make sure that
your error messages match what would happen in the real system. If youre not going to have an
error message then beep is the best youre going to be able to do.
And to avoid cueing participants, make sure that The Computer waits for participants to select an
option before getting the next screen ready.
Now theres another common role in a usability test and thats the role of the observer. Its
sometimes the case that the moderator takes on this role and other times its a dedicated person
who does it.
The role of the observer is to make, er, observations.
Now, that sounds simple but like a lot of things in UX, its not as simple as you first think.
Weve already touched on this concept of an observation when we talked about contextual inquiry.
Youll remember that I encouraged you to make observations on sticky notes, and I pointed out
that the golden rule is to write down one observation per sticky note.
Now that youve become an expert at this, Im going to add another golden rule: Write the
participant number at the top right of your sticky. We didnt do this before as we were mainly
observing Ozzy, but in a usability test youll have a few participants and its useful to remember the
participant that triggered the observation.
You can also see that Ive defined what I mean by an observation: an observation is something that
you see or hear. Its not your guess at whats behind the problem, no matter how sure you are.
168
David Travis
Heres an example of why we make observations and what happens when we make make
interpretations instead.
Heres some data Ive taken from an A/B test where a researcher was examining the hamburger
menu in a mobile app. Its called a hamburger menu because it looks a little like a schematic
version of a hamburger: a beef patty inside a bun. The researcher noted that in a test with 20,000
users, only 2% of people interacted with the hamburger menu.
Thats our observation. Its an objective fact.
Lets say we had seen that in a usability test. Imagine youre there now. Youre looking through the
one way mirror and you can see that people arent using the hamburger menu.
Now, why do you think this happened?
What was it that made the users behave that way?
See if you can come up with some reasons for that behaviour, and then return here.
169
David Travis
9-10 Observations and interpretations

OK, heres some interpretations for that behaviour that occurred to me.
Perhaps the hamburger menu (at the top left of screen) is hard to reach on a mobile device
and people dont think its worth the effort
Or maybe people dont see the control they mistake it for part of the branding, part of the
caffeine informer logo.
Or perhaps people see the control but they assume it does something else, like reload the
page. Maybe it doesnt look like a menu control.
Or maybe people dont need the menu: they can do everything they need to on the main
screen.
The point is that each of these different interpretations would lead to different changes to the
design. For example, if its because the control is hard to reach on a mobile device, we could move it
lower on the screen. But if we think its because people dont recognise it as a menu control, we
might change the hamburger menu to, say, a text button that reads, MENU.
The point is that if we write down our interpretation rather than our observation, we end up with
very different changes to our design. So make sure you make observations, not interpretations, in
your usability tests. Later, we can come to interpret the data along with the design team, but lets
make sure we start with an objective description of the usability issue.
So heres your briefing.
Assemble your paper prototype along with the test scenario you created earlier. Youll also need a
stack of sticky notes that youll use for recording observations.
Ask a friend to play the role of the computer. Make sure you brief them on what they are meant to
do.
Grab a participant and ask them to take part in your usability test.
Run your test with around 5 participants, and then return here and Ill show you how to analyse the
data.
170
David Travis
9-11 Prioritising usability problems

The process is fairly simple. Start with a set of sticky notes that contain the observations you made
during the site visit. Each sticky note contains a single observation.
Working as a team, group the observations into common problems that you saw across
participants.
Running a usability test has been compared with taking a drink from a fire hydrant: you get
swamped with data in the form of usability issues that need to be organised, prioritised and
(hopefully) fixed. Although its tempting to use your own judgement in determining severity, this
causes a difficulty when a developer challenges your decision: How did you make that issue
critical? I think its more of a medium problem.
Having a standard process for defining severity means that you can be consistent in the way you
assign severity and means that you provide the transparency needed for people to check your work.
In fact, by asking just 3 questions, we can classify any usability problem.
What is the impact of the problem?
Problems that affect completion rate (especially with with frequent or critical tasks) are more
severe than problems that affect user satisfaction.
How many users are affected by the problem?
Problems that affect several users are more severe than problems that affect just one.
Will users be bothered by the problem repeatedly?
Persistent problems problems that keep cropping up are more severe because they have a
bigger impact on completion time and on customer satisfaction. An example of a persistent
problem is a web site that doesnt have underlined hyperlinks. This means you can find the links
only by minesweeping over the page. This problem is persistent, because even when you know
how to solve the problem you still have to solve it. Note that repeatedly means that it occurs
throughout the interface -- you keep coming across the problem.
We can put these three questions in a process diagram and use it to define four severity levels.
Weve now mapped our usability issues to four common severity levels:
Critical
This usability problem will make some users unwilling or unable to complete a common task. Fix
urgently.
Serious
This usability problem will significantly slow down some users when completing a common task
and may cause customers to find a workaround. Fix as soon as possible.
Medium
This usability problem will make some users feel frustrated or irritated but will not affect task
completion. Fix during the next business as usual update.
Low
This is a quality problem, for example a cosmetic issue or a spelling error. Note: Although this is a
minor issue in isolation, too many lows reduce perception of trust.
171
David Travis
9-12 Jakob Nielsens Usability Heuristics

Now lets turn to a different method of evaluating interfaces: a usability inspection. Other words
that you might have heard that are synonymous with this include expert review and heuristic
evaluation.
With a usability inspection, you evaluate a design based on a set of usability principles or
guidelines. Now, these have a long history in the field. Although designing usable systems requires
far more than simply applying guidelines, they can make a big contribution by promoting
consistency and good practice.
Over the years, several human computer interaction groups and individual researchers started to
assemble collections of guidelines, tips and hints and they published the guidelines in books and
journal papers.
One of the earliest sets of guidelines was Sidney Smith and Jane Mosiers Guidelines for Designing
User Interface Software. This was developed in 1986 for the US Air Force. This had 944 guidelines
and remains the largest collection of publicly available user interface guidelines in existence.
Ive reproduced one of the guidelines here and you can read the full set at the link on the slide. Now
even though this particular guideline was developed about 30 years ago, you can see that its still
relevant today. And that tells us something important about usability guidelines: the best
guidelines are based on the limitations of people; they are not based on technology.
Technology changes rapidly, but us humans are pretty much the same as we were 30 years ago and
even 300 years ago. Our visual system is the same. Our memory capacity is the same. Our cognitive
capacities are unchanged. And that means this kind of guideline will apply to technologies that
havent even been invented yet.
This is why usability guidelines can be so useful in evaluating user interfaces.
The most well-known set of guidelines is this set of usability heuristics developed by Rolf Molich
and Jakob Nielsen. (A heuristic by the way simply means a rule of thumb. Its another word for a
guideline).
In 1990, Molich and Nielsen carried out a factor analysis of 249 usability problems to derive a set of
nine heuristics that would account for all of the problems found.
Ironically Nielsen was second author on the paper but the fact that these guidelines are now so
closely associated with him might be testimony to the fact that hes so good at self-promotion. I
couldnt possible comment.
Along with these heuristics, Nielsen developed a method for structuring a guidelines-based user
interface review and he called the method an heuristic evaluation.
The nine heuristics were slightly reworded in Nielsens book called Usability Engineering,
published in 1993, at which point he added a tenth heuristic, help and documentation. A revised set
(again, simply re-worded) were published a year later in a book chapter. Thats the set shown on
this slide and the set used today.
Now there are lots of different usability guidelines, so why am I showing you these? The reason is
because theyre the most popular set of usability heuristics. Theyre not necessarily the best, but
theyre certainly the most widely known. And once you know one set, youll be well prepared for
understanding the other sets too. So once you get the idea of how these evaluations work, feel free
to explore other sets of guidelines. You could even develop your own. Imagine that, next time I
present this course, I could be showing your set of guidelines instead of Jakob Nielsens.
Now, when you first look at this list you might think, Well, these guidelines all seem good to me,
172
David Travis
but what do they mean? What Im hoping I can do in this part of the course is give you an intuitive
feel for what these heuristics are about. Hopefully youll remember a few of them afterwards, but if
we get through this part of the course and you can only remember one or two, thats fine by me. So
dont think you need to memorise this list.
So, lets go through the list of ten heuristics and Ill try to give you a good understanding of what
theyre about.
173
David Travis
9-13 Visibility of system status

So, Nielsens first heuristic is visibility of system status. The question to ask here is, Are users kept
informed about system progress with appropriate feedback within reasonable time? This used to
be called provide feedback in his old list.
The idea behind this principle is that the usability of a system is improved when its status and
methods of use are clearly visible. So according to this principle, systems are more usable when
they clearly indicate their status, possible actions that can be performed and the consequences of
the actions.
When we use this guideline to evaluate a system, were looking for controls that are visible, because
that serves as a reminder for what you can and what you cant do. So for example, a red light could
be used to indicate whether or not a kettle is receiving power. You could use auditory or tactile
feedback to acknowledge that actions have been performed and completed: for example, a button
goes click when you press it.
In this example, you can see the standard file copy progress dialog in Windows. If you want, you
can get more information on the progress, but the point is you know the status of the system. When
you see this, and the progress bar is happily moving along, you dont think, Has the computer
crashed?
Now of course, the best kind of progress dialogs will tell you approximately how long you need to
wait. I came across this cartoon that makes the point well.
174
David Travis
9-14 Match between system and the real world

His second heuristic is match between the system and the real world and the question to ask here
is, Does the system use concepts and language thats familiar to the user rather than system
oriented terms? Does the system speak the users language?
Heres an example of a interface on a train in England. This is a control panel for a toilet. You may
well be asking, What kind of world are we in where we need a control panel to operate a door, and
I must admit I would agree with you.
So if you want to use this toilet, you press a button on the door outside the loo, at which point a
circular door opens to admit you. Then you enter and youre confronted with this particular panel.
And my question to you is, Which button would you press if youve just walked into this toilet and
you want some privacy? Well, sometimes people choose the big red button in the middle, but then
they say, Oh, hold on a second, thats the alarm, maybe I shouldnt press that. Then they say, Oh,
actually, Ill choose the open door/close button, the one thats got a kind of a turquoise label on on
the left. Indeed, thats what most people do. Sadly, they forget to also press the door lock button on
the right-hand side. The problem is, when the door closes behind you, you think its also locked,
but its not. As a consequence sometimes, in the middle of your er, relaxation youll find
somebody on the other side of the door who presses the button and youre revealed like a prize in a
game show.
Heres another example of an interface that falls foul of Nielsens second heuristic.
This is from a 2013 Toyota Camry SE. This screen reports the air pressure in the tyres. Theres no
way to tell which tyre any of the icons represent. You cant click on an icon to learn more.
This isnt a million miles away from the cooker hob example we looked at earlier.
How hard would it have been to lay out the icons in a way that made it obvious which tyre is which?
Another problem is that its not clear if these tyre pressures are too low, too high or just right.
How would you have redesigned this display?
175
David Travis
9-15 User control and freedom

Nielsens third heuristic is user control and freedom and the question to ask here is, Can users do
what they want, when they want?
Users often choose system functions by mistake and they need a kind of an emergency exit. Indeed,
in his old list, provide clearly marked exits was what he called this heuristic.
Heres an example of an interface that breaks that principle. This is from the Zango website, and if
you look at that dialogue, let me read it to you in case the fonts a bit too small, but it says here,
Are you sure you want to cancel? Zango content on this and other websites is free if you install
Zango programs. You can easily uninstall Zango via ad remove programs. And then it says, Click
OK to cancel or click cancel to continue the installation. Whenever you find yourself in that
particular situation whenever you think, What do I press now in order to get out of that
situation? thats user control and freedom thats been contravened.
As a side note, Im seeing this Click OK to cancel design pattern increasingly. So it obviously
makes sense to someone. But not me.
176
David Travis
9-16 Consistency and standards

His fourth heuristic is consistency and standards and the question to ask here is, Do design
elements such as objects and actions have the same meaning or effect in different situations?
This heuristic used to be called be consistent in his old list. And its sometimes given the high
faluting name the Principle of Least Surprise, which means, basically, you shouldnt surprise the
user with the way a command or interface object works.
In this first example, we have the standard Windows Yes/No/Cancel dialog. Love it or hate it, its
consistent: you know what to do when you see it.
Compare that with this dialog box that doesnt even have any buttons (just the close box at the top
right).
And in this example, the designers of Ad-Aware chose to replace the standard check boxes with
fancy coloured ones. The problem now is its not obvious that these are interactive buttons. They
look like they are status indicators.
177
David Travis
9-17 Help users recognise, diagnose and recover from errors

Nielsens fifth heuristic is help users recognise, diagnose and recover from errors. This heuristic
used to be called Provide good error messages in his old list.
Heres an example of a poor error message. Sorry, Im afraid, just isnt good enough. Error
messages should explain the problem and suggest a solution.
Another question to ask of your error messages is, Are they expressed in plain language?
So we dont want any codes remember, we want error messages that accurately describe a
problem and suggest a solution.
Now its not that error numbers are terrible, although when an error message begins with a number
you know its going to be bad. In this example, they could have at least moved the error number to
the end. And the message itself is unhelpful: we want error messages to suggest a solution.
And heres my favourite tongue twister from Adobe
178
David Travis
9-18 Error prevention

Were on Neilsens sixth heuristic now which is Error prevention. The question to ask here is,
Can users be led to make an error that good design would prevent?
Human error is inevitable, but it neednt be catastrophic. So forgiveness in design helps prevent
errors before they occur, and minimises the bad consequences of errors when they do occur. So you
want forgiving designs. A forgiving design also provides a sense of security and stability and
encourages users to explore the interface.
So were looking for things like good affordances characteristics of the design than influence
correct use. So for example, a uniquely shaped plug that can only be inserted into the appropriate
hole. Dont get me started on USB connectors.
We also want our designs to support undo, a kind of reversibility of actions. We want to provide
safety nets.
Heres a good example of that from Gmail. Ive written attached in my message but not attached
anything before hitting Send. Googles error message is trying to prevent the error from occurring.
179
David Travis
9-19 Recognition rather than recall

Nielsens seventh heuristic is Recognition rather than recall. So the question to ask here is, Are
design elements such as objects and actions visible? Does a user have to remember stuff from one
part of the system to another, which is obviously a bad idea.
In fact, Nielsen used to call this Minimise the users memory load in his old list and this principle
drives a lot of modern user interface design. Good labels and descriptive links are crucial for
recognition. And things that are clickable, like buttons, should be obviously pressable.
What were after here is helping the user realise that a particular action is possible.
In this example, Im setting the desktop pattern in Windows and the operating system shows me
previews of the images. So I dont have to remember the filename in honeycomb.png or whatever.
In this next example, Microsoft Word shows me the fonts in the font menu actually printed in the
font style. This makes it easier to recognise the font I want to use, I dont have to just remember its
name.
And in this example from Microsoft Excel, it provides examples of all of the different kinds of graph
you can create. I sometime think I have a kind of dyslexia of the column and bar chart variety: I can
never remember which one goes up and which one goes across, so I find these previews really
useful. Its anther example of recognition rather than recall.
180
David Travis
9-20 Flexibility and efficiency of use

Nielsens eighth heuristic is flexibility and efficiency of use. The question to ask here is, Are tasks
efficient and can users customise frequent actions or use shortcuts?
In fact, this heuristic used to be called provide shortcuts. Frequent users need and want them.
Although its tempting to design for only novice users, you also need to consider your expert users
too. After all, if your system gets any traction, then you want to end up with expert users.
In this example from Microsoft Word, you can see they have embedded the keyboard shortcuts in
the menu. So the 100th time youve gone to the menu and chosen Cut, maybe then youll notice
the CTRL-C shortcut and start using it.
And in this example from Tweetdeck, which is basically a very simple app, even that has shortcuts
to allow you to use the program quickly.
So dont forget about your expert users.
181
David Travis
9-21 Aesthetic and minimalist design

Nielsens ninth heuristic is aesthetic and minimalist design. The question to ask here is, Do
dialogues contain irrelevant or rarely needed information? So every extra unit of stuff that you put
on a screen competes with the other bits of stuff and diminishes their relative visibility. Do you
remember that law that weve spoken about on this course before: Hicks Law, where the more
choices you give people the harder they find it to make a choice.
In fact, Nielsen used to call this, simple and natural dialogue and its really a bit of a catch all for a
number of rules of good graphic design which weve already covered, such as contrast, alignment,
repetition and proximity.
And heres an example Ive taken from different versions of Microsoft Word. The top example is the
ribbon from the Office suite and the lower example is from Word version 6.0. Although the earlier
version of Word looks dated now, note also though how the design still looks basically OK: its a bit
of a design classic really. I mean, at least all of the items on there kind of go together. The icons for
example you know, they look like a family, they look like they have got the same DNA. And thats
because theyve used one of the principles that weve spoken about beforerepetitionin the
interface.
Heres a quick question for you: other than the visual design differences, what else is different in
the design of these two toolbars? So they both use icons, but how do the icons in the newer version
differ from the older version?
So youll see that Word version 6.0 doesnt have icon labels. And many researchers have shown that
icons on their own are really hard to memorise. So the Microsoft Outlook toolbar is a good
example: Microsoft researchers discovered that the older, icon-only toolbar, well that tended not to
get used. So they tried changing the icons and their positioning, but that didnt help much either.
But what did help was simply adding text labels next to the icons. That immediately got people
using the toolbar. And in another study, researchers showed that people remember a buttons
position instead of the graphic interpretation of the function. So they remember that its the third
or the fifth button in, without actually remembering the picture. So the point is: your icons need
labels.
In most projects, you also need to know that icons are very difficult to get right and they need a lot
of testing. Anyway, bit of a diversion there, talking about icons, but aesthetic and minimalist
design, Nielsens ninth heuristic.
182
David Travis
9-22 Help and documentation

And finally Nielsens tenth heuristic, help and documentation.
Now the question to ask here is, Is appropriate help information supplied and is the information
easy to search and focused on the users task?
Now, a basic system is not going need a lot of documentation, if any. But if the system includes any
complicated tasks, then users are going to need some help for those tasks, so it means including an
FAQ or some kind of online help, with step by step instructions that help users carry out the most
important tasks.
The key is to not just slap up some help pages, but to integrate the documentation into the system.
Help should be fully integrated into each window so that users never feel like assistance is too far
away.
Research shows people are more likely to use help when its integrated into the user interface
rather than delivered as a separate system.
Your user is frustrated. He or she is a little impatient, possibly angry, and the tension is building
with each unsuccessful click. To write for the frustrated user, focus on solutions to problems.
Micro-copy like this is another example of help. But the help isnt good enough so its being
bolstered with the error message form hell. How is anyone meant to understand that?
183
David Travis
9-23 Why you need more than one reviewer

Now, when it comes to doing a heuristic evaluation, theres something you need to know.
You shouldnt just do it on your own you need to have multiple evaluators. Heres the evidence
for that. This is a study that Jakob Nielsen carried out. He used 19 evaluators to assess a voice
interactive voice system, you know the kind of thing, dial one for support, press two for customer
services and so on. Now, you would never normally use 19 evaluators, but this was a research study.
In this particular system there were 16 usability problems. Notice some things about this. First of
all, there are some problems that are easy and most evaluators get it. So that easiest problem was
spotted by all but three of the evaluators. Also there are some hard problems that very few
evaluators get. That hardest one, only two of the evaluators found. And also notice that there are
some particularly hard problems that are found by evaluators who dont otherwise find many
problems, so that particular problem was found by evaluator 13. Evaluator 13 only found six
problems altogether, but one of them that that evaluator found was one of the hardest problems. So
the point is, you cant just get some guru in to find all of the usability issues, you need to use
multiple reviewers to get appropriate coverage.
184
David Travis
9-24 Web Accessibility Guidelines

Now there are other sets of usability guidelines as well. So, for example, our friends at ISO, theyve
got in on the act with seven dialogue principles. But I wanted to quickly mention another set, thats
aimed specifically at ensuring your system is accessible to disabled users.
This set of guidelines is the Web Content Accessibility Guidelines. Although Im not going to review
these guidelines in depth, you do need to know that these guidelines are based around four key
principles.
The first principle is Perceivable.
Disabled users read websites in different ways, often making use of assistive technology (for
example, screen readers, text-only browsers and Braille). All content on a website should be
understandable by these methods.
This is really the most basic form of accessibility; making sure that content can be read and
understood. There are, of course, several layers to claiming full accessibility under this principle,
but the first level is relatively easy to achieve.
The second principle is operable.
Disabled users may have a range of difficulties with motor skills (for example, they may navigate by
keyboard only).
This category also includes older users who may have deteriorating motor skills and who prefer to
switch between mouse and keyboard.
These users should be able to use all the functions a regular user would.
The third principle is understandable.
Some disabled users have difficulty with things that regular users take for granted.
However many of the techniques that ensure websites are accessible are also helpful to the overall
user experience.
These are things like identifying the language of a page, explaining unusual or technical words,
making website functions predictable and providing assistance when errors occur.
And the final principle is robust.
Disabled users make use of a far wider range of browsers and assistive technologies than regular
users. A website must be compatible with as many of these as possible.
So weve talked about Nielsens usability heuristics and the Web Content Accessibility Guidelines.
There are many more guidelines around, but you need to be aware of these sets as a minimum.
185
David Travis
10-01 How to convince your manager that UX matters

Okay, so weve covered quite a bit of material on this course and what I want now is to give you
some tips on how you can actually start putting this knowledge into practice.
Lets first look at how to get your organisation to take this stuff seriously.
Its obvious from what youve learnt on this course that usability and UX make a lot of business
sense. But trying to make usability happen in an organisation needs more than logical arguments.
You also need to appeal to your managers' emotions and political ambitions. So here are five
successful strategies that I've seen applied in the various companies Ive worked with over the
years.
Im going to encourage you to:
Think Strategically
Recruit a Top-level champion
Raise Awareness
Demonstrate ROI
and Talk the right language
If you look closely, there's even an acronym in there: START.

So first up, think strategically. If your organisation is just starting out in usability, it's likely that
usability testing will form the bulk of what you do. But be careful that you don't fall into a common
trap: trying to run a usability test on every project.
Instead, try a more strategic approach and focus on key projects. To identify a key project, ask:
How important is good usability to this project?

How important is the project within the organisation?
How likely is it that you can use the project to measure the before and after benefits of
usability?
How supportive is the project manager of user-centred design?
You want to aim for end-to-end involvement on mission critical projects that have a lot riding on
the user experience.
You now know that the biggest payback from usability occurs when its done early in the lifecycle,
so 80% of your project work should be focused on understanding customers and iterating designs.
If the design team want you to rubber stamp their design with an expert review, just say No.
Next up, identify someone at board level in your company who is a clear user advocate.
If no-one springs to mind, seek out a manager who is leading a customer-centred initiative like
quality, six-sigma or business excellence and show him or her how usability will support their
initiative. Heres some ideas:
Show how user centred design is linked to key business objectives, such as increasing
conversion rate, decreasing churn and improving customer satisfaction.
Prepare a snappy "wake-up call": dissect a product that failed because user requirements
weren't considered. Explain how usability testing could have saved the company its
embarrassment.
Show the manager some usability test footage where some key customers struggle with your
product.
You also need to raise awareness. This is because organisational change is most effective when its a
186
David Travis
team effort. Some ideas Ive seen work are these:
Maintain a usability intranet with past reports, highlights videos, guidance for best practice,
a slide show... This is advocacy material and you want to make it easy for your supporters to
use in their presentations.
Educate your management team, for example by sending out a monthly newsletter that
shows people that usability means more than testing.
Raise awareness of relevant legislation (like disability laws) and international usability
standards.
Speak at industry meetings and usability conferences. This will validate the relevance of
your work in the eyes of your peers.
Increase your team's profile with professionally-produced posters and giveaways like mugs
and t-shirts.
Another technique is to demonstrate return on investment or ROI. Ive already mentioned that
logical cost benefit arguments don't always work. This is because they aren't based on data from
your company or industry. For real impact, collect "before" and "after" data to show the cost
benefits of your involvement on a specific project.
With e-commerce clients, I teach them about the "domino effect": usability problems early in the
process wipe out the customer base, leaving fewer customers to enter subsequent phases. For a
complex e-commerce transaction, it's not unusual for this effect to reduce sales by over 50%.
And finally, you need to talk the right language.
There is a simple way to present usability data that, under the right circumstances, can make it
irresistible and compels people to action. All you have to do is find it.
In some organisations, this may be a detailed, analytical report that carefully weighs the costs and
benefits of fixing each usability problem.
For other organisations, it might be a PowerPoint presentation, summarising the key findings.
Elsewhere, it might just mean getting the team in to watch a usability test in progress.
And senior managers often get engaged when you show a highlights video.
But you may need to get creative. In one organisation, the most powerful tool I observed was when
they moved from standard reports to a highly visual, one-page "usability dashboard". These reports
spread through the organisation quicker than an e-mail virus. So think for a moment: if you were
going to summarise the results of your 3-day usability test on just one page, what would you put in
it?
187
David Travis
10-02 Getting users for your first user research activity

Another question Im often asked is: How do I get started with users? I know this can be a difficult
prospect for people who work in an organisation that hasnt done much user research in the past.
So here are 5 tips for getting your users involved.
First up, offer your participants an incentive
When you saw incentive on this slide, I bet you thought money. Indeed, money often works.
But if your users are investment bankers, its unlikely your budget will stretch to the kind of cash
payment that will incentivise them. In fact, an incentive doesnt need to be money. A few years ago,
I worked on the redesign of an airlines first class cabin and I found that I could get users to take
part in our research by offering them a voucher for an experience day (we offered them a day
driving a racing car). This doesnt cost much more than a standard incentive but it often appears a
lot more valuable. And for some users, just the offer of free food, drink, t-shirts or coffee mugs is all
it takes to get people to take part.
You could also tell people they are helping to design the future.
People like to hear that their views will make a contribution to design. So telling people that your
new system will define the industry in the next few years, and this is their way of tailoring it, can
often be very tempting for them. At the very least, by getting involved, they get the opportunity to
have early sight of whats coming.
You might also try winning over an influential user.
In most communities whether its a profession, an organisation or a small department in an office
there are a small number of people whose opinion is enormously influential. Make it your job to
identify these people and spend some time bringing them on board.
You could also try just getting in amongst your users.
Go where your users hang out and introduce yourself. You dont need to do any hardcore selling.
Simply tell people that you want to do research with people like them and ask them to suggest a
good way to make contact with people. At this point, I find that the person Im asking will volunteer
themselves or at least identify someone else that they know.
And if all else fails, you can pay for a recruiter.
If you really, really cant face finding people then there are people that will do this for you.
Confusingly, they are called recruiters (but they are not the same as a job recruitment agency).
These people tend to know thousands of people in a variety of walks of life and, for a fee, will get
you just the people you need.
So I hope there is something there that will allow you to find users for your project.
188
David Travis
10-03 Building your UX career within your organisation

In this lecture, as we reach the end of the course, I want to remind you to build your career. So here
are some tips to help you build your career inside your company.
Begin by trying to describe what you do in a memorable way.
Senior managers don't always understand what UX means, or they may have a preconception that
its all about visual design. So instead, create a short, pithy, description of what you do so that
people within your organisation 'get it' immediately. Focus on the most important problem that UX
can solve in your company and create an elevator pitch for it. For example, heres one: "You know
how we get lots of customers abandoning the checkout process? Well, what I do is find the
problems and tell the development team what to fix." Heres another: "You know how 30% of our
handsets are returned as 'fault not found'? It turns out that most of these returns are because the
designers didn't understand how the handsets would be used. I watch customers work and design
technology that fits in with the way they think and act.
Next, youve probably got ideas about how some of the methods weve discussed on the course will
increase profits, cut costs or improve customer satisfaction within your company. So put them in an
e-mail and send them to your boss. If necessary, ask him or her to pass them on to the decision
maker but make sure your name stays with them.
You also need to keep on top of your game.
To get promoted, you need to be confident in your knowledge and expertise. To get that kind of
confidence, you need to know what's happening in the field of user experience. So buy one of the
books on the reading list in your student handbook and read user experience blogs and articles as
often as you can.
This will help you stand out from the crowd and begin to make your name synonymous with user
experience in your organisation. So when someone wants UX support, your name will be the first
one that comes to mind. Let people know that you care about usability and become the recognised
expert.
If you work in a larger user experience team, get a specialism that distinguishes you from everyone
else, such as usability testing, information architecture or ethnographic research skills. So identify
where your interests lie in UX and what you feel passionate about.
And as a final idea, try writing a blog post.
One of the best ways to demonstrate the expertise you've developed on this course is to write your
own blog post on the history and the future of user experience in your specific industry. Outline the
origins of UX in your industry and how it has changed over time. Create some possible scenarios
for the future of UX in your industry and explain how each might pan out.
When youve written it, send me the link and Ill publicise it for you on Twitter.
So what are you eating for? Get writing!
189
David Travis
10-04 Creating a UX Portfolio

So weve talked about building your career inside your company. How about building a career
outside your company?
A critical part of applying for a job in UX is having a portfolio. A UX portfolio sits alongside your
CV and demonstrates your experience. It should comprise a series of case studies of projects that
youve carried out.
If youve followed the design activities on this course, you already have one or more case studies
you can add to your portfolio. But what should go in a good UX portfolio?
Here are some tips on creating a UX portfolio based on the hundreds that have been sent to me over
the years.
First, show your working.
If youre a researcher or designer, you dont design screens. You design experiences. So use your
portfolio to showcase the research work that underpins the designs youve been involved with.
What were the business objectives? How did you ensure they were met? At what points in the
process did you involve users?
Second, tell a story for each case study.
Your case study should start by explaining the business problem you were trying to solve. Just one
or two sentences will do. If you struggle with this, try to remember how the project started: how did
your client describe the problem?
Then describe your approach. Of the universe of possible research methods, why did you pick the
one you did?
Next, present your results. Be brief, but show enough detail to make it clear that you know what
youre talking about. Describe one of the major problems you encountered with the study and how
you solved it. This is the place to show youre a problem solver.
And the final part of your case study is to describe the impact of your work. Relate your findings
back to the business problem. Did you solve it? If not, what did you learn that you will apply to
your next project?
Third, assume your portfolio has just 1 minute to have an impact.
Youll spend hours on your portfolio. But sadly, employers will spend one minute looking at it.
After one minute, theyll decide to spend another 5 minutes on it or send a rejection letter.
I know, its brutal.
But its not dissimilar to the way you behave when you land on a web page. You scan it and then
quickly make a decision to invest more time or hit the back button. You can be brutal too.
But this means you must design your portfolio for skim reading. Not only does this mean its more
likely to get looked at, it also demonstrates your skills in user experience: it shows you know how
people read. Its a great example of the medium being the message.
190
David Travis
In terms of overall size, I know this may not be a great help, but youre after the Goldilocks
portfolio: not too long, not too short, but just right. One way to achieve this is to ruthlessly cut out
duplicate projects. If youve done three card sorting studies and two paper prototyping exercises, I
know that its tempting to include all of them. But dont. Instead, show just one case study of each
type. Aim for 1-2 pages per project and keep it visual.
And finally, focus on the details
This one seems obvious we all know its rule number one when youre putting your CV together.
But hold on: there an interesting twist when youre applying for a job in user experience. Both UX
research and UX design are inherently detail-oriented professions.
Of course your spelling and grammar will be ruthlessly examined. But it goes beyond this.
What font will you use? (Hint: it wont be Comic Sans).

What kind of layout grid will you use for your case studies?
Where is your call to action?
With your portfolio remember, the medium is the message.

So I hope you find those tips useful when putting together your own UX portfolio. Best of luck with
it.
191
David Travis
10-05 Putting your knowledge into practice

At the risk of sounding like Country Singer Loretta Lynn, weve come a long way baby.
So, lets wrap up.
This is the course roadmap that weve been talking about. Its based on the standard ISO 9241 part
210, and this diagram should now feel like an old friend. If youve followed along with the lectures,
you will now have a good grounding in user-centred design.
It seems a long time ago that we started on that can opener exercise. But reflect for a second on how
far youve come since then. You now know about the importance of context. You know how to do
field visits. You can create descriptions of users and their tasks to use in design. You know how to
identify red routes. You can create measures of usability and create experiments to test your ideas.
You know how to organise information using the LATCH model. You know about interaction
design and how to make screens look attractive. You also know how to evaluate usability, both by
running a usability test and by doing a usability inspection.
Thats not bad. You deserve a pat on the back.
But before you rest on your laurels, heres some suggestions for next steps.
Ive described how you can create a good portfolio. Now its your turn: use the work youve done
on the design activities in this course to create your own portfolio entry. Remember, a portfolio is
where you demonstrate your expertise. So use one of those exercises as a case study for your
portfolio.
Next, think about getting certified in user experience. In this course, weve covered the syllabus in
the BCS Foundation Certificate in UX. This certificate is independent of any training providers and
is becoming an industry standard. Do a search for BCS Foundation Certificate in UX to find an
examination centre near you. Ive added a sample paper from the exam at the end of this course so
you can use that to judge the standard of the exam. If youve listened to the lectures on this course
and if youve done the activities, you know enough to pass it.
I also want you to take charge of your career. As well as following up on those suggestions I made
earlier, you need to take charge of your learning. I have other specialised courses on Udemy that
give you the chance to do a deep dive in UX, and I hope to see you in those courses too. Just do a
search for my name in the Udemy system and youll find the other courses Ive created. If you use
coupon code alumni youll save 25%. It would be great to see you there.
Finally, please keep in touch.
I hope youve joined the courses Facebook group. And as well as using the Udemy site to contact
me, heres my business card.
Listen, youve learnt some powerful methods on this course. Id like to challenge you now to put
those methods into practice. Bad design, remember, has consequences. User experience is one field
where you really can make the world a better place by applying your knowledge.
I hate to come over all Ghandi, but be the change you want to see in the world. If you think your
organisation needs to become more user centred, then take responsibility for it: do a field visit.
Create a persona. Define some red routes. Run a usability test.
192
David Travis
If you dont do it, who will?

Think of it as you and me together, fixing one bad design at a time. Theres enough of us now to
make a difference.
So do that. Go make a difference. Go make the world a better place.
193
David Travis
12-01 Bonus Lecture: Persona analysis with multiple behavioural

dimensions
I wanted to summarise the approach that we have been discussing for developing personas. So,
initially, were going to go out and do some contextual enquiry about how to understand our users,
our environments, our goals, and were going to feed those into some kind of analysis machine
which will generate the behavioural variables, such as the knowledge of technology that we talked
about earlier, such as the knowledge of hiking and walking, which is the one we used in our case
study. And out pop our personas. Now, I havent come across one of these machines yet that
actually work. Most of the analysis needs to be done yourself.
But earlier I talked about these two dimensions for our hiking app that we were developing. In
practice, I find that the dimensions that come out of contextual enquiry vary. So, its rare that you
end up with the same dimension across different studies. And this slide shows some of the kind of
dimensions that Ive seen come across in different studies that Ive looked at. Now the fact is, in
real research, its multidimensional. You dont get these two, its rare that you just have two
dimensions. If you do have two dimensions, its great because you get the four personas that kind of
pop out if people populate each of the cells. In practice, it tends to be multidimensional. So, what I
wanted to do now was go through another case study, but this ones a bit more realistic. This
particular case study well look at multidimensions and how you handle that in your analysis
process.
So to do that, lets set up another particular case study. For this particular one, lets imagine that
weve carried out some persona interviews for a company that sells upmarket stationery. Now,
incidentally, this particular firm that Ive got the screenshot from here, David Camerons wife works
for, so the UK Prime Ministers wife works for this company and indeed, they produce upmarket
stationery. You couldnt make it up, could you really? So, were going to interview six people. And
lets assume that we do our interviews and a number of characteristics emerge like, personal,
business purchase, bargain basement, luxury and so on. And what well do now is well map our
research participants to these key characteristics. What were going to is were going to populate
this table with our interviewees.
So, for example, you can see that Craig, Sally and Phil, they tend to buy stationery as a personal
purchase while Emily, Sam and Jane, well, they tend to buy stationery as a business purchase. And
now lets populate the rest of the table. And what were looking for is patterns in this table. Which
interviewees tend to cluster together?
Well, it looks like Sally and Phil share many of the same characteristics. Sally and Phil buy
stationery as a personal purchase, they tend towards the luxury end, especially Sally, theyre brand
loyal, time poor, they purchase stationery frequently, theyre technology novices, theyre highbrow,
they use the internet for purchases rarely, and theyre browse dominant. And it looks like Sam and
Jane share many characteristics too. Theyre pretty much the opposite of Sally and Phil. Notice that
Emily and Craig have the odd thing in common, like they tend towards the time rich end of the
scale, but you couldnt really say theyve much else in common. So, theyre not a persona. And in
fact, if I was doing this kind of work, I would then look at this and say, well, actually we obviously
need to go out and do some more observations because weve got Emily and Craig who are just
sitting on their own at the moment. Surely there are some other people out there. Weve not reached
the point of least astonishment yet: as youd expect given that weve only six people on this table.
(The reason for having six, by the way, is just to make this table easier to understand. If Id put 21
on here, it would be become impossible for you to follow.) But the point is, what we would do next
is then use these data to create personas. So wed combine Sally and Phil into one of our personas,
number 1 the red circles, and Sam and Jane into another, number 2, the green circles here. Now, we
194
David Travis
can then create specific personas based on those psychographic characteristics. Now, obviously, we
need to do this with more dimensions and with more interviewees, but I hope now you get the idea
of how to do this kind of analysis.
195

Transcript of Lectures - UX The Ultimate Guide To Usability

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Transcript of Lectures - UX The Ultimate Guide To Usability

Încărcat de

Drepturi de autor:

Formate disponibile

User Experience: The Ultimate Guide to Usability

Lecture transcripts for User Experience: The Ultimate

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

6-01 Introduction to Lean UX............................................................................................................88

User Experience: The Ultimate Guide to Usability

9-11 Prioritising usability problems.................................................................................................171

User Experience: The Ultimate Guide to Usability

1-01 Why take this course?

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-04 Whats new in this course?

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-06 The business benefits of user experience

User Experience: The Ultimate Guide to Usability

London had been relocated to Ontario.

User Experience: The Ultimate Guide to Usability

1-07 What is Usability? Product evaluation activity

User Experience: The Ultimate Guide to Usability

1-08 Can openers - Demonstration

User Experience: The Ultimate Guide to Usability

1-09 Can openers - User Research

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-10 Can openers - Debrief

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-11 The 6 Rules of Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-12 ISO 9241-210 - A standard for usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

1-13 The Course Roadmap

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

2-01 Introduction to the context of use

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

2-03 What do users want?

User Experience: The Ultimate Guide to Usability

People arent very good at this.

User Experience: The Ultimate Guide to Usability

2-04 Introduction to Contextual Inquiry

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability

2-05 The Remote Control - Activity

User Experience: The Ultimate Guide to Usability

2-06 The Remote Control - Debrief

User Experience: The Ultimate Guide to Usability

2-07 Practical site visits, step 1 - Users

User Experience: The Ultimate Guide to Usability

2-08 Practical site visits, step 2 - Focus

What would the research tell you?

User Experience: The Ultimate Guide to Usability

User Experience: The Ultimate Guide to Usability