Wizards Versus Forms

By Mike Hughes

Published: September 19, 2011

“When I find myself designing an application that is complex, either in terms of its length or its logical dependencies, my natural instinct is to take a wizard approach. But … breaking up a task into smaller steps does not always provide a better user experience.

Many applications must gather information from users. At their simplest, such transactions employ dialog boxes or brief forms. Examples include sign-in screens—Who are you and do you have permission to be here?—and printer setups—What is the page size and do you want single-sided or double-sided pages? Others are quite complex, such as helping a user prepare his income tax return. We can measure complexity by the number of questions we ask or the logical branching we use. For example, the question What OS do you use? might have one set of follow-up questions if the answer is Mac and another if it is PC.

When I find myself designing an application that is complex, either in terms of its length or its logical dependencies, my natural instinct is to take a wizard approach. Wizards are cool; forms are dull. Product managers love wizards because they are so Web 2.0. Developers like wizards because they involve more programming expertise than just cranking out forms.

But even when dealing with complexity, wizards are not the slam-dunk answer for creating an optimal user-interface design solution. Breaking up a task into smaller steps does not always provide a better user experience. Any of us who has suffered through using an automated IVR (Interactive Voice Response) system—Press 1 if you need help with hardware, press 2 if you need password reset and so on—that goes several tiers deep knows the frustration of plodding through layers of micro-logic machinations just to ask one basic question. In some cases, having users choose various forms from a simple menu or drop-down list might provide a better solution—from both a coding and a UX perspective.

This column examines the relative advantages of wizards and forms and examines various dimensions we should consider when making a decision about which is better for a given circumstance.

Advantages of Wizards and Forms

“Wizards and forms each bring their own respective set of advantages to the table.”

Wizards and forms each bring their own respective set of advantages to the table. Wizards are good in the following scenarios:

  • presenting a fixed workflow in a prescribed sequence—This can be particularly beneficial if you need to verify or validate prerequisite conditions before asking a user to commit to a lot of data input.
  • breaking up a long or complex workflow into manageable tasks
    Wizards are effective in reducing the seeming complexity of a task or providing a sense of progress—for example, when filling in a tax form or performing a large number of setups during an initial system configuration.
  • where later information is contingent upon what data a user has already provided—Wizards can keep user interfaces from sounding like the logic portion of an SAT test. If you answered Yes to question 7, provide your OS version here; otherwise skip to question 9.

Forms are good in the following scenarios:

  • presenting a comprehensive list of what information a user must provide—Forms are effective in communicating to users what questions you’re going to ask, letting users gather whatever information they lack before starting a task. A wizard that asks for information on the very last screen that sends a user off on a scavenger hunt can be an awkward and frustrating user experience. It can also add to code complexity by requiring the system to track incomplete states.
  • making it easy to navigate among data-entry fields by pressing Tab
    Power users can provide information efficiently and navigate to fields of interest without removing their fingers from the home position on their keyboard. This can be a significant consideration if users fill in a given form many times during the day.
  • reducing the number of hits on a server—that is, serving up an entire form after only one call—Performance is often a challenge for Web-based applications. Users can quickly lose patience when there are performance lags while a wizard makes background trips to the application server or database.

A workable—but by no means absolute—guideline is that novices and infrequent users like wizards, but frequent and power users prefer forms. However, as is often the case in UX design, the landscape is often more complicated than that. Let’s examine a simple, illustrative task model and consider how a user could accomplish the task using either a wizard or multiple forms. In that context, we can look at some of the aspects we should consider to choose an optimal approach.

An Illustrative Model

“Let’s look at a general model for a task flow that a user interface could handle through either a wizard or multiple forms.”

Let’s look at a general model for a task flow that a user interface could handle through either a wizard or multiple forms, shown in Figure 1. Essentially, the user interface needs to present users with and gather some initial information, then ask a question that sets a conditional state. At that point, the task must branch based on the user’s answer. For example, a user might be setting up a report for distribution, so the first step would be to ask for basic information about the report, such as its name. Next, the user would need to select a form of output such as PDF or HTML. Based on the type of output the user selected, the user interface could branch, asking a different set of questions for each branch. Our model has two such conditional branches.

Figure 1—Task flow

Task flow

One solution would be to provide a three-page wizard. Figure 2 shows a rough wireframe for the first page of a wizard. This user interface gathers initial information, then, when the user clicks Next, branches to a second page whose content is appropriate to the condition set on Page 1. In our model, Page 2 would gather more information and make another contextual branch to Page 3.

Figure 2—Page 1 of a wizard solution

Page 1 of a wizard solution

Figure 3 shows an alternative solution that would use four separate forms, each corresponding to one of the conditional paths shown in Figure 1. In this case, a user selects the appropriate form from Menu 3, and the user interface presents the form shown in Figure 4. The user can provide all of the necessary information using just one form.

Figure 3—Menu items for a multiple-form solution

Menu items for a multiple-form solution

Figure 4—Sample form in the multiple-form solution

Sample form in the multiple-form solution

Criteria for Choosing the Right Approach

In deciding which of these two solutions would make more sense in a given scenario, … we must weigh the size of each benefit against the severity of its cost.

In deciding which of these two solutions would make more sense in a given scenario, you should consider the following:

  • Does one solution offer significant coding efficiency over the other? For example, the logic of one of the conditions might require several server calls and a complex algorithm that compares a user’s input to conditions that reside in several different databases. That would certainly up the cost for taking a wizard approach.
  • Is one solution significantly easier to maintain than the other? For instance, if a wizard was just one file, but the forms were in four separate files, a change in the workflow for a common question might require only one change to the wizard code, but four separate changes to the form code.
  • Does one present a significantly better user experience?

As UX professionals, we might like to think that the third question always trumps the first two, but in the real world of product development, that is not necessarily the case. We must weigh the size of each benefit against the severity of its cost. However, since this is a column for UX professionals, let’s examine how to evaluate the impact of our wizard-versus-form decision on the user experience.

Evaluating the User Experience of a Wizard Versus Multiple Forms

“In taking the multiple-form route, the first consideration is how definitive we can make the menu choices. … Would users be able to easily make a choice among the clear options we present?”

In taking the multiple-form route, the first consideration is how definitive we can make the menu choices. Would users be able to easily make a choice among the clear options we present? If we need to lead users through a series of qualifying questions before they can know what final action they should take, a wizard might be the more appropriate choice.

For example, if the items on a menu represent different trouble tickets that first require some troubleshooting, a wizard might be a better solution. Let’s say a user’s final actions might be to (a) Order a new modem, (b) Schedule a service visit, or (c) Upgrade his data plan; but the user would not know which of those actions would be the right choice for his situation. In such a case, a wizard that walks a user through the appropriate troubleshooting steps would be the more helpful approach.

On the other hand, if menu items represent information that is well known or well understood by users, multiple forms might be the better choice. For example, if the branches were (a) Mac, (b) PC, or (c) Linux, a drop-down list that let users choose their operating system (OS), and thus pick one of three forms based on their OS, might be a much simpler solution to use and code, especially if the forms differ to any significant degree.

Another consideration is the amount of data users must provide. The government puts all of your tax information on just one or a few printed forms. But most online versions of tax software take a wizard approach, so users experience a sense of progress while filling in their information. Plus, they can stop, then resume the task more easily. Technical writers know that the best way to handle a 21-step task is to break it up into three 7-step tasks. Wizards essentially allow us to do this in the user interface itself.

Yet another consideration is the frequency with which users would use a wizard or form. For repetitive tasks, users quickly tire of the overhead of the interactions and performance hits that wizards bring with them. I saw this first hand when I worked on a contract with a warehouse that was installing a large Enterprise Resource Planning (ERP) application. This type of application tends to be a bit clunky—often trampling on usability for the sake of an organization’s being able to configure diverse solutions over its standard back-end files and databases. In this case, users typically added a dozen to forty new inventory items to the system at a time. In their old way, they used a spreadsheet to record all of the information, then did a batch upload. The ‘new-and-improved’ system concatenated several separate screens through a wizard-like flow to accomplish the same thing, but item by item. The users rebelled, and the deployment consultants had to write custom code to replace the wizard.

How Much Complexity Can Forms Handle?

I recently worked on a service-ticket submission application that had to accommodate 40 different paths. Is that too much complexity for a forms-based approach? Traditional information-architecture wisdom tells us that users can handle seven choices pretty easily. So, if I took a two-tiered menu approach, in which users could first choose a category, then choose the ticket type within that category, I could technically handle 49 options. Figure 5 shows an example of the complexity 49 choices would present to users.

Note—Newer research indicates a more realistic constraint might be four, plus or minus one. For more on this topic, see Jeff Johnson’s UXmatters article, “Updating Our Understanding of Perception and Cognition: Part II.”

Figure 5—A two-tiered menu

A two-tiered menu

It didn’t turn out to be as symmetrical as a seven-by-seven array—because there were fewer than seven initial categories—but in some cases, I was able to do some grouping on the submenu to handle more than seven ticket types. In my ticketing application, users could easily recognize the categories and types. For example, a user might want to submit a Policy Change Request for a firewall rule. He would have no problem choosing Submit a Change Request as the primary option, then Firewall Rule as the sub-option. On the other hand, if a user would have to follow a multibranch troubleshooting exercise to determine the right ticket to submit, a wizard might be the better approach. We further simplified the choices by combining similar tickets and making a few fields available or unavailable based on users’ choices.

Conclusion

“Give careful consideration to whether a wizard would truly support … your users’ needs or a not-so-exciting solution using menus and forms might be the better one all around.”

Somebody or others’ law states that, for every problem, there is a simple solution. But that solution may be direct, obvious, and wrong! A wizard might turn out to be just such a solution if we take the instinctive path, feeling that rich interactions are better than dull, old menus and form fields. The Internet puts rich, entertaining media at our users’ fingertips. Users don’t need our applications to entertain them. So give careful consideration to whether a wizard would truly support your company’s business model and your users’ needs or a not-so-exciting solution using menus and forms might be the better one all around.

Join the Discussion

Asterisks (*) indicate required information.