menu

Adventures in Product Design

The work of Bob Ricca

close

Stop Being Clever – A UX Case Study

Case Study UX

Recently I subscribed to a Slack group called “Today’s Question”.

Every morning in this group, a new question is posted for Product Managers and UX Designers from all over the world to answer.

The questions are open ended and all over the map:

  • Beyond the theory, how have you taught “story” splitting in a way that stuck?
  • How has your team’s use of Slack changed communication patterns?
  • Have you tried informal peer mentorship programs? What worked? What didn’t?
  • How do you make sure your company is prepared for the upcoming release? Communication? Meetings? Rituals? Process?
  • Etc…

These types of topics resonate with me. I love trying to figure out how I’d attempt to answer each one and reading over others responses. It’s inspired me to reach out to others, read more, and write about my own experiences – including this article 🙂

• • •

Just before the holidays, the following question came up:

“How have you sold skeptical team members on the value of usability testing?”

This topic was actually fresh on my mind from earlier that week.

You see.. My brother-in-law is currently building a team for an independent UX research agency (Skopos Nova) based out of Cologne, Germany.

From his experience, teams in Germany aren’t as bought in on the concept of “UX” as American companies. After most external presentations he gives, he is often approached with a question like the one above.

So, how did people answer it?

Most had the standard response:

“Show, Don’t Tell”.

It’s not wrong, but you know… it’s a UX canned response straight from the UX 101 textbook. …zzzzzzz…

Others answered:

“Show the team some clever observations, something they never realized and would have never encountered without usability testing”.

Ok. I guess that could work too.

• • •

My Answer:

Be the opposite of clever… show the obvious.

• • •

Allow me to explain with a story:

Imagine you work with an engineering team.

Both you and the team are very close to the product. You both know where the bugs lie.

The team has outlined each bug in a ticket. Time after time again, the bugs are de-prioritized in favor of a new feature or deadline to meet.

Now image that there are also multiple stakeholders that influence the product roadmap. These stakeholders are not as intimate with the product as the team who has built it.

Then enters a UX designer.

Instead of attempting to highlight clever insights, he or she does a listening tour throughout the company to gather a list of common customer pain points.

Chances are, after talking with multiple departments, patterns will emerge. Probably for good reason.

The UX designer seeks to validate the top pain points and in the process records videos of customers struggling with each one.

These video are then presented later as part of a presentation to the company.

A few things happen:

  • Product managers and other stakeholders now attach a painful customer experience with a bug that the team has been wanting to fix. They had no idea the problem was so bad and decide “maybe we should fix this”.
  • The engineering team is glowing. They finally get to fix bugs that have been weighing on them for quite some time. When asked about UX the answer is: “I love UX. We should usability test everything!”.
  • The positive attitudes of the engineering team is noticed by upper management who thinks “Wow, these guys are really fired up. This is great! Maybe we should do this more regularly.”
  • Other teams take notice and start asking “What is the plan to start testing our project?”

What about the skeptics?

They need to make a choice:

  • Go against the grain
  • Go along for the ride

I’ve personally seen this happen a number of times. The momentum and positive impact of user testing for a team is truly eye opening and exciting.