Copyright Chris Johnson, 1999.

Human Computer Interface Design Using Java

Exercise 1: Requirements, Prototyping & Formative Evaluation

A. Introduction

This exercise introduces some of the problems that arise during the development of human computer interfaces. In particular, it focusses on the problems of developing interfaces that must support frequent, expert users. It also introduces the difficulties of obtaining formative feedback during interface development.

You should work in small groups of less than five people. Please form into teams as quickly as possible because there is a lot of work to cover in this practical.

This work is not formally assessed as part of this course. However, it does introduce techniques that you will be expected to use during the assessment exercises associated with this course.

B. The Web Bookstore Scenario

You have been asked by to design the user interface to their new web-based, book ordering service. The owners of this web site envisage a number of different task that their users will want to perform with this application:
  1. Browsing search. The user must be able to explore a number of general categories to look for books whose titles and authors they do not yet know about. These categories might include books on cooking, sport, travel etc. However, it is difficult to determine all of the categories that will be required by the users of this new service.

  2. Directed search It is essential that the user be able to issue requests for the details of books that they know about. For example, it should be possible to list the author, publisher and date of publication for a book with a particular title. It should also be possible to list all of the books by any author with a particular name. If time allows, the client would also like more advanced search facilities.

  3. Recommendations The client would like a book recommendation service that alerts the user to books that are similar to the one that they are currently looking at. It is important that this recommendation service should not distract the user from their current activity, on the other hand, this is a form of adevertising and the clients are concerned to sell as many books as possible.

  4. Ordering Finally, it must be as easy as possible for the customer to order a book (or books) once they have made their selection. You do not have to worry about the details of paying for the book as this will be handled by the electronic payment scheme described under Internet shopping on or shopsmart on

This initial list of task requirements is complicated by the fact that the clients have envisaged two different types of users for their new web site. These can be characterised as:

  1. Infrequent novices. These users will have to be guided through every step of the tasks described in the previous paragraph. You CAN assume that they are familliar with the basics of how to use a web browser. You CANNOT assume that they are familliar with the problems of using web-based search engines. They are liable to make many mistakes and they will need to be helped in these circumstances. They are likely to be particularly nervous that they may have to pay for a book that they do not want.

  2. Frequent experts These users will order almost all of their books through your new service. They will want to perform frequent tasks, such as a directed search by title, as fast as possible. They will also want to be able to perform more complex queries than the novice, infrequent users.
The previous paragraphs have briefly introduced the requirements for the new web site. The list is incomplete - some of the information that you would need to build a usable and useful system has not been provided by the clients. Even worse, you do not have time to fulfill all of the requirements that the client has identified. Sadly, this is exactly the situation that you will be faced with in most real world design tasks. The first task in this practical is to prioritise and clarify the information that you have been given.

C. Your Tasks

This section describes the activities that you should try to complete in this practical. Time is limited and it is important that you get onto the prototype evaluation at the end of the exercise so press on as fact as you can.

Task 1: Requirements Analysis (20 minutes)
Go through the previous paragraphs trying to prioritise the user interface requirements. Tasks which must be supported could be assigned a higher priority than tasks which should be supported. Similarly, you may wish to prioritise your efforts between either novice or expert users. In some cases, it will be difficult to draft a list without further information. In practice, you would go back to your clients and users to obtain this information. For now, simply make an assumption and proceed as best you can.

You should agree a list of priorities as a team and write them down. As before, you would normally check to see whether or not your client (and potential users) agreed with the priorities that you have established. There isn't enough time to do this in the present execise.

This task should illustrate some of the conflicts that arise during interface development. How can we support a range of expert and novice tasks with limited resources of time and money? Is it possible to prioritise our efforts when there is a minimum set of core functionality that must be supported? It is less easy to illustrate some of the other organisational problems that arise during requirements elicitation. For example, different people within the client company may have very different ideas about what the system must do. Finance departments can think very differently about the level of investment that may be necessary to support the user group's activities etc.

Task 2: Pencil and Paper Prototypes (1 hour)
You should now try to design the initial page of the web site. Remember that for a commercial application, the visual impact and style of the page must be balanced against the usability concerns that were identified in the previous task. For example, packing a screen with animated icons can have a high visual impact but, over time, can be both confusing and annoying for some users.

Use a piece of paper to sketch what the user will see when they first access the web site. Then draw further screens to show what a novice or expert will see as they perform one of the high priority tasks that was identified in task 1. In particular, you should be careful to indicate what areas of the screen will remain the same and what areas will change as the user navigates through your site. Hint: if you decide to rely on browser facilities, what functions can you assume will be common to Netscape, Microsoft, etc?

This exercise should illustrate some of the strenths and weaknesses of pencil and paper prototypes. They enable designers to quickly rough-out their ideas in a visual format. They can be shown to other people and feedback is quickly obtained. This is especially important when compared to other forms of rapid application development (RAD). Designers can be very reluctant to throw-away their prototypes in response to users' comments if it has taken them a long time to build the initial mock-ups. Throwing away a prototype would "waste" the time that they have already spent on the design. In contrast, pencil and paper mock-ups help to minise the designers time investment. This encourages people to throw away a poor design in response to the input of other designers or users.

The exercise should also illustrate the limitations of low-fidelity prototypes. They provide a very poor impression of the look and feel of the final system. This can bias feedback which may focus on the limitations of the pencil and paper medium rather than the design itself; "This looks nothing like any web site I've ever used". This lack of fidelity works in both directions; pencil and paper prototypes will look less professional than the final systems but they will also avoid some of the problems suffered by an eventual implementation. For instance, it is difficult to simulate the delays that can arise when users access popular web sites.

Task 3: Cooperative Evaluation (30 minutes)
You now need to obtain formative feedback on the usability of your design. This type of evaluation helpos you to form your design ideas, hence the term "formative". We will be using a version of a technique known as cooperative evaluation.

The first stage in this approach is to identify a task that the user will perform with the prototype. This is important because you cannot simply ask the user "what do you think?". The results from such qualitative questions will be biased in one of two ways. The first problem might be that the user doesnt want to offend/alienate the designers. They may fear that their job is at stake. Conversely, users might be unreasonably antagonistic towards your initial design. People with experience in using an existing system may be reluctant to support any change to current practices. By identifying a task, you can avoid some of these biases. You are not seeking to find out the users opinion but whether or not they can use the system to accomplish a specified goal.

The second step of cooperative evaluation is to identify the user population that will help with the evaluation. In this case, your potential users are quite limited. It would not be sensible to use people who were involved in the design process because it can be VERY hard to spot usability problems in something that you have built yourself. Otherwsie you would have changed them in the first place? For the purposes of this exercise, you should get a member of one of the other groups to be your test-user. This implies that some members of your group will also have to help as the users for some of the other groups.

The final stage in the evaluation is to run the test. You ask the user to perform the task that you identified. They should be encouraged to "think out loud". This is important because a user may be very unsure about how to use your interface, they may then guess correctly and there would have been nothing for you to see that the user really didnt know what they were doing. If they talk to you during the evaluation then you may get some indication about any potential problems. The aim is for the evaluator to talk as little as possible. If you have to intervene to help then you should note down the situation where the problem arose. This will then form the focus of a subsequent redesign.

You should repeat the testing for three users and note down any different usability problems observed during each subsequent evaluation. Hint: it is likely that you will see very few really bad usability problems because your users will already be familliar with the tasks that your system is intended to support. They will also be atypical in their level of skill and expertise in computer use.

D. Summary

This exercise provided a brief introduction to the problems of designing a human computer interface. It is very important that you replicate some of these design activities during the assessed exercise for this course. It may look as though the focus for this will be on the implementation of an interactive system using the Java libraries. Do not be fooled. Most of the marks will be for the design and evaluation activites that were introduced in this exercise.

Back to the main index...