Designing for the reluctant user

I remember studying the concept of the “reluctant hero” in college lit classes. This is the protagonist who is thrust into the role of being a savior or hero, often unequipped and unwilling to be The One. Think Bilbo Baggins, who just wanted to stay home in his hobbit hole rather than steal treasure from dragons, or Arthur Dent from Hitchhiker’s Guide to the Galaxy, or even Han Solo. The reluctant hero typically needs some kind of supernatural intervention or magical object to get them to act.

As an interaction designer, I’ve found sometimes I need to design for the “reluctant user.” This is someone who, given a choice, would rather not use the product I am designing-at all-no matter how cool the features, or how well-designed the experience. I’ve worked on products for disease management (“I can’t wait to sit down and focus on my health condition!”), health insurance (“Sorry I can’t go to the party, I’m too excited to check on my claim status!”), and—the mother of them all—filing taxes (“My dentist couldn’t fit me in for a root canal so I’m doing this instead“). In none of these cases do the users want to use the product and the related service. Yet there are consequences if they don’t, so it’s incumbent on the designers to make the experience as painless as possible.

Unspeakable-clippy081711.png

Case in point

We are helping a client assess one of their tax-related products. Measuring the effectiveness of these kinds of products is difficult. Where normally you are looking for high customer satisfaction rates, in this case, it’s really about minimizing pain, not making it a great experience they want to repeat anytime soon. Nobody wants to spend time preparing their taxes, they just want to it to be over so they can avoid penalties (and hopefully pay the least amount of tax possible). So if a user had a neutral experience, that’s actually a very positive result since we’re really starting from a baseline of ”I don’t want to do this.”

As with any project, key to success is identifying the users’ most important goals, but it’s critical to keep those in the context of how much time they are willing to spend. After working with our tax software client and talking with teams who’ve worked on projects with reluctant users, we’ve gathered some things to keep in mind when designing for the reluctant user:

  • If a user’s goal is to get it done as quickly as possible, make it so. Don’t get cute with whizbang interactions that prolong the experience.
  • Automate when possible (or at least provide options for automating). Users will likely be willing to trade some control for simplification.
  • Use language that engages the user, and be careful to avoid jargon; users won’t be motivated to look up terms (for example, a user dealing with a health insurance claim dispute will want to see procedure names, not just billing and procedure codes).
  • Set expectations about how long the process will take, and show (and celebrate) progress with feedback about completed tasks.
  • Fill up “dead time” (such as waiting for steps in an installation process) with either useful information (such as tips or demonstrations…NOT advertisements), or provide a time estimate so the user can go do something else.
  • Focus on and highlight any positive benefits that come out of having to endure the experience (such as that tax refund).

Quicken does a nice job with this last point, communicating how using TurboTax can help people get a bigger refund (free money is always a good angle to play). Another example is from home healthcare products that take every opportunity to reward the input of information and celebrate improvements in the numbers used to track health.

We’ve recently been hoping for a shot to redesign the DMV service experience, but are still in line waiting for our number to be called. While we are waiting, have any of you worked on products that target the reluctant user? What did you do?

3 Comments

Ryan Swarts
Great points. It's amazing how some planning and hard work (organizing, labeling, reducing steps) can make all the difference. I compare it to being an umpire, which I was for a bunch of years. When you are at your best, you're invisible. That's how experiences should be. The game should be the focus. Or, in these situations, the end goal (paying taxes, filing a claim, etc.).
Steve Calde
Ryan, thanks for the comment. Love the comparison to being an ump. The game can't function without them, but it can't BE about them.
Amitava
Useful points Steve! For in-house IT projects, what I have seen working is getting all users and stake holders on board right from the beginning. Involving the users during requirements gathering, research, design, development and finally hand-holding them during deployment, creates a feeling of ownership and empowerment. That has helped me win over reluctant users.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment