User Feedback
I was listening to ShopTalkShow #544 where Dave mentions his craving for frank, almost brutal, user feedback on the app they’re building (Luro) and it reminded me of something I wanted to write down.
At a previous gig, we hired a head of user research who helped formalize and bring rigor to the practice.
He was fantastic. He got everyone involved in gaining regular exposure to our customers to better understand their needs and how they used our software.
One of the most fascinating things I took away from so many of our sessions was how little people cared about our software — especially the user interface.
All they ever wanted was to get a job done, and our interface was nothing more than a delivery mechanism for the thing they actually wanted.
In fact, customers would often specifically mention how little they cared for the “usability” of our software. They vowed they’d go through the most tedious workflows imaginable if they could ultimately get the primary thing they wanted from us, which was not software.
What did they want from us? Access to insurance in high-risk markets where it was scarce.
It made me think of the different kinds of software I use and how I am willing to deal with difficult, obtuse software if it means I can get the thing I ultimately want which is often beyond the software itself. The software is often merely a means to an end.
For example, booking a flight. If there is only one flight in and out of a specific area with a specific airline, and that flight will save me time and energy and headache, I will do whatever it takes to buy that flight, no matter how crappy the website.
Or, as another example, sometimes I’ll look for something very specific online and I’ll search and search and search until I finally find it from some obscure website run by a ma and pa shop whose fulfillment system happens through individual email correspondence. Convenience falls by the wayside in contexts of scarcity.
And this idea was reiterated to us through our users. It allowed us the opportunity to rethink the kinds of projects we took on, to ask ourselves: “Is our time really best spent making this GUI wizard one step shorter? Or would we be better off doing something else for our users? Perhaps even something not software related?” It was often the latter.
For example, one time we were rethinking an entire workflow UI that we believed made things more modern, more sleek, more refined, more efficient, best in class, etc., and we showed it to a few different customers and their collective response was “Yeah, I suppose this is good and all, but it seems like you’re building stuff just to build stuff.“ As we delved further into their responses, we often found they would be much happier using things in their current state with just a few minor UI adjustments (rather than an entire UI refactor). Small quality of life fixes. And with the time we saved not building what we had showed them, they suggested we talk to the people in department X, Y, or Z and help them fix the processes which were causing them real pain.
In other words, most of their problems were not what was happening on screen. Improvements in software often had a point of diminishing returns for them in their overarching experience of doing business with us.
They cared way less about the software itself than the “real-world” results of interacting the software, e.g. “A new interface would be fine, I guess, but what would be really nice is if you helped us get our profit sharing checks sooner. Or if you could approve more of our quotes. Or if your home inspections didn’t fail.”
You build things thinking you know what people want and how they’ll use it but they’ll often surprise you.
For example, you build a nice playground with some slides that kids can enjoy, then they just go and do something like this.
