By Margarete Fuss, SAP AG, Usability Engineering Center – Last changed on 21.06.2002
This paper is outdated.
This article covers the design stage that marks the next step
in the design process after site visits have been conducted and evaluated: It
describes the process of successively deriving an interaction design from the
data.
The following article describes the creating of an interaction design - one
of the most important steps involved in the creation of a user-oriented application
system. This step is taken directly after the collection and analysis of data
in working practice, gathered during site visits. The user interaction design
is derived from this data successively.
The following steps are performed in Interaction Design Sessions:
These steps are described in greater detail later on.
(These steps correspond with the "contextual design" methodology: Beyer, Hugh; Holtzblatt, Karen; Contextual Design; 1998; Morgan Kaufmann Publishers, Inc., San Francisco, California)
To draft the user environment you need detailed data on the current working practices in the relevant application area. The more complete and better structured this data can be, the better the user interface will be.
Ideally, site visits should be made before starting the design sessions, and the results consolidated in work models. The "contextual design" methodology (see above) is used to create the models Flow, Sequence, Cultural, Physical and Artifact, as well as the Affinity Diagram (see also the article "Contextual Design at SAP" by Karen Holtzblatt & Hugh Beyer and the "SAP Usability Glossary" in the SAP Design Guild).
If, for pragmatic reasons, it is not possible to carry out site visits, then at least one "brainstorming session" should be held. A "brainstorming session" is used to collect all the knowledge within the company on the application area. Participants at a brainstorming session should therefore be mainly consultants and employees from the sales and marketing departments. They use their shared expertise to create user roles and user scenarios, which then form the basis for interaction design sessions.
"Personas" are also very helpful when creating the interaction design. This form of description developed by Cooper (see Cooper Interaction Design) gives user interface designers and developers a clear design goal. A persona is an archetype that represents the requirements and targets of a certain group of persons that will use the product to be developed.
The successful execution of interaction design sessions relies heavily on choosing the right design team. It is most effective if the same team that participated in the site visits also carries out the design sessions. The start of the design sessions, (i.e. after consolidation of the site visit results), however, is also a good time to include new members in the team. Experts in user interface design are especially useful for providing content. It is also frequently the case that for organizational reasons, not all members of the team can participate throughout the entire process from the site visit to the design phase. In such cases you should also plan to change team members at the point between consolidation of the site visit results and creating a vision.
Ideally, the team should be composed of the following:
In this step a "big picture" of the new working environment is created: a vision tells a story about how the work is carried out in the new environment created by the team.
The vision forms the basis for the concrete design of the new product and is the most important input for the next user interaction design steps. The vision is also just as important for representing the new product to the different target groups:
These groups can use this information to start work in parallel.
Figure 1: Example of a vision
The vision is created by grounded brainstorming by the entire team. To ensure that the newly invented environment perfectly meets the requirements of subsequent users, the team must have full knowledge and practical experience of the existing environment. This step is started with a "wall walk". The team members take a quiet look at all consolidated work models and the affinity diagram. They note down the design ideas on Post-its and stick them to the model.
Figure 2: Example of an affinity diagram
The brainstorming methodology is then used to identify the available technologies.
n these first steps, the team is perfectly prepared to apply the available technologies at the correct points when redesigning the working processes. The next step is therefore brainstorming "hot ideas", (i.e., the ideas that are considered to be the most important are collected on a flipchart).
For every "hot idea", the team invents a story about how the work will be carried out in the new environment. These stories are written up on the flipchart as they are created and the corresponding advantages and disadvantages are defined. The individual visions are combined to create a common vision that eliminates the disadvantages and maximizes the advantages
For this final step a trained moderator is extremely important in order to optimize the team result.
While the vision describes all aspects of the new working practice, it is still much too rough to provide a specification for the new system. For this reason, the team then creates storyboards. These define in detail the new working practices described in the vision and which will form the basis for the new design.
A story board can be compared to a comic, where every image in the storyboard represents an interaction with the system, an interaction with another person or a manual step. User interfaces are only roughly drawn. The important factors here are the overall structure and functions. It is not necessary to go into precise language, the appearance of the icons, or the layout.
Figure 3: Example of a storyboard with Post-its notes collected after the full team discussion
To create the storyboard, the vision is first divided into individual tasks. The team is divided into smaller groups (2 - 4 persons per group), each of which creates a storyboard for a task.
In a group, the participants look at the working models, the affinity diagram and the vision in terms of the task. In this step, the sequence model is of particular importance, because it describes the old working scenario. Therefore it serves as a reference model and is used to check against the storyboard (e.g. for completion or to solve identified problems). The brainstorming methodology is then used to collect alternatives for carrying out the task within the framework of the vision. The ideas are written up and the advantages and disadvantages are collected, if necessary an additional alternative is developed. The group continues developing ideas and subsequently evaluating them until it agrees on which idea is to be used. The group then creates a storyboard for this idea and checks it against the consolidated working model.
Each group then presents its storyboard to the entire group, which then goes over it. Inconsistencies are either solved immediately or in the smaller group.
The user environment represents the structure of the application as it supports the user, independent from the user interface or implementation.
The user environment can be compared with a floor plan. It displays all the rooms contained and the connections between them. It does not, however, describe the colors on the walls, the material from which the doors are made or the floor coverings used. It is the main communication tool for the architect, the customer and the builders.
Figure 4: Floor plan
The user environment divides the system into the separate areas that support concrete work activities. These areas are called focus areas.
Every focus area displays
The user environment provides a structural view of the work. It does not provide sequential processes but it still provides the right functions and objects for every required processing sequence. This represents a much more powerful tool than pure representations of scenarios (e.g. use cases in object-oriented modeling).
Figure 5: User environment for a mail system
Advantages of a User Environment for the Development Team
The team can
Deriving the User Environment from Storyboards
The focus areas are derived from the storyboards bottom-up. A group is formed for every storyboard. The group plays through the storyboard step by step. The group then goes through the following for every step that represents an action with the system:
The user environment created in this way is then carefully checked within the framework of a walkthrough because it will eventually provide the basis for the user environment.
When you have a user environment, the drafting of the user interface is reduced to selecting the type of interaction and the assignment of the suitable interaction elements.
The physical model is used to determine the required platform type and the interaction type (mouse, keyboard, speech recognition,...). When this has been done, you can determine the elements in the user interface for every individual element of the user environment. For a Web application, for example, this could be the following:
The user interface standards (styleguides) and usability principles for the selected platform must also be considered.
Drafting of the user interface is also carried out in groups. Every group is assigned to a related section of the user environment and uses the brainstorming methodology to sketch several alternative drafts. Common determination of the advantages and disadvantages is used to derive the best possible draft and a paper prototype is built.
The groups present their paper prototypes to the entire team and then remove any inconsistencies or problems determined.
A paper prototype represents a user interface with Post-its for windows, pushbuttons, menus… The developers can execute the processes in a paper prototype by simulating the behavior of the computer. During a test, the users carry out their everyday work activities with the system. The actual goal of the paper prototype is achieved when developers and users are working together to redesign the user interface.
Figure 6: Example of a paper prototype
Paper prototypes are useful for the following reasons:Before a user tests the paper prototype, a starting point should be decided upon, from which the user can start to work on the prototype. This is important to guarantee a relevant initial point. Then a scenario from the relevant working practice should be used.
Before the user test, all open points for the preceding steps should be summarized so that the testers bear these in mind when carrying out the test or formulating questions.
Two people are always needed for the test with a paper prototype. One person makes the notes and one carries out the interactions with the paper prototype.
If the test conclusion is that the user had serious problems using the prototype, then an alternative should be developed and tested. If required changes to the prototype affect the user environment, then this must be adapted accordingly.
The final version of the paper prototypes is fixed and, together with the adapted user environment, represents the specification for the new product.