“…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
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
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.
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.
I don’t find that there is anything ground breaking in this article, and it’s predecessor. Hubs have been around since the dawn of computers in the form of configuration screens. Wizards haven’t been around for as long, but they have been out there for the last several releases of the Microsoft OS’. The guide is a fairly logical extension of the Wizard, that I have been using for a couple years and have seen around.
That said it was nice to see them all compared to each other in a clear and concise manner. It’s a little analysis I never bothered to do, and will probably be useful down the road.
Bob, thanks for another great article.
Do you have any recommendations or comments on designing for dynamic wizards (where number of steps in the wizard is determined by the user)?
The problems that I ran into with designing dynamic wizards are:
can’t tell the user how many steps it would take to finish the wizard, and displaying correct status indicator.
This is a fine article, except that “wizard” is a stupid word that I wish we’d stop using. It’s lost it’s “magic,” don’t you think?
Alfred North Whitehead said “It requires a very unusual mind to make an analysis of the obvious”.
Let’s face it though, much of the boxes and arrows conent is NOT ground breaking. Many of the topics have been covered 5, 10, 15, & more years ago. Look at design history, early HCI literature, work in data visualization, Dreyfuss’s book on Designing for People, etc, etc…
Good article I thought. Well written & thought out.
Thanks for the comments and kind words. Ji, if you can provide a bit more context around your question I might be able to offer a few ideas. And Max, couldn’t agree more with your frustration over the terminology. In my maturity however, I’ve learned to pick my battles and I fear that that one is not only unwinable, but also long since concluded.
On a more abstract note, there’s something interesting going on in Ben and Liam’s comments. My goal with these articles is not so much to break new ground but rather to describe the workings of proven interaction design mechanisms so that less experienced designers can make more appropriate use of them. To my eye there is no shortage of poor design that could easily be fixed by a better understanding of these basics pattern.
This approach stems from my philosophical position that design in general, and certainly interaction design in particular, is fundamentally a craft — a craft that is both easy to learn and difficult to perfect. The implicit disappointment in Ben’s comment however points to a different, competing philosophy, a philosophy that sees interface design as a type of science that is constantly evolving new knowledge and new techniques.
I suspect the truth is somewhere in between those two positions but would be interested in hearing what others think.
Another year; another fine Bob Baxley article. Thanks!
I do have a few nits to pick, however…
1) Terminology: yes, the term “Wizard” sounds like techno-obscurantism. However, many users coming from a mainstream GUI background (i.e., Windows) tend, in my experience, to already be familiar with both the term and (roughly) the concept. So using it lessens the learning curve and the need for having to explain the flow of that (wizard) UI. This is a win, though not necessarily a big one.
2) Both the diagram and the example screenshot of a Wizard show a ‘Start Again’ navigation path. While I think that is a defensible addition the normal navigation paths in a wizard, it *is* a quite unusual one! So, I would change the diagram so that there were just left/right arrows between adjacent bubbles on the diagram–that would much more closely correspond to a ‘traditional’ wizard.
3) Finally, it is not clear to me that the distinction between a ‘wizard’ UI and a ‘guide’ UI is a useful one. They _both_ look like wizard UIs to me, except that the latter one has some (what I call) non-linear navigation paths added.
Furthermore, if you think about it, the BA.COM screenshot example (and the wizard diagram) could be considered as using a ‘guide’ UI design, albeit a degenerate one where the only non-linear path support is the ‘back to start’ one.
So I would refer to the two UI designs as: a ‘traditional’ wizard vs. a wizard with non-linear navigation added.
I’ve seen implementations of the latter in both GUI (Windows) applications and in Weblications. For an example of the latter, go to: http://www.sonexis.com and then click on the button entitled (“See the Power of the Sonexis Conferenceing Solution”), in the middle of the home page. When you see the UI entitled “Schedule Conference For Later”, notice the captions over in the left ‘sign post’ area–these are actually hyperlinks and, thereby, support non-linear navigation of the wizard.
Jim: Thanks for both the kind words and substantive comments. I understand your point about the “Start Again” navigation on my diagram and how it breaks with traditional wizards. I agree that the additional navigation is unusual but it is easily defensible, and certainly useful, for wizards that result in complex transactions rather than non-reversible operations. Such “start again” options don’t appear in “traditional” wizards because they simply aren’t applicable for operations like software installation, disk formatting, or account creation — the procedures typically handled by such wizards. Again, it depends on the specifics of the situation but there are certainly cases where a “start again” option can be useful and so I chose to add it to the diagram.
In terms of your final point, I agree that the distinction between wizards and guides is a subtle one. However, I chose to differentiate the two because I wanted to enforce the point that the strict, linear wizards are too often used in situations where they are not required. My hope was that by referring to guides as a separate type of workflow it would inspire readers to seek out solutions that supported the additional navigational flexibility characteristic of guides.
Thanks again for your comments and I’ll try to make sure that it’s not quite another full year before my next article. 8^)
The discussion of Wizards versus Guides in these comments ignores the situations where a wizard is applicable, but a guide is not: linear workflows with conditional branches based on user input.
In this case, a Wizard serves an important function: hiding complexity that is not required for all users. In this sense, a wizard is much more than a single form broken up into tranches… And a guide would not enhance the experience, unless the “hub”-style map changes its shape based on user selections.
Che…you are of course, absolutely correct. Support for conditional workflows is one of the fundamental differences between the two structures.
Thanks for pointing out the omission and apologies for my near-total brain cramp 8^)
Comments are closed.