the problem

Our software allows fine grained control of many connected systems. Because of this there are many situations that arise where a certain combination of settings may make another configuration in another part of the product unavailable.

Prior to this project, those settings would simply fail. Sometimes there was an explanation of why, but often there was simply an unclear error message and a screen that could not be saved.

We wanted to handle these situations more elegantly.

the process

I was encountering this situation in a couple of my designs at one point. Another designer brought a design for review, and I saw that he was encountering it as well. We decided to meet and discuss a new design pattern to address the problem.

We chose to frame the problem as a dependency. The user's goal wasn't impossible—it was dependent on another action that needed to be taken elsewhere in the system. As we discussed this, we realized that there were two aspects to the problem. One was making the user aware of the dependency, its cause, and the action required to fix it. The other piece was guiding them in solving the problem and returning to their original task without losing their work.

I decided to focus on the awareness problem.

I examined a number of potential solutions, and I realized that a successful solution would need to have the following aspects:

I eventually settled on a design where the dependent setting was disabled, with an unobtrusive message explaining why. In user testing, no one saw the message. Many users didn't even notice the setting was disabled. Some clicked the disabled setting repeatedly and then clicked "Save", hoping that maybe the settings they wanted would be saved. Almost no one understood that there was a dependency or how to fix it.

I needed a more obtrusive message. However, I didn't want this message to show all the time--it was noisy and would often not apply to what a user was doing. I opted for enabling the setting even though it couldn't be saved. A warning callout would appear in line when the dependent setting was selected. This felt a little odd—almost a bait and switch. However, I reasoned that it was possible to save the selected setting as long as another action was taken. This was the best way to ensure someone would see the dependency at the earliest moment that the system could know the dependency existed.

This solution performed quite well in user testing. I refined it, coordinating with design, product management, and engineering. I submitted the design to be added to our design system, and it was built out to allow this pattern to appear anywhere that a combination of settings would result in a dependent flow.

the solution

The solution is an inline warning callout that appears when a dependent setting is selected. It has a consistent icon and title: "Action required: {Name of other setting}". It contains an explanation of the dependency and a button to fix the dependency and come back.

Before the dependent setting is selected:

Before the dependent setting is selected

After the dependent setting is selected:

When the dependent setting is selected.

After the dependency is resolved:

After the dependency has been resolved.