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?

[Fwipp]

Something something Henry Ford, something something faster horse

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:No shit?

[mcmonkey]

It really depends. Talking to people is often better. In large user bases that are isolated, this is hard; but when you're doing i.e. department-to-department, you're far better off asking. If you're writing software systems for Accounting and Finance, for example, there's 200 people working there. You want to interface with the Accounting Manager and Finance Manager--who will be doing, in part, exactly what's proscribed here--while also communicating with some of the actual people in these departments. This will get you a much better understanding of requirements than just "Well I don't know a fucking thing about finance, but I watch the finance people bang their heads on this shit a lot so we should do it this way instead! It would be better!"

What happens often with that scenario is by talking to the people in Finance, the developer ends up thinking he or she has learned something about finance, and can write up requirements which read well and will be accepted by the users, but actually has very little understanding of what the users need and will produce awful software.

There are a few reasons for this. First, every area of expertise has its jargon. Often jargon is an ordinary word with a different, specific meaning in a certain context. So better to follow someone through their work flow and know you're getting lost or not understanding some steps than to have a description you think you understand.

Second, something obvious to anyone who has even a 101 intro level of understanding in a field may be completely unexpected to someone outside of that field. When talking to the folks in Finance, there is some basic assumption so elementary they never mention because everyone in finance covered it in day one, but is completely unknown to the developer with no finance background. Talking will almost never solve this issue. They won't think to mention it; the developer won't know what question to ask.

Third, we relegate tasks to "muscle memory." When describing oft-performed tasks, people invariable miss steps. There are little things that, while vital to successful completion of the process, we forget just because we've done them so many times, they happen without conscious thought. You won't know where these are until you try to replicate results from a procedure someone has described, or if you observe that someone doing the procedure.

So for someone who doesn't know a fucking thing about finance who is developing a system to be used for finance, there's so much more to be gained by watching the finance people bang their heads than just talk to the finance people. As for the Finance Manager, talking to this person should be strictly reserved to some or all of 1) budget of the project, 2) timeline of the project, 3) availability of the finance people for requirements gathering.

Not really new...

[Longjmp]

Don't program what they say, but what they mean.

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.

Re:Medical

[carlcmc]

No, I disagree. As someone who has some background in computers/it/programming (programming in C and fortran for fun in college as elective classes) as well as being Physician Assistant taking care of patients, I think you are totally off track.

Your customer is your customer - the users and purchases of your software. That would be like saying that you develop POS software and the customers in the hardware store are your customers ... . You thinking you know better than the medical professional as to how the program should work for me is the same as me telling you what development language or database backend you should use.

Listen to your customers ... highly educated physicians, physician assistants, nurse practioners who are highly analytic when they tell you there are good reasons to do things certain ways.

You act like easy to use and safe for patients are contradictions ...

I contend that I have used applications that were safe for patients that were easy to use and not easy to use and vice versa.

Re: Difficult != Safe

[HeadlessNotAHorseman]

Everybody seems to be confusing the term "customer" with "stakeholder". The fact that a person may not understand what they really need when asking for an info system should be no surprise to anyone in the IT industry by now. It's the whole reason for the existence of business analysts like me. Being a good programmer does not by any means guarantee that you are good at gathering and understanding requirements. Being a good BA certainly doesn't make me any sort of programmer (though I do understand the concepts).