Usability Part 2 - How To Do It

In my last post, Don't Fear The User Part 1 - Empowering Software Development With Usability Techniques, we talked about what usability is. The practice of making software easy to use. And that you accomplish this by listening to your target end user. Incidentally there is a great post on Good Experience today where Mark Hurst mentions his tweet:

Before you get customers involved, first you should probably check if the boss can handle bad news.

This is important because before you try to do usability work your boss needs to be on board. If you're boss is fearful and can't handle bad news then it might be a futile effort. Instead usability should be empowering. It will resolve problems and can help an organization meet its goals.  Now I'm going to elaborate on how to do it.

Step 1: Who is The End User?

User Experience Designers when we go to work, we do this thing called "User Centered Design". And all this means is we try to focus on The End User when we're designing. Let's use Blogger - this blog - as an example. If I were to sit down and start creating this Google product we know as Blogger, the first question I would ask myself is, "Who is the end user for Blogger?" THAT is the person you design for, not your client or your boss.  You want to target a persona that accurately represents your end users. If you do design for your client, boss, or self the problems are: a) you miss a lot of good ideas b) you miss all kinds of important details c) you might overcomplicate things for the person who needs to use that software d) your boss's wants are in conflict with the end user's etc.

Common question: But what if we want everybody to use our product? There are techniques for that too. For large-scale high traffic websites & apps, there are best practices. And if this is your product, you really need to work with a professional UCD person and I'd love to speak with you more :^)

Step 2: Listen to The End User

Wow I know right? This is so common sense you're probably rolling your eyes. OK but LISTEN - there are ways to listen to your customers. You don't just want to fire off a bunch of surveys, that's sooooo marketing. Nor do you want to ask for a list of all the features the user wants (they'll ask for everything). The best thing to do is listen to users as they interact with something. You take notes and record your research. It's fun and easy. This is also known as User Research, and sometimes referred to as Listening Labs.

Common question: But we aren't even settled on a product idea? Listening to your potential customers will help you figure this out. Watching them use a competitor's product will reveal all the ways you can succeed. If you work with an experienced product designer (ahem) they can help you glean this information from user research.

Step 3: Focus on The End User When Developing Your Product

There's always this temptation while developing something to look at your colleagues and say, "Wouldn't it be cool if it did this?!" It's fun to come up with cool ideas but it's better to postpone frosting the cake until after you bake it. Never forget who you're designing for. Don't let your bosses forget. Remind the developers so they don't forget and code a bunch of shortcuts and hacks.

Step 4: Usability Test

This is not QA testing. You are not looking for bugs. What you are testing is weather or not the end user can perform a task using the product. How long does it take that person to perform the task? How many clicks do they have to make to do what they need to do? Can they find the button? Do they know what feature lives in that dropdown menu?  That is usability testing.  See how agnostic this is? 

Step 5: Apply the Research and Testing To Your Product

Don't just report your research and testing, apply it. Make concrete recommendations for how to fix flaws in the UI that impede people from performing a task. Ideally this is all done as part of a larger development process and you have time allocated for usability testing and time to make changes to your interface.

Here is how to make this sound like bad news to the boss:
"When we did research, people complained that it was hard to sign-up. When we tested the sign-up process, only half the users were able to sign-up."

Instead it's better to discuss improvements you can make to remedy the problem: "When we did research, people complained that it was hard to sign-up. When we tested the sign-up process we found that if we reword the title and make this button larger we can make sign-up easier."


That is how you do it. Let me know if you have questions.