Pages

Wednesday, May 26, 2010

When You Should Hurt Your Users

I'm going to let you in on a little secret. I don't always do what's best for users. I know, I know. This is a horrible thing for a UX person to admit, but it's true.

This shouldn't come as a surprise to anybody, but it's shocked enough of my clients that it bears stating clearly. As an interaction designer, my job isn't (or at least, it shouldn't be) always to optimize everything exactly for the end user. There are several reasons for this.

The Best Thing For the User May Be Bad for Business

One of my favorite Dilbert cartoons explained that what users really want is "better stuff for free." As much as I dearly love to help the end user, my clients would quickly go broke if I gave users everything they wanted. A big part of the UX job should be balancing what is best for the user with what is best for the business. Sadly, those aren't always the same thing.

What does this mean in reality? It means that every time you see a banner on a free site, some UX designer accepted the necessary evil of showing an advertisement for acai berry in return for offering content for free. It means that sometimes a pricing page will be designed to showcase a more expensive option than the user might otherwise have chosen. It also means we have to work extra hard to identify features that are good for both users and the business (for example, features that make current paying users happy and thereby increase retention), so that we don't always feel like we have to sacrifice either revenue or customer happiness. 

Caution! This can go too far in the other direction. I would argue that a lot of Facebook's recent privacy debacles have been driven by optimizing too much for the business and not enough for the end user experience. The result of this, of course, can be losing end users, which can end up being bad for business in the long run.

Getting It Out There May Be Better Than Getting It Perfect

Nothing is perfect the first time it's released. If it is, you probably spent too much time on it. And sometimes the very best solution for the user is impractical for a lot of other reasons.

What does this mean in reality? Well, it means that if the absolute optimal solution for end users will take 6 years and a team of 20 geniuses to implement, I will try my hardest to find the next best alternative. I'm not saying I'm going to settle for a bad user experience. I'm just saying that there are a lot of different ways of making the user happy, and if it can be done without killing the engineering department, that's a bonus. 

Caution! This does not mean that you get to ship a bunch of crappy features and then never touch them again. If I give you a pass to deliver a suboptimal first version to the user in the interest of time and engineering effort, I expect that it will be iterated upon and improved in the very near future. It may never be perfect, but it had better improve!

I Have More Than One End User

Some users are more useful than others. There I said it. As much as we'd love to believe that a change will make everybody happy, we probably have lots of different types of users who all want something slightly different. In the same way that optimizing for the end user can sometimes be bad for engineering or revenue streams, optimizing for one type of end user can be bad for other end users.

What does this mean in reality? Consider freemium products. Freemium products have several distinct sets of users: those who pay and those who don't; new users and returning users; power users and casual users, etc. Sometimes, a feature that is optimized for a brand new, non-paying user can annoy or bore a retained, paying, power user. Since annoying people who pay me is not something I'm generally in favor of, when I'm adding a new user feature, I need to make sure that I'm considering the effect I'll have on everyone else. I also need to make sure that power user features are introduced correctly to (or hidden from) new users so that nobody gets confused or frightened away. These tradeoffs may make some things worse for some types of users.

Caution! Try not to always screw over one type of user, unless you're absolutely sure that that type of user will never convert into a more valuable type of user. If you've got a freemium model, most of your paying customers were probably once non-paying customers. And, of course, all of your power users were once noobs. You need to do at least enough for them to get them stick around and decide to pay you.

I Don't Always Know Exactly What's Best

Once, I had an engineer come up to me out of the blue and ask exactly what color and size would be optimal for a button. He was more than a little shocked when my answer was, "I have no idea." As much as I'd like to pretend that I have a mind meld with all of my users, I just don't. Sure, I tend to have good instincts based on years of designing and testing products, but the best way to find out what users really like is still to run a test of some sort. 

What does this mean in reality? It means that even if you have the best designer in the world working for you, you should still be following up with users in some way to make sure that everything is on track. Whether it's usability testing, contextual inquiry, collecting metrics, or (preferably) all of the above, you need to be constantly making sure that your designer is making the right decisions. Because sometimes we're not.

Caution! Relying solely on testing for design decisions can have drawbacks. People misinterpret both qualitative and quantitative data all the time, and metrics can't replace vision. Still, combining qualitative and quantitative data with design is an outstanding way to improve your product.

What's the Right Balance?

The ideal solution is always to try to find those magical features and projects that benefit as many different people as possible. When you've run out of those, you're going to have to start making some tough decisions.

My approach is to try to find the optimal user solution and work backwards from there, if it's absolutely necessary. If the optimal user solution is really bad for some other part of the business or user base, I try to find close alternatives that deliver the same benefits without most of the drawbacks. Every time I change something crucial, I reevaluate to make sure that it's still delivering value to the original user for whom it was intended.

It's probably more art than science, but starting from the best possible user solution and subtracting always seems to give me a better balance than starting with something inherently bad for users and trying to make it nicer.

Do you have other examples of when it's ok (or necessary) to do what's not best for your users? Share them in the comments, please.

Like the post? Please use the widget below to share it with your networks! Also, follow me on Twitter.