With the advent of remote usability testing services such as TryMyUI and others just about anyone can create a usability test in minutes and have it performed by a user somewhere in the world in a matter of hours. The can receive a video of the users screen and his voice as he performs the test for as little as $35.
Because it is so easy and cheap to conduct remote usability tests, designers, developers product managers and others who don’t have a great deal of experience in writing a good test script are writing them. We run the remote usability testing service TryMyUI and we have reviewed thousands of tests and have found that the way the scenario and tasks portion of a test is written greatly affects the results you get when a user performs the test. There are a few common mistakes that novice test creators make. Writing a good usability test is quite straightforward especially if you keep in mind the following guidelines.
1) Write an engaging scenario.
The scenario is the part of the script that tells the user the frame of mind he should have when performing the test. It is really important for the user to really put himself in the proper frame of mind before conducting the test. To make sure your tester really immerses himself in the scenario you need to make your scenario as engaging as possible. Be sure to describe the scenario in the form of a story and use concrete, specific details rather than vague generalized wording. Details and a story allow the user to visualize the situation and more easily immerse himself in it.
For example:
“When you got home from work you found the fire department at your home and your house in ashes. You are in shock. You need to contact your insurance company and what you should do now and also find out if they can arrange for a place for you to stay while you get this disaster sorted out.”
is more engaging than:
“You are trying to figure out how to file a claim on your insurance policy.”
2) Pick your tasks thoughtfully.
If you haven’t conducted any usability tests on your website then it is very useful to make a list in priority order of: “What would have motivated a user to land on my site and what tasks does he expect to accomplish now that he is here.” This list of tasks will be the basis for the tasks you ask the test user to perform on your website.
3) Make the first the first task a general impression task.
Since you have a user who has not seen or used your site before it is very useful to get her first impressions of your site. How long does it take her to understand what the site is about. What clues on the page guide and shape her understanding. A good first task is always to ask the user to give you her general impressions of the site when first visiting. Ask her to figure out what the site is about, what the purpose of the site is and to say out loud what makes her think so as she figures it out.
4) Don’t “lead the witness” by the way you word the tasks.
When you word your tasks be sure to present them in a very general way and never use the same language that you use on the website. For example if you want to test the process of buying an electric drill and they are buried in your site under hardware / power tools. Write the task as “find the right electric drill that will meet your needs” rather than “Click the link that says hardware. Then click on power tools. Then pick an electric drill.”
5) Ask open ended questions.
It is often enlightening to ask the user general open ended questions, like: “What would you have done differently or better?” or “Where have you seen this done better?” It is also often useful to start a test not on your website at all to get an idea of how a typical user might approach solving the general problem your site solves if he did not know about your site in the first place. Give him a blank browser, put him in the proper frame of mind with a well written scenario and ask him to use the web in general to solve the problem.
About the author:
Please us the information at the following link for about the author:
https://www.uxbooth.com/author/sanielfishawy/
Maybe you might be interested
