Responsive Disclosure

As the user sees the task unfolding directly in front of him via a dynamically growing UI, he can form a correct mental model of the task more quickly and easily. None of the awkward context switches that separate wizard screens impose exist here: the users aren't yanked out of their workflow into a rigid set of modal screens shown one at a time.

Furthermore, since the UI is kept together on one page, the user can easily go back and change his mind about earlier choices. As each step is redone, he immediately sees the effect on subsequent steps. This is better than jumping from one content-starved wizard screen to another.

For occasional tasks, this device can work better than presenting a complex and interlinked set of controls all at once, because it's always obvious what the first step is -- and the next, and the next. The user never has to think too hard.

How should you choose between this pattern and Responsive Enabling? If you use Responsive Enabling, you will put all the controls for all choices on the UI -- you'll just disable the irrelevant ones until they become relevant (again, in response to the user's choices). Sometimes that can make the UI too cluttered or complicated-looking. It's a judgment call: if you need to fit the UI into a very small space, or if you think too many controls on the UI might look bad or make users nervous, use Responsive Disclosure instead.

In many such step-by-step designs, the choices the user makes at one step alters the rest of the task (i.e., the task is branched, not linear). For instance, an online order form asks whether the billing address is the same as the shipping address. If the user says yes, the UI doesn't even bother showing entry fields for it. Otherwise, there's one more step in the process, and the UI shows the second set of entry fields when appropriate.

This technique is less successful when used to radically change a preexisting UI, instead of adding UI controls to a blank space. Restructuring a UI from under a user can turn his sense of space upside down -- it's very disruptive! But when done in an orderly and predictable manner, it provides a compact, space-sensitive way to present a Wizard to a user.

The concept of responsive disclosure isn't new. It was used in 1981 in the first commercial WIMP interface, the Xerox Star. Its designers considered "progressive disclosure," a more general concept that includes responsive disclosure, to be a major design principle: "Progressive disclosure dictates that detail be hidden from users until they ask or need to see it. Thus, Star not only provides default settings, it hides settings that users are unlikely to change until users indicate that they want to change them." Indeed.

In the Star's Property Sheets, for instance, blank space was reserved for controls that would appear as needed, in response to user choices. When a user chose from a set of values including the word "Other," for instance, an extra text field would appear for the user to enter a number.

Instructive Interaction: Making Innovative Interfaces Self-Teaching, by Larry Constantine and Lucy Lockwood, discusses this pattern under the name "Progressive Disclosure."

This example comes from an internal application at Northwestern Mutual. The user first selects "TSO" for Request Type; the application then shows a new box, asking for TSO information. When the user then selects "Delete ID," a third box appears. The history of this user's choices remains visible on the page.