Usability… Emphasis on the U

“Shall we dance?” Said the user to the software…

“Sure, if you don’t mind me breaking your toes.”  Said the software to the user.

So, surely we can all get a grasp on what role the users need to play in usability testing right?  Well, for the purpose of this post I’m going to assume that, because I want to focus on U!  U being the person who’s coordinating the usability testing.  The person who needs to ensure it’s success (well, you have that responsibility whether you like it or not).

Where were U when the developer was outraged by the user’s way of doing things?  If U were there, what would U have done to calm them down, or justify what the user was doing?  How would U have ‘marketed’ the importance of what the user was doing?

So, what are some of the common elements U need to consider when coordinating usability testing (in no particular order)?

• Your goals – Always a good place to start.  What’s the challenge?  What are you trying to achieve from this testing?  Do you have certain questions to answer about the product?  The user base of the product will drive most of this.
• Approach – Identify a particular approach to your usability testing.  Just like you would with other test levels.  A Heuristic Evaluation is a good example.  What are your indicators (heuristics) of success going to be?
• Users – Probably the most critical aspect of your testing.  Who are they?  What do they do?  How do they use the product?  How should they use the product?  Do you need a particular level of experience or maybe differing levels?  How many users will give you a good indication of usage patterns, etc?  How well do they know testing?  They may need your support and guidance when it comes time to developing test cases/user scenarios, or when reporting defects.
• Test cases/user scenarios – Obviously, they need to be realistic.  Now, I said obviously but you’d be surprised how often they are not realistic when it comes to the user’s perspective.  Go back to the cartoon above.  U may have given the user a test case, or even the product’s user manual to guide them through, but when they use the product they do something completely different.  So, was that realistic test case really that realistic? (say that five times fast!).  Another critical point here is coverage.  This comes back to the above dot point.  Engaging the correct users will assist greatly in developing the appropriate coverage.  Leverage the users experience, opinions, etc.
• Incentives – Maybe not so common, but definitely something I have seen plenty of.  Think about this… U have developed a plan and a schedule which involves users from the real world (could be customers).  U are all set to go on day one and the user is running late, no hang on, they’re actually a no show!  Damn, there goes that testing.  Rewind… U offered some sort of incentive for their time.  Could be petrol money, free lunch, actual payment for their time… whatever it may be I’m pretty sure it will assist in getting them there!
• Environment & Motivation - U need to make the environment (and I’m talking physical environment) is as comfortable as possible.  Quite often these users will be a touch nervous and may hold back when they stumble across and issue.  Maybe they don’t want to offend?  Make sure they are willing to let U have it via both barrels!  U are reliant on their open and honest feedback.  On motivation… quite often the users will be from the business side of your company.  They are there because they’ve been told they have to be there.  They don’t like testing, they’re not interested in it!  U need to think of ways to motivate them to get the best feedback out of them.  No silver bullets here, as everyone is different.  Just keep this on your radar.

Definitely not an exhaustive list by all means, but a good start.

I can’t emphasise enough the importance of usability.  Take a look at this great post from Rob Lambert which highlights this!  When I approach a new project, generally my first two questions are as follows:

• Who will be using this product?
• How will they be using this product?

I say generally as I tend to ask about what problem the product is try to solve somewhere in there as well.  ;0)

So, if you can cover off on some of these common elements, your initial question about dancing with the software may be answered with a “Sure, would you prefer a Tango or a Waltz?”

No related posts.