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.

No question about it, you must watch and learn.

[udachny]

When designing systems for my clients I first listen to what they are trying to convey but then I always take a trip to their locations, departments, stores, whatever it is and I just ask to be allowed to be there, to see what they are doing. Some operations are quite intricate, so I have to sit in with a user and have him/her guide me through the processes, sometimes it's enough just to observe what the operations are like to understand problems.

For example when I started building my retail chain management systems, my background in telecom / banking / insurance / manufacturing / utilities did NOT prepare me for what I observed in retail, in fact it was counter-intuitive and seemed wrong on its face. When an execute order comes to a bank, everything is done in the proper sequence, the transactionality is ensured, etc. In retail that's not the case at all. An order arrives to a store, the boxes can be checked for the products quickly and then pushed to the floor, where the items are placed on the shelves immediately and then they can be sold right away.... but the order may not be in the system yet, so this means the products are NOT in the electronic system and they can already be sold.

This means you have to be able to handle negative amounts of products, as an example, all the way from the cash registers to the accounting systems and your systems have to be able to deal with all of these weird situations, weird from POV of somebody who is used to strict transactionality in terms of processes.

Yes, you have to observe people working IRL or you'll have a bunch of preconceived notions that may be totally wrong and your systems won't handle them at all.

Re:Captain Obvious?

[plopez]

No. SOP is to hire sales droids who sell something to the customer, vaguely define what the customer says, hand off to requirements gathers who work off of emails and conference calls, architects who have no experience in the industry the user is in who then hand off to the designers who decide the legacy system is an old musty systems and that they need to shiney new tools sets which have just reached the beta release. Then managers hire the best low bid contrators money can buy who a looking to be no more than "butts to bill". And finally QA is bolted on at the end, just as an after thought.

Hope this helps. Have a nice day.

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.

I've got an anecdote

[wjcofkc]

A few years I was with a company where several hundred users had to use the same database application. It was fairly large, with lots of features and was the golden company standard. The problem was that it was a buggy, crash prone POS that made everyday a nightmare of restarting software in the middle of something important - worst case a full system reboot. It made everyone's lives miserable. The complaints were universal across all users, we were always complaining to management who themselves knew it was crap software. From management our grievances would go to the mysterious developers that no one ever actually saw. They would review our complaints and roll out useless software updates that would sometimes disable important features, or at best make the situation worse. They simply didn't get it because they were so disconnected and segregated from the end users. This went on for years - people quit their jobs over this. One day, without much warning or any explanation as to what it was about, I was called into a focus group with what appeared to be a random sampling of end users. Holy smokes! The mysterious shadowy developers were right there in the room! We spent a couple hours talking with them one-on-one about the issues and the order of priority for what needed fixed. At the end of the meeting, it was agreed that the developers would spend the next week sitting with us at our desks, watching us use the software. They would spend a couple hours with someone at one desk, making notes, observations, actually seeing our problems and the business impact they were having, asking questions, and then select another random person.

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

Re:Asinine Quote

[Anonymous Coward]

Henry Ford lost over 50% of his market share by refusing to listen to his customers, his employees, and his family. Everyone told him that customers wanted different color cars. Ford said any color you want, as long as it's black. And GM ate his lunch.

Not entirely accurate. Ford had made cars in different colors, but when he put his focus on the Model T, an automobile inexpensive enough for working people to buy, the paint drying time slowed down the assembly and shipping process. There was only one paint that would dry fast enough to keep the production going, and that was Japan Black. They had to wait for faster-drying paints to arrive before they could mass-produce cheap cars in different colors.

If Ford had produced Model T's in other colors, they would have been more expensive and therefore fewer people would buy them. It was a business necessity, not arrogance on Ford's part.