CUT TO:
INT. SCREEN SHARING MEETING – DAY
A client shows their consultant the progress they’ve made on a redesign. They want the consultant’s feedback before it’s too late.
CLIENT
Currently the user does A, then B, then C. Now the user will be able to do C, then A, then B. We don’t think we’ve been giving enough attention to C, so we put it earlier.
CONSULTANT
How often is C being used?
CLIENT
It’s by far our most popular feature. That’s why we want more people to use it.
CONSULTANT
What research have you done on how people are using it?
CLIENT
We haven’t really asked anyone about it, we can just see the data.
Consultant hangs her head in shame.
FADE OUT
I’ve acted in this scene too many times. The client makes changes based on instinct and then wants my stamp of approval. This is their idea of doing UX. I mean, they asked my opinion, right?
This kind of client behavior means one thing: I’ve failed.
When I start working with a new client, it’s crucial that I convey to them that now that I’m here, they no longer have to guess. I coach them through my process, help them articulate their goals and principles, and build their capacity for empathy towards their customers and one another. At every step of the way this means asking more questions of themselves and everyone around them, and making decisions based on intel not intuition. In my world, assumptions are evil and the bad habit must be broken.
My client has a feature that is doing really well. They think it could be doing even better. They have three assumptions: (1) everyone can benefit from this feature; (2) those who aren’t using the feature must not be seeing it; and (3) the feature will still be valuable — maybe even more valuable — earlier in the process. None of these assumptions can be validated by quantitative data, which is the only input they have.
Yes it’s possible that moving the feature could increase its use. But a few bad things could happen too: It could end up being irrelevant at that stage in the process. It could be missing for those who are looking for it where they’re used to finding it. It could seem like it’s required or encouraged to use when it’s actually optional.
Could, could, could = uncertainty and risk. Why open yourself up to that kind of failure with a feature that’s already so successful?
I’m not saying ‘if it ain’t broke, don’t fix it’ — in fact, I hate that saying. We should always strive for continuous improvement. But we’re never going to know how to make the right changes if we don’t first know why. Knowing why beats knowing how. In fact, knowing why tells you how. Why guess?
Knowing why requires asking people the right questions and then listening very carefully to their answers. You can’t intuit it from numbers no matter how hard you try.
But let’s be honest, most of the people in this business don’t actually want to talk to people at all. They work in technology so that they can create systems that will talk to people for them. Their technical skills are superior to their interpersonal skills, so they continuously fall back on what they know.
If we’re afraid to ask for help, reluctant to connect with our customers, and unwilling to challenge our intuition, guessing becomes a way of life, and success will always be something that comes to us by chance — not by choice.
Related Posts:
- How “When I…” Reasoning Poisons a Team August 16, 2012 | 9 comments
- How do you choose your clients? October 17, 2012 | 5 comments
- Whit Hour – Week 14 August 23, 2010 | 1 comments
- UIE Virtual Seminar with Tamara Adlin: Ad-Hoc Personas February 22, 2010 | 3 comments
- Whit Hour – Week 4 August 26, 2009 | 5 comments
Pingback: Pleasure and Pain » Why Guess? A Familiar Screenplay « David Hattingh
Pingback: Whitney Hess » Pleasure and Pain » If VCs Understood UX…
Pingback: The importance of understanding ‘why’ « « The Equity KickerThe Equity Kicker