Slashdot Mirror
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."
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Don't program what they say, but what they mean.
There are fewer illiterates than people who can't read.
IANAD (I Am Not A Developer) but isn't this Standard Operating Procedure in most software development these days?
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.
MY OTHER COMMENTS
This isn't a problem of "eating your own dogfood" . . . Its not enough to use your own product. (I think) the point of the article, is that you should observe UNexperienced users and how THEY utilize (or have difficulty utilizing) the product.
I encountered the same thing this weekend using a popular "drawing" type product . . . watching the videos on the Company site, or on Youtube, made it seem easy. When I tried it for myself . . . I couldn't draw lines in an color but BLACK for TWO HOURS. The "experienced" users . . . unwittingly skipped over many basics a newbie user . . . just doesn't know.
It should almost be a "interrogation room" "through the glass" observation. So the developer can't "train" and can only see the suffering the new user experiences while trying to "find" the features they need.
For the tool I was using . . . its ultra powerful (once you know it) but . . . even the simplest features are maddeningly difficult to initially find. Easy and Powerful once found, but tortuously difficult to find.
That's the kind of "observation" I believe the article spoke of.
No, I don't remember your name. But the memory mapped screen on a TRS80 from 1977 is from 15360 to 16383 if that helps.
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.
"I opened my eyes, and everything went dark again"
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.
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
Apple tells me what I need, thats the perfect scenario right?
When I did my Degree in HCI 20 years ago, this was the touted as the way to get the best results when building usable, user-centric systems. Sadly in the two decades since, I don't think I've ever come across a system - hardware, software, app, or anything else for that matter, that actually develops this way. Which is a shame because if they had, my elderly mother could have probably been able to use a PC by now, intead of "What you mean I have to move that little arrow thing All the way over there and press what?"
There is no substitute for side-by-side. Which is really hard to do if your user is in Denmark, your designers in California, and the development team is in India. Which is why Agile works not for distributed development.
putting the 'B' in LGBTQ+
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.
You can hold down the "B" button for continuous firing.
Any decent HCI text will tell you the same thing. This has been known for a few decades now.
FTFY
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.
Brought to you by Carl's Junior.
You also need to pay attention to the stuff you see them doing that seemingly does not involve your system.
You will occasionally hear or see they do something in passing, maybe as simple as entering a name and address not only in your system, but also in some other parallel system such as a "rolodex" or simple spread sheet, and when you ask why, you find out that your system never made a provision for printing mailing labels, or the information they need for some obscure report takes way too long to find using your system.
Often you can accommodate these functions with a few lines of code, greatly improving acceptance of the system. (Someone is sure to jump up and scream "Feature Creep", but extensive or expensive additions aren't what is being mentioned here).
Also, don't forget to look into their Closet of Anxieties, those things they only mention while grumbling about their lot in life.
Sig Battery depleted. Reverting to safe mode.
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. Be condescending to your users at your own risk. Shoot, GNOME seems to pride itself on doing the opposite of what users want and that is working out so well for them.
My customer is the patient and the FDA.
In all likelihood neither of those is your customer. Your customer is the person tasked with actually using the device, most likely a nurse or doctor, and the organization that pays you for it. The FDA is certainly not your customer. The FDA's job is to ensure you aren't selling snake oil. They do not buy or use your equipment. They are a regulator not a customer. Just because you have to please them doesn't make them your customer.
If making it easier for the nurse compromises the safety of the patient, its BAD software.
Of course but making it needlessly difficult for the nurse also compromises the safety of the patient AND it hurts operational efficiency which is both a treatment risk and an economic cost. Safety first obviously but don't try to excuse bad design as a safety measure when it isn't.
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.
Cwm, fjord-bank glyphs vext quiz
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.
"How to Do Nothing," kids activities, back in print!