Matching User Experiences

At Thursday's UX Office Hours , a funny thing happened -- somebody came in wanting to talk about user experience. The reason I say that's funny is that, most of the time, people come in wanting to talk about their user interfaces, not their user experience. They bring in mockups, screen snapshots, prototypes, and actual products and web sites. And they want to know what to do to make it better. Almost always, I have to pop the conversation up a level, to talk about what they want to accomplish for their users, rather than how they should move pixels around. Part of what I try to do is to educate people so that, when they walk out, they're better equipped to move forward. So, what's the difference between UI and UX?

In a nutshell, you want to give your users a good user experience. A good experience means they'll be able to accomplish what they want, they'll be happy with your product, etc. One of the ways to get a good user experience is to have a good user interface. You might think that makes no sense -- how can it be that UI is only one of the ways to provide a good UX? What other ways can there possibly be? Well, here are a few:

• Provide functionality or content that your users can't find anywhere else, that they absolutely need
• Do things automatically for your users, so they don't have to see any UI
• Build a system that is fast, that, once learned, allows your users to do things faster than they can anywhere else
• Same, but replace "fast" with "better" in some context specific to your business
• Pay your users money (yes, this is real -- look at Google AdSense, Amazon Associates, or Ebay)

And what should you do? You should work to understand your users and then do those things that will give them the experience that you think will accomplish your business objectives.

Back to the guy who came in yesterday. It was a great discussion and I hope I was able to help him better understand what he needed to do. One slightly surprising thing was that his company has two very distinct classes of users and he was trying to figure out how to craft an experience that met both of their needs. Unlike a system like Ebay, where buyers and sellers are largely similar people, or Monster, where the point of the site is for job seekers and job posters to interact with each other, his two classes of users weren't similar and weren't going to be interacting with each other. I told him that he should build two completely separate UIs for these two groups, that to try to build one interface would end up serving nobody well. After he left, I thought of some great examples:

• Google provides completely different experiences for people placing ads, for people putting ads on their sites, and, of course, for people seeing ads on the net.
• Amazon Associates provides a completely different experience for associates than they do users who see associates' links.
  

While his business is different from these, the same rules apply. And the bar for the quality of the UI is different for these different classes of users -- the interface for people creating and placing ads,or creating associate links is so much less important than what the people seeing ads or an associate link get. The first group of people are making money, so they're incented and a bad UI won't stop them from using the service. But, if the ad or link UI is wrong, nobody will make any money.

To provide the best product for your users, you want to create an experience that matches them. Sometimes, that means figuring out the classes of users you have and building different experiences for them.