It’s Time We Seriously Talk About Users and Experiences

For some reason, UX people never speak about users or experiences. And that hurts our work.

“But I talk about my users all the time.”

Sure, we often say things like “Our users deserve the best user experiences,” but that’s not what I think is missing.

What’s missing is that we never discuss specific users and their detailed experiences. What are the users’ names? What happened in their lives that our product or service could’ve improved? That’s the specificity I’m talking about here.

Can every UX team member name one of your users?

Last week, I spoke with a UX team manager whose company makes software for teachers. It’s incredible software that they think could substantially improve teachers’ work. 

Yet the team manager couldn’t name a single teacher who could use this software. The team’s research efforts were lagging, and they met very few teachers. The manager didn’t know the name of a single teacher they’d met.

Instead, they relied on subject-matter experts (SMEs) who aren’t teachers today but were once teachers, worked as administrators in a past life, or had once studied education theory. They weren’t teachers today, with the challenges that teachers face daily, but they claimed they knew what those challenges were. 

These SMEs are indeed intelligent, capable people, but they aren’t the teachers who would use this product daily. Maybe they know what teachers need. But what if they don’t? What if they’re guessing because they don’t know everything that goes on in the lives of teachers today?

We say we practice user-centered design. Yet, all too often, we can’t name a single user.

Can every UX team member describe the differences between users?

Not all teachers are the same, even in the same school. Not all doctors are the same, even in the same practice. Not all insurance claims adjusters are the same, even in the same claims department.

However, we often talk about users as if there aren’t meaningful variations between people with the same role. I blame our oversimplified approach to personas, where the temptation is to create a single persona for a classroom product called “teachers” and another one called “students.”

Yet, some teachers may find our product easy to integrate into their current classroom practice, and others may struggle to make their practice work with our product. The difference may be in the years they have been teaching or their understanding of technology, whether their students are fluent in English, or whether the software can be easily tuned to meet their needs.

Without identifying and cataloging users’ differences, designing for the full range of variations will be challenging. If your UX team can’t describe how one user might be different from another, there’s a good chance they are designing for nobody.

Can every UX team member describe a user’s actual experience?

What is a teacher’s day like? Not a generic teacher — an actual teacher.

Let’s say we’ve met a teacher named Edna. Edna is a middle school special education teacher in Knoxville, TN. 

What did a recent day for Edna look like, from the moment she started thinking about work until she stopped? Was it, in her opinion, a good or bad day? What made it good or bad?

I rarely encounter a UX professional who can answer questions about a specific user’s experience. Most people in our line of work seldom get detailed exposure to their users’ everyday experiences.

They are also not exposed to their users’ extreme experiences. What was Edna’s worst day this year? What made it so challenging for her? What was her best day so far, and why?

How can we improve each user’s day without knowing what makes certain days challenging for them? How can we ensure our product doesn’t worsen the users’ best days without knowing what makes them great?

UX professionals should know their users’ experiences inside and out. Yet, I’ve found few ever do.

Can your product and development team members name and describe a user who will benefit from their work?

As you read this, developers are writing code, and product managers are doing whatever PMs do. Everyone is working hard to deliver new capabilities for your next release.

However, can any of those people name one of the users who will benefit from those new capabilities? Can they describe how different users might benefit from the product in their own distinct way?

Can the developers and PMs describe how their new functionality will improve each user’s worst days and how they’ll ensure the product doesn’t make things harder for any users? If the people we work with don’t know anything about the users they’re developing for, there’s a good chance that the new capabilities they’re producing won’t work for anyone.

Do product requirements come from real-world experiences of real customers and users?

If your stakeholders and product leaders can’t name a single user or describe a genuine experience that user had, where do the product requirements come from? How can we craft accurate user stories when we don’t know the first thing about our users?

More importantly, how likely will our customers be thrilled with a product we didn’t design for their needs? How valuable will they find what we deliver if we don’t consider their particular needs? And how can we do that if we can’t even name one customer who would benefit from our product or service?

It’s time we start talking about our users and their experiences.

UX should be all about our users and their experiences — it’s right there in the name.

When we can’t name a user or describe their experience, we slow everything down. Each UX team member, developer, product manager, and stakeholder thinks the user needs something different. 

We end up arguing and debating what our users need or even who our users are. All that debate slows projects down. In addition, when the team guesses what the users and customers need wrong, it results in lackluster sales and missed business goals.

Let’s start talking about who our users genuinely are in detail. Let’s ensure everyone in our organization knows what makes each user unique. Let’s make our entire organization **the world’s foremost experts** on our users and their experiences.

Talking about our users and their experiences is our most valuable contribution to our organization.