|Resources: Design Process|
|ASUG, SAP, and Usability – Face-to-Face Influence on Development|
|SAP Innovates Usability Testing|
|SAP Developer Network|
By Hendrik Achenbach, SAP AG – November 19, 2004
German Version • This article has also been published in SAP INFO 122
Traditionally, the user interface has been created late in the development process, without taking much of the user's tasks and goals into account. To boost usability and user productivity, SAP's UI First process now brings the user directly into the earliest phases of interface design.
Every software vendor has an interest in creating products that increase the productivity of its customers. In this respect, the user interfaces are of particular significance: Not only can they provide a superior user experience, but they help to reduce the training effort required to master the software and enable users to achieve better results faster.
The reality of software development often gets in the way of creating user interfaces that meet these criteria, because frequently the developers are the ones who both code and design the user interfaces. Alan Cooper argues that this inevitably leads to a conflict of interest that reduces the quality of the product, because "programmers' performance is typically judged by their ability to code efficiently and meet incredibly tight deadlines." 
The problem is complicated by the fact that developers are forced to deal with user interfaces from a very technical point of view because they are the ones who have to make sure that they work. They usually create the user interface only after the underlying technical entities are available. Since the user interface sits on top of functions in the program logic and a database, why not create them early in the process and see what kind of interface will evolve?
This approach inevitably leads to a user interface that mirrors database structures and to a user interaction that is determined by the flow of the program logic. It should be influenced; instead, by the way users act and think.
Even if the developers honestly try to create a usable interface, the technical point of view will still get in the way – after all, you cannot look through two pairs of glasses at the same time.
The solution to this problem lies in distributing the tasks that have to be accomplished to create user interfaces. This is one of the characteristics of UI First – SAP's process for designing user interfaces. Product managers are good at talking to users and judging competitive situations. Developers excel in judging the technical feasibility of design drafts and implementing them. Technical writers are clever at finding words, so they should take care of the user interface texts. User interface designers know how to use the building blocks of user interfaces to create prototypes.
Making use of the full range of these talents, SAP developed 14 process steps which are divided into four phases:
UI First only works as intended when there is continuous teamwork from beginning to end. Developers are not likely to implement a user interface as specified if the prototype and the specification are thrown at them after completion and they have no chance to propose changes. On the other hand, they are likely to see usability testing with prototypes in a new light when they can take part in one of the test sessions. UI First is concerned with the balance between a distribution of tasks and teamwork.
We have seen that UI First relies on a team of people with different project roles (product manager, developer, user interface designer, etc.) The notion of "roles" is equally important to UI First in a second sense: The team members need to be clear on the user role at the very beginning of the design process, because the user role determines which users are chosen to gather user data in the first process step. Based on this data, the team creates a persona (a fictitious, but realistic user) to stand in for this user role and serve as a constant control point when making design decisions.
Although the persona will help the role-project team understand the users, continuous contact with real users is an integral part of UI First. Initial interviewing and observing of users who occupy the role being designed creates extensive data that will serve as the basis for making informed design decisions in the next process steps.
Once the team has come up with a conceptual design of the "role content" (that is, all the applications and information needed to accomplish the user's tasks), it is a good idea to have real users review it. The same applies to the user interface prototypes that are created later in the process.
UI First is focused on designing user interfaces through a collaborative and iterative process. Since there are "natural" boundaries that can get in the way of working with users - tight budgets and tight schedules first and foremost - making this collaboration happen is one of the most challenging aspects of a UI First project.
UI First acknowledges that the users of a software product should be the most important stakeholders in the development process. Other influencing factors may – or even should – have an impact on the design:
These are only a few of the possible reasons for making an "iteration loop" in the design process: The team members go back to a design step where a problematic decision was made and fix it.
A picture of all the possible loops that can occur throughout the process would show nothing but loops, but it is clear that going round and round forever is not possible. Like every other project, a UI First project has a defined beginning and a defined end. However, planning for such a project must take into account that iteration loops will occur and that they are vital to the quality of the project's results.
Observing and interviewing users, collecting application content, describing user scenarios, specifying the interaction between user and interface – when the UI First process goes by the book, a lot of information must be captured. To make sure that none of it gets lost, UI First offers working templates for many of the 14 process steps. They standardize the way the information is recorded, so results can be shared and compared with other project teams. Use of most of the templates is not mandatory, but meant to help the team members record their results in an efficient way.
The obligatory output of the UI First process has been reduced to three things. They support the lifecycle of innovation at SAP:
The Product Innovation Lifecycle (PIL) is one of the building blocks at the core of SAP's business. PIL describes how SAP manages its portfolio of products throughout their entire lifetime, from invention to transition and across multiple releases. During the Invent phase, ideas are rolled in from a market perspective and prioritized. Their requirements are translated into development activities during the Define phase, later assigned to development projects. Following development, products are deployed to the market and optimized, eventually moving through new releases or products.
UI First, as a sub-process for designing user interfaces, is tightly integrated into this life cycle. As mentioned above, the Role Specification and the User Interface Specifications are the final output of the process. These documents in turn become input documents for the Software Requirements Specification – one of the central documents that are created during the definition phase of SAP's Product Innovation Lifecycle.
The idea of placing users at the center of the software design process is not new. Donald A. Norman, "the father of user-centered design," edited a volume on the subject as early as 1986. However, software companies still seem to be rather slow in putting this idea into practice. This may stem from the challenges that a user-centered design process such as UI First poses:
Despite these challenges, user interfaces that increase user productivity permanently – and thus, the return on investment for our customers – can only be created by putting the user first.
 Karen Holtzblatt, Hugh Beyer: Contextual Design: Defining Customer-Centered Systems, 1997