A launchpad is a graphical user interface that's used for tasks that have too many steps or are too complex to fit into a single wizard. The launchpad acts as a central access point for launching a series of related wizards, dialogs, or a combination of both, each of which completes one step of the end-to-end task. Launchpads can also aid novice users by providing a preview of the steps required to complete the task, such as installing a product. Figure 1 shows a picture of a launchpad from the IBM Data Warehouse Center product.
Figure 1: A sample launchpad

When should you use a launchpad?
The main reason for linking wizards or dialogs together via a launchpad is to enhance usability. Some situations in which a launchpad would improve ease-of-use are:
- You have an overly complex wizard. If your original wizard design has too many steps and the user must scroll, then you should break the single wizard into smaller, related ones and tie them together using a launchpad.
- Users need help understanding the task order. Sometimes individual wizards or dialogs are not enough to help the user successfully complete a complicated task. Users may have trouble grasping the "big picture." If users do not understand the order in which wizards should be completed or are having problems finding individual wizards, a launchpad can help tie things together.
- Different users complete different subtasks of the end-to-end task. You may discover that your original task assumptions were incorrect and that in some environments the same end user does not complete all the subtasks of the end-to-end task. For example, at some companies one person may create and monitor objects while at other companies different people would complete each task. A wizard that encompasses the end-to-end task of creating an object and specifying a monitor for that object would not be useful at the second type of company. However, a design that divides the end-to-end task into two separate dialogs -- one for creating the object and one for specifying a monitor -- and clearly links the two dialogs, would accommodate end users at both types of companies.
- You can organize similar functions. Your software might contain a number of wizards or dialogs, which are spread throughout the menu structure and interface, but which users might feel are related. For example, you might create a launchpad to provide access to wizards that create various graphical objects, such as pictures, graphs, and animations. However, the use of launchpads as a basic shortcut mechanism is less common and will not be the focus of this article.
Design recommendations for launchpads
If you decide that a launchpad would help improve the ease of use of your product, you can design an effective one by following a few basic guidelines.
Limit the number of tasks (<10) on a launchpad to ensure that all are visible on screen
Never make the user scroll. If your end-to-end task contains too many steps or wizards to fit on a launchpad, show only the necessary or most common steps. For example, do not include optional or expert tasks on the launchpad. Do not provide shortcuts to all tasks in the software, or the number of options on the launchpad will be overwhelming. You may have to redefine your task structure and provide multiple launchpads, with each one supporting a more limited set of tasks. For example, instead of providing a single launchpad to complete state and federal tax returns, provide two launchpads -- one for federal tax returns and one for state tax returns -- and link them together.
Support a coherent and useful set of tasks from the end user perspective
The launchpad should support a coherent and useful set of tasks based on how your end users think about the task, not based on the software architecture. Work with your end users to understand how they approach the tasks and subtasks, to identify a useful subset of product functions, and to verify that the same end user completes the steps of each subtask. Make sure that the user can complete an entire task without leaving the launchpad.
Launch dialogs as separate windows and return focus to the launchpad after the dialog is completed
You have several options when designing the interaction between your launchpad and dialogs. One option is to launch the dialogs within the same window container as the launchpad, effectively replacing the contents of the launchpad. Another option is to launch the dialogs or wizards as separate windows and to leave the launchpad visible. During recent usability tests at the IBM Silicon Valley lab, participants preferred to have dialogs and wizards launched as separate windows. They felt that this approach helped to enforce a clearer division of where one task ended and the next began.
Use visual cues to denote dependencies between steps
A vertical arrangement implicitly denotes a linear sequence of the tasks from top to bottom, whereas horizontal and multiple column arrangements suggest non-linearity in the tasks. You can use these launchpad arrangements to reflect your task's characteristics. You can also use numbers, indentations, or arrows to visually denote task dependence.
It may be tempting to disable steps whose predecessor tasks are not yet completed or to mark completed tasks with a symbol such as a checkmark. However, these types of cues can be quite complicated to program due to issues of persistence, context, or scope of the launchpad, and recognition of objects. For example, suppose that your launchpad helps users to complete an end-to-end database task. Marking completed steps becomes quite complicated because the interpretation of "complete" can depend upon a number of issues such as:
- What will happen when the computer is turned off -- will the checkmark state be saved?
- If the user has several databases, will you need to save a separate launchpad or launchpad state for each database? For example, can the launchpad for database1 show three completed steps, while the launchpad for database2 shows only one completed step?
- If a user completes a task without using the launchpad, will the launchpad recognize that the necessary prerequisites for a step were completed?
- If a user uses the launchpad to complete each step, but saves the scripts to be run later, will the checkmarks still appear? What do the checkmarks mean in this context? What if a script fails?
If the launchpad tasks are to be completed only once per software installation, in a sequential order, and only through the launchpad, then the launchpad should show information such as task dependencies and progress. However, if your task dependencies are not as stringent, then it may be more usable not to show task dependency and progress information. For example, a travel launchpad may allow the user to make hotel reservations, buy airline tickets, and reserve a rental car. If the launchpad forced the user to make airline reservations first, it would be too stringent. Users may want to make hotel reservations before airline reservations if they are afraid that the hotel may fill up, if they are expecting someone else to make their airline reservations, or if they are trying to coordinate flights with other travelers. For this type of launchpad, you may decide to allow the user to access any task at any time. In this case, your launchpad design can assume that the user knows (or is able to determine) if previous tasks were completed and if they need to be completed.
Participants in our user studies wanted a general sense of progress through the launchpad end-to-end task. They did not care about the exact number of steps across all wizards launched from the launchpad. This type of progress information was considered too low level. To provide this general sense of progress, give a clear visual indication of which wizard is currently being used.
Provide descriptions of each step
Describe each step on the launchpad so that the user knows what to expect before clicking on a step or task. One easy way to do this is to provide descriptions as the user moves the mouse pointer over specific tasks or steps. For example, in Figures 2 and 3 the textual description at the top of the conceptual graphic explains what will happen as the user completes the task. This text changes as the user moves the mouse pointer over each step.
At IBM, the launchpads in our database and data warehousing products contain an interactive, conceptual graphic of the end-to-end task. This graphic changes as the user moves the mouse pointer over the buttons corresponding to each task, to illustrate which objects are utilized in each task. Figures 2 and 3 illustrate how the conceptual graphic appears for different steps. In Figure 2, the objects that will be affected by the second task -- Source, Log, and Change Data Table -- are brightly colored while other objects are faded.
Figure 2: The Source, Log, and Change Data Table are affected during task 2

Figure 3 illustrates the objects that will be affected by the third task. When the user moves the mouse pointer over "Define Subscription," the Change Data Table and Target objects become brightly colored, while the Source and Log objects become faded.
Figure 3: The Change Data Table and Target objects are utilized during task 3

Our usability test participants have provided consistent, positive feedback on the conceptual graphic. Several participants were able to describe the complete process for setting up a complex database task after using that launchpad a single time. Some even claimed that they would use it as a teaching resource for new team members!
Development of a useful conceptual graphic requires many iterations and usability tests to ensure that the correct concepts are being communicated. Guidelines to help begin the process include:
- If you have a large number of tasks, such as 10, do not include a visual representation for each task. Providing a symbol for each task would make the conceptual graphic too cluttered and complicated.
- Use similar visual elements in the launchpad as in the rest or your product. For example, always represent a chart object by using the same icon.
- Use the conceptual graphic to display the relationships among objects affected by the launchpad tasks.
- Make sure that the dominance of visual elements in the conceptual graphic is directly related to their level of functional importance.
- Use color to highlight the active aspects on the conceptual graphic. Ensure that the active and inactive pieces of the graphic are noticeably different.
- Avoid using gray for graphics that are clickable. As with other objects, gray graphics do not appear to be selectable.
- Modify the conceptual graphic so it reflects user input -- this can help the user understand and relate to the material. For example, before the objects are worked on, use generic labels, such as "database" or "table." Then, as the user completes steps using the launchpad, replace these generic labels with the actual object names, such as "human resources database" and "employee table."
Expert users often want to complete tasks more efficiently. To aid these users, add information about how to complete the task without the launchpad (if such methods exist). You can provide this information as a brief description, as a set of graphics that displays the steps needed, or simply as a hypertext link to a more comprehensive help system. This information is also useful if users do not need to complete all the launchpad steps at once. Users might prefer to launch one or two dialogs or wizards from the software product rather than to open the launchpad first and then launch the dialogs/wizards from there.
Give users easy access to the launchpad
Users shouldn't have to search for your launchpad; it should be easy for them to find and access. There are at least three approaches to making your launchpad easy to find. Use one or all of them.
- Automatically launch the launchpad upon starting the product. If your launchpad provides a broad overview of the product and helps the user to understand dependencies among tasks, automatically launch the launchpad upon starting the product. However, give your users the option of not having the launchpad displayed automatically in the future. One way to do this is to add a "Don't show this launchpad the next time the product is started" checkbox to your launchpad.
- Provide access to the launchpad through shortcut menus. If your software has a tree view on the left and a details view on the right, give your users access to the launchpad from the shortcut menus on the relevant objects. If the launchpad applies to the entire product, rather than a limited subset, include the launchpad menu item on the topmost object in the tree view.
- Provide access to the launchpad through a list of wizards or a list of launchpads. If your product lists wizards in its menu bar or Help menu, add your launchpad to these lists or create a similar list of the launchpads found in your product.
If end users are having trouble completing complex tasks with your software, launchpads can enhance its usability. Effective launchpads have a limited yet coherent set of steps and contain features such as step descriptions and conceptual graphics to help users understand relationships among steps.
Learn
- Check out "Crafting a Wizard" by Jodi Bollaert, here on developerWorks.
- Read The Cranky User: Modal dialogs and learn why you want to think twice before restricting user freedom.
- For more on how to design and evaluate wizards and launchpads, pick up a copy of
Designing Effective Wizards: A Multidisciplinary Approach by Daina Pupons Wickham, Debra L. Mayhew, Teresa Stoll, Kenneth June Toley, and Shannon Rouiller (Prentice Hall PTR, 2002).
- Go to the download page for IBM's Data Warehouse Center product (part of DB2 Universal Database), and try out a launchpad to see how it behaves.
- The Alertbox is a bi-weekly column by Dr. Jakob Nielsen on usability-related topics, mostly for the Web (US$2 fee for regular readers).
- IBM's Ease of Use site offers new innovations, user-centered design, guidelines, stories, technologies, and other resources to help improve the total user experience for your products and services.
- Stay current on the latest technology with developerWorks technical events and Webcasts.
- Visit the developerWorks Web Architecture zone for more articles, tutorials, and resources that specialize in Web technologies.
Discuss
- Participate in developerWorks blogs and get involved in the developerWorks community.




