All writing

The Importance of UX Research (an Anecdote)

“Can you make sure they add sounds to the next version?”

I’m standing in an aisle of a Wal-Mart in suburban Florida, scrambling to open up my notebook as the rest of my team walks out the door onto the bus. I’m still not entirely sure what’s going on, but the guy in front of me looks frustrated, so I’m pretty sure he’s about to tell me something valuable.

It’s the end of 2015; I’m doing UX work at a small agency, mostly for Fortune 500s who are trying to make their internal tools a little less horrible to use. On this project, I’m traveling around the country with a small team, shadowing merchandisers from a brand-name consumer-goods company as they drive to different stores and stock the shelves with their product. It’s just me, my project manager, and three consultants from a gigantic consulting company.

We’ve just finished shadowing this particular merchandiser and are getting ready to leave for our next stop. I’m the last one out of the aisle, and the merchandiser we’ve been observing pulls me aside.

“I’m not sure if you can do anything about this, but I’m having an issue with our new app, and I think other people have been having an issue too.”

I offer to listen, but I don’t make any promises. That’s the job, and I don’t even know if the project will even go beyond the research phase.

He goes on to tell me that the company had previously used dedicated inventory devices — hardware with actual, physical buttons — and replaced them with iPads with a custom inventory app.

“The old devices used to click when you’d press a button,” he says. Now, it’s impossible to tell. “There’s no click or anything when you tap the screen. It’s too easy to miss the button, or hit it too many times. I’ll try to order two cases of something, but accidentally order 22.”

I’m trying to write while listening — this is the most valuable feedback I’ve heard all day. Sometimes people are reluctant to share what they really think when being shadowed, because they feel like corporate is watching them.

“The app was supposed to help us work faster, but instead it slows us down. I have to double-check the screen every time I do something, to make sure I’m not double-ordering. If it just made a clicking noise when I pressed a button, I wouldn’t have to do that.”

I thanked him for his feedback, and told him I’d do what I could, but again — no promises. He said thanks, and looked like he was happy to have unburdened himself. It’s strange how much stress can accumulate from these tiny, inconsequential-seeming design decisions. Somebody in an office a thousand miles away decided an app didn’t need sound effects; now a ground-level employee finds that his job is a little harder than it was before.

It’s been years since I worked on enterprise software, or at an agency. With some distance, I’m reminded of three design truths:

  1. Everything’s easier when your customer is also your user. With business software, it’s often the opposite — the person buying the software will likely never use the software, leading to misaligned incentives and a poorer product.
  2. Research is the easist thing to cut out of the design process, but without it, design is based on our all-too-fallible instincts. Without talking to actual users, I doubt I would ever consider the importance of sound effects to an inventory app. Whoever designed that app probably had the best intentions, but lacked the time or budget or support to do user research. It happens much too often.
  3. The latest and greatest technology is sometimes a step back for usability. iPads sound great when compared to old-school push-button hardware, but in reality, they present a lot of extra challenges for users who are moving fast and not giving 100% attention to the screen.

This wound up being the last thing I did on this project — the company decided to push it back, and my involvement ended with the research phase. I left agency life soon after to join a startup, which presents a very different set of challenges than working with giant enterprises. I think of this story occasionally, though, whenever I think about the value of user research.

If you enjoyed this, you might enjoy an article I wrote for A List Apart on a similar topic, about a year before this incident: UX for the Enterprise

Note: Obligatory reminder that human memory is faulty, so any quotes and descriptions are an approximation of what happened, rather than a precise reconstruction. Also, I’ve tried to obfuscate any identifying details, since I’m not cool with revealing the specifics of client projects without asking first.