| Print version | |
Related Links |
|
| Interaction Design Sessions (new version) | |
| Resources – Overview | |
| Article List – Overview | |
Background Links |
|
| What is the SAP Design Guild? | |
By Margarete Fuss, SAP AG, Usability Engineering Center
This paper is outdated.
Abstract
The aim of interaction design sessions is to design software products that help users carry out their tasks as efficiently as possible. Taking accurate user- and task-data as a starting point, a methodology is applied step by step to develop a user interface and an initial prototype.
In interaction design sessions, user interface designers, development teams and other application experts create draft versions of the user interface. User interface designers have considerable know-how about how people process information and what conclusions can be drawn for software design. Development teams understand the functional requirements and the technical background of their application. Combining this expertise in the early stages of the design process is the best prerequisite for producing a people-oriented user interface.
Only users can judge whether the application system is also adapted to their special requirements and daily tasks. For this reason users should be involved in the overall development process as frequently as possible (for example, through site visits and user days). Interaction design sessions cannot replace customer feedback, however they provide necessary additional input.
The methodology of the design sessions is based on the user- and task-data previously gathered and consolidated. It uses this data to systematically produce a suitable interaction structure and draft versions of the user interface.
Table 1 provides a list of who should participate in an Interaction Design Session:
|
Person
|
Function
|
|---|---|
| User interface designer I | Coordinates and chairs the design session. Provides usability expertise. |
| Application development team | Describes and presents the subject of the design session. Provides application expertise and user- and task-data. Implements the solutions found. |
| User interface designer II | Provides usability expertise |
At least one of the following
people from the same department:
|
Provide application expertise and user requirements |
Table 1: Participants in an Interaction Design Session
During a preparatory discussion, the user interface designer I and the application development team plan how to proceed. They decide on the application area, the participants, the date and duration of the meeting.
The stage of development and any activities that have been carried out so far in the user-centered development process (brainstorming user/task, site visits, user days etc.) are recorded. The user interface designer finds out which materials were gathered during these activities that are therefore available for use in the design session.
The user interface designer explains how the existing materials need to be processed, and lists the information that the development team still needs to gather during the preparatory phase. They discuss which information should be sent to the participants in advance and decide on a date for sending the information.
The application developers compile documentation that describes the subject being discussed in the design session. For the most part, this documentation contains the results of activities in the user-centered development process. If the development team has already started creating a user interface, the documentation may include prototypes, interaction structure diagrams, and so on.
|
Source
|
Results
|
|---|---|
| Site Visits | User roles (e.g., flow model) Work scenarios (e.g., sequence model) Comments (general observations, usability problems, design ideas) Possibly: personas |
| Brainstorming user/task | User roles Work scenarios |
| Review or user Day | Usability problems Design ideas |
| Previous design activities | New work scenario Interaction structure Prototype |
| Previous implementation activities (continued development of an existing product) | Most recent program version of the application |
Table 2: Starting Points for a Design-Session
During the preparation phase, participants must also determine if the project entails designing a new application or redesign/minor changes to an existing application. If redesigning or making changes to an existing application, participants must have access to the application.
The other participants prepare themselves using the documents and develop initial ideas for a solution.
At the beginning of the design session, the development team presents the user roles and their tasks and work scenarios. The participants discuss the comments from the site visits.
If the application is to be completely redesigned and redeveloped, and there is already a new work scenario, interaction structure and/or prototype, the development team presents these as well. Then all the participants analyze and improve or supplement the presented material.
If there were no previous design activities, the participants develop a new work scenario (vision and storyboards) and interaction structure. The user interface designer I then explains how to create a paper prototype. The participants produce a paper prototype and test it using the new work scenario.
If an application is not being completely changed, but has some serious usability problems, the development team presents the problems. The participants then find alternative design options for each problem.
If the draft versions present certain technical requirements, the user interface designer I records these and later forwards them to the appropriate people.
Finally the participants evaluate the results and record the most important results. The material produced is compiled and participants decide how to proceed. For example, additional design sessions may be necessary, or users may need to test a prototype during user days.
The results of a design session are:
The following section describes the resources required by the development teams. It lists the different objectives of interaction design sessions.
The following assumptions are made for resource estimation:
For very small or very complex applications you may need to increase or decrease the number of man-days accordingly.
|
Design Session Objective
|
Resources (MD*)
|
|---|---|
| New design | 21 |
New work scenario: |
6 3 |
Interaction structure: |
|
Paper prototype: |
|
| Processing known usability problems in an application | 3 |
Testing the design of an existing
application
|
9 3 |
*Man-days
For more information on interaction design sessions or workshops, contact the user interface designer for your application.