Product and Tech
About the author: Emelie Markström is a Product Designer in the Money Team.
We have a segment called UX something during our department-wide Product meetings where a lucky product designer gets the chance to convert more colleagues into UX geeks. I’ve had the pleasure of hosting a couple of them, and was asked to share some tips on how I successfully manipulate my colleagues into thinking UX stuff and Design Thinking is pretty neat (I mean, because it is!).
I think a great starting point is learning how to empathize with our users, because it’s hard to dismiss someone you care about. In this blog post I’ll share three things I do when I have the whole department’s undivided attention, and the results I’ve seen.
An oldie but goodie. You can’t go wrong by smacking a user quote or two into your pitch or presentation. If you’re lucky, you have a survey or interview to grab quotes from. If not, scavenging through support cases, NPS comments or feature requests and using the users’ own colorful language to describe their pain points also does the job.
But before you copy and paste those gems onto some neato slides, consider trying out the next two examples first.
As a product designer, I am well aware that people often assume that their users feel and act the same way they do. It’s one of the biggest hurdles to overcome if you’re trying to deliver user-centered design.
With that disclaimer out of the way, let’s totally disregard it for a moment.
If you complain about someone’s work they might become defensive. Just because many of us product designers are always on the lookout for users that will tell us how we could be better, it doesn’t mean it’s a pleasant experience for everyone.
So before you dump a bunch of pain points in the lap of your team or department, try to make a case for them by making it more relatable. How would they feel in these situations?
Recently, I was involved in looking into why our users request refunds. The findings were relevant to the whole Product department since it’s valuable to all of our work. I wanted my colleagues to be able to relate to our users and used an interactive presentation tool to do so. Surprise, surprise! I used Mentimeter!
During my presentation I asked them to rate how much they agree with each of these statements:
I also asked them how they would feel if they tried Mentimeter out, stopped using it after a month, and were surprised when it was renewed a year later.
They could answer these questions anonymously on their own phones. When enough people had answered, I presented the results live.
The results of the Scales question showed a mix of statements we were aligned and split on.
The results of the Multiple Choice question showed a wide range of emotions across the department.
This was a great foundation for me to build upon. It showed that we were very aligned on some things, but not on everything. It showed me where I might meet resistance, and showed my colleagues that their own perspective might not be universal.
On another occasion, I was looking into the navigation and information architecture of our settings pages (riveting work, indeed). I suspected that there were a few central user cases that had a hard time navigating through our structure.
I could’ve reached out to users or user testers and tested my hypothesis, but I figured I could kill two birds with one stone if I arranged for my unsuspecting colleagues to take part in a user test instead:
So, during my presentation, I asked the audience to imagine they are a paying Mentimeter customer, wondering when and how much they will be charged next time. I showed them a blurry screenshot of what our users see when they log into Mentimeter, and asked them to tell me what their first step would be.
To the left, a screenshot of what the participants saw on their phones. To the right, the result of where everyone clicked showing up live on my presentation slide, using the Pin on Image question type.
Why was it blurry? I didn’t want them to be too influenced by wording. I was more curious about how they would intuitively navigate to that kind of information.
The result was pretty much unanimous. Almost everyone went for the pink circle at the top right corner - what we might call the user’s “avatar”. That didn’t surprise me, since it’s an industry standard to hide a settings menu there. But I was very curious what navigation they were expecting to find there.
Instead of influencing them by showing them the settings menu, I gave them a blank action menu and asked them to type out what they expected to click.
To the left, what the participants saw on their devices. To the right, a Word Cloud that was generated from all of their responses and showed up in my presentation when the answers had been submitted.
When I had that info in the bag, I was ready to show them the pages they could choose. I asked them where they would go to find out when and how much they’ll be charged next time. When I had gathered enough results, I displayed them directly on the slide I was presenting.
To the left, what the participants saw on their devices. To the right, the results presented live in my presentation, using the Pin on Image question type.
This was the moment when the token fell down (as we say in Sweden), and the participants realized we had a problem. Like a rock in a stream, our navigation is splitting us up into two flows. Half of us will end up on the wrong page and need to track back, which is never a pleasant experience. Struggling to find answers to easy questions about when we’re planning on grabbing their money? Infuriating.
Wait, didn’t we already cover this? Yeah, well, it’s time I practice what I preach and show you the results I promised in the clickbaity subtitle.
“I was very impressed by the product talks about UX you’ve done, particularly the one with regards to naming and payments. Very well explained and humble.”
“Your thorough approach to investigate user behaviour makes an excellent basis for improvements, like the superb Menti-meeting “billing” test."
The best part of running a segment like this is the feedback you get afterward from product peeps that usually spend their days digging deep into our backend and don’t often get an insight into the work us product designers do. So if you want to create cross-functional empathy in your product department, give these tips a try.