When All On Means All Off

By Carol Barnum

Published: January 23, 2012

“Here’s my own experience of the problems I encountered with my DVR remote after my recent switch from one cable provider to another.”

We hear a lot about the difficulty of getting all of our entertainment devices to talk to each other. Jakob Nielsen once wrote an Alertbox column about this problem, showing the six different remotes he uses to watch TV.

Often, people buy after-market, add-on products to remedy such problems—for example, Logitech’s Harmony all-in-one remote, which lets users connect to all of their devices via a single device—or so they advertise. It’s a testament to the frustration level of many people that they are willing to pay upward of $200 for a device just to support the devices they already own and use.

But what if the problem is not having multiple remotes, but issues with just one remote: the essential DVR remote? Here’s my own experience of the problems I encountered with my DVR remote after my recent switch from one cable provider to another.

I’d Rather Fight Than Switch!

“Brand loyalty keeps people using the products they’re used to. Of course, in some cases, people avoid switching to a new product because of a fear of the unknown, the uncertainty of change, and the inevitability of running into problems….”

You’d have to be of a certain age to remember the commercial that used this slogan. But, even if you don’t recall the commercial, you probably get the idea behind it: brand loyalty keeps people using the products they’re used to. Of course, in some cases, people avoid switching to a new product because of a fear of the unknown, the uncertainty of change, and the inevitability of running into problems when switching from one brand of technology to another. Or one software product to another. Or one Web application to another.

That’s why usability testing is becoming a much more common part of product development. Companies that know about issues with technology adoption and technology switching understand the importance of doing usability testing to minimize users’ stress and improve their transition to the use of new products.

If you like using a product, you’ll tell a few folks. But if you don’t like a product, you’ll tell the whole world. This has always been true in marketing, but the ease with which we can now share our displeasure with a product through a tweet or on our Facebook page can make the news about a bad user experience go viral in no time.

That’s why I have to wonder why my cable company provides such an unusable DVR remote. Clearly, they gave little thought to the device’s usability. Figure 1 shows a photo of my new remote control.

Figure 1—DVR remote control

DVR remote control

Although this remote control may look simple to use, there’s a major, hidden-in-plain-sight usability problem: the red All On button at the top is not to be touched! Pressing this button breaks your setup and disables the other buttons—such as access to cable via the cable button. And worse, the DVR will not record the shows that you’ve carefully programmed for recording. Why? Because the DVR is in an all-off state.

Seeing Red

But it’s so tempting to touch the red button. After all, it’s red for a reason: to call attention to itself—as my husband so quickly demonstrated.

Despite the fact that I had taken careful notes from the technician who installed the DVR and told me how to use the remote and what to avoid using—like that big red button—and despite my having told my husband that I had some instructions that I wanted to review with him when he got home from work, he picked up the remote and—you guessed it—intuitively and instantly hit the red All On button.

So, everything was off from that point forward.

I can’t blame my husband for hitting that button. It was so tempting, so logical, so inviting—so big, so prominent, so red. Like Eve with the apple, he bit.

Should We Blame the Technical Writer?

“Bad design always falls in the lap of the technical writer, who has to “fix” the problem with the documentation.”

Bad design always falls in the lap of the technical writer, who has to “fix” the problem with the documentation. Believe me, I know, because I started out my teaching career as a technical writing instructor. I fully understand the kinds of challenges technical communicators face in making sense of the illogical or the incomprehensible.

So, let’s look at the documentation for the remote control, which appears on page 3 of the instruction manual, as shown in Figure 2. This is actually the first page of the documentation, following the “Welcome” page.

Figure 2—Documentation for using the remote control

Documentation for using the remote control

The instructions for using your remote control seem to call out and explain everything, except what happens when you hit the All On button. The problem lies in the fact that the instructions

  1. begin at the point after the remote has been programmed
  2. describe the functionality of each button, but not the procedure for using each of them

The technical writer begins with the assumption that the remote has already been programmed, as it should be when the DVR is installed. Based on this assumption, first two steps—for AUX and TV—begin with “When programmed….”

The instructions for the next button—the Power button—tell you that this button turns the cable box, TV, and any auxiliary components on or off. While this is true, the new user may not necessarily understand this readily. Yes, you can turn individual components on or off with this button, but, if they are not programmed to work together, you won’t have the capability to record new programs or view previously recorded programs. You will merely be turning each individual component on or off.

So, you find yourself in the situation I was in after the All On button got pressed: seeking guidance from the manual on how to reprogram the remote to reconnect the DVR to the TV.

The instructions for the All On button seem to be the right place to get this information. However, instead of steps for how to program the devices, there’s just a description of the feature. Again, this description is only partially correct. Yes, this button turns everything off, but, no, it does not turn everything back on.

How did this critical mistake in the documentation happen? I can think of several possible reasons:

  • The technical communicator received the information or specs from the engineering department and wrote the documentation from this source.
  • The technical communicator did not have access to the equipment—remote control, DVR, and TV—so perhaps wrote the documentation from photos or illustrations instead.
  • The technical communicator had access to the remote control, DVR, and TV, but a technician programmed the equipment and told or showed the technical communicator how everything worked. Perhaps the technical communicator did not make the mistake of hitting the All On button, so did not encounter the problem.
  • The technical communicator did not have access to real users with whom to test the documentation.

Meanwhile, Back to the Problem with the First-time User…

If only the manufacturer had thought about and tried to provide a good user experience for the first-time user. They could have made the experience for new users much less painful—perhaps even enjoyable.

One week later, we still hadn’t figured out how to undo the damage done by pressing the wrong button.

If only the manufacturer had thought about and tried to provide a good user experience for the first-time user. They could have made the experience for new users much less painful—perhaps even enjoyable. If only the technical communicator had been able to actually use the remote—in effect performing an expert review—or, better still, observe new users using the remote, in order to understand the faulty user experience and write documentation to address the issue.

Not only does the documentation misinform users; it also leaves them without a solution. In my search for something to help me out of my problem, I found this FAQ on a page of FAQs at the back of the manual:

Why is my remote control not responding to any button presses?

Press the Cable button on your remote control to try to change the channel. If nothing happens, check the batteries for possible replacement. If the remote still doesn’t work, press the arrow button on the front of the set-top box. If the channel changes, then most likely you have a faulty remote that may need to be replaced. If you are having an issue with a specific button, the button may be inactive for future features.

At that point, I didn’t know whether I should laugh or cry.

Power to the People!

“Managing user perceptions and instilling a sense of satisfaction in users begins with their first experience of a user interface, whatever form it may take.”

The people who use this DVR remote to control their entertainment devices are highly motivated, but they do not expect the process to be so hard. Using their entertainment devices should be a pleasant experience.

Managing user perceptions and instilling a sense of satisfaction in users begins with their first experience of a user interface, whatever form it may take. As we know from Web site studies, we have only 50 milliseconds to make a good first impression. Maybe we have a bit more time with new users who are learning how to use a device they have purchased—like this remote control. But how much time? And how much user frustration is acceptable?

I think, naively perhaps, that my cable company’s goal should have been to make their users happy customers from their first click of the remote.

Thinking back to Nielsen’s 10 usability heuristics, three are particularly pertinent:

  1. error prevention—Even better than good error messages or documentation is a careful design that prevents problems from occurring in the first place.
  2. helping users to recognize, diagnose, and recover from errors—We should express error messages in plain language—not including codes that have meaning only to developers—precisely indicate a problem, and constructively suggest a solution.
  3. online Help and documentation—Even though it is better if users can use a system without documentation, it’s usually necessary to provide Help or some other documentation. Such information should be easy to search or browse, focus on users’ tasks, list concrete steps that users must perform to complete them, and should not be overly extensive.

An expert review using these heuristics or others would help identify these sorts of problems. But we may discover some problems—such as the incorrect use of the All On button—only through direct observation.

We know the path to solving such problems: usability testing. Seeing is believing. Seeing is understanding. Writing documentation based on what we learn from study participants can help users avoid problems that are inherent in a device’s design. And, even more important, its user experience and documentation can guide users and help them solve the problems they encounter.

Join the Discussion

Asterisks (*) indicate required information.