Stop Listening and Start Watching If You Want To Understand User Needs 161
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."
No question about it, you must watch and learn. (Score:5, Interesting)
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.
Medical (Score:2, Interesting)
My wife is a nurse practitioner. Anyway, she is constantly complaining about how the software's UI doesn't make any medical sense - like things she needs the most are a few screens deep and the things that she rarely needs are right on top.
Or when entering vital statistics the individual's height has to be entered every time - at least have it default to the last entry because even if you're doing pediatrics, the height may not have changed since the last visit.
MS did the first cloud service before dropboxq (Score:4, Interesting)
i was an alpha tester back around 2008
there was no cloud storage, but you could sync files between your computers running the client. i left my home PC on and sent files while on vacation 1600 miles away. Everyone testing it said how awesome it was on MS Connect. Of course MS didn't do anything with it and dropbox was born
..and the penny drops (Score:4, Interesting)
False premise - usually devs DONT want to (Score:2, Interesting)
Most of the time developers want to ship the product by the due date, and usually decide that they're smarter/cooler than the users anyway. "You'll take Feature X and suck it, luser." is the motto.
Re:Medical (Score:3, Interesting)
there's a reason for the height entry being new each and every time as a change in height either direction can indicate certain problems - a good example is a sudden gainning of 2 inches (5cm) in a very short time frame could indicate a glandular problem. Same with sudden loss of height could be an indication of spinal issues. Simply put, the fields are derived from what is a common Vital Stats Sheet (hard copy) and are god damn standardized by the Medical Profession.
On the UI screen issue, yes that should be addressed - This is where devs really do need to watch how a user works because what "You" think makes sense does not from their work flow perspective and it can make/break the use of your app.
Re:Medical (Score:4, Interesting)
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.
Asinine Quote (Score:4, Interesting)
Mobile app observation. (Score:5, Interesting)
As I watched several users go through a few of my apps, an interesting behavior became apparent.
Many people as soon as they see a new screen on a mobile app instinctively flick up or down attempting to scroll. If the page doesn't bounce or in any way give them visual feedback they think that it's frozen and start to tap around looking for a response.
After that, I started making every single screen in my apps scrollable, even if it just bounces content smaller than the screen. That tiny little change makes users feel like the app is faster and more stable.
And you don't need a one-way mirror... (Score:5, Interesting)
At one now-defunct Fortune 500 company I worked for, they were sort of reluctant to apply any informal techniques like watching users try to use software (without instructions or coaching), because they had a nascent Human Factors group that wanted to build a facility with one-way mirrors and video cameras, and they kept telling everyone that you needed to have a facility like that in order to learn anything.
On numerous occasions at numerous companies I've simply corralled someone, anyone, who had not yet used the software, and asked them to try to accomplish basic tasks with it. "Please forgive me for not helping, I just want to see how far you can get without help. I'll help you if you really get stuck." And then I've watched them as they tried to use my software.
I always learned a lot from this, and I learned it very quickly, and a lot of what I learned was really trivially easy to implement. You can so easily miss the blindingly obvious when you are familiar with the software yourself.
The worst advice--well, maybe not the worst, but bad advice--tended to come from people giving advice that they imagined was on someone else's behalf. You really do NOT know what things people are going to find easy or difficult until you actually watch them try.