There are many books for designers. There are fewer good books for designers. There are even fewer good books for designers where information is presented straight to the point without unnecessary details.
Think Like A UX Researcher is a must-read for all UX designers, researchers, and perhaps Product Managers. It’s not just a book; it’s a textbook with a straightforward presentation of information and practical exercises after each chapter. It’s one of the few books that you should always have on hand.
In this post, I want to share the most interesting quotes from the book.
a
Field visits and user interviews give you signposts, not definitive answers. It’s broad-brush stuff, a bit like the weather forecast.
It’s those conversations that help you identify the gap between what people say and what they do — and that is often a design opportunity.
It’s those conversations that help you identify the gap between what people say and what they do — and that is often a design opportunity.
b
You shouldn’t approach interviews with a vested interest: The UX researcher’s job isn’t to convince people to use a service, or to get the results management want; it’s about digging for the truth. This doesn’t mean you shouldn’t have a point of view. You should. Your point of view should be to help the development team understand the data, not just tell the development team what they want to hear.
c
Here’s a secret many people don’t know: you don’t need to create personas to be user centered. User centered design is not about personas. In fact, personas really don’t matter.
d
Holmes was an investigator par excellence, but he was not a super hero (he did not have super powers). Instead, he had well-honed skills and specialist knowledge about a few things. And he was nothing if not methodical. His method comprised these five steps:
• Understand the problem to be solved.
• Collect the facts.
• Develop hypotheses to explain the facts.
• Eliminate the least likely hypotheses to arrive at the solution.
• Act on the solution.
• Understand the problem to be solved.
• Collect the facts.
• Develop hypotheses to explain the facts.
• Eliminate the least likely hypotheses to arrive at the solution.
• Act on the solution.
e
Here are some things we can learn from Holmes’s approach that can help our UX research thinking:
• Focus on the problem not the solution.
• Create an explicit research question (actually write it down with a question mark at the end).
• Don’t start doing any research until you have this question.
• Don’t assume the question has never been asked before.
• Find out what your colleagues and your company already knows.
• Do an archival search—start by reading any prior research reports.
• Interview team members and stakeholders.
• Use a checklist to collect background information in a systematic manner.
• Leave nothing to guesswork.
• Focus on the problem not the solution.
• Create an explicit research question (actually write it down with a question mark at the end).
• Don’t start doing any research until you have this question.
• Don’t assume the question has never been asked before.
• Find out what your colleagues and your company already knows.
• Do an archival search—start by reading any prior research reports.
• Interview team members and stakeholders.
• Use a checklist to collect background information in a systematic manner.
• Leave nothing to guesswork.
f
Fundamentally, all UX research answers one of two questions: (a) Who are our users and what are they trying to do? (b) Can people use the thing we’ve designed to solve their problem? You answer the first question with a field visit and you answer the second question with a usability test.
g
Without field research, you’re designing in the dark. With field research, it’s like someone has turned on the room lights.
h
Development teams almost always overestimate the technical competence of their users.
i
Innovation happens only when teams fundamentally question what they are designing — and the best way to raise these questions is by understanding users’ needs, goals and motivations.
j
One of our favorite examples comes from IDEo. They were designing a new kind of sandal. They expressly included outliers in their sample, like podiatrists and foot fetishists, to see what they could learn. This is what we mean by understanding the boundaries of the research domain.
k
Include in your participant sample people with low digital skills. In other words, don’t just recruit the ones who are tech savvy. Including people with low digital skills will make it much more likely you’ll find problems that affect a low proportion of users. This is the idea we introduced in the last essay of recruiting people on the left of the bell curve.
l
To run a usability test, you need to know the business objectives of your product because otherwise you don’t know where to focus your test. What is the business trying to achieve with this thing? It’s not unusual for different business units within an organization to hold competing, contradictory or inconsistent business objectives. So getting a direct answer to this question is crucial for any future UX research and design activities you engage in.
m
Development teams maintain a backlog of technical work that they want to complete and when this gets overly long you’ll find someone adds “simple to use” to the list. But “simple” isn’t a feature. You can’t build “simple” into a product. You have to weed complexity out.
n
What people do is a better indicator of the underlying user need than what people say.
o
In fact, as Caroline Jarrett has pointed out, asking one person the right question is better than asking 10,000 people the wrong question.