What is Usability Testing?

Date Added: marts 26, 2011

Author: Lay Berls

First of all what is a usability testing or user testing as it is sometimes called?

In a usability test you watch as a user who is unfamiliar with your website attempts to perform a task or set of tasks on your website. The goal is to uncover usability problems that typical users might experience.

Traditionally usability testing is conducted in person with a moderator guiding the user. Typically users are recruited, screened and asked to come on site for the purpose of conducting a test. A user is seated in front of a computer and a moderator asks them to perform various tasks on the website and asks carefully worded questions. The session is recorded for later analysis.

Quantitative vs qualitative testing

Usability testing is qualitative testing rather than quantitative testing.

In quantitative testing you are trying to prove something definitively, such as “design A converts better than design B”. For quantitative testing to work you need rigorous scientific and statistical methods to be assured of getting the right answer. You also need large sample sizes.

With a qualitative usability tests you uncover glaring problems that you as the site owner or designer are blind to but that are obvious to just about everybody else. Usability testing requires a relatively small sample of users (5-10). Usability testing works because every site has problems – often big problems – and these problems are often not obvious to you because you know how the site works or should work. A fresh pair of user’s eyes quickly stumble upon these problems. The result is an “aha” moment as you become aware of a glaring problem that you were previously blind to.

Remote usability testing

With the advent of remote usability testing services like TryMyUI and others you don’t need a moderator and don’t need to recruit users. You enter a script for your test and select the demographics of users you would like to perform the test. The script and your website load remotely on the user’s computer. And the user performs the test from the comfort of his own home. Typically users are instructed to say out loud everything they are thinking . You get the results in the form of a video of the user’s screen and voice as he attempts your test.

Remote usability testing is much less expensive than moderated testing. You can get tests performed for as little as $25. Moreover the results are often better than a for a moderated test conducted by an inexperienced moderator. Since there is no interaction between a moderator and the user in a remote test there is no risk of an inexperienced moderator skewing the results with body language or leading questions. You just need to make sure you write an effective script for your remote test. Finally, there is the added benefit of being in the users bedroom so to speak. You get to see how your site feels in *his* computing environment warts and all.

5 Secrets to Writing a Great Remote Usability Test

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 $25.

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:


var gtbTranslateOnElementLoaded;(function(){var lib = null;var checkReadyCount = 0;function sendMessage(message, attrs) { var data = document.getElementById(“gtbTranslateElementCode”); for (var p in attrs) { data.removeAttribute(p); } for (var p in attrs) { if (“undefined” != typeof attrs[p]) { data.setAttribute(p, attrs[p]); } } var evt = document.createEvent(“Events”); evt.initEvent(message, true, false); document.dispatchEvent(evt);}function checkLibReady (){ var ready = lib.isAvailable(); if (ready) { sendMessage(“gtbTranslateLibReady”, {“gtbTranslateError” : false}); return; } if (checkReadyCount++ > 5) { sendMessage(“gtbTranslateLibReady”, {“gtbTranslateError” : true}); return; } setTimeout(checkLibReady, 100);}gtbTranslateOnElementLoaded = function () { lib = google.translate.TranslateService({}); sendMessage(“{EVT_LOADED}”, {}, []); var data = document.getElementById(“gtbTranslateElementCode”); data.addEventListener(“gtbTranslate”, onTranslateRequest, true); data.addEventListener(“gtbTranslateCheckReady”, onCheckReady, true); data.addEventListener(“gtbTranslateRevert”, onRevert, true); checkLibReady();};function onCheckReady() { var ready = lib.isAvailable(); sendMessage(“gtbTranslateLibReady”, {“gtbTranslateError” : !ready});}function onTranslateRequest() { var data = document.getElementById(“gtbTranslateElementCode”); var orig = data.getAttribute(“gtbOriginalLang”); var target = data.getAttribute(“gtbTargetLang”); lib.translatePage(orig, target, onProgress);}function onProgress(progress, opt_finished, opt_error) { sendMessage(“gtbTranslateOnProgress”, {“gtbTranslateProgress” : progress, “gtbTranslateFinished” : opt_finished, “gtbTranslateError” : opt_error});}function onRevert() { lib.restore();}})(); (function(){var d=window,e=document;function f(b){var a=e.getElementsByTagName(“head”)[0];a||(a=e.body.parentNode.appendChild(e.createElement(“head”)));a.appendChild(b)}function _loadJs(b){var a=e.createElement(“script”);a.type=”text/javascript”;a.charset=”UTF-8″;a.src=b;f(a)}function _loadCss(b){var a=e.createElement(“link”);a.type=”text/css”;a.rel=”stylesheet”;a.charset=”UTF-8″;a.href=b;f(a)}function _isNS(b){b=b.split(“.”);for(var a=d,c=0;c