For all of us who make software, the user is ultimately our reason for being. She buys the subscription that supports the app that is owned by the client that pays our mortgages. He reads the content that is supported by the ad-space that supports the content writers who work for the other client that pays the rest of our bills.
But do we know these users? These readers, workers, buyers, and subscribers? Have we actually talked to them?
“Talk to them?! That’s {UX Person}’s job. Besides, it takes a bunch of cameras and two-way mirrors and black magic and candy dishes. How would I even try to pull that off?”
Well. Darren is glad you asked. He spent a whole day talking with us about it.
Everyday User Insights for Everyone
Darren Kall formerly worked at Microsoft, LexisNexis, IBM, and other impressive places, and he’s an all-around smart and engaging guy. And despite the intimidating list on his resume, his Maker Series goals were focused on approachable, everyday tools for everyone. That’s right. Darren believes that it’s not just the trained user researcher who can benefit from and deliver user insights—he also believes in equipping developers, designers, managers, business stakeholders, and the like. His Maker Series workshop promised techniques to deliver user insights that could be used the next day, and he delivered.
Workshop attendees were treated with lesson-style teaching from Darren, but we were also invited to practice and participate. We volunteered. We were volunteered. We did small groups. We ate donuts. It was an all-around good time.
We discussed and practiced four user research techniques that on the continuum of user research techniques, leaned toward the simpler and easier to learn and implement in a field-study situation. The four techniques can be used separately, building upon one another, or in mix-and-match combinations, depending on the situation. And, though the techniques are simple at their core, the opportunities for user insights are great—and grow greater with practice and experience.
What follows is a recap of each of the four techniques that we discussed and practiced.
Technique #1: Structured Observation
Essentially, this is the “sit back and watch the user” technique. It is watching users with a great deal of preparation, intentionality, and focus as they navigate a predetermined activity: using your app; completing a task with the full web; using a physical product; just doing their life activities without ever touching your product; etc.
Your Attitude for Structured Observation:
Be curious.
Be open with your user about what you’re doing. You’re in this together.
Be willing to accept what you discover. Even if it makes your product look bad.
Observe without interfering.
Your Preparation:
**Prepare a list of internal questions you’re hoping to answer as you observe: **
Who are they?
What are they doing?
Why are they doing that? Etc.
Have a structured format for note-taking.
You’ll be taking copious notes, so you need to capture your observations quickly yet be able to interpret them easily later.
Note users’ behaviors. Don’t assume and guess their motivations.
Guesses and hypotheses should be noted separately, labeled for what they are, and proven/refuted otherwise with evidence.
Your Rhythm for the Observation:
Actively observe.
Observe in this very moment.
Watch with purpose. Observation is not just seeing.
Filter what you are looking for. You cannot observe everything.
Observe with a partner. You’ll see different things and should compare notes later.
Organize what you observe.
Take notes in a way that suits you.
Note your hypothesis for later clarification.
Understand what you observe.
Identify purposes for your observation ahead of time.
Be active and focused on your goals. Learn something specific and useful.
As you observe, discover insights.
Make connections among your purposes, goals, and observations as you go.
Do something useful with your user insights.
Technique #2: Inquiry for Clarity
This technique flows very naturally out of Structured Observation. Though Darren didn’t expressly state that Inquiry for Clarity should always follow a time of Structured Observation, it does seem to be the natural progression. Essentially, in this technique, we have been and continue to observe the user in his activity. However, we are now choosing to intentionally ask simple questions to gain more clarity from the user about those actions.
With these questions, we are testing our hypotheses, hoping to prove or disprove them. The goal, however, is to be as least invasive as possible; the more you involve and engage the user, the more you change the dynamic and affect his actions. This becomes an intentional dance as you balance keeping the user on track while influencing outcomes as little as possible.
The inquiry is not an interview; it is a simple question, preferably one that can be answered with a simple “yes” or “no.” Before you start, tell the user that short answers are ideal to set his expectations ahead of time. And while we aren’t interviewing users, we still need to gain insight into their thoughts. As humans, we tend to speak in generalities in an uncomfortable situation, so be sure to have users speak for themselves. When he says, “everyone wants this,” you should clarify, “Do you actually mean, ‘I want this’?’”
Examples of Poor Questions
Open-ended: What would make it a better design?
Leading: Would you have noticed it if it were purple?
Framing: I think you had a pretty hard time with that. Don’t you agree?
Judgmental: That was kind of a silly mistake, wasn’t it?
Examples of Good Questions
Was that what you expected?
What did you just do?
What are you trying to get to?
Have you completed the task?
What is the name of that thing?
What button did you just press?
Are you trying to return shoes?
Do you intend to purchase today?
Can you do that again, but more slowly?
Technique #3: Talk Aloud Protocol
Again, this technique could be a natural progression following Structured Observation and/or Inquiry for Clarity, but it would work as a standalone activity as well. Essentially, the Talk Aloud Protocol involves the user “thinking out loud” or talking as she performs her activity, sharing whatever comes to mind as she works.
For example, she may share:
What she is doing.
What she is looking at.
What she is looking for.
Why she is doing so.
How she feels about it.
As an observer, your role is noting all of this, especially those places where the user has difficulty or frustration, and keeping the user talking and on-task while affecting her behavior as little as possible. As she talks, she may simply be describing her actions as she does them, or she may be describing her intentions as she does so. Both are useful as an observer.
One important note is to be wary of censoring. If the user seems to be omitting something, she may be frustrated, surprised, or annoyed. Perhaps she doesn’t realize she is holding back, or perhaps she is being polite. Regardless, what she is holding back is likely something very valuable. Watch for this censorship and gently prompt to get it out.
Technique #4: Descriptive Storytelling
Humans are natural storytellers. We’ve done it since the beginning of time, and the easiest story to tell is our own. While Descriptive Storytelling isn’t as precise as the other techniques we tried, it is one of the more natural techniques for users in which to engage. In this technique, we give the user a scenario, and we simply ask him to give us that story.
Examples of Good Story Prompts
Tell me about your typical work day.
Describe for me the hour before and after you use our product each day.
Tell me about your interest in traveling.
Share with me how music fits into your life.
I want to hear about the planning of your wedding.
Tell me about a time you got really lost.
The user then simply tells his story. It will be deeply colored and personal. It will contain emotions, locations, details, memories, and values. It may not be wholly accurate or even truthful, but it will contain a rich, subjective narrative of information that you can inquire about, steer, and explore.
As the listener and observer, notice also what he is not saying in his story. What details did he consider unimportant that you’d like to know? The user may also include details that don’t seem apparently important to you, but since they were important enough for him to mention, they could be worth exploring.
As with previous techniques, you want to gently guide your user without biasing. Be patient for the story to develop—it may not be immediately relevant—but seek to keep it at least distantly related to the goals of your observation. If there is a part of the story the user introduces that you’d like to know more about just ask, “Can you tell me more about that?”
The end result of this technique is observations and insights that are likely very different than what you would gather with alternative techniques. Consider how different the result would be if your original example story prompts (above) were framed more like this:
What do you want our product to do to help you in your work day?
How could our product be better?
What do you want a travel app to do?
Which music service do you prefer?
Did you use a website to plan your wedding?
How do you use your map app?
Go for It
As I mentioned previously, Darren devoted this Maker Series workshop to discovering and practicing techniques that we could use immediately in gaining new user insights. He chose the four techniques that he did because of their relative simplicity to execute, and he encouraged all of us to use them to improve our users’ experiences.
Working directly with users is a rewarding and enlightening experience. It doesn’t take much effort to realize how valuable user insights can be; however, the opportunity for greater insights grows with repetition, practice, and experience.
So go out there, and go for it. And if you’re looking for more information, I’m sure Darren would be happy to have you hit him up on twitter @darrenkall.
