Earlier this year I had a client who hired me to redesign the first step in their 3-step process. The page was getting loads of customer complaints and the last three iterations on the design hadn’t helped.
As always, I started the project by interviewing key stakeholders: the product manager, the product owner, the head of development, the CTO, the head of customer insights, the head of UX, and a few sales people. Each person gave me their perspective on the problem, re-articulated the goals for the page, and offered a few of their best guess solutions.
It quickly became apparent that there was a lot of contention around one field in particular that had survived all the previous redesigns: a drop-down that acted as a filter for the content displayed in step 2. It had a vague label, contained options that were apples and oranges, not all options related to the label, and for several customer segments there were no options that applied. There seemed to be some enthusiasm from the team around renaming, moving or splitting the field into two to be clearer and more relevant, but for some reason, no changes had been made. I needed to get to the bottom of it.
In my interview with the product owner — who ultimately has the final say on what goes in the product and what stays out — I came to learn that he actually uses the product for one of his extracurricular activities. As I always do, I asked him which elements on the page worked well and should be maintained in my redesign. His response: the notorious drop-down.
I was perplexed. How could the product owner not know how much his team loathed this component? Was he out of touch or did he know something they didn’t?
So I pressed on: “What is the greatest benefit of this drop-down for the user?” I could hardly believe what I heard.
“Well, when I use it for my [extracurricular activity], I select [so and so] from the drop-down and get exactly what I need on the next page.”
“How many other people who [do this extracurricular activity] select [so and so] to find that?”
“Oh I don’t know, but they should.”
Not only did he have no data, quantitative or qualitative, he demonstrated no understanding of the concept of designing for your customers’ needs, not your own. That aside, he was being an impediment to his team who was trying to experiment in order to fix a persistent problem.
It’s something I’ve seen all too often. This is one example, but I can think of several others that have gone down almost exactly the same way.
Being the one person on the team who uses the product as a customer — regardless of your role — gives you the license to act as the proxy for the customer. Any disagreement that arises can be shut down by a “When I…” statement because no one else can respond with a “Oh yeah, well when I…” The team becomes forced to make a choice between believing the person and allowing them to make the decision that benefits himself, or changing the design and removing functionality that they know he uses. Who wants to be stuck in that no-win situation?
There are two lessons here: (1) Listen to yourself closely and recognize when you’re the person who reasons with a “When I…” statement and commit to being more objective; and (2) Don’t allow anyone else on the team be the one person who’s a customer of your product. You need to be a customer of your product, too. Not only to ward off the subjective decision making that is a poison to your process and to your team, but also to help build empathy with your customers while gathering feedback and conducting research. Having been where they’ve been will enable you to better identify with their needs. The better you can understand and express the problems your customers are facing, the more prepared you’ll be to use hard data as a shield against the “When I…” sword.
Related Posts:
- Why Guess? A Familiar Screenplay August 10, 2012 | 10 comments
- Designing the Company, Not the Product August 15, 2012 | 4 comments
- Nationwide Insurance demonstrates user research with NationPam January 18, 2011 | 3 comments
- The Purpose of a Business is to Create a Customer August 13, 2012 | 18 comments
- If Seth Godin were me… May 30, 2012 | 5 comments
I used to work with someone who was color blind, and this person was also the product owner. I always had to add unnecessary design gloss (gradients, shadows, etc.) to pacify this person, even when some of the decisions negatively affected the experience for the entire customer base. It was beyond frustrating. Needless to say, I don’t work there anymore.
To expand, working with someone who is color blind is a a tricky situation because you want to be empathetic to their situation. But in my case is was over the top personal feelings of this one person, rather than the person thinking empathetically like “I want to make this a great experience for other color blind people because I can relate.” Instead it was “Change to whole design to work for me personally.” Never once openly thought about the effect it had for the vast majority of non-color blind people.
Goes to show that understanding the needs of our target audience — whether they need something more than we do, or in this case something less than we do — is always the basis for making good design decisions.
Hi Whitney,
Having been in such a situation before, I was excited to read the conclusion of your post which you had built up to being a solution to “I-based” reasoning. However, your conclusion left much to be desired.
Surely you advocate for more than simply battling an I with an I? Becoming a customer of the product just leads to a battle of the “I”s. It becomes our word vs theirs, and as an outside consultant I’m afraid ours means little when it comes to the final call.
What about bringing in outside evidence from actual users?
What about breaking down barriers to dialogue that exist between the team members which would help the stakeholder see things differently?
I look forward to your response.
Jonathan, I hear you loud and clear, and I think I didn’t drive this home clearly enough at the end. In suggesting that we all become customers of the products we create, I’m not advocating for a battle of the “I”s; what it combats however is one person being able to steamroll the team because they are the only ones with first-hand experience. So it’s a base requirement that everyone be experienced with using the product in their own real-life scenarios.
The last line of my post: “The better you can understand and express the problems your customers are facing, the more prepared you’ll be to use hard data as a shield against the ‘When I…’ sword.”
I didn’t go into depth here because I’ve written about this process so many times before. This is what we really need to be focusing on, and it’s a drum I beat in every client meeting, on every project and in every presentation I’ve given. It’s not about us, it’s about the customer. Plain and simple.
As an infrequent reader of your content, and someone who was directed here from twitter, I did not know that this topic had been discussed in the larger context of your blog.
Thank you for your reply.
Two observations:
1. I don’t think “When I…” is always bad — there are situations in which tru-isms are shared like, “When I see a page of chock full of paragraph blocks, I return to Google” and those are sometimes useful reminders. Of course, in situations like the one you describe, specific personal preferences or needs are prioritized, and that’s a problem.
2, I’ve found this sort of response to be endemic and a potential indicator of a bad client. Once a team allows that rationale to slip in, it seems to be almost overnight that the majority of the team is using it. It becomes a game of Whack-a-mole.
I love this post. This is a much too familiar scenario for me as well! It’s not so much the “When I…” reasoning that drives me mad, it’s the stubborn response to challenges to that reasoning. We have recently had this situation with a stakeholder who also uses the product, and was adverse to placing improvements to it as a priority because, to him, it was perfectly clear and easy to use. Finally, after some much-needed usability testing we discovered that this was far from the truth. Not only were the problems we expected apparent in the testing, we also found a few weak areas that we hadn’t considered. I find that a big part of what I do is to help stubborn stakeholders advance their thinking from “I’m the customer” to “I wonder which problems are out there that we aren’t taking care of.”