 |
 |
||
Links & More
 |
Print version |
Related Links |
|
 |
Site Visits (new version) |
 |
Resources – Overview |
|
Article List – Overview |
Background Links |
|
|
SAP's Design Process |
Customer Visits for Analyzing Work Practice
By Jörg Beringer and Günter Schmidt, SAP AG
This paper is outdated.
Abstract
The method described here emphasizes the individual end users and their actual work vs. the common function-centered approach for software specification. Development teams benefit from getting a detailed overview of end users work practice. Approved instructions on how to conduct the customer visits are given.
(This approach is adapted from Contextual Design as introduced in: Beyer, Hugh and Holtzblatt, Karen: "Contextual Design: Defining Customer-Centered Systems." San Francisco, CA, 1996) / InContext Enterprises)
From experience, we know that in the request specification for a new software product or for a new release of an existing software application the emphasis is on collecting the required functions and additional features. The database design and the inclusion of new functions are therefore the main aspects of the specification phase. Focus on the individual end users and their actual work is easily lost.
Marketing and product management make contact with the customer at the level of IT management. This customer contact usually concentrates on customer requests. Product quality, however, is defined by all aspects of usability, such as learnability, efficiency, flexibility, and the definition of individual requirements, and not only by the functionality.
Learnability and suitability for performing the task are the decisive product characteristics for the end user. If these aspects are restricted, the end user will not be satisfied, and costs will be greatly increased by additional training and support requirements and by less efficient work.
To optimize the usability, it is essential that work practice models focused on the individual work places and user roles of a task be created in addition to business process models.
To extend the application specification to the work practice analysis, we recommend that you adopt a new form of customer visits that is specially adapted to analyzing daily work practice. The procedure is described below.
Partnership Instead of Consulting
The basic principle for the customer visits recommended here is that the customer is an expert in his work and we want to learn by watching him do his daily work. In contrast to the conventional consulting-oriented or implementation-oriented SAP customer visits, the actual or prospective end user, and not the customer's IT management, is the discussion partner.
You should therefore ask the customer whether you might observe work practice in a certain area for half a day by interviewing people working there.
A cross functional team of 3-4 persons from areas such as developers, usability experts, documentation developers and managers should be drawn up for the visit. Prior to the visit, you should agree with the customer on the number of interviewers who will come, and which users may be visited at what time and for how long. Optimally you can observe four users in parallel on one morning.
The objective of the customer visit is to hold an approximately two-hour contextual interview with users performing their daily work in a selected area.
Concrete Data Instead of General Remarks
A contextual interview closely resembles the interviewer simply watching the user and occasionally asking questions like an apprentice. The interviewer asks the user to continue with his normal work and notes down as many details as possible. The interviewer only records things that really happen. It only makes sense to record past work processes if they did not occur longer than two weeks ago and can be verified with concrete documents (artifacts).
Which and How Many Customers Should I Visit?
The first customer visit invariably makes a great impression on developers who never saw their application actually being used or have not seen it in a long time. However, a single visit is not enough to understand the common or different features of work practice within the entire target market.
This requires visiting several customers having different characteristics. To obtain meaningful data from a limited number of customers, the customers and their employees must be selected so that each user role is observed more than once and the spectrum of customers visited covers all important aspects of the potential market.
Since you are only collecting qualitative and not quantitative data, the customers visited need not be statistically representative. The objective is to obtain potential differences. For a complete user/task analysis, you should typically visit about 3-5 customers, interviewing a total of about 10-20 users.
To analyze work practice in an area, you can also visit customers who are working for example with a Legacy System or a manual paper solution at the moment, and who are not already using the software in this area. The organization of the work and the tasks to be performed will not be very different.
Without a Focus You will not See Anything
The effectiveness of the customer visits depends on selecting the right customers and users, using the right interviewing technique, and on the focus with which one observes the users.
When preparing a customer visit, you should therefore discuss in a preparatory meeting which questions are most important and which customers and user profiles should be visited. This focus can be changed or made more precise from one customer visit to the next.
What Should I do with the Data?
A customer visit without debriefing is better than no customer visit, but interpreting and editing the data after the visit provides information that is relevant for the design and that can be passed on to other team members that did not take part in the visit.
The team members participating in the customer visit should therefore describe the interview precisely in a subsequent meeting. New findings, design ideas and questions will occur inadvertently and must be noted down.
The work processes observed at the customer site can be split into the following views and recorded in separate models:
Communication flow: Persons observed and their responsibilities are recorded as network nodes. Every observed communication to another person is entered as a link between two nodes.
Task Sequences: The observed work sequences are recorded step-by-step. The triggering event and the objective of the sequence are recorded.
Relationships: Informal relationships and attitudes to persons, departments, companies and the software are recorded.
Work environment: The physical situation is recorded in a sketch.
Artifacts: Documents used by the customer are collected: forms, reports, notes, screenshots.
You can group these views for all customers after several customer visits. Similar remarks are sorted into groups and identified.
Discussing the customer visits within the team automatically communicates the knowledge acquired about the application area within the development team, including the developer, who only knows the application area indirectly.
What is the Result?
Development teams get a detailed overview of work practice in the target market, especially from the repeated user roles and the communication flow. A list of realistic user scenarios is also created.
These consolidated models for work practice and the findings discussed after the customer visits can be used to create a vision of how the R/3 application can optimally support these users and how the application can be optimally structured for these user roles.
In addition to the functional requirements and the business process model, information is provided about work practice and organization from the view of the user. This greatly simplifies structuring the application to suit the tasks and permits good interface design.
Watching users work in their natural context will automatically give you new design ideas how to optimize work or solve open problems.
Customer visits carried out in this way are also a very effective method of becoming familiar with the market in question and of collecting further product requirements.
