You know that app you have to use all the time for your job, but it is JUST SO PAINFUL to use?
I call this “death of a thousand cuts” software.
And it’s all too common.
In this video, I share six things you can to do avoid your product becoming a “death of a thousand cuts” user experience.
Transcript:
Every time I have to use my business banking’s mobile phone app, I just about lose my mind.
Look, it does what it has to do, and it works reliably. It allows me to receive money from customers, and it allows me to pay money to employees and suppliers. That’s all good and fine. But the user experience of it is what I call “death by a thousand cuts” UX.
There are rough edges, weird error messages, form fields that unexpectedly lose focus and so on.
Some things simply don’t work, and I’ve had to learn a series of steps around these problems. The question I have for you, the software you create, is it also becoming “death by a thousand cuts” software?
More importantly, how do we prevent our software from getting like this? From becoming an app or product that people are reluctant to go and use every time they need to because they know it’s just going to be such a miserable experience.
Here’s what I think we can do to avoid it.
Acknowledge that no-one sets out to make painful software
First of all, let’s acknowledge that no one actually sets out to make software this painful to use, not even the bank I use for my business, and yet it happens.
I don’t think we realize how painful we can inadvertently make our software to use, so we need to acknowledge that our software will become painful to use unless we deliberately make efforts for that not to be the case.
Use your software yourself as much as possible
Second, you’ve got to be using the software yourself as much as possible. Daily is ideal, but even weekly or once a month is good. And I don’t just mean you, singular. I mean, the whole team, as many people in your team as possible.
I think that’s the problem with my business banking’s app. Because it’s an app made for people who run and manage businesses, but it’s made by people who work in a dev team at a bank, who are not business owners.
So they’re not using the app day to day, and they’re not encountering the UX headaches that I do.
As much as possible you – your whole product team – have got to find a way to be using the software yourself.
As you use the software, you’ll realize the difficulties that are there and you’ll be motivated to fix them.
Educate the team about painful UX
Third, as the person in charge of the team, as a product manager or a product owner, talk a lot about UX, talk a lot about UX problems, talk about the problem of rough edges, and talk about the fact that you don’t want them to be in your product.
It’s not enough just to say this once to your team and expect everyone to absorb it. You need to repeat this message a lot before people internalize it and before people actually believe you’re serious about fixing these problems.
Empower your team to report and fix the rough edges
Which brings me to point four: empower your team, empower your team to care about these “death of a thousand cuts” problems, empower them to report them, make them believe you’ll actually listen to these problems, that they’re easy to report and that you’ll do something about them, empower your team to fix them.
These are usually easy fixes, quick wins. Often it’s as simple as just realizing, oh, this screen’s confusing.
That field for some arbitrary reason loses focus just when I want to type in it, or this one requires me to put in at least ten characters when I only have five characters of information.
It’s usually things like this that don’t require a lot of work, so you can fit them in amongst your work on the big features.
Do a lot of demos
Fifth: do demos. Do lots of demos. Daily, weekly, monthly. I don’t care. Do them whenever you can to whoever you can.
Do them in person. Do them over Zoom calls. Do them in webinars. Each time you’ll find yourself encountering the rough edges in front of people, and you’ll be embarrassed.
As soon as you’re off that call or out of that demo, you’ll be wanting to make sure that the problem gets fixed.
(Does it sound like I’m talking from experience here? I’m afraid I am. I’ve been doing webinars twice a week lately, and this has been exactly my own experience.)
It’s an iterative process. Maybe you do a few demos, you find the problems, you fix them, but that lets more problems come to light.
Also, as your team continues adding to your product, they’re inadvertently creating more rough edges where additional features clash in unexpected ways. So keep the demos going, keep the polishing going.
Ask customers
My last tip for avoiding “death of a thousand cuts” UX is this: When I’m doing customer interviews, that is, interviews with people who actually do use my product every day, I end the conversation with this question.
“Is there anything about using our software that frustrates you that you wish could be changed right now?”
My experience is that people almost always come up with something. You asked, they feel they have to answer. But the way they answer is revealing. If they have to think a bit, if they have to scratch their head while they search for something to complain about, then I know it’s not really such a big problem for them. It’s the ones who start to answer before I’ve even finished asking the question that are important. Then I know we have a real problem and that’s something we need to fix immediately.
So that’s it.
Six things you can do to avoid your product becoming like my business banking’s app. Follow these and your customers won’t have to endure a “death of a thousand cuts” user experience.