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?

[Areyoukiddingme]

Or to put it another way:

Domain knowledge is everything.

Which is why hiring in house and working hard at retention is tremendously valuable. Too bad no MBA-driven organization is capable of understanding that. Software a cost center? Ha. Software is the lifeblood of a modern organization. It is the thing on which ALL business processes run, from hiring to benefits to production (if any) to sales and customer service and everything in between. There's a lost generation in management who do not understand this and will never understand this. Some day the madness of outsourcing your mission critical systems to a third party who doesn't care if you live or die will be understood for the rank insanity that it is.

I keep telling myself that... I may not live long enough to see the day.

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?

[Runaway1956]

It's even worse than that. No "management" personnel worry about the future of personnel. Or, more accurately, they don't worry about future personnel. Where are the apprenticeship programs of ages gone by? Today, no matter what department, you hire some guy off the street, plug him into some narrowly defined job description, and expect him to perform. If he fails to perform, you get rid of him, and find some other guy off the street. There is no training, seniority means nothing, and no one is advanced from the labor pool. Geez, Louise - in ten years, or fifteen or twenty years, when us older folk have died off, what is the new generation going to do? Where are managers going to find people to do the necessary jobs? There are literally MILLIONS of kids sitting on their asses today, WISHING they could get a decent job, or an apprenticeship.

Domain knowledge? The kids who are being held back today might be qualified to design a new deep fat fryer for McDonalds.

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.

Not sure stop listening is right

[TheCarp]

I think its more about understanding needs. Don't stop at listening may be better. Listen to what they say "I want drop box" and think what does that mean?. Does it mean "I want some third party to make everything work"..... no it means they want a way to make working with files so seamless that it seems like they have a single global filesystem...without having to think about it.

I want drop box everywhere too. I don't want drop box at all because I don't want some unknown third party who does who knows what and I don't want to run somebodies proprietary code and service for anything that I rely on working...but the underlying "I don't care about the details" functionality.... absolutely, I want it too.

Slashdot beta

[game kid]

I wonder if the Slashdot admins will be doing either when they pull a YouTube and inevitably (it's always inevitably, for some reason) turn the main site into beta.slashdot.org.

Here's an easy one: "Archieved[sic] Stories" at the bottom. Listen to us, watch us, whatever, but please don't fuck it up, and fix what isn't right.

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

[ColdWetDog]

The person using my software is not my customer. My customer is the patient and the FDA. If making it easier for the nurse compromises the safety of the patient, its BAD software.

While you may think that's the right way to look at things, that attitude is what makes EHR (Electronic Healthcare Record) software just blatantly awful.

You're really quite wrong: Your customers are FDA, the vendor, the insurance companies, CMMS (Center for Medicare and Medcaid Services) and the medical provider using the software. Yep, having all of those 'customers' (stupid concept, BTW) is hard. That's why this stuff costs what it does.

But the attitude that the people using the software aren;t important (your implication) is what makes doctors and nurses really negative about EHRs).

Re:Medical

[malkavian]

When your bad user UI gets in the way of effective clinical care, you'll soon kinda realise that your customers are the ones who pay the bills.
If you get to streamline (correctly and safely) the job of the clinicians, you save hospitals money, and save lives both at the same time.
The patient is the client of the clinicians, not you. Your job is to enhance the clinicians' effectiveness, helping save lives that would otherwise be lost.

Re:I've got an anecdote

[mcmonkey]

A few years I was ... After that week of seeing things first hand, the software was fixed in about a month.

That post should be mod'ed to +6 and stapled to the forehead of every project manager or system owner who thinks developers should be kept away from end users.

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).