The cost of waiting for users to complain
When was the last time you complained about a product or service that you use? I don’t mean, mumbling under your breadth about a shoddy customer experience, or moaning to your friends about something you bought, I mean actually complained to the company itself? Actually spoke to someone about your complaint or filled out the dreaded complaint form. If you can remember, it was probably a while ago. If you can’t, then I wouldn’t at all be surprised. You see, whilst complaining is certainly more socially acceptable in some cultures, as a general rule people don’t like to complain. Complaining makes us feel uncomfortable. It’s not nice telling someone that something they did sucks, so most of the time we won’t complain, even though we know that we probably should.
Deep down I think we all know that people don’t like to complain and yet time and time again I’ve heard product teams say something like, “ We’ll release an MVP and wait for our users to complain so that we can find out what to work on next.” Or something like, “ We’ll release it without [insert important feature here] and wait for our users to complain. If they need it badly enough, they’ll let us know “.
The problem is that we could be delivering a terrible experience to our users and yet the vast majority of them won’t let us know. They are simply too nice, too busy, too lazy or too apathetic to complain.
I’m sure you’ve seen Henrik Kniberg’s example of an MVP approach (shown below). We might think that providing our users with a scooter or bike to get from A to B is fine and yet our users are far too polite to tell us that getting soaked to the bone every time it rains and arriving at our destination with legs like jelly is not what they hoped for.
Ok, so we might annoy a few users along the way but doesn’t this, ‘wait for the users to complain’ approach help a team to decide what to build? Well yes, but it comes at a cost. A cost that is generally not worth paying.
The true cost of waiting for users to complain
It’s estimated to cost up to 5 times more to acquire new customers than to retain existing ones. To put it another way, pissing off your existing users is a very expensive way to run a business. Furthermore, for every user that complains you can bet there are a lot more who feel the same way but won’t let you know. Of course they will be more than happy to let their friends and family know, given that we share bad experiences by word of mouth more quickly and more widely than good ones.
A mis-guided design strategy
Waiting for users to complain is not just a risky business strategy, it’s also a very lazy and poor design strategy. A team shouldn’t have to wait for a user to complain to deliver functionality they know users need. For example, if you know that there will be a need for tabular data to be exported, don’t wait for users to complain about not being able to export their data before you start working on it.
I’ve previously written about why the user is not always right. It’s not the user’s job to tell the team what to do, it’s the team’s job to work out what the user needs and how to best meet those needs. After all, when a user complains about a missing feature or suggests a design change, most of the time their suggestion is not the best solution. As Henry Ford almost certainly didn’t say, “ If I had asked people what they wanted, they would have said faster horses “.
Be proactive, not reactive
Rather than waiting for users to complain, teams should be proactively discovering user needs through user research, such as interviews and observation, and then designing, validating and delivering solutions that meet them. And don’t expect users to tell you whether their needs are being met or not. Again, that’s not their job, it’s yours. It’s important to proactively measure the experience of your users so that you can act before the complaints start flooding in. For example, through tracking and observing usage of your product or service.
By proactively discovering user needs, collecting user feedback as early as possible (at the design stage, not just following delivery) and tracking the experience of your users you can minimise the number of complaints and be in a much better position to judge which you should and shouldn’t be acting on. Don’t take the costly approach of waiting for users to complain about something before you act. By the time the complaints start coming in the damage might already be done.
See also
Image credits
Originally published at http://www.uxforthemasses.com on June 9, 2021.
