Previous Table of Contents Next


5.1. CONCEPTUAL DESIGN

The goal of the conceptual design is to create a conceptual model of the system that allows the users to concentrate on their work tasks instead of manipulating the system. Initially, this work is carried out on a comprehensive, abstract level, where decisions are made about which services the system should offer and how to present those services in ways that are logical to the users.

There are other important issues in connection with the conceptual design:

  What metaphors can be used to exploit the users’ previous experiences from other areas?
  Which enabling information is needed for the users to be able to actually make use of the services offered?

These general issues are addressed iteratively during “time-outs” in the conceptual design work. At the start of the conceptual design it is very difficult to find good metaphors that support the services, but a good metaphor makes the work of structuring the services much easier. It is the “Catch-22” of conceptual design. The work of finding a metaphor is described in more detail later in this chapter.

5.1.1. The Workshop

The main work during the conceptual design phase is carried out as one or more workshops. The main task of the workshop is to define a structure for the services offered by the system. The background material, consisting of user profiles, activity graphs, scenarios, design recommendations, and a concept list1, is used to cluster related system services, objects, and intentions into focus areas. The focus areas describe the actions a user might perform on relevant objects at a given time. The concept and notation of focus areas are based on the work of Holtzblatt and Beyer (1993).


1The concept list is a collection of user terms and their meaning. It is continually updated during the run of the project.

Because of the large number of aspects that determine if a system is to be usable, the conceptual design tries to reflect as many of these aspects as possible by bringing together individuals with a variety of relevant skills in sketching an overall structure of the user interface. The work at the workshops is very intense, but it is the best way for a group to produce the blueprints for the user interface and to achieve a shared understanding of the users and their work tasks. It works well to run at least two workshops, with each workshop lasting two or three days. The time plan for TSS 2000 only allowed for one 2-day workshop. This allowed time to design a basic service structure, but left very little time to discuss alternative solutions.

5.1.2. Participants in the Workshop

In order to make the workshop and the continued development run smoothly and efficiently, it is important that the participants represent the team that will design, implement, and test both the user interface and the intrinsics of the product. In large design projects it is impossible to have all designers taking part in the workshop, but since there are often several design teams working in parallel it is important to have key representatives present. It is also important to get “buy-in” from the developers who are going to implement the real user interface. The mix of skills also allows a more holistic approach to the design of the user interface by always having people present who know the different areas.

The participants of the case study workshop were

  A moderator
  A system designer
  A technical communicator
  A GUI-prototyper
  A system architect
  A system tester (of TSS 2000)

The workshop is led by a moderator who is responsible for the “flow” of the work, for effective management of discussions, and for keeping the group focused on the work process. In the case of the TSS 2000 workshop, the moderator had limited knowledge of the previous products and the work domain of the users. This proved very productive because it kept discussions from lapsing into unnecessary details. It also forced the participants to describe the tasks and problems of the users in a manner that made it easier to form a conceptual model.

The usability study was jointly led by a system developer and a technical communicator, both of whom were experienced in their respective fields, and also were knowledgeable with the Delta Method. The technical communicator had developed the user manuals for some of the previous tools and was therefore aware of the many difficulties involved in explaining the use the old system. She also provided most of the suggestions on how the user information should be divided among the on-line help, on-line documentation, and the user guide. The system developer had the best knowledge of the current users and their tasks because of having documented the results of the task analyses and the activity graphs earlier.

The GUI-prototyper had not taken part in the user and task analysis and therefore needed to quickly understand the most important aspects of the earlier work so as to effectively implement the computer prototype later in the study. During the later stages of the conceptual design, he could also offer advice on how different concepts could be represented graphically.

The system architect had been one of the driving forces during the development of the current versions of the test tools. He was extremely knowledgeable on the design of the current test tools and on all the technical aspects of the equipment the users test, such as the operating system and communication protocols.

The system tester had long experience of testing and debugging the current version of one of the test tools. Several of these tests were performed at the customer’s work sites in cooperation with the users of the system, so he had developed a good understanding of the characteristics of the users’ tasks and their workplace.


Previous Table of Contents Next