Why bad design = bad human experience
How do we create things that actually help the people who use them, rather than make their lives harder?
A bad design = a bad human experience. I was “face-to-face” with this reality a few weeks ago while shopping at a very notable home improvement store. It was a painful interaction, not because the human helping me was inept, but because the software they were using was absolutely worthless. I witnessed them log in and out of several different systems, re-enter the same information each time, then rinse and repeat, all in the name of a would-be simple task. It took way too much time and energy.
The software was bad, thus the human experience was bad (for both the associate and me!). So, how do we make sure we’re creating products and services that actually help the people who use them, rather than make their lives harder?
Start with creating good relationships:
I began exploring this idea back in 2016. My thought was that every interaction we have could potentially create a positive return… or not. The ask was for people to consider a parallel between human relationships and the products they are designing.
As someone who has worked in digital product design for almost 16 years, I’m still amazed at how much awful software is out there. If the software doesn’t help someone do their job well, then it does the opposite of improving the experience: it worsens it.
Alas, people are persistent. They find weird workarounds for the poor tools they’ve been given, like saving information in external tables or sheets, or writing notes alongside their computer, or using copy-paste-copy-paste repetitive actions, etc. Sure, these workarounds allow people to get work done, but during a time when it’s easy to compare them with intuitive design like Instagram, YouTube, etc., it’s hard to overlook the clunky and outdated tools many people use every day. Time is wasted, frustration grows, and feelings of disempowerment set in.
So how do we start creating better software for better end-user experiences? My answer is that we need to think about the products and experiences we design in the same way we think about interacting with other people.
Get into the weeds:
I often work with teams who have the privilege of helping people do their jobs better (ideally, more effectively and efficiently using software). For example, last year I worked with a client focused on two end-users:
An EMT who is on-scene to help a patient and is using software to get patient information from dispatch, and;
A billing associate at an IT service provider who is responsible for invoicing for services provided
In order to figure out how to help these end users, we needed to get into the weeds on the types of scenarios and specific moments in which they interact with the software. What’s working in these scenarios? What isn’t? Why are the end users frustrated? Why are they satisfied?
Extract the information:
I use a handful of techniques from my work as a facilitator to unearth the answers to these questions, like:
Role Play: Set up a mock experiment where one person pretends to be the software (yes, the software), and the other acts as the user of the software. Replicate the experience or scenarios in which the software is being used currently. Then re-do the role play with a better version; one with a narrative that yields a more positive experience. Do it again and again if necessary. Take notes, and capture observations and reflections. You’re starting to get at the heart of what your end-user wants/needs!
Interview people: Another way to improve the experience is to interview your end user about what pains them. Also, be sure to ask what they would like to feel like when they use a redesigned version of the tool. This happens naturally on day one of a Design Sprint during the “ask the experts” portion of the session. Whether or not you’re Sprinting, you can still invite in customers during the front-end of the process.
Ride-alongs: Observe the end-user actually using the tool. I couldn’t help myself from doing this with the associate attempting to help me at the aforementioned home improvement store. Doing so will help you identify redundancies and places that could be more efficient, reveal looks of pain or frustration on the end-users faces, as well as looks of relief. This is a really useful method since articulating why/how something isn’t working doesn’t always come naturally to everyone.
Make sense of it:
Now that you’ve extracted the information, use the details as data points to refine and design a revised version of the software. Then test it on your desired end-user to make sure you’ve nailed it!
In the case of my EMT and billing associate end users, we did just that. After we prototyped new versions of the tools, we had the end-users review and give feedback on the proposed solutions (boy, did they have opinions!). In both cases, the product teams who were responsible for the software had huge shifts in their perspective because they saw first-hand the importance and impact of the tools they work on, and what it meant to deliver value.
A lot of software is designed without consideration for the people who use it. (I know, it’s shocking.) Too often, we forget the power and potential impact we have on people’s daily lives when designing tools they’ll use every day. So, try some of these ideas out. Lead with the intention of doing meaningful work. Because a good design can mean a better day for someone at work and a better day can mean… everything. And that probably also leads to world peace, but I don’t have the data to back it up yet.