The True Cost of User Experience

I wrote this blog post several years ago and I just recently revisited it. I felt that the message was still very relevant but I needed to update it to sound like I know what I’m talking about. I reworked most of the content to make more sense than it did in 2011(young wide-eyed UXer that I was). Hope you enjoy.

In some schools of thought, user experience design (UXD) and usability testing are a box to be checked somewhere in the development life cycle. As long as you, at some point in development, talk to someone about the design of your product things should move smoothly ahead. Usually these user interviews happen near or at the end of development and any feedback given is taken with a grain of salt.

The problem with this thought pattern is all the hidden costs of overlooking or short selling UX.

For instance, this real example shows a very confusing experience while trying to change a password for a login to an online application. (I am not going to reveal the company that had this experience. They have since come to the light side and now embrace user research and UXD.)

As you can see the form is pretty straight forward until you have to select what button to press to complete the task. The form is asking you if would like to reset your password. If you do, you fill out the form and then… Do I hit OK? Maybe that seems like I am giving the form permission to reset my password. Do I hit RESET? I think so… The form is asking me to “reset” my password so “RESET” must be the right button.

Wrong.

The RESET button clears the fields above and doesn’t give the user any feedback as to what just happened. Oh, by the way, the OK button is the right button, but the user would never know that. The user doesn’t get any feedback on the OK button either. It behaves the exact same way the RESET button behaves and now the user can only assume that their task is complete.

So, how do we break down the overall cost of this terrible user experience?

First we take a look at it from the user side. They now assume that their password has been changed. The next time they come to use the application; they put in their user name and their newly changed password. The application tells them that “The username and/or password are incorrect. Please try again.” So thinking they misspelled something they try again… same error. Fumbling around with this several times is taking precious time and patience away from the user. This is just the tip of the iceberg when it comes to cost.

Next that user then calls customer support to get some help. In walks the cost to the proprietor of the application. They are paying for every call that comes into their call center to troubleshoot this issue. They have thousands of users and are now funneling hundreds of calls through their call center on this one issue (Especially because this particular application requires users to change their password every 90 days.).

Some users even go as far as dropping the service and using a competitor’s application. “If it’s this hard to change your password, I can only imagine how difficult the rest of the application is.” Now, this may be an extreme viewpoint, but there were still some customers who felt that way. Hidden cost number 3 — loss of users.

Fed up with all the issue troubleshooting, the company decides that they need to get to the bottom of all the problems their users are having and perform some user testing. They go through several sessions of usability, take the finding and come up with a plan to implement the necessary changes to make the experience better for their customers.

The final cost of that is taking part of the development staff off their current tasks, getting them to crawl back through all the code to fix all the troubled spots of the application, retesting the application to make sure the changes haven’t caused any additional issues elsewhere in the application and finally re-rolling that application out to a production environment where the users can take advantage of the new improved design.

Had this company taken the mock-ups through user testing prior to one line of code being written, they would have discovered this issue (among others) and could have resolved it prior to launch. This would have prevented all the hidden costs of aggravated customers, larger call center volumes, troubleshooting time with each customer, lost customers, a ton of rework getting in the way of new enhancements, and pushing back future releases.

The cost of that simple change up front would have been minor compared to what actually occurred.