Wizard Style Guide

SAP Wizard Style Guide

Print version (PDF)

Read First!

● What Is a Wizard?
● When Should Wizards Be Used?
● How Is a Wizard Created?
● Creating a Wizard with the Wizard Framework
● Integration of the Wizard in the R/3 System
● Navigation Buttons
● Individual Screens
● The Interim Screens
● Roadmap
● Text Area
● Input Area
● Wizards in Customizing

top

file:///F|/resources/wizard_html/CONTENTS.HTM [08.01.03 16:55:20]

Wizard Style Guide

Read First!

Why Have a Wizard Style Guide?

A wizard is a tool that supports the user in performing a defined task, by leading them through that task step by
step. This tool limits the user’s decision-making freedom by only allowing them to enter a limited range of inputs
and commands themselves.

These guidelines illustrate several areas where wizards can be sensibly used to improve the usability of the SAP
applications. They also introduce a tool for generating wizards, the Wizard Builder.

By publishing this Wizard Style Guide and introducing the Wizard Builder, we hope to standardize the
implementation of the SAP wizards throughout the system.

Who Can Benefit from These Guidelines?

These guidelines are intended both for developers who want to implement or improve a wizard and for other
interested parties who are considering wizards as a potential design solution for their applications.

What Can’t These Guidelines Be Used For?

When a wizard is used as a tutorial, you have to follow certain guidelines that are not explained in this style
guide. The Wizard Builder is not suitable for tutorial purposes either. Functions such as Preview, which are
important for a teaching tool, are not supported in the Wizard Builder.

This guideline can be found in Resources on the SAP Design Guild Website (www.sapdesignguild.org).

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/read_first.htm [08.01.03 16:55:06]

Wizard Style Guide

What Is a Wizard?

Definition

A wizard leads a user through a task step by step. It is a type of help system that - in contrast to an Assistant
(like in Microsoft Word) - has to be called explicitly. In the SAP terminology, only programs with this step-by-step
guidance should be called "wizards".

Screen Areas

Wizards consist of consecutive modal screens.

Each of these screens consists of five areas:

● Titlebar
● Roadmap (a navigation aid between the individual wizard sections)
● Text area
● Input area
● Navigation buttons

file:///F|/resources/wizard_html/what.HTM (1 of 3) [08.01.03 16:55:07]

Wizard Style Guide

Example of a Wizard Screen (Successive Screen in the Wizard Builder)

The Start screen contains an overview of the objective of the wizard.

The Start and End screens are different from the intermediate screens.

The end screen contains a Finish button instead of a Continue button. When you press Finish, a Technical Audit
Report is generated - this is a closing report that

● Summarizes the steps just performed (e.g. by explaining the consequences when the wizard has defined
something in the database)
● Contains additional instructions or offers a preview

file:///F|/resources/wizard_html/what.HTM (2 of 3) [08.01.03 16:55:07]

Wizard Style Guide

Structure of a Wizard

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/what.HTM (3 of 3) [08.01.03 16:55:07]

Wizard Style Guide

When Should Wizards Be Used?

A wizard lets users perform tasks that would otherwise be more complicated and take longer.

Wizards offer

● Simplification when the steps for completing a task are very complex
● Support when expertise is required
● Mental relief when the user has to pay attention to a large number of associated factors (dependencies,
typical generation tasks, etc.)

A wizard accomplishes these goals by

● Dividing the task into just a few logical steps

● Offering the user sensible default values for selection
● Making decisions for the user so they can only perform the task in the order of the specified steps

In many cases, this restriction to the user’s decision-making freedom may come at the expense of efficiency.
Therefore, the wizards should only be used as a supplementary tool, and should NOT replace the actual
program itself.

Technical Requirements

Because wizards force the user to run through a pre-defined sequence of steps, it is essential that you follow
some specific ergonomic criteria. These criteria are the basis for the technical requirements described here.

If you use the Wizard Builder to implement your wizard, you will fulfill many of these ergonomic requirements
automatically, since the Wizard Builder automatically makes certain functions available.

Technical requirement Technical support

The instructions must be clear and the ● Graphical text editor

consequences of each user input must be ● Consistency
apparent. ● Active formulation

The task should only require a reasonable Between 3 and 7 single steps (including the start and end
number of individual steps. screens)

It must be possible for the user to change their Back button

mind. (IMPORTANT: Back means back, not undo - this means the
data is saved and offered for change again when the user
navigates back to the corresponding screen.)

The user must be able to find out at all times

how many steps are still needed and which Roadmap
phase of the program is currently active.

file:///F|/resources/wizard_html/when.HTM (1 of 2) [08.01.03 16:55:08]

Wizard Style Guide

The user must be able to leave the wizard

Cancel button
without changing the data at any time.

At the end of the wizard, the user must know

Summary Screen, Technical Audit Report
what happened and how to continue.

Wizards should have an attractive appearance. Graphics and color

Target Group

The potential areas of user for wizards are dependent on:

● The quality of the task

● The frequency of its use
● The qualifications of its users

Various design options are possible, depending on the expertise level of the target user group. It is important to
know whether the user has the following knowledge:

● User department knowledge

(Example: To understand the term backflush, the user must know about goods movements.)
● General IT knowledge
(Example: An application wizard is intended for users with little IT knowledge. In this case, you should use
radio buttons instead of list boxes.)
● Special program knowledge
(Example: A wizard for creating tab strips in the R/3 System; the target group is developers with system
expertise; the wizard should bundle a task for practical use.)

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/when.HTM (2 of 2) [08.01.03 16:55:08]

 Wizard Style Guide

How Is a Wizard Created?

Basic Principles

The following principles apply to the wizard creation process:

● The user’s decision-making freedom is restricted (he/she can only execute a few instructions).
● The user is not buried in irrelevant information.
● User entries lead to sensible branches that automatically take all dependencies into account. The wizard contains multiple
sequences to react to any feasible scenario (e.g. installing a program on different platforms). Still, the user only sees the sequence
that is relevant for him/her.

Branches Dependent on User Input (Example: International Trip)

Example: You want to book an international trip. Whether or not you need to apply for a visa depends on your
citizenship. Are you a citizen of the destination country? Then the sequence of steps is straight ahead (you don’t need a
visa). If you are a citizen of a different country, you may have to run through a complex sequence, for example, during
which you are asked about the purpose of your visit or your intended length of stay.

file:///F|/resources/wizard_html/how.HTM (1 of 3) [08.01.03 16:55:10]

Wizard Style Guide

Procedure

SAP provides the Wizard Builder tool and the Wizard Framework for creating wizards. The Wizard Builder is available from Release 4.6
onwards by calling transaction SBPT_WB.
The Wizard Framework encompasses various function modules that represent both the individual wizard screens and the navigation
between these screens.

Screen Mode
The generated wizard always runs as a dialog box, never in full-screen mode.

Method

The first and most important step is the task analysis. It provides the template for the wizard steps. You should first consider whether
your application could be designed more user-friendly without needing a wizard. Wizards should not be used as a crutch to compensate
for incorrectly designed transactions.

Procedure Examples

Step 1: Task analysis Purpose: Memory aid

● Purpose: Determine the purpose of the (See example for above diagram "Branching Dependent on User Input")
wizard:
❍ Simplification
❍ Support
❍ Mental relief

● Structure: The task normally contains

several steps and dependencies. Divide the
task or process into individual, logical units.
You can use a graphics tool to model the
structure of your task.

Step 2: Determining the target group Target group: One example of a target group with good IT knowledge is system
Create a profile of the future user group. administrators.
Determine whether the user group has ● List boxes instead of radio buttons (for users with good IT knowledge), or

● User department knowledge ● 1-2 lines more explanation (for users with little user department knowledge)

● General IT knowledge or

● Special program knowledge.

When selecting the GUI controls, make sure you

choose controls that your target group knows
how to use.

Step 3: Prototyping
Create a prototype, either on paper or as an
HTML prototype.
● Formulate the introductory text such that
your target group can comprehend and
implement it without difficulty.
● Minimize the number of screens.
● Avoid branches from the wizard to other
application components.
● Branch in accordance with the input. Do not
confront the user with irrelevant options.

file:///F|/resources/wizard_html/how.HTM (2 of 3) [08.01.03 16:55:10]

Wizard Style Guide

Example of a paper prototype

Step 4:Testing
Test your wizard on real users.
● Make sure the instructions and terminology
are comprehensible.
● If you use screens or diagrams, ask your
colleagues how they interpret them.

(For more information see User Day Toolkit in

the verification section of the Design Guild.)

Step 5: Implementation
Use the Wizard Builder to create the wizard

Step 6: Careful inspection

Verify that you followed all the instructions listed
above while creating your wizard.

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/how.HTM (3 of 3) [08.01.03 16:55:10]

Wizard Style Guide

Creating a Wizard with the Wizard Framework

The Wizard Builder

The Wizard Builder is provided for generating fully executable wizards with the Wizard Framework.

Genesis of the Wizard Builder

Workflow wizards were created to display wizard-like dialog boxes (for Release 3.1G, initially for SAP Business
Workflow) using standardized function modules. Thanks to the pre-defined layout, many wizard functions could
be made available with little effort (or none at all). As such, the wizards were easily definable for the endusers.

This collection of different function modules was expanded to form a Wizard Framework, which serves both to
display the individual wizard screens and to navigate between these screens.

The Wizard Framework standardizes and simplifies the creation of wizards in the R/3 System. The core of the
wizard concept is that every wizard has a similar structure. The dialog windows are generally the same size,
have almost identical structures, and differ from one another only in their contents.

Start Screen of the Wizard Builder

file:///F|/resources/wizard_html/create.HTM (1 of 6) [08.01.03 16:55:12]

Wizard Style Guide

Next Screen of the Wizard Builder: Assign Wizard Name

file:///F|/resources/wizard_html/create.HTM (2 of 6) [08.01.03 16:55:12]

Wizard Style Guide

Third Screen of the Wizard Builder: Define the Steps

file:///F|/resources/wizard_html/create.HTM (3 of 6) [08.01.03 16:55:12]

Wizard Style Guide

Fourth Screen of the Wizard Builder: Refine the Steps

file:///F|/resources/wizard_html/create.HTM (4 of 6) [08.01.03 16:55:12]

Wizard Style Guide

Last Screen of the Wizard Builder: Completing the Wizard, with Title

Implementing the Wizard Concept

The wizard sets up its structure in an internal table and passes it on to the dispatcher module, which controls the
course of the Wizard Framework. Depending on the user input, the dispatcher module calls either the next or the
previous screen (or exits the wizard). Dispatcher modules have been implemented as callback FORM routines,
which themselves call a Wizard Framework module to display the screen. Each wizard screen contains a
roadmap, descriptive text, and navigation buttons. This layout is standardized and is supplied by the Wizard
Framework. The wizard developer only has to implement the dialogs as subscreens.

Using the Wizard Builder

New wizards are created with the Wizard Builder (transaction SBPT_WB). This tool generates a wizard that is
already executable, but does not yet contain any application-specific interactions or dialogs. The wizard
developer has to "fill in" the empty areas, like the documentation and the screens. This "filling in" is also
supported by the Wizard Builder. Although the Wizard Builder has strictly pre-defined interaction and design
options, please be sure to follow the guidelines in the Wizard Style Guide as well.

file:///F|/resources/wizard_html/create.HTM (5 of 6) [08.01.03 16:55:12]

Wizard Style Guide

Integration of the Wizard in the R/3 System

Supplementary Function

Whenever possible, please make the wizard available as a supplement to the actual transaction. Using the
wizard should be voluntary.

Call from the Menubar

Configure two options for calling the wizard:

● Through the menubar, under menu item Extras

● Through the application toolbar, using the wizard symbol

Name of the Wizard Transaction

The wizard transaction is called: [Name]_WIZARD.

Title

The titlebar is constant on every screen, and contains the name of the wizard.

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/integrate.HTM [08.01.03 16:55:13]

Wizard Style Guide

Navigation Buttons

The Wizard Framework supplies the navigation buttons Continue, Back, Cancel, and Finish on every screen by
default. These buttons have been arranged optimally to make the mouse paths as short as possible, should the
user change his/her mind. Therefore, you do not have to worry about arrangement or navigation between the
screens.

Navigation button Properties

Continue Go to the next screen, once all the information has been entered

Back Go back one step

(exception: This button is not active in the start screen)

Cancel Exits the wizard without saving any of the changes made so far

Finish Appears instead of the Continue button in the end screen

The roadmap is an alternative navigation option. In addition to its orientation function (as a map), the user can
use the hyperlinks to go back to steps that have already been processed. Forwards navigation is not supported,
as each successive step in the wizard is dependent on the inputs in the preceding step.

IMPORTANT: When the user presses the Back button or goes back in the roadmap, the user's inputs so far
should not be deleted. The user expects the wizard to make their tasks easier, not create additional problems.
Therefore, the data must always be retained when the user goes back, to enable them to check their previous
inputs at any time.

The linear progression of steps in a task gives the user a sense of security. If the user has to leave this linear
chain to perform actions outside of the wizard, they may become confused. Therefore, avoid any branches that
leave the wizard.

Do not write anything to the database during the wizard steps. This makes it possible for the user to exit the
wizard at any time without having made any changes to the database. The user should explicitly approve any
changes to the database during the last step of the wizard.

Other Pushbuttons in the Navigation Bar

NO other pushbuttons are allowed in the navigation area of the Wizard Builder. All pushbuttons are defined by
the Wizard Framework, and cannot be changed by the wizard developer.

file:///F|/resources/wizard_html/navigbuttons.HTM (1 of 2) [08.01.03 16:55:14]

Wizard Style Guide

NAVIGATION
Do's
Branch after every user input
Make sure that any user changes are written to the database during the last
step of the wizard

Dont's

● DON'T include more than 7 single steps in the wizard

● DON'T include any branches that lead outside the wizard
● DON'T write to the database while the wizard is running

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/navigbuttons.HTM (2 of 2) [08.01.03 16:55:14]

Wizard Style Guide

Individual Screens

Start and End Screens

The first screen of a wizard consists of two areas: the left area consists of a roadmap (answers the questions
Where am I? What should I expect?), while the text in the right area provides an overview of the wizard’s
objective, function, and actions. The Back button is not active in the first screen, and pressing Cancel does not
cause a confirmation prompt to be displayed, since no data has been changed yet.

Example of a Start Screen (Wizard Builder)

The last screen of the wizard contains a summary - the Technical Audit Report. At this point, all the user’s
changes are written to the database. The Continue button is replaced in the end screen with the Finish button.

Make sure that the user knows how to proceed after exiting the wizard, for example, by including an explanation
on the last screen of the wizard.

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/screens.HTM [08.01.03 16:55:15]

Wizard Style Guide

The Interim Screens

Number

The number of interim screens should lie between 1 and 5. In general, two simple screens are preferred to one
complex screen with multiple fields and options. Consider each individual case carefully, however, since the
reverse case - placing two related input fields on two different screens to "keep things simple", for example - may
also annoy the user.

The interim screens also contain

● A navigation part with roadmap

● A text area with instructions or a brief explanation
● An input area for the user data

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/interscreens.HTM [08.01.03 16:55:16]

Wizard Style Guide

Roadmap

Text

The roadmap shows the user where they are, where they just were, and where they will go next. It can also
contain graphics, and can be used to return to the previous screens of the wizard.

Graphics and Screens

In the present Wizard Framework, screens are positioned through the roadmap. This should help make sure that

● The recognition symbol for the wizard is always visible

● The roadmap does not become too long

The screens must be available in GIF format and must be checked in with transaction SMW0. The exact size and
permitted color palette are added here.

The roadmap can contain both diagrams and photos or graphics. The important thing is that the screens help the
user to understand the task, and are tailored to the specific situation. Please omit graphics and screens that only
"look good", but whose benefit in achieving the objective of the wizard is not immediately obvious.

Keep the graphics consistent throughout the different screens: for example, make either all or none of the
graphics three-dimensional. The screens must not contain any texts, as translating them is technically difficult or
impossible.

Please note that every graphic can affect the performance of the wizard flow.

ROADMAP
Do's
Use brief terms in the roadmap
Use meaningful words

Don'ts

● DON'T name the wizard phases "phase1", "phase2", "phase3", etc.

● DON'T use the same words to refer to different terms
● DON'T use text in the screens
● DON'T user any graphics that are larger than 100 KB

top

file:///F|/resources/wizard_html/roadmap.HTM (1 of 2) [08.01.03 16:55:16]

Wizard Style Guide

Text Area

Function

The text area is used to explain the tak that the user has to perform.

Length

Keep the text as brief as possible. The text must fit on one screen, to avoid forcing the user to scroll. Consider
that your text may be longer when translated into other languages.

Formulations

Keep the instructions in a wizard brief and precise. Follow these rules:

● Keep your records brief, clear, and simple

● Address the user directly. Use the imperative, with "you" where applicable (e.g. "Enter the recipient").
● Use active formulations. Passive sentences make it difficult for the user to figure out what they have to do.

Follow the Standards and Guidelines for Writing at SAP in the MLP folder Guidelines/Standards for Information
Development (GUIDELINES), message New Standards and Guidelines. Always have your information developer
look over your texts and revise them as required.

Examples for Formulation Guidelines

Guideline WRONG RIGHT

Use active formulations A selection must be made here. Which ... do you want?

Use positive formulations, avoid double Do not select a plant that does Select a plant from this
negatives not belong to this region region

Avoid subordinate clauses Select a plant, which is specified

Select a plant
below.

Avoid extra words At this time Now

At a later time Later

Avoid insertions and parentheses

(Excerpts from Deutsch fürs Leben, Wolf Schneider, Rowohlt, 1994, ISBN 3-499-19695-6)
Emphasis

You can use different techniques, like bold print, to draw the user’s attention to specific words. But remember:
less is more. Only use bold print to emphasize primary terms.

Colors

Use highlighting and color sparingly. Remember that online literature is read differently than printed materials.

file:///F|/resources/wizard_html/textarea.HTM (1 of 2) [08.01.03 16:55:17]

Wizard Style Guide

TEXT AREA
Do's
Address the user directly
Tell the user what they have to do
Highlight important terms and required fields
Use bullets and numbering sensibly
Use as little text as possible

Don'ts

● DON'T include too many details in your explanations

● DON'T use more than three different colors

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/textarea.HTM (2 of 2) [08.01.03 16:55:17]

Wizard Style Guide

Input Area

The input area is an SAP subscreen, size 11 rows x 62 columns, that you can define with the Screen Painter.
This area is intentionally kept small to prevent complicated controls from being placed in the wizard. Tree
controls or tab strips, for example, should not be used (to avoid leaving the impression that you are "hiding"
something from the user). When arranging the fields, follow the guidelines described in the SAP Usability Style
Guide.

The less is more principle also applies to the input area: the fewer screen elements you use, the more
comprehensible it is for the user. A screen should always contain only the required elements. Therefore, only
include the input fields and labels that are needed by most of the users. Special cases should not arise in a
wizard.

If the user has to choose from a given number of alternatives, the wizard should always display any existing
default values.

INPUT AREA

Do's

Use as few input fields as possible

Keep the text as short as possible
Highlight critical terms
Use bullets and numbering sensibly
Use checkboxes instead of radio buttons
Use list boxes as dialog windows instead of drop-down (or F4 help)
Display as many default values as possible

Dont's

● DON'T crowd the text with too much detail

● DON'T use complex controls like trees or tab strips
● DON'T use more than three different colors
● DON'T install any branches to outside the wizard

Other GUI Elements in the Input Area

Follow the guidelines described in the SAP Style Guide.

file:///F|/resources/wizard_html/input.HTM (1 of 2) [08.01.03 16:55:18]

Wizard Style Guide

Wizards in Customizing

You should only use wizards in customizing when:

● Ongoing settings are involved OR

● The user is technically inexperienced AND the lack of centralized functions will not cause problems during
data distribution (transport, backing up the production system)

Please consider carefully whether the benefits gained from using a wizard - which simplifies maintenance of
selected parameters - outweigh the problems that will arise due to the lack of generic services. Please remember
that the average customizing user is not usually technically inexperienced; they are usually consultants or staff in
the IT department.

When they configure the system, the customer thinks in processes, not in applications. In this context,
customizing - in the furthest sense - is an application in which the processes are configured for all application
areas.

The problems with system configuration lie not so much in setting parameters as in transporting and distributing
the customizing data. To solve these problems, centralized functions like the Cross-System Viewer and the
Transfer Assistant are provided in the centralized, generic tools (transactions SM30/SM34). If such functions
are missing in a customizing transaction, the effort needed to distribute the data and ensure data consistency in
the target system increases. No support is available to the user in case of error. Moreover, inconsistencies can
arise in "application" customizing with regard to use and functionality.

The customer expects the customizing screens to be as homogenous as possible. Therefore:

● All transactions in the user interface should be uniform

● All the services required to configure and distribute customizing data must be available in all customizing
activities

These requirements can be easily met when developing customizing transactions: simply use the central
customizing tools (transactions SM30/SM34).

Therefore, all individual transactions - including the wizards - must offer these services:

● The existing services from the central tools should also be available in the individual customizing
transactions.
● New services must continually be added.

Existing Services
● Links to:
❍ The Transport and Correction System

❍ The Cross-System Viewer

The Cross-System Viewer is responsible for comparing the customizing settings with the IMG activity.
❍ The Transfer Assistant

Customers can use the Transfer Assistant to transfer their verified customizing settings into the target
system. In the process, all checks are performed in the customizing transaction just like they would be in
dialog. This guarantees the consistency of the data environment
❍ The application log

Changes to customizing activities are logged in the database. The display of these changes corresponds
to the data structure of the IMG activity.

file:///F|/resources/wizard_html/customizing.HTM (1 of 2) [08.01.03 16:55:19]

Wizard Style Guide

❍ The Text Control when called from customizing for simultaneous memo and parameter maintenance.

● Displaying and activating Business Configuration Sets

This gives the customer an option to use the sample settings supplied by SAP. In the process, all the checks
from the dialog configuration activity are taken into account.

Planned Services
● Distributed customizing
● Organizational criteria for the authorization check

top

Source: SAP Wizard Style Guide

file:///F|/resources/wizard_html/customizing.HTM (2 of 2) [08.01.03 16:55:19]