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.
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:
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.
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.