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

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.

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.