When designing software, what can we learn about user interface requirements? When using Scrum, what can product owners, and development teams, learn from users? Some organizations still rely on asking people what changes they'd like to see in their software or service. Does asking really work?
It's not what people say, it’s what they do
Gerry McGovern writes in It's not what people say, it's what they do that The worst way to design a website is to get five smart people in a room drinking lattes and posting post-it notes. […] The next worst way is to get 10 customers in a room drinking lattes and giving their opinions on the new design. That model is really, truly broken.
People Cannot Tell You What They Want
UXMyths posted Myth #21: People Can Tell You What They Want. So, if it is a myth, and people cannot tell you what they want, why do we keep asking them?
From reading Malcolm Gladwell's Blink, I can remember the failed experiments:
- The Iyengar/Fisman study revealed that what the speed-daters say they want and what they were actually attracted to in the moment didn't match when compared.
- The New Coke is one of the most famous research failures. Despite thousands of sip tests and countless efforts to fine-tune the taste based on the customer feedback, the New Coke was a huge disaster. "Gladwell contends that what people say they like in these tests may not reflect what they will actually buy to sit at home and drink over a week or so." See the full story on Wikipedia.
(Image from Wikipedia)
- The now acclaimed Aeron office chair received very low ratings in early tests. Despite the ratings, the company decided to go on with manufacturing. The rest is history: Aeron became one of the most iconic and best selling chairs in the history of office furniture. And the irony: once the chair became famous, people started rating it much favorably.
(Image from Wikipedia)
Lean Startups
Present an idea, and ask about their pain point
? Ask if they would pay X for this product? This is what some teams say they do when they try to "validate" their startup idea.
The problem here is that asking people is not a good approach. They'll say one thing, and do another. It's not that they're lying. It's just that humans are not good at speculating on future use of a product or system. Their answers are neither right nor wrong, they're just unreliable.
Scrum and Product Owners
What can product owners and development teams gain from this insight? What happens during Sprint reviews?
During sprint reviews, it is good that teams show what they've built, and have the product owner use it. That way, it's not just what the product owner says, it's more about what s/he does with it. Better yet, the product owner should find ways to get the product to actual users and see if they actually use it (e.g. download it, or click through it).
Show, Don't Just Tell
People don't know what they want until they see and use it. If you're designing a new system for people to use, have more than one design running, and have people use it. Don't ask them which one they like. Have them use both, and see what they do with it. If they keep using one version over the other, then you have a winner. (web usage analytics? A/B testing anyone?)
If you really really really have to ask, make sure you know what you're asking, and know how to interpret the results.
No comments:
Post a Comment