MikePadgett.com

Usability testing with web prototypes: an overview

Source: Wikimedia Commons

This article is intended for technology professionals new to usability testing programmes and prototyping.

In the broadest terms, usability testing seeks to place proposed elements of a user experience in front of participants in order to:

1. Measure and evaluate a particular aspect or collection of aspects of use;
2. Discover new, sometimes unforeseen issues, problems or requirements;
3. Limit and manage project risks and resources.

Usability testing versus other types of testing

Usability testing should be strongly distinguished from, for example, user acceptance testing or systems testing, both of which have very different and terms of reference and outcomes. The temptation to mix these processes out of a sense of convenience or perceived harmony should be scrupulously avoided.

Usability testing does not concern itself with defects, bugs or performance any more than how these might damage or otherwise affect the quality of the user experience.

Nor do usability testing programmes follow on from the development process.  Testing should normally be conducted prior to development, since that is when issues should be recognised and risk can be limited, all at the least risk and cost to resources.

The role of test participants

It is common to find a range of different testing methods employed in a usability testing programme. These can be roughly divided into learning or practice methods, in which testers gather information from participants either by discussion or by interaction with user experience objects such as interface or device prototypes.

The participant him-/herself is not the object of the exercise. Useful results are rarely achieved without the participant being completely aware of this fact.

Indeed substituting the word customer for the word user in the classic adage the customer is always right explains the principle precisely. A problem experienced by the participant as a result of his/her user experience almost always translates to a trend of improvement. In this way, problems should be fully recorded rather than explained away!

Dependencies for effective usability testing

The character and effectiveness of a usability testing programme depends squarely on the circumstances of the project into which it is introduced but also on the quality of the variables involved. These variables typically include:

1. Partiality or prior conditioning of participants;
2. Depth and incremental frequency of testing work packages;
3. Analysis and result handling in the project governance.

Key test components

Usability testing usually involves or may even generate certain components, each of which are important to the success of the overall programme.

Objectives

Test designers should identify objectives for the test based on what they consider to be the most important issues to be addressed. Examples might be the flow of navigation or the perception of a particular task.

The measure of innovation within a proposed concept can also influence the objectives of the test programme, especially if the concept seeks to establish some kind of novel user experience pattern.

Any testing programme absolutely requires defined objectives, without which it is otherwise difficult to define the other test components.

Scenario

The scenario consists of preparatory information about the role of the participant and the purpose of the test, together with any other relevant information such as expectations or task descriptions. A simple example might be:

Story so far

You are a university student and you’re planning your next academic year. You are required to enrol online for two extra-faculty modules in the Spring Semester.

Your task

Use the module booking facility to enrol for the two modules “PH101 – Introduction to Philosophy” and “PO102 – Political History Since 1945″ in the faculties of Philosophy and Political Studies respectively.

Use case

As in Business and Systems Analysis, the use case describes a sequence of actions expected to be taken by the participant from a starting point to an endpoint. The general purpose of a use case is to achieve a task, which should already be described in the scenario.

I do not wish to imply that the endpoint is always associated with successful completion, since the test designer might actually intend failure. An example of this latter case might be where the test programme’s goal is to evaluate the quality of error handling.

The image below shows a very simple use case example in which all the possible paths to the endpoint are shown:

The term “use case” is often used interchangeably with “scenario”, though inaccurately so. The latter describes the process of use, whereas the former is concerned with the creation of a viewpoint for that process.

Web prototypes

For the purposes of this article, a web prototype consists of one of the following:

1. A single or collection of paper sheets containing representations of interface elements which, taken together, form the illustrative basis of a use case (the ‘paper prototype’);
2. A single or collection of screen-based views presented in a browser which again, taken together, satisfy the flow of a use case (the ’screen prototype’).

In a paper prototype test, the test subject interacts with the paper sheets, progressing through a pre-defined use case. In the latter example, the same occurs onscreen with the usual methods of interaction peculiar to that medium.

The value of prototypes

Prototypes are cheap to create and easy to manage. Success criteria can be measured without great expenditure of resources.

Just as in industrial design, prototypes enable designers to mock-up and user experience professionals to try out a concept, object, or process before major investment in design or development.

Furthermore, since the prototype is simplified to its basic elements, the test process better targets basic objectives without distracting participants with other, specious concerns.

Paper prototypes

A paper prototype is produced with every iteration of a rapid iterative design process. The prototype represents the elements of a user interface drawn to the minimum of detail required to communicate  patterns or concepts clearly to the target audience.

The participant is invited to navigate a paper prototype as they might onscreen. Instead of a mouse pointer, the participant interacts with a pencil.  Interactions are managed using additional paper elements, new pages are replicated by new sheets of paper.

The prototype will be hand- or computer-drawn and should not normally include any rich graphical objects . The purpose of this approach is to remove any subjective notions or judgements about the prototype, thereby avoiding any confusion accidental or otherwise between purely visual design and usability.

Care must also be taken to ensure visual consistency. This is particularly important when using paper sheets that were originally computer-drawn and then printed.

Similarly, even though some representations do not lend themselves to the dimensions of a single page, all sheets must nevertheless retain the same scale and that might mean joining pieces of paper together.

Screen prototypes

Just as with the paper version, the screen-based prototype must maintain consistency and avoid any superfluous graphical detail.

The interaction between the user and the interface should try to maintain fidelity to the experience of the medium. In a web browser, this translates to the requirement that browser functionality including scrollbars and software-level navigation should always be retained.

An example of a screen-based prototype is shown below:

Choosing between paper and screen prototypes

Which type is appropriate for a test programme depends first and foremost on the resources and processes available to the project.

Though consistency and fidelity to a real user experience is usually easier to maintain with screen prototypes, they can be more difficult to maintain than paper prototypes throughout a rapid iterative design process.