Previous | Table of Contents | Next |
5.1.3. The Design Room
The design room acts as a repository for all usability information that is gathered during the course of the project. We strongly recommend the Design Room approach suggested by Karat and Bennet (1991). In some projects, including this one, we have experienced problems enforcing the sanctuary of the design room. The reasons have varied from No vacancies to I need the relevant information available at my desk.
In the usability study of TSS 2000 we did not use a permanent Design Room for the usability work. Instead the workshop was held at a small conference hotel away from the city. This arrangement allowed us to focus on the work without being disturbed. The walls of conference room were used for posting the background information and new information was constantly being added to the walls.
The moderator was constantly on his feet heading the discussion, moving between the different walls. All conclusions were first sketched on the white board; when the concept started to stabilize it was summarized on a flip chart; finally, when the subject was closed, the paper was moved to the appropriate wall. This way of working allowed the concepts to gradually mature and then be added to the facts and assumptions concerning the users and their tasks or to the emerging design described in the User Environment Diagram.
5.1.4. Walk-Through of the Background Material
When all the background material has been posted on the appropriate walls, the team conducted a walk-through of the information. The walk-through during the TSS 2000 workshop developed into an interview where the moderator interviewed the participants, walking through all the background information that was visible on the walls. This gave all the participants a basic understanding of the facts, with more details available from the system developer and the technical communicator on request. The other participants offered their reflections on the data as they were presented, and relevant comments were added to the user profiles and activity graphs.
The walk-through has several purposes:
The main focus for the walk-through was the user profiles and activity graphs. We had more material visible on the walls (e.g., the design recommendations and screen shots of the old user interface), but time constraints forced us to leave them out of the discussion.
The important characteristics of each user category were summarized an a large paper sheet. For each category we tried to jointly answer questions such as, Who is this user? and What is important to him or her? Together we reassembled the users from the essential information we had collected about them so that they would appear as people we all knew and could relate to.
The activity graphs proved to be the first obstacle of the workshop. The level of detail was simply not sufficient. We needed more details, regarding the actual work, the information needed to perform each activity, and the information that would result from the activities. The system designer and technical communicator who had produced the graphs actually knew much more than was reflected in the graphs. It was simply a matter of extracting the information and having the system architect and the tester verify and supplement the information they had acquired themselves. Once again the moderator acted as an interviewer, leading the discussion and adjusting the level of detail in each graph.
During these discussions we noted several possible improvements to the work process. One user behavior that had been observed was refined by the group into new services for the system. The tests run by the system testers were often tedious and time consuming because of the need to simply wait for things to either break or to conclude in a normal fashion. The tests were often run overnight, but there was no support for this way of working. The test could run for hours before halting or could stop the moment the tester left. In either case the tester needed to be able to specify alternative test paths or what should happen in the test tool when an error occurred.
This rather detailed walk-through compensated for the fact that there were no scenarios prepared in advance. The activity graphs served as a guiding thread and we jointly created scenarios as needed. I would recommend that the design team have prepared scenarios to describe the future work tasks of the user. The scenarios are easier to verify with the users than are some forms of graphical work description.
Previous | Table of Contents | Next |