Putting the "You" in Usability

Have you ever used a product and found it difficult at first?  Or maybe I should say, when have you not found this to be true?  Some things are just easy to pick up and use.  In fact, the best products don't even require much documentation because they are just that intuitive.  I'm happy to say that many product teams are now engaging in the discipline of usability testing and today I was the guinea pig in a usability test.

The product provides useful functionality in a library that is built on Windows Workflow (WF).  The team was recruiting experienced WF people to give feedback on the product so I signed up.  I spent about an hour and a half trying to complete a 6 step process on a product and technology that I had no background with and no idea of how to actually use it.  There were many fits and starts as I went through this process.

  1. Read the instructions of what I am supposed to do
  2. Try to guess at what activities on the tool palette might do that thing
  3. Try to guess at what the properties do and which ones I ought to set
  4. Look at the doc fruitlessly searching for help on the thing
  5. Study some sample code that was written by a pro who did the "right" thing but not the simple thing (meaning they wrote lots of code and did it in a way that no noob would do).
  6. Offer my perplexed guesses at what I should do to the team who was monitoring my test


Wow - what a great time eh?

Really, it was a good time.  I enjoyed taking the hit on this early product so that hopefully they will iron out the kinks and get somewhere better in the future before they unleash this product on you.  I think they were very surprised at the way I looked at the product (am I really that different?). 

When I work with some new piece of technology, I don't begin by reading the manual cover to cover (who does?) but I start my own scientific process.  I experiment, observe the results and form hypothesis about the way the thing works.  I then conduct tests to prove or disprove my hypothesis.  Sooner or later I develop a mental model of the way the thing works and after a while I find myself saying things like "Oh - that thing?  It's easy..."

How does one do a usability test?

First off you can do these at any stage of the project.  Even before any code is written you can do paper prototype testing (as I covered in this ARCast interview with Mia Northrop of seek.com.au).

Once you have some working UI and perhaps some basic help files you can construct a test.

Think about the kind of test subject you are looking for.  If you have thought much about your users you might have developed a list of "personas" that represent the kind of users you expect to have.  You will want to test with several people who represent your personas to see if they respond as you thought they would.

  1. Give them a set of small tasks with minimal instructions.
  2. Invite them to sit down at the computer and "think out loud"
  3. If they aren't saying much prompt them with questions... "What are you thinking?", "What are you looking for?"
  4. When they get stuck offer hints - "What if you tried...?", "Does the help say anything about this?"

Afterward you will find that you have a great deal of information about where people got stuck, what they were expecting and some guesses as to why they didn't find it.  At this point it may be too late to make major design changes but clear documentation and samples might help people to work around such issues.

Skip to main content