SAP Wizard Style Guide

SAP Wizard Style Guide 

SAP Wizard Style Guide 

Read First! 

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 

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. 

Source: SAP Wizard Style Guide 

file:///F|/resources/wizard_html/index.htm [05.02.02 15:20:57]

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. 


file:///F|/resources/wizard_html/read_first.htm [05.02.02 15:20:58]


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) [05.02.02 15:20:59]


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 



Structure of a Wizard 

top 




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 

consequences of each user input must be 

apparent. 

● 

● 

● 

Graphical text editor 

Consistency 

Active formulation 

The task should only require a reasonable 

number of individual steps. 

It must be possible for the user to change their 

mind. 

DThe user must be able to find out at all times 

how many steps are still needed and which 

phase of the program is currently active. 

Between 3 and 7 single steps (including the start and end 

screens) 

Back button 

(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.) 

Roadmap 

file:///F|/resources/wizard_html/when.HTM (1 of 2) [05.02.02 15:21:00]


The user must be able to leave the wizard 

without changing the data at any time. 

At the end of the wizard, the user must know 

what happened and how to continue. 

Wizards should have an attractive appearance. 

Cancel button 

Summary Screen, Technical Audit Report 

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 


file:///F|/resources/wizard_html/when.HTM (2 of 2) [05.02.02 15:21:00]


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) [05.02.02 15:21:01]


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 

Step 1: Task analysis 

● Purpose: Determine the purpose of the 

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. 

Examples 

Purpose: Memory aid 

(See example for above diagram "Branching Dependent on User Input") 

Step 2: Determining the target group 

Create a profile of the future user group. 

Determine whether the user group has 

● User department knowledge 

● General IT knowledge or 

● Special program knowledge. 

Target group: One example of a target group with good IT knowledge is system 

administrators. 

● List boxes instead of radio buttons (for users with good IT knowledge), or 

● 1-2 lines more explanation (for users with little user department 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. 



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 




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) [05.02.02 15:21:02]


Next Screen of the Wizard Builder: Assign Wizard Name 



Third Screen of the Wizard Builder: Define the Steps 



Fourth Screen of the Wizard Builder: Refine the Steps 



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. 



top 




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 


file:///F|/resources/wizard_html/integrate.HTM [05.02.02 15:21:03]


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 

Back 

Cancel 

Finish 

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

Go back one step 

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

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

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) [05.02.02 15:21:03]


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 


file:///F|/resources/wizard_html/navigbuttons.HTM (2 of 2) [05.02.02 15:21:03]


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 


file:///F|/resources/wizard_html/screens.HTM [05.02.02 15:21:04]


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 


file:///F|/resources/wizard_html/interscreens.HTM [05.02.02 15:21:05]


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) [05.02.02 15:21:05]



file:///F|/resources/wizard_html/roadmap.HTM (2 of 2) [05.02.02 15:21:05]


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 

negatives 

Avoid subordinate clauses 

Do not select a plant that does 

not belong to this region 

Select a plant, which is specified 

below. 

Avoid extra words At this time Now 

At a later time 

Select a plant from this 

region 

Select a plant 

Avoid insertions and parentheses 

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

Emphasis 

Later 

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) [05.02.02 15:21:06]


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 


file:///F|/resources/wizard_html/textarea.HTM (2 of 2) [05.02.02 15:21:06]


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. 

top 

file:///F|/resources/wizard_html/input.HTM (1 of 2) [05.02.02 15:21:06]



file:///F|/resources/wizard_html/input.HTM (2 of 2) [05.02.02 15:21:06]


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) [05.02.02 15:21:07]


● 

❍ 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 


file:///F|/resources/wizard_html/customizing.HTM (2 of 2) [05.02.02 15:21:07]

SAP Wizard Style Guide

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?