Master UX for Processes With Blazor Stepper and Wizard Components

Here’s how to recognize what your users will regard as a “difficult task,” how you should deal with it in your UI, and the two UI for Blazor components that will help you do that.

The goal of good user experience design is not to eliminate difficult tasks—difficult tasks exist, and both your users and your application have to deal with them. The goal (quoting Vogel’s First Rule of UI Design) is “to ensure that users always know what they have to do next in order to achieve their goals.”

Using the Stepper component from the Telerik UI for Blazor components will let you create as simple or as sophisticated a UI as you need to achieve that goal. Using the Wizard component, on the other hand, will let you add an effective wizard in very little time—and what time you require will be spent on the wizard’s business logic, not on getting the wizard to do the right thing.

But, to use either of the components well, you need to understand the problem.

What Makes a Task “Difficult”?

What most often makes a task “difficult” is that the user is unfamiliar with the task—anything new is going to be harder than something the user has dealt with before. Unfortunately, that’s not the only criteria for a “difficult task”—even familiar tasks can still be difficult.

The U.S. military, for example, defines a “hard mission” as having five characteristics, summed up in the acronym VUCAD—which has now been integrated into business language. Those characteristics are:

• Volatility: The task changes while being performed.
• Uncertainty: The user can’t be sure what will happen next.
• Complexity: It’s difficult for a user to keep a model of all of the components of the task in mind.
• Ambiguity: Inputs could mean multiple things.
• Delayed feedback: The user doesn’t know what the results of an action until well after the action is taken.

To sum up: In a difficult task, the user is constantly having to decide what to do next without the information to make good decisions.

Reducing the Difficulty

If we put familiarity together with VUCAD, we can gain some direction about what we can do in our UIs to reduce a task’s difficulty in the user’s mind.

Obviously, a good beginning in reducing a task’s difficulty is to make the task look familiar: Create a UX that matches the user’s mental model of how the task should be addressed and looks like something the user is already familiar with. An obvious example of “making things familiar” is just breaking a complicated task into several discrete steps: Most users have experience with working through a set of steps.

Adopting a step-by-step process also allows you to address the characteristics that make up VUCAD:

• Volatility: Steps provide a predictable path through the task.
• Uncertainty: Showing the steps in advance provides visibility to “what’s coming next.”
• Complexity: Breaking the task down into smaller tasks reduces the complexity at any step.
• Ambiguity: Breaking the task down allows you to clearly define what’s happening in each step.
• Delayed feedback: Showing the user the result of their actions within each step helps the user understand the results of their decisions.

Instead of users having to figure out “What do I do next?” users just do Step 1, are automatically taken to Step 2, do Step 2, and carry on until they’re told that they’ve completed the process.

If this sounds like a wizard … well, it is. And, since your users have almost certainly seen a wizard before, this overlap gives you another opportunity to make your task look familiar.

Design Goals for Effective Wizards

The three primary design goals for creating a wizard that actually helps users are:

1. Do nothing until the user gets to the last step. Only when the user clicks on the Done button on the last step should you take action.

The reason for the first principle is to keep from having to back out changes if the user returns to an earlier page and makes a change that might invalidate any “premature” updates you’ve made. Instead, when the user clicks on the Done button in the last step, you validate the user’s entries in the earlier steps and (if everything is complete and consistent), perform all the required updates and close the wizard.

2. Arrive at the last step with all the user’s data complete and consistent.

The primary purpose of the second goal is, of course, to avoid annoying the user. If you don’t find a problem until the user gets to the last step, then the user has to go back to an earlier step and fix the problem. No one is going to regard that as a feature when dealing with a complicated problem.

But there’s a second reason for this goal: If the user does return to, for example, Step 2 and makes a change, that change may invalidate an entry that the user made on Step 3 when they went through your wizard the first time. Now, users not only have to fix their original problem—they have to resolve any conflicts that fix creates. It’s better for everyone if all the problems in a step are found before the user leaves the step.

3. Make all the wizard’s steps independent of each other and, failing that, not have later steps affected by changes in earlier steps.

The idea behind the third goal is precisely to avoid problems created when the user returns to an earlier step. Even if there isn’t a problem, users go back to earlier steps because, as they work through the wizard, they come to understand the problem better—your users get smarter. The reason wizards have a Previous button is because users realize, late in the process, that they made an “unfortunate” entry on a previous step. Achieving the third goal reduces the impact that changes in earlier steps have on later steps.

But do recognize: These are goals that you aim for and may not be achievable in every wizard you create. When you can’t achieve them, the least you can do is implement the “blank slate pattern” on the last step of your wizard and give users a chance to review what will happen when they click the Done button (this pattern is also a good choice for an overview page that introduces your wizard).

Wizard and Stepper Components

Both the Wizard and the Stepper components in Telerik UI for Blazor will let you achieve those goals and support your users in dealing with complicated tasks, but they’re targeted at different levels of complexity/customization.

The Blazor Wizard component gives you all the support you need to create a standard step-by-step process that walks the user through a process, including beginning with an overview of the process and reporting to the user where they are in the process. The Wizard component includes the default Next, Previous and Done buttons (though you can customize them) and integrates with the Form component so that the user can’t move on to the next step while there are errors in the step. Really, the Wizard component takes care of almost everything required in creating a wizard so that you can concentrate on the business logic your wizard implements.

The Blazor Stepper component is the simpler of the two components and gives you the most room for customization: The Stepper just builds the UI for the list of steps that make up the wizard—the UI design pattern called “steps left” or “steps on top” (in fact, the Wizard component uses the Stepper component to build its list of steps). The Stepper component leaves it up to you to build and integrate the UI for the steps that the component shows to the user. But that also means that the Blazor Stepper component gives you the most flexibility when you’re building a process that doesn’t fit into the standard wizard format.

What’s coming up, then, are two deep-dive series—one for the Stepper (here is Part 1 of that) and one for the Wizard (here is Part 1 of that)—that will show you how to exploit these two components to support your users through any complicated process.