Archive - Edition 7: Composite Applications

back To Overview of Composite Applications Edition

Introduction

Leading and General Articles

Theoretical Foundations

Designing xApps, Examples of SAP xApps

 

Prototype-based xApps Design Process

By Michael Hatscher, XDG, SAP AG – 10/20/2003

Abstract

In the following text, I describe the prototype-based design methodology used by SAP's xApps Design Group. I explain the prototype development life cycle, discuss the advantages and disadvantages of different prototypes and prototyping materials, and illustrate how the prototype approach fits into SAP's xApps software development life cycle.

 

Who is XDG?

SAP's xApps Design Group (XDG) is a central, cross continental, shared-services group with offices in Walldorf, Germany, and Palo Alto, California, U.S. XDG supports the xApps product teams in requirements analysis, interaction design, and visual design. The group also works on cross-xApps topics such as design methodologies and user interface patterns for development departments and xApp partners.

 

The XDG Design Process

The XDG design process combines different requirement gathering and interaction design methodologies. Early prototypes make it easier to visualize ideas. Involving pilot customers in the design process helps ensure that xApps optimally support customer processes. Close collaboration with product management (PM) and development teams during later design stages means that designs are realistically defined. We include product management and development teams in methods for usability evaluation toward the end of the design development cycle. These are mostly usability tests, but also include cognitive walkthroughs at the customer's site or at vendor fairs (see, for example, Nielsen, 1993). For these activities, we use prototypes with different degrees of fidelity: paper prototypes, wire frames, high-fidelity PowerPoint-based prototypes, HTML prototypes, and functional prototypes.

 

Why Prototypes?

Prototypes are illustrations of the screens of (future) applications that help communicate the look (and, to a limited extent, the feel) of the planned application, its product concept, its functionality, its scope, and its screen flow – both to internal and external customers. They can be made using all kinds of materials and range in fidelity from rough pencil sketches ("lo-fi prototypes") to "real" user interfaces ("hi-fi prototypes") done in the technology that will be used for the final development.

Prototypes are a great means of communication. For example, they can help foster and focus discussions by offering participants a visual representation of what they are talking about. This in turn helps participants to understand open issues and to come up with viable solutions. Different groups of people work together to build the prototypes, which serve different purposes for different people:

Prototypes can be built using various materials – from paper to visual tools (such as Microsoft PowerPoint, Adobe Illustrator, or Flash) to code (such as HTML, Visual Basic, MacOS X's Interface Builder). Each method has its advantages and disadvantages. In brief, low-fidelity prototypes (created, for example, using paper, PowerPoint, or Illustrator) are great for conveying ideas and seem to invite users to suggest more changes. High-fidelity prototypes seem to better communicate the planned look and feel of the final product but also to intimidate users: The quality of these prototypes leads users to believe that development has progressed beyond the point where changes can be made without undue effort. Our prototypes evolve over time from lo-fi to hi-fi prototypes, which in the end mirror the final product as closely as possible.

 

Prototype Process

The following paragraphs briefly describe the prototype process as part of the overall XDG design approach. Please bear in mind that xApps are not enhancements or re-developments of existing applications, but rather new applications for which no customer data has been collected.

Basic Scoping and First Demo

First of all a very rough "prototype of a prototype" is built. It consists of paper and pencil sketches that detail isolated product features, possible screen flows, or User Environment Designs (see Contextual Design). This prototype serves to create a common understanding of what the planned application is supposed to do. Product Management and XDG work on this task as a team, envisioning the future application together.

First paper and pencil sketch

Figure 1: First paper and pencil sketch

The first sketches eventually develop into low-fidelity prototypes in Microsoft PowerPoint or Adobe Illustrator (depending on the designer's preference), which illustrate screen element layout, screen flows, functions, and widgets. At this point, it is possible to imagine how the first version of the product will look, but, as there is no customer data at this point, we have to rely on guesses of what customers want and how to structure the information.

The prototype is then turned into a demo product using HTML, WebDynpro, or a related front-end technology. The demo can be presented to customers and used to gather feedback and create product awareness in the market. These presentations may help win pilot customers.

Design Verification through Iterations

After analyzing feedback collected by product management, we return to the workbench and re-think the whole application: Did it fit the customer's business needs? Did it properly address pain points? Did it match their processes or introduce improved ones? Pilot customers support us a lot during this phase; their input is invaluable in verifying users' needs and in creating designs that are both usable and fit into the work context. Contextual Design techniques (contextual interviews, sequential and flow models, affinity notes, and wall walking) help us understand what really matters in the users' work practice and what needs to be addressed to create a practical and attractive solution. Insights gained during our contextual inquiry greatly influence the prototype's design and the application's structure.

An advanced version of the prototype (with all the requested changes built in) is tested at the customer's site with potential future end-users using different approaches: usability tests, focus groups, and pluralistic cognitive or heuristic walk-through (see Nielsen, 1993). Again, our findings are incorporated into improved versions of the prototype.

Different prototypes are employed as well: In one project, we used a hand-built paper prototype crafted out of Post-it® notes. All buttons were painted on the Post-it® notes and could be moved freely by the test users. (The participants were able to move all the screen elements around on the screen, re-arranging the screen layout and elements to better suit their needs. Our test participants liked the paper prototype: They enjoyed seeing the widgets done in paper and being able to interact very actively with them. However, they did not show any interest in actively participating in the application design. This may have been due to how we interacted with them. Nevertheless, in the end, the time and work invested in building the paper prototype did not pay off.) We also conducted parallel usability tests using our PowerPoint-based prototype. In this case, the different testing material did not seem to have a major impact on the results.

An iterative approach is central to XDG's prototyping methodology: We improve the prototype based on user feedback, heightening its fidelity with each round (through integrating screenshot fragments or coding the prototype in HTML). After conducting usability activities and gathering feedback, we go back to incorporate new findings into the prototype. XDG-internal discussions and consolidation efforts help give the xApps a common look and feel, and help us come up with cross-xApp design guidelines and rationales. Screenshots from the prototypes can be used to illustrate the internal design documentation.

After a couple of rounds we can stabilize the design. It then becomes the basis for writing a specification document. This document is used for development purposes. It serves as the blueprint of the application's user interface.

Alan Cooper (1999) speaks of the "scar tissue" that is created when a prototype is used for later development purposes rather than just for illustrating the idea. We are able to circumvent this problem by separating of prototype technology (Microsoft PowerPoint, HTML, Adobe Illustrator) from product technology (HTML-B, WebDynpro): Prototype material cannot be used for development purposes. After all, the material is only intended as a visual aid.

Development Support

Issues that surface during development are discussed and resolved within the triad of product management, development, and XDG. We illustrate possible solutions in the prototype. User interface-related decisions are built into the prototype (and into the specification) as well. This way there is always a design foundation to build the actual application from, and the whole development team has a (visual) basis for discussion. This reduces fruitless discussions on imagined user interfaces, helps identify unresolved issues (there are always a lot), and thus decreases the degrees of freedom for development. Hopefully, in the end all areas in the user interface will have been addressed and developers will not have to rush to come up with a solution by themselves.

Planning Ahead

There comes a point in the development life cycle where delivery time has become too short to consider further design suggestions. Now the prototype turns from a living design specification (which is always on par with application planning and development) to a product vision document. It shows how we envision the next version of the application will look and work. This enables us to save time for the next release and – at least internally – to begin discussing and consolidating future designs.

 

Conclusion

We have found our prototyping approach very worthwhile. The prototypes can be used for different purposes during their life cycle (for example, product marketing, usability tests, or identification and clarification of open issues). They act as a living design spec and reduce fruitless debates by delivering a visual foundation for discussion. The prototyping process is highly interrelated with development and product management activities, and the exchange of information between these teams results in many changes to the prototype. The prototype thus functions as a constantly up-to-date visualization of the upcoming application.

 

References

Beyer, H. & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. San Francisco, CA: Morgan Kaufmann Publishers.

Calde, S. & Cooper, A. (2000). Cooper Interaction Design enjoys SAP. SAP Design Guild, Philosophy Edition. Last viewed 1 August 2003.

Cooper, A. (1999). The Inmates are Running the Asylum: Why High-Tech Products drive us Crazy and how to restore the Sanity. Indianapolis, IN: SAMS.

Holtzblatt, K. (2000). Contextual Design at SAP. SAP Design Guild, Philosophy Edition. Last viewed 1 August 2003.

Nielsen, J. (1993). Usability Engineering. San Francisco, CA: Morgan Kaufmann Publishers.

 

top top