Wizards and Guides

“…the seeming simplicity of these structures belies their versatility and broad applicability to a wide range of situations…”

In part one of this article the discussion was one of views, forms, and the manner in which they could be combined into a particular type of task structure known as a hub. The purpose of this installment is to expand on those themes by exploring two other types of task structures commonly employed in web applications. Known as wizards and guides, these additional structures are useful for presenting complex transactions and multipart processes in smaller and more manageable sequences of individual steps.

As shown in Figure 1, all three of these structures—hubs, wizards, and guides—are not only conceptually simple; their basic forms are also easily diagramed and understood. Like many primitive patterns, however, the seeming simplicity of these structures belies their versatility and broad applicability to a wide range of situations, from the simplest consumer applications to the most robust enterprise management tools.

As unlikely as it may seem, taken together, hubs, wizards, and guides comprise the full universe of task flows applicable to web applications and form the basis of all web-based processes and transactions. Although this closely parallels the world of information architecture and its similarly small universe of organizational structures—indexes, webs, and hierarchies—whether such a parallel results from an artificial coincidence, debatable definitions, or some sort of universal truth, is a subject I’ll leave to the comment boards. For now, however, let’s shift the focus to the subject of wizards: what they are and what they can do.

Problem: How to structure rigid procedures
Solution: Wizards

With a predilection for precision and a fondness for exacting input, computers are unavoidably creatures of habit. Try as we might to curb their natural tendencies, disguise their demands, or inject flexibility into their routines, there remain situations that require users to follow specific and prescribed paths in order to complete particular operations or procedures. Such situations call for the task flow known as a wizard.

A staple of desktop applications, wizards are also found in a variety of web-based applications. Essentially predetermined sequences of forms, wizards provide a mechanism for guiding users through complex operations that can be completed in one and only one sequence. One of the most common uses of a wizard, as shown in Figure 2, is found in applications used to reserve limited resources—a seat on an airplane, a ticket to a sporting event, or the increasingly-scarce conference room, for example.

Reservation wizards are a particularly useful case in point because they illustrate, in a concise manner, the defining characteristics of a wizard: a multi-step procedure where the interdependence between steps dictates a specific sequence. That last bit is the crucial part.

Wizards are not simply chains of dialog boxes strung together to make life easier for the user. Rather, they are a particular interface pattern for expressing a precise and rigid procedure that has to unfold in a known and specific sequence. Although wizards can contain any number of required or optional steps, that does not mean users can randomly navigate between those steps.

I know what you’re thinking: “But aren’t there any reservation systems where the user can browse availability without having to frame such a specific request?” Well, such systems do exist, and one example is at the site for British Airways. Shown in Figure 3, the BA design is an interesting and innovative approach because it exposes a significant portion of the fare structure in a clear and concise calendar format rather than leaving the user to fumble around, testing dates for pricing and availability.

There are two important things to note about this example. First, although this design doesn’t necessarily escape the tyranny of the wizard, it does enhance the interaction by recognizing that users will make more satisfying and efficient choices if they are given sufficient information. Second, because this wizard ultimately results in a transaction, it terminates with a page that summarizes the user’s choices and provides the relevant interface elements for either completing the transaction or discarding it and starting over.

Although not the case in this particular situation, wizards can also be used in the context of an operation where a terminating summary view isn’t necessarily relevant. Software installation and image uploading are two such examples of wizard-based operations that don’t terminate in an editable end state. In both cases, although the user specifies various options before initiating the operation, once the operation is underway it cannot be edited or abandoned in the same manner as a transaction. In these cases, rather than a transaction summary, the end state is either an alert confirming the success of the operation, or the return to an appropriate location in the application. A software installer typically terminates with an “All Done” message, for example, while an image upload operation naturally ends by displaying a page containing the uploaded images.

Although wizards are a common feature of the interface landscape, their rigidity clearly runs counter to one of the basic tenets of user-centered design: providing the user with appropriate control over the interaction. Therefore, like the pointy-hat mystics for whom they’re named, wizards should generally be treated with suspicion and skepticism, and ideally avoided whenever possible. Fortunately guides, a third type of task flow, can often be used in place of a wizard.

Problem: How to structure complex transactions and flexible procedures
Solution: Guides

Combining the structured sequence of a wizard with the navigational flexibility of a hub, guides are another type of task flow commonly used in web applications. Unlike wizards, guides do not assume any sort of strict interdependence between steps. As a result, guides can incorporate the navigational flexibility needed for users to access, process, and edit the forms in any order. And unlike hubs, guides also provide the requisite structure and sequencing needed to ensure users can successfully create and manage lengthy or complex transactions.

In the simplest, though admittedly abstract, terms, guides are effectively wizards that terminate in the view page of a hub. This view page allows the user to return to any part of the guide, modify data, and directly return to the terminating page without having to go through any of the intervening steps. Typically, the terminating page of the guide also includes a submit button, enabling the user to indicate that the transaction is complete and ready for processing. One of the most frequent uses of a guide is the checkout process common to ecommerce sites. A case in point can be found at AllLearn.org, an online learning alliance. Like similar processes elsewhere, AllLearn collects billing, shipping, and payment information by logically breaking the task into multiple forms. Unlike the reservation wizard from British Airways, however, there is not a strict requirement affecting either the grouping of the information or the order in which the information is collected. For example, although AllLearn collects the user’s shipping address before their credit card information, that sequencing is by convention rather than necessity. As a result, because the steps are not dependent on one other, once the user has made their initial pass through the steps, they can randomly access and edit any of the previous steps without having to pass back through the entire sequence.

In fact, as shown in Figure 4, the final page of AllLearn’s guide effectively functions as the center of a hub task flow but with the addition of a master submit button that enables the user to finalize the transaction. (For more on the hub task flow, please see part 1 of this article.)

Because so many web applications are designed to facilitate lengthy or complex transactions, the guide’s ability to combine the navigational flexibility of a hub with the simplicity of a wizard renders it an extremely useful and versatile taskflow.

Guidelines for Usage

For designers, proper usage of wizards and guides not only requires an understanding of their relative advantages, disadvantages, and utility, but also an understanding of various conventions and best practices. These include the following:

• Communicate purpose- It’s an obvious point that bears repeating: it is important to not only be clear about how to use a guide or a wizard, but also to be clear on why you’re using it, and to communicate that purpose to the user.
• Minimize the number of steps- One of the more challenging aspects of designing these taskflows is to strike the appropriate balance between too many steps and too many options within any given step. While there’s no golden rule about this balance, suffice it to say that the optimal solution requires a conscious consideration of the tradeoffs.
• Provide an exit path- Guides and wizards are not inescapable hallways; they are rooms. And like all rooms, they should include an accessible door so users can easily get out of them. Of course, if there are consequences to an untimely exit, those consequences should be communicated.
• Limit navigation options- While a wizard or a guide is analogous to a room, we should limit the analogy to a museum gallery, rather than a concert hall. While it’s important to have an exit, if you’re trying to corral users down a particular path, it’s also wise to not have too many exits. Therefore pages that are part of guides or wizards should have limited navigation options. (For a more detailed explanation, please see part 1 of this article.)
• Inform users of their progress- Because these taskflows embody discrete procedures and operations, users understandably enter them with a sort of “are we there yet?” mentality. Therefore, it’s important to keep users informed of their progress by clearly displaying both the number of steps in the sequence and users’ progress through them.
• Do your homework- This isn’t really a guideline so much as a reminder that wizards and guides are merely one more interface convention: another arrow for your quiver, another tool for your toolbox. As such, they are simply a reflection of the care with which you analyze, understand, and address the unique needs of both the task and the users expected to complete it.

In Conclusion

Although this discussion has covered a lot of ground, it would somehow fail to be complete without the obligatory collection of summarizing sound bites. To wit:

• Embrace the medium- The natural behavior of a web application features two modes: viewing and editing. Design accordingly by removing extraneous navigation options from forms and inappropriate interface controls from views.
• Hubs- You go, you come back. Hubs are ideal for situations that use multiple, discreet, single-page forms.
• Wizards- Step one, two, three. Wizards are appropriate for multi-page procedures or operations that must be completed in a prescribed order.
• Guides- This way please. Guides are useful for complex, multi-part sequences that seek to combine the navigational guidance of a wizard with the navigational flexibility of a hub.

So there you go: hubs, wizards, and guides in all their glorious detail. I look forward to reading your comments soon.

Next up, my model for dissecting and describing a user interface.

Bob Baxley is a practicing designer who specializes in interaction design for Web applications and desktop products. An independent consultant in Silicon Valley, he is also the author of “Making the Web Work: Designing Effective Web Applications.” Bob writes about design at www.baxleydesign.com and a host of other things at www.drowninginthecurrent.com.