Software

Usability vs. user experience


I am repeatedly struck between the difference between usability and the user experience. I know, “user experience‿ has been beaten to death by Microsoft for the last five years. You cannot have a good user experience without usability. After all, if the user cannot use your product to accomplish their goals, it does not matter if they enjoyed not being able to do what they wanted to do.

This all comes back to how versus why. When developers are working strictly for usability, they are still focusing nearly exclusively on how questions. “How can we let the user perform operation XYZ easiest?‿ When developers are working towards why, questions like “does the user even want to perform operation XYZ?‿ come up instead.

All too often, software and hardware is loaded down with the wrong features, or too many features. This hurts the overall user experience. The user quickly becomes lost, unable to figure out what they want to do, or even what they can do. Study after study has shown, the user is better off with ten operations or functions then fifty, if the ten choices cover 90% of their needs. On the other hand, power users need a way to easily unlock the full potential of the product. Nothing is more frustrating to an advanced user than being blocked by a “user friendly‿ interface that forces them to jump through step-by-step hoops, wizards, and so on to do an advanced task that they already are familiar with. This is one of my persistent frustrations with Microsoft Office. Every time it thinks that it is helping me, it is really hindering me.

A good user experience meets and exceeds the user’s expectations. Unfortunately for developers and product engineers, there are only a few select products on the market which cannot be easily imitated and improved upon. This is how Google became such a successful search engine; they recognized that all of the existing search engines offered a poor user experience, and improved the entire workflow, from opening the search page faster with less clutter all the way through to displaying meaningful, accurate results. It was not that other search engines were not usable; every search engine had about the same syntax for advanced searches, basic search all worked the same, and everyone could find the box to type in the query. It was that the overall user experience was miserable.

The user experience is so much more than usability; it starts the moment the customer first hears about your product, carries through to the purchase process, the customer support, the installation and configuration, and all of the way through no longer using the product. For most products, the primary portion of the user experience is how it addresses their day-to-day why based goals. Does it help them do their job more effectively than other products or what they previously were doing?

And this is why it is so important to code towards the user’s why and not just the how. Usability focuses on making sure that the how is flawless; user experience is about ensuring a perfect why.

What are you doing to give your users the best experience possible?

J.Ja

About

Justin James is the Lead Architect for Conigent.

16 comments
bschreil
bschreil

User Experience Design is an overall discipline of making things usable, while Usability entails 2 subsets of overall User Experience Design: 1] UI Analysis, and 2] Usability Testing.

c45207
c45207

Is anyone else seeing an "undertie" character instead of a closing "? Opera 9.5, Firefox 2.0.0.13, and Internet Explorer 8 on an English Windows Vista machine all show ‿ , 0x203F instead of ”, 0x201D.

Jaqui
Jaqui

with no contest. and for exactly the reason you stated. if the site or application is not usable, there is no user experience worth mentioning, or no positive experience.

Mich-a-billy
Mich-a-billy

My last manager was only interested in what the application looked like and not how it worked. I spent a lot of time writing application that the users hated. When I broke away from this pattern, and started dealing with the users, understanding thier needs, I wrote good applications that they enjoyed because they could get their work done in an effecient way. I was let go because I broke away from the way the boss wanted it done and wrote application based on the users needs.

John Quillen
John Quillen

Thanks. You hit the nail on the head. To answer your question... Spend time with customers to understand what they want and how they want it. Show them what you believe they asked for, let them touch and feel it and then revise based on their comments. Prioritize. Prototype and then implement their most important features. Then re-prioritize the rest of the features after a release. One of the things that I say frequently is "Just because you can, doesn't mean you should." Cool features that catch people's eye the first time often frustrates them to no end in use. I recently saw an app that emulates a magazine online, complete with page turning animation and even the shadow on either side of the crease at the binding. It looked really cool. It was a burden to use it. It did allow for turning off these features, but because it was 2 columns of text per page I had to scroll down and then back up to read each page. Usability is non-negotiable in a successful app. Thanks

seanferd
seanferd

Aside from categorizing these concepts? The article is circa four years old - do you think the design process has changed? Do you think that the implementation of the process has improved since then? It is an interesting subject. Since you have resurrected this article (and my interest), I may just have to look up some more current, and more specific, articles on this.

Justin James
Justin James

It is always painful to see a company let a customer-oriented employee go, just because being customer-oriented is not in line with a particular manager's beleifs. If that department is a critical part of that company's operations, I cannot imagine them being in business for too long. J.Ja

Tony Hopkinson
Tony Hopkinson

disaster of the nineties, I am seriously wary of prototyping. May be we've learnt enough to do better, but I saw far too many applications with a nice crisp interface that worked really badly with only some specific data. Or the one where you spend so much time moving buttons a few pixels to the left and picking a font, all the budget gets used up and you end up with a beautifully wrapped turd. Usability is very important, but it's not just having an intuitively decorated button in the logical place. It's the function it calls, not falling on it's arse and completing before your coffee goes cold. All prototypes should be deliverables, if you aren't prepared to deliver it, then don't. Please don't. Please.

bschreil
bschreil

I wrote, becuase I found the article inadequate in describing the relationship between UX Design and Usability. I don't think that the design process will ever fundamentally change, in each case, the designer has to deal with understanding the user's mental model of the information space and constructing the information architecture so that all user needs are predicted and compensated for from the initial screen of the design. Implementation will always change as the technology changes, but that's not my forte.

javier.arrospide
javier.arrospide

For example lets say the customer needs a security solution againts a device type unauthorized use. He also wants an option for the security to be user level. If the security strength is better served by making the protection machine level. It should be advisable at minimum to explain the implications of providing the option. So, if your reputation is on the line. at least on security matters the customer will not always be right. Am I right?

John Quillen
John Quillen

There is an absolutely an art to prototyping. Paper prototypes do a great job of setting users' expectations and usually get much of the desired feedback. I'm curious, though; What makes a first release without a prototype better than one with?

javier.arrospide
javier.arrospide

If the product you make you also plan to offer as a security solution to others (all). Then that customer would'nt constitute a big porcentage of who pays the bills. So just to say in different scenarios other considerations might apply. For example when one says the customer is always right. Does he really mean the mayority of my customers are always right.

normhaga
normhaga

If after you explain the implications of the contradictory wants in writing and the customer still want what s/he wants and it can be coded, then code it. The customer pays the bill. If you do not care about the customer or about eating, then withdraw.

Tony Hopkinson
Tony Hopkinson

I must have mispoke. A prototype is meant to be a simplified model of whatever you are developing. QAD made the current version of the prototype the application.

notoriousDOG
notoriousDOG

I like to create wireframe "screens" in Visio and use the hyperlink feature to link to different pages. The wireframe aspect totally eliminates design comments, and the hyperlink lets users actually navigate the "site". You can email the Visio file (which run locally in Visio) or export as html to post to an online test area (although this creates a full screen gif of the "screen").

Justin James
Justin James

Since most of my users are remote, my "paper prototypes" are usually "draw useless screens in Visual Studio and take a screen shot." I do not like to prototype by sending the user running executable code, because they get hung up on stuff like "can we get that icon in cornflower blue?" and "but we need a pie chart!" and totally ignore the actual functionality of the software, usefulness of the interface, and the simple "does this meet our needs and wants and help us acheive our goals?". J.Ja

Editor's Picks