Selection-Dependent Inputs

By Luke Wroblewski

Published: February 20, 2007

“As arbitrators of checkout, registration, and data entry, forms are often the linchpins of successful Web applications.”

In a previous Communication Design column, “Refining Data Tables,” I alluded to the importance of Web forms in online commerce, communities, and creation. As arbitrators of checkout, registration, and data entry, forms are often the linchpins of successful Web applications.

But successful Web applications tend to grow—both in terms of capability and complexity. And this increasing complexity is often passed on to and absorbed by a Web application’s forms. In addition to needing more input fields, labels, and Help text, forms with a growing number of options may also require selection-dependent inputs.

Selection-dependent inputs are, in essence, a pretty simple concept: Once a user initially makes a selection from one or more options in a form, the user must provide additional input related to the selected option before submitting the form. Figure 1 illustrates this behavior by showing two steps from the eBay Create a Download Request form. After an eBay seller selects the Sold option in the Listings and records drop-down list, the form presents additional input fields for selecting a date range. Were the user to select a different option in the Listings and records list, completing the form would require a different set of additional options.

Figure 1—An example of selection-dependent inputs

Example of selection-dependent inputs

It’s worth pointing out that, in most cases, users cannot submit a form with selection-dependent inputs until they fill in the additional fields. In other words, selection-dependent inputs introduce additional requirements to forms.

While selection-dependent inputs may seem like a basic user interface design problem, the myriad solutions to this problem on the Web indicate there’s more to this interaction than one might initially assume. The problem becomes particularly interesting when a form requires many additional inputs of varying types once a user makes a simple initial selection.

To illustrate just how interesting, here are a number of user interface design solutions for the selection-dependent input problem that I’ve seen work—and not work. Of course, I encourage others to share their unique approaches to tackling this issue.

Page-Level Selection

“Perhaps the simplest way to address selection-dependent input within a form is to divide the process into two clearly defined steps.”

Perhaps the simplest way to address selection-dependent input within a form is to divide the process into two clearly defined steps. On the Web, this most often translates to two separate pages. The first page—or step in the process—shown in Figure 2 presents users with an initial set of options. Once they select one of the options, the appropriate set of selection-dependent inputs replaces their initial selection.

While the relationship between their initial selection and the dependent inputs is clear to most users, the two-step model removes valuable context once users make an initial selection and is likely to be slower than inline solutions. As a result, page-level selection is often not a viable option.

Figure 2—Page-level selection

Page-level selection

Section Tabs

“To avoid additional pages within key workflows, designers have explored several inline approaches to exposing selection-dependent inputs.”

To avoid additional pages within key workflows, designers have explored several inline approaches to exposing selection-dependent inputs. In one approach, section tabs arrayed across the top of a panel, as shown in Figure 3, let users navigate to a section of the form that contains selection-dependent inputs. The tabs present not only the initial set of options, but also provide a strong indicator of the current selection.

While most users are familiar with the concept of navigation tabs on the Web, the manner in which they fill in Web forms frequently impairs the effectiveness of the section tabs approach. When completing a form, many users move from top to bottom and, as a result, often ignore horizontal options. There is also a lack of clarity about whether section tabs are mutually exclusive. Will I submit my selections on all three tabs with the form—or only the selections I made on the active tab?

Figure 3—Section tabs

Section tabs

Finger Tabs

To compensate for the lack of visibility of left-to-right section tabs within Web forms, using top-to-bottom finger tabs can better align with common patterns of form usage. When users move from top to bottom through a form, vertically stacked finger tabs, as seen in Figure 4, are consistently more noticeable.

To address the mutual exclusivity question inherent in the use of both section and finger tabs, you can include radio buttons to the left of the finger-tab labels to clearly communicate that they are mutually exclusive options.

Figure 4—Finger tabs

Finger tabs

Section Selectors

Both the section and finger tab methods maintain a unique interface element—in this case, a tab—for each initial option. This keeps all the initial options visible, but requires considerable screen real estate to do so. When the number of initial options grows, these methods tend not to scale very well.

The section selector method shown in Figure 5 utilizes a drop-down list and group box to confine all selection-dependent inputs to a specific area of the form. Though this method obscures most of the initial options—as only one option is visible in the drop-down list at a time—using a single control better communicates the scope and impact of the initial selection.

Figure 5—Section selectors

Section selectors

Expose Below Radio Buttons

“A strong visual indication of the dependency between the initial selection and its additional inputs can help communicate their relationship more clearly.”

Another inline method of selection-dependent inputs involves vertically separating the user’s initial options from any exposed additional inputs. This approach, shown in Figure 6, has the advantage of always keeping all the initial options—and a user’s selection among those options—visible. However, in usability testing, I’ve seen considerable confusion about the relationship between the initial selection and additional inputs.

Since, by default, one of the initial options is selected, it is not immediately clear that a dependency exists between the two sections. Also, the jumping effect that occurs when users change their selections and the screen updates to show a revised set of additional inputs can disorientate users.

A strong visual indication of the dependency between the initial selection and its additional inputs can help communicate their relationship more clearly, but isn’t likely to resolve all of the issues with this approach.

Figure 6—Expose dependent inputs below, following an initial selection

Expose dependent inputs below

Expose Within Radio Buttons

“When the set of additional inputs is quite small …, this method can maintain the context of a user’s initial selection while introducing the required selection-dependent inputs where they are most relevant.”

Similar to the expose below approach, the expose within method reveals additional inputs within a set of initial options, as shown in Figure 7. When the set of additional inputs is quite small—one to two additional inputs—this method can maintain the context of a user’s initial selection while introducing the required selection-dependent inputs where they are most relevant.

If the number of selection-dependent inputs is substantial, however, this method breaks down quickly. The combination of page jumping and the movement of the initial set of options—as the elements between them are revealed and hidden—makes for a disorientating interaction that frequently has users questioning which user interface element triggers which set of options.

Figure 7—Expose dependent inputs within, following an initial selection

Expose dependent inputs within

Exposed Inactive

“When there are many additional inputs for each initial option, the association between the user’s selection and the other initial options can get lost.”

To address the disorientation caused by movement of the initial options when a user selects a different option—because of the page jumping that results from revealing and hiding selection-dependent inputs—the exposed, but inactive method shown in Figure 8 keeps all additional inputs visible, but makes only one set of options available. The other selection-dependent inputs are unavailable and most commonly appear dimmed, or grayed out.

While this method keeps all additional inputs visible and within the context of an initial selection, the sheer volume of inputs that are visible can quickly overwhelm users. Also, when there are many additional inputs for each initial option, the association between the user’s selection and the other initial options can get lost. Adding to this effect is the fact that the visible difference between inactive and active elements is frequently too subtle.

Figure 8—Expose inactive dependent inputs

Expose inactive dependent inputs

Exposed Groups

To compensate for the disassociation between the set of initial options in the exposed inactive method, Figure 9 uses visual groupings to bound each set of selection-dependent inputs beneath an initial selection.

In this method, however, the visual weight of the many additional inputs can quickly reduce the visibility of the initial set of options.

Figure 9—Expose dependent inputs in groups

Expose dependent inputs in groups

In Conclusion

Each of the aforementioned solutions for selection-dependent inputs within Web forms has both advantages and disadvantages. As with all design decisions, it’s best to consider which solution is right within the context of the problem being addressed. If you’ve found success tackling the issue of selection-dependent inputs in other ways, let me know!


Great article! Thanks for such a thorough overview of the approaches. A few other things that figure into choice of options:

  • Form UI conventions may be imposed by COTS (commercial off-the-shelf) software, which may limit some of the options and require us to be more creative with allowed options—maybe combining elements of some approaches.
  • Accessibility requirements—for example, Section 508—may impact the options that can be chosen or at the very least require careful consideration of how options are implemented—JavaScript, visual elements.

Again, thanks for a great piece.

+1 on using radio buttons instead of tab imagery to resolve the mutual exclusiveness ambiguity. If the tab pages comprise all the controls for input, you can also resolve the ambiguity by putting the action button on each tab page rather than outside the tab control, thereby implying only the controls on the current page are related to the action.

An alternative between finger tabs/radio buttons and a drop-down section selector is to use a scrolling list box for the section selector. It takes no more space than finger tabs/radio buttons and keeps many options visible at a time while scaling to a large number of items. It also eliminates the click that a drop-down needs to open the list to make a selection.

How about a bridge between the first and second example: a wizard-style multi-page treatment with step indicators—Step 1 of 4—and a summary of each steps’ fields and/or purpose above or to the side of the form fields?

Nice overview of the usability implications. I was wondering if you had any insights on the accessibility of the options, since most of them seem to require some form of client-side scripting, which may not be supported by assistive technology.

Good article, Luke.

One other technique you can use here is to rephrase the question. As developers, we tend to pose questions to the user in computer logic. For instance:

A) Do you want to meet in the conference room?

B) Do you want to meet in a cubicle?

If you want to meet in a cubicle (B):

1) Do you want to meet at your cubicle?

2) Do you want to meet at my cubicle?

This would commonly be presented as a selection-dependent input using any of the above techniques. But really, this could be represented as:

A) Do you want to meet in the conference room?

B) Do you want to meet at your cubicle?

C) Do you want to meet at my cubicle?

This kind of simplification may not always be possible, but it is definitely the first thing to look for when requirements call for selection-dependent inputs.

My experience, from 3 years of usability tests, is that it’s better split it up into two or more steps. Dependencies between fields are hardly ever understood by users.

Love articles like this. Thanks.

Roman, great reminder!

Tabs—either conventional or finger tabs embedded within a page as your scenario utilizes—are generally not suitable for this purpose.

Why? Because tabs are usually assumed by users to represent various content, for which only one is shown at a time, for layout purposes. Generally, the frontmost tab has no special meaning or rights; data shown or entered into other tabs is equally valid. This is true for all tab implementations on all GUI platforms.

The Sun Web Application Design Guidelines actually forbid applications from taking any special meaning from the currently visible tab at the time actions are taken on the page—that is, data is saved.

The exception is when the actions—that is, buttons—appear within the tabs, so that the action is clearly local to the tab’s content and not global to the whole page. In that case, however, what your tabs are implementing is a lot of little pages or forms that happen to appear on a single physical page.

I agree with Jaime that it’s best to steer clear of tabs—top or side—for conditional inputs, because users expect them to represent completely different steps in a process.

I design lengthy data-entry forms that often include a lot of demographic information—client responses to survey questions, etcetera. I have found some success using fieldsets and labels to organize each group of related questions, then revealing additional form elements within the fieldset for conditional responses—more or less like the first example in this article.

When I tried a similar layout using tabs—that is, 5 tabs/5 pages rather than 5 fieldsets on one page—I found that some users didn’t see the tabs and expected to be finished with the whole form when they reached the bottom of the first tab.

Of course, the drawback of using fieldsets is that the page can become terribly long. Plus, as Luke points out, the page jumps when the user’s choice reveals an additional field.

Thanks for the new ideas!

Hi all, Thanks for the comments and the additional ideas. I’m curious if the folks that steer away from tabs have tried finger tab solutions. In the studies I have seen, top-aligned tabs caused exactly the issues you’ve described, but finger tabs—especially those with radio buttons in them along with labels—performed much better. I’m interested if anyone else has experienced the same? thanks~

It seems to me that the “Page level selection” is being somewhat unfairly evaluated when you say, “… the two-step model removes valuable context once users make an initial selection and is likely to be slower than inline solutions.”

There is no reason why it would automatically remove context, is there? It could be argued that the clarity of the approach would make providing such context more confusing, not less.

I also think your assertion that it would be slower is a little weak, in order to cast this approach as presenting a problem for users. It may well not be slower at all, and some users may appreciate a slight lag in the context of choosing an important option. I know I’ve observed dissatisfaction quite often when screen elements change state immediately.


Unless you copied everything over from the previous page, you wouldn’t see all the additional options you didn’t choose. That’s the context of your choice—all your options.

In terms of slower, I can’t see how a full-page reload would be faster than a partial page update. Can you clarify what you mean there? Are you saying people might be slower to get their bearing when a portion of a page changes versus a full page?

What if you don’t select a radio button by default in Figure 6? That’s the approach described in the example used by Jennifer Tidwell, and it looks to work well.

Hi Luke

Great summary of the different approaches.

I, like Zephyr, would be interested in your take about the need for client-side scripting for a number of these approaches. In a number of cases, I have recommended the first approach (separate pages), because clients needed their forms to be accessible.

I’d also like to comment on your statement that this approach is not often suitable, because of the loss of context. I agree that in some cases this argument applies, but in many other cases, there are distinct steps that are more internally than externally contextual.

Breaking the form into these steps would, as I think Jonathan argues, improve rather than worsen the user experience, because tasks are being put into more manageable and focused chunks. You also often have the option of providing backward as well as forward movement, allowing the user to access previously entered information if they want to.

Cheers Jessica

Hi Jessica, The right answer is, of course, “it depends”. Sometimes it is appropriate to divide form questions across multiple pages. Sometimes it is more appropriate to utilize a dynamic in-page UI. For situations where selection-dependent inputs are short and seeing them may cause people to revisit their initial selection, a page-level option may be sub-optimal.

In my new book, Web Form Design, I’ve dedicated an entire chapter to selection-dependent inputs, and some eyetracking and usability testing we did on the options listed here. In our testing, page-level selection performed averagely. It achieved average satisfaction scores, a relatively low number of errors, and faired well on eyetracking measures like number of eye fixations, total length of fixations, and average fixation length. However, this solution had the second longest completion time of all the options we tested. So if you are looking for a safe solution with average performance, and quick completion times are not a concern, page-level, selection-dependent inputs might be a good match.


Hi, I am currently evaluating my company’s intranet and giving them a specific UI Guideline manual. I actually thought about all of these options and found that none of these would probably be the best.

I have another solution. It’s pretty much mentioned here, but kind of overlooked.

The idea of using Radio Buttons is good for listing, because it lets the user know the possibilities right on without clicking any drop-down list.

And the idea of Finger Tabs is good, because it gives a clear distinction to what an option encapsulates. But it also gives the impression that we need to click each tab to finish the process.

In my opinion, putting Radio Buttons in front of tabs is so much better, but is also kind of confusing.

So why not change the look and feel of the tabs? Keep the radio buttons, then on click, just open an animated window box within the page? Something like this: On a radio button selection, a line starts from the end of the radio button text, then a box opens up under it with the context-sensitive content. This does not make it look like a tab and gives the user feedback about what is going on.

I also like the idea of changing the text of radio buttons to questions. This highlights the mutual exclusivity further.

Let me know what you guys think…

Thanks for the article. I have been working with software for 20 years now and have implemented almost all of those methods in both win32 and Web environments. The other side to the coin that I think is the most difficult is when you need to go in reverse. Meaning, you have a returning user that has existing data and you need to populate the form based on existing input as well as allow them to edit it. So the order in which you do this is critical, because you can’t populate a list with values that do not match what this user selected.

Join the Discussion

Asterisks (*) indicate required information.