Previous Table of Contents Next


The analysis of the questionnaire identified three user categories: test program developer, tester (as shown in the inset above), and support person. The user categories were created based on their work title, their description of their work, the tools they were using, and knowledge of the customer organization. Further analysis, after performing a number of user interviews, led us to eliminate one of the user categories, support person. The category of “tester” was split into two separate categories: system tester and function tester. The work tasks of these two categories were found to have different characteristics, which imposed some conflicting requirements on the system.

4.3. TASK ANALYSIS

Based on the user profiling, the usability team selects representative users from each category and they are asked to participate in an interview, including a task analysis session. The purpose of the interview is to identify all relevant work tasks and to study how the users perform them currently. The interviews are conducted at the workplace of the users, allowing interviewers to observe the users performing their present tasks and to capture the atmosphere of the workplace.

The observations of the users performing their tasks allow interviewers to capture the physical environment in which the work is carried out and to verify the descriptions from the interviews. The users often forget details regarding their tasks, especially when it comes to the information that is needed to perform it. In one case a user pulled down a binder, looked up something, and then returned it without a comment. Afterwards he was not able to recall what information he had accessed during the task. Spending more time at the workplace would increase the interviewers’ understanding of the work climate, but usually there is little time to study this in detail.

During the interview, the user describes his or her work situation and tasks. The interviewers will try to capture the tasks in an activity graph (see Figure 7.2) which describes the user’s tasks and environment. The activity graphs method of taking notes is described in a Swedish book Verksamhetsutveckla datorsystem (Enterprise Development of Computer Systems) by Goldkuhl (1993). To verify that the information in the graphs is correct and complete, the interviewers “play back” the description of the tasks to the user. This means that the interviewer describes the work tasks to the user as they are described in the activity graphs. It allows the user to listen and concentrate on correcting the description and adding missing information.


Figure 7.2  An activity graph showing part of the taks of a tester.

Eight future users of TSS 2000 were selected for interviews based on the questionnaire or after being suggested by key contacts within the customer organization. The users represented all the categories and the user characteristics found by the questionnaire. Each interview lasted approximately 2 hours and resulted in activity graphs, updated user profiles and general notes on the design of the future system.

The user interviews of the TSS 2000 project were conducted at the users’ workplace. The actual interviews were conducted in an ordinary conference room, but the visit also included a guided tour of the facilities and an opportunity to observe the users performing their tasks. During the tour we also met and talked to other users that were not scheduled for the interviews. They were still very eager to tell us about their situation. The users taking part in the interviews had no problem mastering the notation and most of them actively took part in the drawing of the activity graphs. The graphs were a good way for the users to structure their story, and it helped them to recall the information needed to perform the tasks. It was also helpful in keeping the users on track. Some users were primarily interested in giving their opinion on the shortcomings of the current system and their wishes for improvement. Focusing the user on the graph helped to structure and control the interview. The activity graphs drawn in cooperation with the users were later merged into supergraphs representing a consolidated description of all the tasks of a user category.

The usability team also created general descriptions of the work tasks based on the interviews and questionnaires. The tasks of the System and Function Testers are described below:

Work Descriptions:

The System Tester is handed a fairly complex test case from the Test Program Developer, with 5 to 8 test programs and a parameter set that is to be tuned during test execution. The system tests are executed over a long period of time, during which different parameters such as traffic load are constantly changed.

The Function Tester writes the test programs, the test specification and the test instruction himself. The test programs are usually written from scratch. The function test programs are written to test a specific function in the telecom equipment. The Function Tester is not interested in observing the test tool while the test is running unless something goes wrong during the test set-up.

It is important to focus on the work tasks of the users and not to become involved in a discussion about the shortcomings of the current system. The expectations of the users can sometimes lead to difficulties. During a customer satisfaction survey in Japan, the users and customers reported a number of problems to the interviewer, expecting them to be fixed in the next release. Since this was not the focus of the survey, the problems remained in the next release, much to the annoyance of the Japanese customers.


Previous Table of Contents Next