Or,
Everything I know about guiding conversations I learned from psychotherapy
Conversations play a critical role throughout user-centered design, from requirements elicitation to usability test debriefing to issue resolution. And when our objective is to be objective — to avoid biasing the information we collect and the responses we receive — it behooves us to pay close attention to how our words affect those with whom we are conversing. Herewith, three words to avoid: why, but and can’t.
Why
Think about the last time you asked someone for something and they asked you why you wanted it. How did you feel?
Although asking “why?” is usually intended to elicit the underlying reasons, it often comes across to the listener as a challenge, implying that something is not quite right about the request or the action. This question often creates defensiveness, which can make it harder for us to obtain the information we want. So here are some alternatives:
For an action taken:
“What led you to do…?”
“What was your purpose in…?”
“How did you come to…?”
For a design feature requested:
“What objective are you trying to reach?”
“What would it help you do?”
“How did that idea come to you?”
But
Think about a time when you’ve asked for something and your listener has started his or her response with “but…”. Doesn’t that diminish the value of your request just a little?
“But” (as does “however”) creates a false or exaggerated contradiction or dichotomy. It discounts the importance of what came before. Here are some alternatives to consider:
“and”
“still”
“yet” (maybe!)
The only alternative that I really like, though, is “and”.
Can’t
Think back again to a time you asked for something that was important to you and your listener started with “We can’t do that.”
“Can’t” gives the impression that the client/user has made a wrong request. It gives the discussion a negative tone, even adversarial. Here are some alternatives:
“That’s an interesting idea. Tell me more.”
“Here’s what we can do…”
Others
Have you noticed any other words or expressions that tend to produce resistance when someone uses them in talking with you? What problems do you think they might create in an interview? What might be some alternatives?
And how come I am writing about this?
Well, you know, they say we teach what we most need to learn…
And I find that I need to keep reminding myself of it, every time I work with a client or a development team.
Don’t ask why
Or,
Everything I know about guiding conversations I learned from psychotherapy
Conversations play a critical role throughout user-centered design, from requirements elicitation to usability test debriefing to issue resolution. And when our objective is to be objective — to avoid biasing the information we collect and the responses we receive — it behooves us to pay close attention to how our words affect those with whom we are conversing. Herewith, three words to avoid: why, but and can’t.
Why
Think about the last time you asked someone for something and they asked you why you wanted it. How did you feel?
Although asking “why?” is usually intended to elicit the underlying reasons, it often comes across to the listener as a challenge, implying that something is not quite right about the request or the action. This question often creates defensiveness, which can make it harder for us to obtain the information we want. So here are some alternatives:
For an action taken:
For a design feature requested:
But
Think about a time when you’ve asked for something and your listener has started his or her response with “but…”. Doesn’t that diminish the value of your request just a little?
“But” (as does “however”) creates a false or exaggerated contradiction or dichotomy. It discounts the importance of what came before. Here are some alternatives to consider:
The only alternative that I really like, though, is “and”.
Can’t
Think back again to a time you asked for something that was important to you and your listener started with “We can’t do that.”
“Can’t” gives the impression that the client/user has made a wrong request. It gives the discussion a negative tone, even adversarial. Here are some alternatives:
Others
Have you noticed any other words or expressions that tend to produce resistance when someone uses them in talking with you? What problems do you think they might create in an interview? What might be some alternatives?
And how come I am writing about this?
Well, you know, they say we teach what we most need to learn…
And I find that I need to keep reminding myself of it, every time I work with a client or a development team.