How To Think Like Sherlock Holmes

I remember watching the first episode of Sherlock in 2011 with my brother. While my brother decided to promptly ditch the show to play his video games, I was immersed in it immediately. I remember the iconic music, the deerstalker, the cloak, the suspense mounting beyond all breaking points, and finally, finally, at long last the awaited solution, when it all made sense and I’d shake my head, just like Dr. Watson, and think, Of course; it’s all so simple now that he says it.

Holmes was an extraordinary detective, yes. But what truly made him special isn’t just his way of solving crime. It is his deep insights into the human mind and an entire way of thinking, a mindset that can be applied to countless enterprises far removed from the 221B Baker Street of London.

In this essay, I’ve tried to distill my observation on how we, as UX professionals, can learn to create a model for thought, for decision making, for how to structure, investigate, observe, and solve problems like Sherlock Holmes.

Understand the Problem to be Solved

“I never guess. It is a shocking habit—destructive to the logical faculty.” – The Sign of Four (1890).

Most projects fail not because of poor technology or bad user experience. They fail because nobody in the team bothered to answer two basic questions:

1. What do we want to get out of this product?
2. What do our users want to get out of it?

Many teams, who use an iterative design like Scrum, don’t invest enough time in discovering & defining the problem the website/product is trying to solve. Instead, they jump right into development with their preconceived ideas about user needs & problems. Yet, it’s by having a clear understanding of the problem that gives the team the best chance of innovating and creating a great user experience.

Here’s the thing – When we fixate on the solutions too early, we risk losing sight of the actual problem we were trying to solve.

If you don’t understand the real problem, your solution doesn’t have any inherent value. So before a single pixel is pushed, a line of code is written, or any server is installed, have a thorough understanding of the problem you are trying to solve. And don’t assume that your problem is unique and no one has asked the same questions before. Interview the company and team about what they already know, read the background and prior research reports, synthesize it to makes sense.

Leave nothing to guesswork.

Collect the Facts

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

Opinions are not facts and speculation is not evidence. When we see or hear things, it requires no effort on our part, absorbing countless streams of sensory inputs without necessarily processing what those inputs might be.

The best way of collecting facts, Holmes says, is through careful observation. Observation requires an active involvement. We are forced to pay attention, to move from passive absorption to active awareness. We have to engage.

Observation can help us find the unmet user needs during field visits – often which the users can’t even articulate properly or know is even there.

It’s best to observe with no judgment, expectations, or prior assumptions or theories. Don’t try to interpret things or try to fit things together at this stage. Start with a blank slate and don’t worry about what you are noticing & capturing.

Watch people in their real environment, actually doing the work; don’t just get a demonstration. Remember that your participants are the real experts, you are the “novice.” Focus on the most typical tasks, busiest days, typical days, and critical incidents. Find out the activities that precede and follow the task you are observing.

Look for inconveniences, delays, and frustrations. Shadow people, follow them wherever they go. Point to things and find out what they are for. List the tools people are using. Make note of people’s dynamics and interactions. Be alert to things happening simultaneously. Record anything unusual about the scene you are looking at. Ask yourself if anything is missing

Observe behavior at a low level of detail — watch what people touch and what they look at. Pay attention to the sequences and timing of events and actions. Pay attention to trifles. And most importantly. don’t get in the way.

Develop Hypothesis to Explain the Facts

Sherlock Holmes was a specialist. He had a deep knowledge of very narrow fields. His understanding of Chemistry, footprints, bloodstains and various poisonous flowers ( but not general gardening) was unparalleled. But, he didn’t bother knowing that the Earth revolves around the Sun.

“What the deuce is it to me? You say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work.”

We need to have deep knowledge of human behavior, technology advances, market trends, and our company’s business goals so that we can develop strong hypotheses that best fit the facts we collect from our UX research.

Our hypothesis helps us identify the gaps in the way people work— a gap being the opportunity that emerged when we compare the way something is currently being done, and the improved way it might be possible to do it in the future.

To help the team see these gaps, we need clarity on our users, their tasks, and their environment of use (Who? Doing what? Under what circumstances?)

Our models, personas, scenarios, and stories should include:

1. The primary goals that people have.
2. The workflow of tasks people carry out.
3. The mental models people build.
4. The tools people use.
5. The environments people work in.
6. The terminology people use to describe what they do.

When our analysis is completed, we should have clear answers to these. This will allow us to see the gaps and the opportunities for improvement, and then, finally, we can start working on solutions.

Eliminate the Least Likely Hypotheses to Arrive at the Solution

It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.” The Adventure of the Beryl Coronet (1892).

At this stage, if we have done our work right, we will have a number of potential design solutions, product ideas, and improvements.

Now we start eliminating the weaker solutions by asking:

Does our hypothesized solution fit the results of our investigation?

Eliminating potential solutions is a high stakes game, as the evidence for or against a solution must be compelling — it needs to be reliable, valid, and unbiased.

Experiments are our friends. It helps us test the strength of our hypotheses, ideas, and solutions. As we move into the development cycle, controlled testing should continue as an iterative process, with the team prototyping its way towards success.

Act on the Solution

You have understood the problem, collected the facts, came up with potential hypotheses & solutions, eliminated the least likely hypotheses, now how do you ensure that your recommendations are carried out by the development team?

Here are a few recommendations:

1. Conduct a one-day UX research and design workshop to “explain what we found and how we did it” and to transition the user experience findings and solutions to the development team.
2. Provide the development team with specific and actionable design recommendations.
3. Agree on accountability for implementing your user experience recommendations.
4. Promote iterative design by arranging to test multiple versions of the prototype.
5. Create and present a clear series of next user experience steps—both tactical and strategic.
6. Educate the team in UX research methods.
7. Don’t just attend design meetings: chair them.

In Conclusion

Your users don’t think as you do — this concept is the easiest to understand intellectually, but the hardest to appreciate intuitively.

Your user’s worldview is different than yours. They don’t see the world the same way you do. They don’t value the same things you do. They don’t know the things you know. Trying to understand their worldview before you make your product — that’s empathy.

People like to think that their decisions are rational and made with deliberate thought.

But, in reality, people are very bad at introspecting their behaviors & decisions.

People want to tell a good story—a “narrative”—of their life and will change what they say to fit the view of who they are and to whom they are talking.

So stop asking users to introspect their behaviors. Instead, run experiments where you can observe them & find how they are currently solving their problem. Try to map their needs, goals, and pain points, ideally where the action happens. Don’t just listen to what users say they do. See what they do while they do it.

Never act on assumptions. Search out the facts and act on those.

Lastly, as Holmes said, “You know my methods. Apply them!”

• ← We are made to create
• How would you have lived your life differently if you had a chance? →