Trust and Blame

Their error: The warning came too late.

The time to warn a user is before a problem happens, not after it occurs. The faster things happen, the earlier the warning needs to be. Think about how early you should warn someone that they are stepping carefully, walking, or running toward the edge of a cliff. If there are any hard-coded limits, warnings should appear when there is room to spare.

My error: I didn’t pay enough attention to the error message.

I treated the message like an annoying child, giving it just enough attention to quiet it, but not enough to really understand what it was saying. But if I had received the message from a person, there would have been some easy-to-recognize change in tone to warn me that this was serious. Instead, the device showed me a little window that looks almost identical to the window that says it has completed its task successfully.

I barely read the message, of course. I just glanced at it and clicked OK in the same instant. So, by the time I realized that I had not really gotten the message, it was too late. The message was gone forever. If there was another way to find out what had happened, I missed it, too.

Their error: Important information that should be visible wasn’t.

If it’s important for users to be aware of a condition, it’s essential that they have a way to monitor it. We figured this out with battery status warnings. Why not with disc or memory space? This applies to messages as well. If an error message contains critical information, don’t make it look just like the message that says everything is okay.

My error: I tried to fix their problem without really focusing on it.

I remembered “remove some records” and tried to find something I could remove quickly. The calendar offered me only the options of removing items from one week, two weeks, three weeks, or a month ago. Not far enough back. I decided to remove completed tasks. I think I did it right, but who knows. I didn’t spend much time on this decision and certainly didn’t look up any instructions.

Their error: Failure to protect user data.

I don’t really know what happened here, but I’ll bet it’s a bug. Perhaps the error was in not testing boundary conditions carefully enough—or in assuming something will never happen. But when it does happen, don’t punish the poor human who did nothing more than buy your product and try to use it.

It will, of course, take a complete culture change to make the humans on the product-creation side take responsibility for their human errors and the product defects they cause. This change, however, is critical if we are going to create good user experiences rather than just user experiences that work okay as long as nothing bad happens.

This brings us to the second lesson: trust.

Learning (Not to) Trust

When a product—computer, mobile device, or whatever—is just a toy, it doesn’t matter so much if it works well. It might be annoying if your favorite game dumps your playing history just as you’ve reached the highest level, but not much more. However, if you’ve stored all of your financial data in an application, losing it has real consequences.

The more we rely on our electronic devices, the more we are trusting them to be there when we need them and to safeguard our information and our privacy. And the more we rely on them, the greater the consequences of any failure.

I don’t know anyone who has not been through at least one catastrophic failure. Some have long-lasting consequences, other results are more short term, but the pattern of what follows is the same. After going through denial and anger, we make a bargain with ourselves: we will never let this happen again! During the depression phase that follows, we are more conscientious. We back up our data. We don’t push the system so hard. But, over time, the memory softens, we accept what happened, and we fall back into our old habits.

I’m not talking about “average” users, but people who work with computers regularly and have a good enough understanding to know their limitations. We have a strong affinity and start with a high degree of trust, so it takes a lot to whittle it away.

I just trusted that the Palm would not trash my data without warning me. After all, this is one of the few user interfaces that doesn’t ask me if I want to save the data I’ve just put effort into creating, but assumes that, of course, I want to keep my work. This incident left me a bit shaken, but in the end, I kept on using my Palm. I back up my data a bit more often, and I don’t trust HotSync not to destroy both sets of data, but I can already feel myself slipping into resigned acceptance.

There’s a saying: “Fool me once, shame on you. Fool me twice, shame on me.” How many times will people be fooled by technologies before they give up and decide that they can’t be trusted? Or will we make them trustworthy before that happens?