Designing for Failure

When any device, product or gizmo gets released to the world, it is the lovechild of the designer’s initial idea and hours of refinement. The refinement may come from the device’s physical makeup, the materials used for the manufacturing or the colors used for the aesthetics. It may also come from the addition or subtraction of features. But a majority of any refinement comes from removing all of the flaws, bugs and malperformances of the device.

Removing all errors from a device is an obvious goal. Some product makers don’t always seem to take it to heart as well as others do. But I can image that even for those more failure-prone devices there was some manager during the brainstorming session discussing how this product should work, with an assumption that frequent failures for the device isn’t an option.

But have you ever noticed a device that was designed for failure. Meaning that instead of fixing the problems that occur in the device, the maker designed the device to make recovering from failure easier.

It almost seems oxymoronic to do such a thing, but I recently came a device that does just that which prompted a few thoughts.

First, I’d like to give brief definition of what designing for failure is to me. Followed by my post-inspiring story of what device I came across that was designed for failure. Then I will dissect what criteria this device follows that could make it possible for devices to also be designed for failure. Finally, I will pose a few other thoughts that came to me about this whole idea.

And here … we … go

Designing for Failure: Definition

Definition: A device that the builder took time and money to implement a system to diagnose errors, report them to the user, and instruct the user on how to repair the device.

Rule 1: This must be a tangible device. Nothing completely digital.

Rule 2: This must be a moderately common device. Nothing too unheard of.

Designing for Failure: The Inspiration

Lately I’ve been making screenshot printouts for a web app demonstration at work by using my company’s mammoth printer. This is one of those printers that take up half a room, but can do pretty much anything it’s asked to do. Seriously, I saw a guy feed some dough into it one end and 10 minutes later a pepperoni pizza came out the other side.

As I’m printing the handouts, the inevitable happens and something breaks during the printing process. The paper runs out, the staple clip is empty or the paper gets jammed. Regardless of the reason this time, I’m not getting any more handouts until it’s fixed.

This printer has one very nice feature that makes correcting the problems a breeze. When something goes wrong, the printer shows a video on the display instructing the user how to fix the problem. Also, there is a small amber light next to every door, tray or imaginable place where something could go wrong. When the video starts playing, the corresponding lights turn on to help guide the user to the problem area.

For more complex problems, such as removing sections of the device and removing paper jams, the printer can follow the user’s progression though the problem solving steps and change the video and lights to the current step.

While waiting on my printouts, my mind began to contemplate, as it’s prone to do, this printer’s design and its implication on design as a whole. So I’d like to take some time and analyze this designing for failure idea.

Designing for Failure: Criteria

Although this printer is currently the only device I know that is designed for failure as I defined it earlier, here are my criteria for when a device should be designed for failure. The overarching question that these criteria are trying to answer is ‘When should a device be designed for failure?’

1. The device fails often.

The device must break regularly before it would be cost effective to design a diagnosing and reporting system.

We have all pushed the print icon on our computers, gotten up to get our print to find that the print failed for whatever reason. Printers fail and they fail often.

Let’s assume it’s simple to repair a standard oven. Well the standard oven only breaks once every 3-5 years. There’s no reason to waste R&D time and money to implement a design to guide users in step-by-step instruction on how to repair their broken ovens. If it breaks twice a day, then that’s a different story.

2. The repair is a simple, but not immediately obvious, one.

The repair should not be so simple that most people will be able to solve the problem without assistant, but also not so complex that it requires any extensive amount of time or training.

An average person can open up a printer tray and add more paper to it. He or she should also be able to see the paper jam next to the glowing amber light and remove it. Repairing a printer requires no tools or advanced training.

Another device that is designed for failure, but the method to repair it isn’t relayed to the user, is an automobile. Error codes are captured with information detailing what the problem is, but that information is kept from the user. The mechanic on the other hand can plug into the car to retrieve the error codes in order to repair the automobile’s problem.

Users aren’t privy to the diagnostic information because the repairs aren’t simple. A how-to video and amber light indicators won’t cut it when it’s time to rebuild the carburetor.

I added the “immediately obvious” clause because of this often failing, yet simply repaired device, a toilet. This device fails more often than I wished, but the solution is simple. With a clogged toilet you can basically do one of two things. You either pull the clog out with a plunger or you push it through with an auger.

3. The device is on-demand.

Necessity is the mother of invention.

-Plato

The device needs to be repaired in a timely manner with as minimal downtime as possible.

If waiting a few days for a printer to be repaired were acceptable, then I doubt it would be designed for failure. But who prints his or her important documents out a week before being needed. I have many memories of running around my college campus in desperate search of a working printer minutes before my term paper was due.

A printer is designed for failure, because, frankly, failure is not an option. The print is needed now, and waiting even an hour is unacceptable in most cases.

4. The device relies on uncontrollable variables.

The main reason why a device could be designed for failure is when there are a number of external variables that the device isn’t able to properly account for or it cannot easily fix those externally introduced errors.

Printers suffer from a large number of externally introduced errors. The person loading the paper could have put the wrong stock or size sheets in the tray. The paper itself could be wrinkled or dog eared so that it doesn’t go through the printing process correctly. And even though it might be simple to qualify which types of errors occur most frequently in printers, I would imagine it would be very expensive to build the printer to check for and correct these errors. These types of external variables are the main reason why a printer is designed for failure instead of being able to be designed without failures.

Conversely, the Xbox 360 is the one of the most failure-prone devices around, but that’s designers fault. The failures came from the manufacturing process and has nothing to do with external sources. Why would they build the device for failure when they are in control of the failures to begin with? Showing a video on how to solder some joints or how to install an extra heatsink onto a chip would be ridiculous, because Microsoft controlled all of these problem areas back in the assembly process.

To start an always loved Apple vs. Microsoft debate, a huge reason why Apple products don’t fail as often as Microsoft products do is because Apple controls almost every stage of production of its devices, both hardware and software. Microsoft typically only controls the software and must account for an insane amount of variables that come from hundreds of different hardware vendors building for a Microsoft platform. Yes, I am aware that the Xbox 360 is both hardware and software controlled by Microsoft. Feel free to make any assumptions about what that means about the quality of the company’s products.

Designing for Failure: Questions

Is this acceptable?

If a product meets all four guidelines above, is it acceptable (or even necessary) to design the product for failure?

Is the failure still the designers fault?

Even though the major reason for the failures comes from external variables, should the device be designed to eliminate all possible failures? We were able to send a man to the moon over 40 years ago, can we seriously not create a printer than doesn’t get paper jams? Is the printer manufacturer designing for failure as a cop out because its accounting team ran some numbers and found out that it’s cheaper to design for failure than it is to reduce the number of failures.

I understand that my printer scenario has a classic quantity vs. quality dilemma. Do you want a printer that prints 100 pages per minute with a high frequency of errors, albeit easily fixed ones, or would you like a printer that prints 10 pages per minute but never has errors? But does this dilemma still give the maker an excuse to not build a better device.

What other products are designed for failure?

I tried thinking of other devices, that met my definition, that obviously took the time to instruct its users on how to repair the device when it breaks, but could not come up with any other commonly used devices. This alone is a main reason why the idea of designing for failure was so intriguing to me in the first place. It seems very odd for this design pattern to not be repeated elsewhere. Is a printer really the only common device that it makes sense to design for failure?

Alas, I don’t have a large enough of twitter followers to properly crowd source the idea as I would have liked. Help, me out in the future and follow me on twitter.

I would love to hear any opinion you might have about this Designed for Failure situation. The idea is very new to me and I would love to get other’s thoughts about the matter.