After users have completed some task, it’s easy to identify whether it was a “difficult task”: It’s one where users frequently make mistakes (by which we mean: Users get something they don’t want). Unfortunately, that identification comes too late to help our users.
It’s possible to create UIs that reduce the difficulty involved and increase the chances that users will get what they want. Ideally, with the right UI, users will never realize how difficult the task was.
Eliminating difficulty has real benefits: The Warwick School of Business estimates that the world’s largest organizations lose about 10% of their earnings because of complexity in their business processes. I can sympathize: As a software project leader, I once delivered a software application that worked…as long as the staff was willing to put in two or three hours of overtime every day figuring it out.
If I’d asked those users what made using my application “difficult” they probably would have said that my application combined one or more the components summed up by the military acronym VUCAD:
In Learning Tree’s user experience design course, we provide some useful advice in how to create a UX for difficult tasks — this blog post will draw on that course. Actually, we have enough advice in the course that I’ll have to split the topic over two blog posts.
Users can identify a task as ”difficult” because “uncertainty” matters to users: If a user doesn’t know much about a task, they’ll classify the task as difficult before they even start. This means that the first issue that your UX should address is eliminating that unfamiliarity. At the very least, your UI should provide an overview of the inputs required, the outputs to be delivered, and the steps users will go through to get the result they want.
If users will perform a task frequently and you’ve devoted a separate form to the overview, you should make it possible for users who’ve become familiar with the process to skip the overview (after all, your user will, eventually, stop being unfamiliar with the task). However, it’s not always necessary to devote a separate form to the overview. A popular design pattern that integrates the overview with the forms making up the process is called “Steps on Left”: This pattern puts a graphic representation of all of the steps on the forms, along with a summary of what each step involves (and also, typically, showing which step the user is on right now). Don’t take the name of the pattern too seriously, by the way: the steps don’t have to be on the left. In one common variation on this pattern, for example, the steps are displayed across the top of the form.
Your next step should be to address complexity: The multiple factors that can overwhelm a user. Your best choice here is to break the task down into a series of smaller “bite sized” bits that don’t overload the user’s cognitive capacity. It’s critical here that you break down the task in a way that makes sense to the user – a way that matches the user’s mental model of the task. The user has enough problems just dealing with the problem without your UI trying to make them think about the problem “differently.”
At this point you may be thinking that by breaking the process down into steps, you’re going to create something that looks a lot like a wizard. There’s a reason for that: the Wizard design pattern works, was designed to handle difficult tasks, and is well understood by most users. Using a well understood UI pattern — like the Wizard pattern — reduces the user’s cognitive load (remember, a difficult task is one where users already feel overwhelmed). However, you don’t necessarily have to create a wizard in order to break a problem down into manageable tasks. A tabbed interface can also segment a task, as can a screen with well-defined areas with each area on the screen devoted to a different part of the task.
I’ve talked about understanding the user’s mental model elsewhere but the critical point to understand is that the user thinks about the problem in terms of the goals the user is trying to achieve. For example, if you’ve created a configuration tool for a communication device, it’s tempting to believe that the user thinks about configuring the device in terms of changing the device’s internal settings (certainly, that’s the way the device’s designer thinks about the configuration screen). However, the user thinks about the configuration screen simply as a means to end: to connect two networks, to get on the Internet, to print a document. To be helpful to the user, the individual steps in the process should not be organized in terms of the device’s internal state. Instead, organize the steps around the user’s goals: Show how will this step or decision moves the user closer to their goal (e.g. connecting two networks).
Breaking down the problem into steps that make sense to the user is just the first step in reducing complexity — you need to design those steps to reduce ambiguity, eliminate uncertainty, and avoid delayed feedback. And that’s what I’ll talk about in my next blog post.