Stop Listening and Start Watching If You Want To Understand User Needs

rsmiller510 writes "It would seem on its face that simply asking your users what they need in an app would be the easiest way to build one, but it turns out it's not quite that simple. People often don't know what they want or need or they can't articulate it in a way that's useful to you. They may say I want Google or Dropbox for the enterprise, but they don't get that developers can be so much more creative than that. And the best way to understand those users' needs is to watch what they do, then use your own skills to build apps to make their working lives better or easier."

Comments

No shit?

[grasshoppa]

Sorry, but to anyone who's worked with users in any serious capacity for any length of time, this is kind of obvious. And when I say "Kind Of", I mean "blindingly".

The best way to make the tools that help your users is to understand their job. Get in there and do it yourself. Only then will you have the knowledge you need to create the tools that will really save them time.

Re:No shit?

[bob_super]

And the worst way is to ask their boss how he thinks they're doing their job. And present the material only to him because "this is not something for the engineers to be deciding".

Did I mention I want to punch my head of marketing?

Re:No shit?

[bluefoxlucid]

Every good management text explains the value of retention. Even hardly-relevant stuff in Kepner-Tregoe's problem solving techniques covers this: solving human resource problems is a good thing because replacing human resources means you made a mistake when hiring someone--a fucking expensive mistake. Now you have to eat the costs of months of settling in, plus general bad productivity, plus the cost of the hiring process (expended human time), plus salary and benefits paid to a worthless employee. Sometimes the mistake is less bad: you can modify their job function and gain something valuable while retaining their organizational experience (which is pretty significant); and sometimes the mistake is elsewhere: something besides "this employee sucks" is affecting their productivity, and correcting that is far less expensive and more valuable than throwing them out and replacing them with someone else who is more tolerant of the problem.

As for promotion from within, that's a tough one. Peter's Principle says people get promoted on merit and achievement, and cease being promoted once they've reached a level where merit and achievement no longer occur--because they can't function in their newest job. Now you have engineers who think they're smarter than their managers who become managers and still behave like engineers who think they're smarter than their managers... and their engineers. Then they micro-manage like hell and piss off all the engineers, who then work to get promoted up to management because they think they're so much smarter than their managers.

Re:Medical

[Nadaka]

Medical software is a medical device and subject to regulation as such. I am in the business of writing that software, and while I as a developer can and would be happy to make things easy and awesome, risk management often determines that "easy" can also be "dangerous". Make the default route too easy and you risk a user accidentally skipping the correct route.