Skip to page content or Skip to Accesskey List.

Work

Main Page Content

Gorilla Usability

Rated 4.18 (Ratings: 9)

Want more?

 

D. Keith Robinson

Member info

User since: 29 Oct 2002

Articles written: 3

Do You Know Your Users?

That is a tough question to answer. It could mean so many different

things. That's fairly obvious. But it's a question everyone who works

with technology that other people use should ask themselves. I've

often asked myself this question, and have come up with different

answers at different times on different projects. I came to the

realization at some point that for the most part I knew who my users

were, and I had an idea of how they used my sites, but other than that

all I had was a bunch of data and even more assumptions.

I've been lucky enough to be involved in some formal usability studies

before, and it was an informative, eye-opening experience. The main

problem with these formal studies is that they are expensive. They are

also arcane and time consuming. In my case we hired a company to come

in, set up studies, conduct them and hand over the results at the end.

I was able to weasel my way into these sessions as an observer and

that was much more informative to me as one who actually works on the

site than all of the statistics and reports combined.

I couldn't help but think, "Hey, I could do that." I'm the guy who

actually designs and builds the sites, why not cut out the middleman?

That's what this article is all about. I'm going to show you some ways

to get to know your users in a real world, out-from-behind-the-glass

kind of way. There is a place for formal usability and if you have the

opportunity (read: time and money) to do them, I recommend doing so.

It's also great to learn from what others have experienced, to read

books on usability and to keep up with the gurus. I've done all of

those and frankly they all pale in comparison to the information I get

from, what I like to call, "Gorilla Usability."

What Is Gorilla Usability?

Don't worry. I know how to spell. I imagine you've heard the term

"guerilla marketing"? Well, it's kind of like that, but a lot less

subtle. It's about getting out from behind the video camera, the

reports, the stats and all the guru commandments and actually getting

to know your users. It's about making that direct connection between

the makers and the users. It's about getting into their world, seeing

how they use your sites on their turf. It's about learning how to

listen to what your users want, and getting past your own assumptions.

There are many benefits to getting to know your users. Some are

obvious and some are not so clear. If you make an effort to understand

your users on every project you are involved in you will begin to be

able to make design decisions that will save you time and grief down

the road. Your sites will be better tailored to user wants and needs

and in the long run you'll save your clients and organizations money

as well as help to build a solid relationship with the people who

matter most.

Quite a bit of what I'm going to talk about it common sense, and

really there are many directions you could go with this. The main

thing is to make a commitment to get to know your users, doing

something about that commitment and then following up with all the

great user feedback and observations you'll have.

So, How Do I Start?

The hardest part about Gorilla Usability is getting that initial

contact with your users. I've worked on many projects where the Web

team is working in a vacuum, with little or no contact with the users

aside from Web stats logs and the occasional e-mail. Depending on the

type of project you are working on you have a few options here, and

I'd stress that a few users are better than none (but none can be

better than one or two — more on that later), so if you can put your

designs in front of family members, friends or co-workers it's better

than not trying to get user feedback at all.

If you are working on a redesign or project that has another related

site with existing users this will be easiest. There are a few ways to

get some of your users to help out and most of those are free — or

really cheap. It could be as simple as posting a link on your site, or

sending an e-mail to your mailing list asking for participation in

user studies. Make it clear that you are doing this to help them, and

let them know you need their help to make a better experience for

everyone. If you have a small user base or worse, apathetic users,

offer a small gift or to feed them, that seems to work well. In my

experience there are always a few people who are willing to help out

and share their opinions with you. These folks are usually more

engaged than the "typical users" that you'd get for a formal study -

and they're usually free!

Another method is a simple feedback form, or survey posted on your

site. This works really well for Intranets or projects with highly

engaged users. It's a great way to collect some basic user data and

opinions and if you make a request for volunteers you'll quickly have

a user base with which to set up you studies.

We've Got Volunteers. Now What?

Now comes the most tedious part. You'll need to set up appointments

with your volunteers. This can be time consuming and frustrating at

times, but hang in there. I've done this a few times now and it's gone

fairly smoothly, I found that making sure they knew that you were

going the extra mile and advocating for them seemed to help this

along. You can have them come to you, or, what I'd suggest — you can

go to them.

Conducting the study at a user's home, desk or office will give you a

greater insight into how they use your sites, and the Web in general.

It'll be an extra effort on your part, but the payoff is great,

believe me. You'll see things you'd have never seen in a classroom

setting or at your own workstation. I recently did a study where we

wanted to test a PDF form. We knew there were some problems with it,

but we didn't have a handle of how people used this form on the Web.

The idea was to have people fill it out online, save, print and then

fax it in. Well, I went out to conduct the study at a few of our

user's offices and I found out, to my complete surprise, that most of

them didn't have a printer connected to the computer they used to hit

the Web. They had a copy of the form and when they ran out they used

the copy machine to make more. One office had only a small laptop

connected directly to a DSL line. It was shared by five people, no

network, no printer, nothing. And this was closer to our typical user

than we'd ever dreamed.

One thing to remember when setting up these studies is that if you

have several people on your Web team conduct studies — which I think

can be a really good idea, especially for small teams — you need to

make sure that each person gets at least three users per study. If

possible it would be good to do six or more. The problem with doing

one or two users is that you tend to identify with those users and

when it comes time to get your observations together and make a plan

on improving your site you'll have a tough time seeing the big

picture. Every user has particular problems, and some of these might

be limited to that one user. You need to know when to let those go and

take care of the issues that matter to the majority. In my experience

it takes at least three users to begin to see patterns emerge.

Now Comes The Fun Part

You've got volunteers lined up, you've scheduled appointments to meet

with them in their lairs, now what? You need a plan. It's Gorilla

Usability, but it's still smart usability. What I like to do before I

go out to conduct a study is write up a simple "to do" list for me and

a simple script for the user. I put to paper what I want to tell the

user and how I'd like to set up the study. I do this in a very loose

manner, as these studies, unlike formal usability studies, tend to

have a mind of their own and often go all over the place. That's a

good thing in my mind, it keeps it interesting, makes it fun and may

uncover some things about your users you might not have gotten to, but

I at least try to have some semblance of order to them.

The "to do" list is something like this:

  • Thank the user for helping out, let them know what the study is

    about, and that we are testing the site and not the user. Let them

    know it's OK to make a wrong turn and that all their feedback will

    help make a better user experience.

  • Ask the user what they think the site is about, or if they use it

    currently what they use it for. Ask them what they like and don't

    like and just get a general feel for how they view the site.

  • Have them look at the site as a whole. Ask what they think might be

    in different areas of the site, or what different functions would

    be for. Gauge their expectations and first impressions.

  • Now give the users some tasks. Use a script based on some areas you

    would like feedback on and some other general areas or functions.

    Keep the user on track if possible, but note where they deviate.

    Take notes, observe and encourage the user to keep talking about

    what they are thinking. Try to avoid coaching unless the user asks

    for help.

  • When the tasks are done, thank the user for their help.

  • Ask the user for their general opinion and impression of the site

    and the experience. Let them express how they felt while using the

    site.

  • End the study. Make sure you give them your contact information in

    case they have any more feedback.

That is just an example, your plan could be more or less detailed.

It's just a road map for the study to help keep you focused. The next

thing you'll want to prepare is a script for the user tasks. Pretty

much what you want is some tasks for the user to do that will help

simulate a typical session using your site. This will vary greatly

depending on your project. For example, on a corporate Intranet you

might have a script like this:

  • From the home page find Human Resources

  • Now locate the cafeteria menu

  • Go back to the home page

  • Search for information on the president of the company

  • Locate the casual Friday policy

  • Submit a classified ad

  • Find the holiday schedule

You get the idea. The trick here is to give them tasks to do without

telling them how to do them. You'd say "Find the weather in Sydney"

rather than, "Go to the Weather page, choose Australia, then select

Sydney from the drop down menu." This way you can observe how the user

gets to that information. Lots of times they do exactly opposite of

what you'd think.

Once you've conducted the study and have lots of notes and

observations your almost ready to start advocating for your users and

solving some of their problems.

Almost Ready?

Well, yeah. Before I go on I wanted to let you know that there are a

few other ways you can get some good data about your users aside from

the studies. I've already mentioned having surveys and feedback forms

on your site as a good way to get volunteers to help out with your

studies. These are also nice things to have when collecting data to

help you move forward solving issues.

Another great way to help understand your users is by looking into

your Web logs. This way you can get some data on what pages are used

the most, where users are entering and leaving the site and lots of

other interesting data. Alone this data is nice to have, but coupled

with the feedback and usability study observation it becomes a

powerful ally in helping you determine what issues to tackle first.

There are many different software packages out there that can help you

decipher these logs and put them into a format that you can read and

use. One I particularly like is "http://www.clicktracks.com/" title="Opens in a new window"

target="_blank">ClickTracks
It takes your logs and

couples them with the actual display of your Web site, showing you

visually where and how often people click different links.

There are lots more ways to connect with your users, so be creative.

Get to Work

Now you're ready to get to making your site a better place for your

users. In my experience there are always a few obvious things you can

take care of right away. If your logs are telling you that 60% of your

users hit the menu on your restaurant site, but you moved the link to

it with the new design and now people can't find it - you might want

to fix that. What I do is go through all the data I have and start to

identify patterns and similarities. Some are fairly obvious and some

harder to find.

Once we have these it's time to work out a plan for getting them taken

care of, we've learned about our users needs and are ready to advocate

for them in our project plans. We also have a basis from which we can

make design decisions and another stakeholder to refer to when

weighing options.

It's also a good idea to keep the lines of communication open. Sites

tend to evolve, business rules change, user bases change, heck,

everything changes, and usability needs to be an ongoing process. Once

you're done you should start thinking about the next round.

I can say that these types of studies and just the effort of getting

to know the users of my sites has made me a better designer, a more

efficient developer and has saved me time and effort in the long run.

Not to mention enhancing the experience of people who use my sites.

There is a lot more to usability that this — all of it good stuff —

but I like to boil usability down to one simple rule. Get to know your

users. How you do that is up to you.

D. Keith Robinson lives in Seattle Washington. To read more of his thoughts, visit asterisk*, to view his photography go to Almost Wordless and to get him to do some work for you hit up DKR Productions.

The access keys for this page are: ALT (Control on a Mac) plus:

evolt.org Evolt.org is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.