Assume an Amorphous User

By Mike Hughes

Published: March 21, 2011

“Assuming a spherical user, … who knows what he wants to do and takes the logical path in achieving his goals. Our scenarios describe happy paths that lead to success for this user.”

Apparently, the following joke is very popular among physicists:

A dairy farmer is concerned because his cows aren’t giving enough milk, so he consults a friend who is a theoretical physicist.

The physicist listens to him and says, “I’ll need to think about it.”

The next week, he calls up the farmer and says, “I’ve got the answer.”

“Tell me,” pleads the excited farmer.

The physicist starts his answer by saying, “First, we assume a spherical cow…”

Physicists often have to construct clean, clear-cut models to describe messy realities. They do this by cleaning up their concepts about reality, assuming things like frictionless surfaces, lossless mirrors, and yes, spherical objects. UX designers often do the same thing, assuming a spherical user, as represented in Figure 1, who knows what he wants to do and takes the logical path in achieving his goals. Our scenarios describe happy paths that lead to success for this user.

Figure 1—The spherical user

Spherical user

Anything outside those happy-path design boundaries we term edge cases. The result is often a design that works great when it works, but fails horribly when it doesn’t.

“Anything outside those happy-path design boundaries we term edge cases. The result is often a design that works great when it works, but fails horribly when it doesn’t.”

When I was working in a very methodical design environment, employing use cases to define clear requirements, I didn’t worry much about this. We had a rigorous design phase before developers wrote any code. During this phase, we would first work through the happy path—the direct and preferred route from trigger to successful outcome—and make sure we could provide that solution. Then, we would review each step in the use case for failure modes, and we would design appropriate mitigations.

Looking back, however, I should not have been so complacent. For the most part, we investigated technical failures—such as a server’s not being available—or non-compliance with business rules—such as a user’s not having sufficient funds in an account from which he wanted to transfer money. In other words, I accepted a complex environment, but still assumed a more-or-less spherical user.

Now that I work in an agile environment, I worry about this more, because the accelerated development pace and emphasis on minimizing preproduction design documentation seem to make any cracks in the system large enough for things to fall through.

I recently posed a question on my blog, The Humane Experience, about how to systematically avoid this kind of pitfall in agile, and Richard Mateosian posted this comment:

“Assume an amorphous cow and see what goes wrong. In other words, make your implicit assumptions explicit, then see what happens as you violate one or more of them.”—Richard Mateosian

Richard certainly makes a lot of sense, and for most of us, this is nothing new. I can recall many examples where I have done that, but not always systematically and explicitly. In this column, I examine specific steps UX professionals can take in considering the amorphous user.

Negative Scenarios

“There are a couple of models that can guide us in dealing with negative scenarios—meaning scenarios that deviate from the happy path and result in user failure.”

There are a couple of models that can guide us in dealing with negative scenarios—meaning scenarios that deviate from the happy path and result in user failure. One model, negative scenario testing, comes from quality assurance; the other, negative case analysis, from qualitative research.

Negative scenario testing deliberately breaks rules in a user interface to see how the system responds. Its underlying assumption is that the design is right, and some user will inevitably be wrong. It mainly ensures that the system programmatically rejects invalid entries without breaking. For example, if a functional specification calls for new passwords to have both alphabetic and numeric characters, a QA engineer creates negative test scenarios in which he tries to create a password comprising all alphabetic or all numeric characters. If the system prevents these attempts, the product passes those tests. Of course, good design in these cases ensures that the system provides adequate feedback to the user, informing him that he has made an error, and ensures the user suffers no catastrophic loss of work as a result.

Negative case analysis is a qualitative user research technique that tries to account for observed outliers that do not fit the theoretical results. Its purpose is to refine the theory, so those outliers do fit. Its underlying world view is: Hmmm, something’s going on that the theory doesn’t account for. Let’s make the theory richer. This basic model is a good one for UX designers and UI (User Interface) designers to emulate. For them, we might restate this as follows: Hmmm something’s going on in the user’s world that our user interface doesn’t account for. Let’s make our user interface richer. This certainly describes the spirit of usability testing, in which we view user failures as legitimate outliers that our design assumptions have not accommodated and our subsequent reaction is to adjust the user interface.

But I’m looking for an approach that’s a bit lighter—one that fits at the beginning of a design cycle and reduces the likelihood of our taking wrong directions in the first place. Agile creates a fast-paced environment, and getting developers to revisit an issue from the last sprint is not easy.

The process I’ve used is similar to negative case analysis, in that its inherent assumption is that user errors are often the result of rational user behavior….”

I’ve gotten some good results by treating negative scenarios with the same rigor that I treat happy paths—going into the same detail and depth of exploration where it seemed warranted.

The process I’ve used is similar to negative case analysis, in that its inherent assumption is that user errors are often the result of rational user behavior—that is, error is not a result of a user’s doing anything wrong—or at least not illogical. Although negative case analysis attempts to rationalize outliers, I’m instead using scenarios to anticipate the reasonable outliers that a current design has overlooked, in the hope that I can make the design richer or at least more forgiving. I also think rich descriptions of scenarios help developers and stakeholders develop empathy for users, making them more willing to accommodate their well-meaning errors. In my doctoral research, I studied the effects participating in usability studies had on development teams. One of the things I learned was that the willingness of a team to fix a problem increased significantly when the developers empathized with users.

The emphasis of this approach is on describing scenarios where users could take reasonable alternative paths that would lead to failure. How reasonable is reasonable? That’s a legitimate question and depends on how much design time you have. Eventually, all what-ifs decompose to a level where you have to accept that users may just have to ask a friend for help or call the Help Desk. But even then, you can prepare the Help Desk to handle the inevitable calls better, as we will see in a later example.

A Recipe for Investigating Negative Scenarios

“Once you have identified and laid out all major happy-path design scenarios, systematically review them….”

Once you have identified and laid out all major happy-path design scenarios, systematically review them for the following:

  1. At each step in a scenario, ask whether there are reasonable alternatives users might take that would lead to error. Developers can handle the unreasonable and blatantly wrong scenarios without much help. It is in helping them to identify and handle the reasonable alternatives that UX professionals can offer the most value. Look for things like the following:
  • ambiguously labeled menu items
  • links on a page that might cause a user to accidentally leave a workflow
  • fields with overly restrictive format requirements—for example, a date field that can’t parse today
  • static fields that look editable and editable fields that look static
  • places in a flow where a user could get interrupted or need to retrieve data from elsewhere
  1. Examine what happens to users if they take such alternative paths. Follow these branches to their failed conclusions—if that is the likely outcome. Then, think about how you can prevent those failures. Well-designed user interfaces, like well-designed trails in parks, lead errant wanderers back to the happy path unharmed—so there might not be a failure waiting at the end of a wrong turn.
  2. Eliminate the negative consequences of users’ taking a wrong path. For example, if my email client has menus titled Create and Actions, where do I go to create a folder? Hmm…, this feels like an action, but I’m also using the word create. Somebody anticipated this problem—including a command for creating a new folder on both menus.
  3. Reduce the likelihood of users’ choosing a wrong alternative by providing better signals in the user interface.
  4. Mitigate the dangers that you cannot remove. If you can do nothing else, at least share the scenario with customer support, so they can be ready for that type of call when it comes.

Example: The Secret Password

“Investigating the negative scenarios that were associated with using passwords helped mitigate what could have turned out to be some ugly user experiences.”

Passwords are supposed to be secret, right? Well, in one case, they were so secret users did not know their own password. Investigating the negative scenarios that were associated with using passwords helped mitigate what could have turned out to be some ugly user experiences.

The assignment seemed easy enough: Integrate a third-party application into an existing customer-facing portal by putting a link to it on the main menu bar. Doing this would make the service seem better integrated with the other services the portal offered. Solving this apparently simple problem hardly seemed to justify having a UX person on the team. However, an interesting technical problem emerged: A single-sign-on solution was not possible. If a user changed his password for the portal, it would not pass that password change to the third-party application. The developers’ solution was to create a behind-the-scenes password users could not change and have the portal use that password to sign into the third-party application. What could go wrong?

The UX person on the team decided to investigate this approach, initially to understand what extra work this would entail for the personnel who would have to create background passwords for new users. A scenario emerged that considered what would happen if the third-party application timed out. Such an event would display a session-timeout screen that asked a user to sign in again. Oops! That screen was looking for the secret password, but the user would most likely enter the portal password he routinely used. That would generate yet another error message that provided a contact link for the third-party Help Desk, not the portal Help Desk. All of this came to light as the UX person investigated and documented the ensuing scenarios.

And the irony was that all a user would need to do would be to go back to the portal and click the link on the main menu to get back to the third-party application. But these scenarios revealed that users would likely follow a long and potentially time-consuming path—being passed around to various Help Desks before they were finally told to do that. The solution was to rewrite the third-party vendor’s first-response email messages and Help Desk scripts to essentially say, “Oh, if you are with company A and got a timeout message, go back to your portal, then click the link on the main menu, and the system will log you back in automatically.”

Conclusion

“Users are not spherical. They are irregular, lumpy beings who introduce spin and resistance into your well-planned happy paths.”

Users are not spherical. They are irregular, lumpy beings who introduce spin and resistance into your well-planned happy paths. Walk through a design, explicitly asking at each step: What might a reasonable person do that could lead to failure? Examine the consequences, then change your design to prevent, mitigate, or repair the damage that could result. If you need to convince others to implement your solution, either involve them directly in the walkthrough or document negative scenarios to the same level of detail that you document happy paths. One lesson I learned as a usability test facilitator: If developers feel users’ pain, they will fix the problems. Describing negative scenarios in detail is one way to shift the perception from “Stupid user!” to “Oh, wow, that would be a reasonable thing to do, and look at what it can lead to!”

Join the Discussion

Asterisks (*) indicate required information.