If you’re building a new business application, the obvious temptation is to ask the prospective end users what they need it to do and how they want it to work. But that approach, no matter how well-meaning, is built on a very shaky premise: that those users have any idea what they actually require.
User picture from Shutterstock
Gartner analyst Bard Papegaaij pointed out the problem with this approach during the opening keynote at Gartner Symposium/ITxpo this morning:
Don’t ask people for requirements. Everybody amongst your colleagues has trouble formulating those, let alone consumers.
The solution to that dilemma? “Don’t ask what they want, observe what they do,” Papegaaij suggested. As well as providing evidence of their actual behaviour, you’re likely to get more data that way, since you’re not relying on someone else filling out a form.
Throughout this week, Lifehacker is covering Gartner Symposium/ITxpo 2014 live from the Gold Coast, bringing you practical tips and advice for running business IT more effectively.
Check out all our stories from the event.
Comments
10 responses to “Why Collecting User Requirements Is Often A Waste Of Time”
Title is sort of misleading. You’re still ‘collecting’ user requirements if it’s through observation, just that you’re not soliciting them directly via a stale survey or similar.
Maybe a small sounding distinction, but it makes a huge difference in terms of meaning. Was this intentionally misleading so that people would click the article expecting to see someone advocating skipping the process entirely?
My own experience is the way to get attention on the symposium circuit is to have a title that is controversial, even if the actual message is not. There’s nothing revolutionary here if you’ve been involved in elicitation in any capacity.
OMG, you are not accusing Lifehacker of engaging in click bait I hope.
Next you’ll be suggesting an unhealthy appetite for KFC. Outrageous.
To paraphrase using academic jargon: ethnography yields richer information than survey.
Of course, Henry Ford already knew it. He said,
I wrote about this! The short is “what are you trying to do” or “what is the core condition of satisfaction”.
To do it in IT Support terms, what is wrong? my printer doesnt work. Nope that’s a possible solution or a user diagnosis not what their problem is. Their problem is they want a hard copy of something and cannot get it…. you can keep tracing back until you get to the root outcome. That is what you should be getting, not requirements or specifications.
Also – https://medium.com/@EvilSpyBoy/so-you-want-to-build-an-app-part-1-5e6e866aab20 (I wrote a little about this approach in terms of startups & mobile apps more specifically)
To be fair, the end users tend to have a better idea of their requirements, than their managers who document the requirements without their input.
Tell me about it! I’m on a project right now and 4 months before go live I’m getting told by the users that the process maps are wrong.
Users have no idea what they want, and their “opinions” are largely worthless. There are only business requirements, never user requirements.
Are all users the same, though? And do they remain the same during the product lifecycle? Yes, most users cannot envisage a new paradigm.
To some extent the software developer could drive user satisfaction (not ‘requirements’) because users will often give the rear-vision view of requirements; that is: ‘this is how I’d prefer the things I did in the past to work’, whereas I’d expect a developer to go places I’d have no idea a software system could go.