Measures Required to Achieve Objectives

Process Innovation through a User-Oriented Procedure Model

When the EnjoySAP project got under way, the existing usability services such as design sessions, usability reviews and usability testing became more closely coordinated and interlinked. In addition, the new methods that were introduced, such as brainstorming sessions and site visits, provided stronger support in the early phases of the development process. The additional user feedback in its various forms (paper prototypes, discussion groups, workshops, etc.) was provided under the uniform label of "user days" and supported the results of each method from the user’s viewpoint. The feedback during the early stages of development, such as specification and design, was essential because changes could still be made to the user interfaces at this point at a relatively reasonable cost. Overall, a mix of expert-oriented and user-oriented methods had to be offered and applied phase-specifically over the course of the entire development process (see Figure 1).

The design of the user interfaces and the working environment became the central focus in the development departments. When the process began, the fact that the managing board had set the course helped the development departments to apply the methods suggested openly without feeling obliged to deliver new functionality. The methods were thus given the opportunity to prove their effectiveness.

In particular, time was available for site visits to customers in order to observe users in action and bring their requirements to the fore. The procedure model stipulated by the EnjoySAP project team at the beginning of the project provided the development departments with direction. The fact that the procedure model was introduced so early on also allowed the development departments the time they needed to consider these methodological issues when planning their development procedure.

The following methods were suggested as building blocks of the procedure model:

• Brainstorming session. The development team and all those with an interest in the development project (product managers, quality managers, consultants, sales personnel, etc.) met to explicitly make their knowledge available to all using the technique of brainstorming. The brainstorming sessions were an effective preparation for observing users in action. As a result, people received the best possible preparation for conducting an interview with a user. The questions that remained open in the brainstorming sessions were familiar to all participants, and observation could thus be directed, among other things, toward answering these questions.
• Site visits. The purpose of these was to observe users in action going about their everyday tasks in the workplace. In contrast to the experimental usability test, the focus was more on the qualitative aspects of the work, which also involved interrupting users in order to allow the software engineers to clarify what they had observed and ask the user immediately. This combination of observation and open questioning permitted them to gain a full understanding of the user’s work. The many observations and notes of the software engineers were collated and used to produce different
  charts -- work models -- on the basis of "contextual design" [BeyerHoltzblatt et al. 1998]. If new questions cropped up, the software engineers attempted to get the answers from other users in the next round of interviews.
• Design session. The consolidated work models produced as a result of a team effort on the part of the development group could then be filled out to form a draft user interface. This was usually done in a number of design sessions with intermediate steps.
• User days. As a minimum, a user day was staged using the last intermediate result before implementation, a paper prototype. Invited users completed tasks assigned to them using the paper version and gave the software engineers feedback as to what they considered still ought to be improved. The recommendations of the procedure model were that users should be given intermediate results before the paper prototype was produced (in workshops, for example) so that changes and additions could be made in good time.
• Programming. At implementation, the software engineers had test programs available for usability testing (Usability Monitor). These compared the screen design with the rules of the SAP Style Guide, issued messages in the event of deviations and indicated where changes needed to be made. Questions going beyond this on the implementation of the user interface design worked out in design sessions were to be answered by the usability coordinators in ad-hoc consulting sessions. The usability hotline of the UEC established before EnjoySAP was retained and open to the usability coordinators and software engineers so that they could obtain assistance.
• Usability review. This was an inspection method [Nielsen et al. 19943]. Usability experts came across problems when the software was used to perform tasks in realistic situations. On the basis of their design expertise, the usability experts produced solution proposals for these problems. These were discussed in the review session so that at least those proposals that could be easily implemented could lead to improvements before the product was shipped. In addition, synergies developed as a result of what was learned benefited subsequent software development projects.
• Acceptance test. R/3 implementation consultants ubjected the application systems to an intensive test before finally releasing them. Subjective satisfaction with the tested components was investigated in a questionnaire, and the users were asked to indicate where improvements were needed. Since the consultants were not users who used the R/3 applications as tools on a daily basis, this feedback channel was only offered as an option in the required procedure model.

Source:  EnjoySAP - Success Factors