The first rule of user experience (UX) is to understand our users.

Even if you disagree that’s the first rule, everyone agrees it is vitally important.  You can’t always trust what users say, but you need to understand what they do and how they do it. Empathy is the foundation of design. And so we have processes for discovering personas, often focused on the various roles and goals in our user base.

Discovering personas is good and worthwhile; yet personas often fail – fail to provide long-term value, fail to meaningfully capture critical aspects of reality.

There are a few reasons for this, but I think it’s largely because personas tend to ignore context – or at best, focus on a single context. Context can completely change how a person interacts with a system, often in ways that are unintuitive and hard to predict.

I was recently reminded of this in a visceral way. Grab some coffee. I want to tell a little story about CPR training.

The Emergency Context

I learned how to do CPR many years ago in high school. I never used the knowledge and thus rapidly forgot it. When my daughter was born several years ago, I decided it was time to refresh that knowledge and took a Red Cross class on CPR & First Aid. That training felt much simpler than what I learned in high school, but who knows. Decades separated the two.

Again, I didn’t use the training, thankfully, and thus rapidly forgot it. Recently, I renewed my certifications again, and this time the training felt even simpler. Is it me or did the training change?

I was curious about this but didn’t want to disrupt the class with meta-tangents. Afterwards, I hung around and asked the trainer about this. She kinda grimaced, and I could tell I hit a nerve, could see her weighing options of how to respond.

Finally, out poured this monologue:

“You know, it turns out that most people suck in emergencies. It’s not their fault. Reality isn’t this classroom. Here, it’s easy to count compressions and think about what to do next. It’s calm and relaxed.

Reality is fluids everywhere.

People screaming and crying, family who won’t give you space to work. There’s blood, spittle. Heart attacks make you vomit. Other things evacuate your bowels.

Reality is slippery chaos.

Unless you’re a professional and do this all the time, you’re gonna be freaked out. That’s just what happens. Your adrenaline’s flowing; your heart’s beating out of your chest. You forget how to do the most basic tasks.

You make bad decisions that you’d never make in here.”

I’m paraphrasing her, but I remember her vehemence. She went on to give several specific examples. I remember two around checking for responsiveness:

• They used to advise checking for a pulse. Now they don’t. Your heart, amped-up in an emergency response, is beating so strongly that people frequently feel their own pulse in their fingers and mistakenly think it’s the victim’s. So now, the training skips the pulse check altogether.
• They used to advise “Look, Listen, Feel” for breathing. Look to see if their chest is rising and falling. Listen over their mouth and nose for breathing sounds. Feel their breath against your cheek for 10 seconds. Now they don’t. Instead they just advise to watch the chest for 5 seconds and proceed with care protocols if you don’t see a rise and fall.

 

What’s behind these changes?

It turns out the Red Cross conducts user research studies. They figured out, over time, that even these simple-seeming instructions were having an unintended negative consequence.

Lay responders (that’s you and me) would often get so caught up trying to find a pulse, debating whether it was the subject’s or their own, trying to determine breathing, was that a breeze or a breath, etc… that sometimes 5-10 minutes would elapse just determining if the person was responsive.

• That’s 5-10 minutes longer before an ambulance is called.
• That’s 5-10 minutes longer before compressions get oxygenated blood to the brain.
• That’s 5-10 minutes separating life and death, sometimes.

As they understood their users better in the emergency context, they simplified the training to focus on what matters most, to match the needs and abilities of their population.

Aside: If you start compressions on someone who actually is breathing, you probably won’t hurt them in the first few compressions before they respond. The risk of minor injury is worth it to expedite the life-saving call and care protocols – according to my recent training.

Cool story but how does this relate to UX?

My key takeaway is that you can know your users and their goals, but if you don’t understand their various contexts for using your system, you cannot design a great experience.

Fixing the problem starts with a simple understanding: The same person using the same functionality can have vastly different priorities and needs depending on the context.

Emotion Reveals Context

I respect that the Red Cross has the courage to train skills that feel overly simplified in the classroom context, because experience shows the training is appropriately simplified for applying it in a real emergency context.

That’s not an easy thing to do, and it took them decades of iterating and adapting. It makes me wonder if we, as an industry, are still missing a framework for discussing and capturing this.

There are tools like scenarios or Jobs-to-be-Done that can help, but in my experience, they’re typically leveraged in a cold, emotionless way – the output reads as if robots will be performing the tasks.

At least for how I’ve encountered them, they neglect the fact that understanding the user’s emotions – when somebody feels strongly about a system – is equally important in understanding the contexts they inhabit.

A surprising pattern I’ve noticed about contexts is that, often, people aren’t even aware of them. People just don’t frame their experience in terms of context.

So if you ask someone about the various scenarios and contexts in which they use a system or solve a problem, they probably won’t have much to say. If you ask them about how a system makes them feel, they can talk for hours.

Towards Understanding Context

When capturing requirements, I first focus on the what: what tasks must be performed, what outcomes are desired, etc.

Then I like to step back, look at the bigger picture, and try to understand the why: why do these outcomes matter to the business, why are these tasks and this system the best way to achieve those outcomes, etc.

This is a fairly typical approach for seasoned designers and engineers. I think what I’m proposing is adding a third facet that focuses on emotions.

For example, during stakeholder interviews, what if I asked questions like these:

• Do you ever feel angry at the current system?
• Does it ever make you feel unsafe?
• Do you ever wish it would just get out of your way and let you do your job? What’s happening then?
• Is there any feature that you love?
• Does it ever make you happy?

Honestly, I’m not sure I’d feel comfortable asking those touchy-feely questions to Serious Business People™. Maybe I should ask them anyway.

How Do You Feel About This?

As engineers, designers, and product managers, it is critical that we understand the many contexts of our systems. It is critical that we test in those contexts. It is critical that we design for the fullness of reality, in all of its slippery chaos.

But I don’t have all the answers here. I don’t know how to perfectly balance the need to understand contexts with all of the real-world constraints in designing a system.

Whenever I’m stuck on a design problem, empathy provides a path forward.

Do you feel context is missing in traditional UX requirements?

Do you feel comfortable asking questions about emotions?

Do you have other tools you use to address this?