Back in the 2000s, when I was creating my first websites, I had one that looked perfectly fine on my computer. Months after publishing it, I happened to check it on one of my friend's computers.

It was completely broken.

My response was something like:

"Well, you need a 1024×768 monitor with Internet Explorer 7."

And somehow, I thought this was okay.

Puff.

That was one of those moments when you realize that you weren't designing a website for people. You were designing a website for yourself.

The website worked under the conditions I had imagined. The problem was that I had imagined the wrong world.

That is where mistake-proof design starts.

Two different possibilities, one approach

When we talk about mistakes in design, we usually think about the user doing something wrong.

But there are actually two broad categories of things that can go wrong.

The first is a mistake made by the user.

The second is a mistake, limitation, or unexpected condition caused by everything around the user.

The interesting part is that both require essentially the same mindset:

What if?

What if the user does something unexpected?

What if the user doesn't know the language very well?

What if they're a non-technical person?

What if they're old?

What if they don't know that the little downward arrow means "expand this list"?

What if they don't realize that something is clickable?

What if they can't read tiny text?

What if they don't understand your icon?

What if they are using a keyboard instead of a mouse?

What if they are using a screen reader?

What if they cannot see?

What if they cannot hear?

What if they cannot use a touchscreen?

What if they cannot use a mouse?

What if they have difficulty typing?

None of these are weird edge cases.

These are people.

And accessible design is, among other things, an acknowledgment that the person using your product doesn't necessarily interact with it in the way you imagined.

A designer can look at a tiny grey icon and immediately understand it.

The person using the interface might not.

A developer can look at a chevron and know exactly what it means.

The person using the website might think it is decoration.

You might consider 12px text perfectly readable.

Someone else might not.

The interface doesn't get to decide whether the user's interpretation is "correct." If the interface consistently produces confusion, the interface has a design problem.

And then there is everything that isn't the user

This is the other category that designers sometimes forget.

You need to ask thousands of little "what if" questions.

What if their internet connection is slow?

What if their device is old?

What if their browser is old?

What if JavaScript is disabled?

What if JavaScript fails to load?

What if CSS fails to load?

What if one of your external resources is unavailable?

What if an image doesn't load?

What if the API takes ten seconds to respond?

What if the server returns an error?

What if the browser doesn't support the feature you are using?

What if they are on an old Android phone?

What if they're on an iPhone?

What if the viewport is unusually narrow?

What if the device has rounded corners or a display cutout?

What if the browser's text size is increased?

What if the user zooms to 200%?

What if the connection disappears halfway through submitting a form?

What if they press the button twice?

What if they refresh the page?

What if they navigate backward?

What if they open your website in a browser you never tested?

This is where "it works on my machine" becomes one of the least useful sentences in software.

Your machine is not the product.

The user's environment is the product.

Poka-yoke: making mistakes difficult or impossible

There is a useful concept from Japanese manufacturing called poka-yoke, roughly meaning "mistake-proofing" or "error prevention."

The idea was formalized by industrial engineer Shigeo Shingo and became associated with the Toyota Production System. Instead of merely telling people not to make mistakes, the design itself is changed so that the mistake becomes harder, impossible, or immediately obvious.

A classic example is an electrical connector that can only be inserted in the correct orientation.

You don't need a warning saying:

Please rotate the connector 180 degrees if it doesn't fit.

The connector already tells you.

Better yet, it physically prevents the wrong action.

That is a very different philosophy from:

"Here are 17 instructions. Please don't screw this up."

The mouse with the strange battery compartment

A more modern example is the Razer Orochi V2.

Its battery compartment is designed to accept either an AA or AAA battery, but only one battery at a time. Razer explicitly describes it as a hybrid AA/AAA battery slot and warns users not to attempt to install both.

The interesting thing isn't the mouse itself.

It is the principle.

A good design doesn't merely explain the correct behavior.

It constrains the possible behavior.

The same idea appears everywhere.

A USB connector has a particular orientation.

A SIM card has a cut corner.

A microwave won't start with the door open.

A washing machine can prevent certain operations while running.

A car may require the brake pedal to be pressed before shifting out of Park.

These are all examples of designing the system around the fact that humans make mistakes. Wikipedia documents several of these examples as applications of poka-yoke and forcing functions.

The best interface is sometimes the one that refuses to let you fail

This is an important distinction.

There are two ways to deal with a dangerous or confusing action.

You can allow the action and then complain about it.

Or you can design the system so the action cannot happen.

Consider a form.

A weak design might allow the user to submit an invalid email address and then display:

"Error: invalid email."

A better design might show the expected format while they are entering it.

An even better design might make the input itself communicate what is expected and provide immediate, understandable feedback.

The same principle applies to destructive actions.

"Are you sure?"

is useful.

But it is not always enough.

Sometimes the better solution is to make the destructive action reversible.

That way, even if the user clicks the wrong thing, the mistake isn't catastrophic.

Mistake-proofing isn't necessarily about preventing every error.

It can also mean making errors cheap to recover from.

Your website should survive reality

This is where my 1024×768 and Internet Explorer 7 website becomes particularly embarrassing.

I wasn't really asking:

"How does this website behave?"

I was asking:

"Does this website behave correctly under the one configuration I happen to have?"

Those are completely different questions.

A robust website should be able to tolerate a surprising amount of environmental chaos.

If JavaScript doesn't load, perhaps the core content should still exist.

If CSS doesn't load, perhaps the page should still be readable.

If an image fails, perhaps its alternative text explains what disappeared.

If the network is slow, perhaps the user can still understand that something is happening.

If a request fails, perhaps their work isn't lost.

If the screen is narrow, perhaps the layout adapts instead of collapsing.

If the browser is old, perhaps the user gets a simpler experience rather than a completely unusable one.

Progressive enhancement is basically mistake-proofing applied to the web.

Build the fundamental experience first.

Then enhance it when the environment allows you to.

The download-link problem

There is an even simpler version of this problem that appears constantly on websites.

You know where the download is.

The designer knows where the download is.

The developer knows where the download is.

Everyone involved in creating the page knows where the download is.

The visitor doesn't.

And someone eventually says:

"But the download link is right there."

That's the wrong question.

The question is:

Could a reasonable person fail to find it?

People regularly ask for help finding download links because something that seems obvious to its creator isn't necessarily obvious to its user. For example, developers have posted questions specifically because they could not locate download links on software websites.

This is one of the most important lessons in UX:

Obvious to you is not the same thing as obvious.

Design for the user's attention span, too

And then we arrive at another problem.

Even if everything works technically, your interface still has to compete with the user's attention.

This might be the most hostile computing environment humans have ever created.

Your user opens your website.

Their phone vibrates.

A notification appears.

Another one arrives.

Someone sends them a message.

Their browser asks for permission.

An email arrives.

They switch applications for two seconds.

They come back.

Now they have forgotten what they were doing.

The web used to assume that someone would sit in front of a computer and give a website their attention.

That assumption is increasingly fragile.

So mistake-proof design also means designing for interrupted attention.

Don't make people remember something they can see.

Don't make them remember information from three screens ago.

Don't make the only explanation disappear after five seconds.

Don't make a form erase everything because one request failed.

Don't make users restart a process because they accidentally navigated backward.

Don't hide the important action among twelve visually identical buttons.

And don't assume that because someone understood your interface once, they will remember it six months later.

A good interface reduces the amount of memory required to use it.

Good design is not just beautiful design

This is where I think the idea of "good design" gets confused with "beautiful design."

A beautiful interface can still be terrible.

It can have perfect typography, carefully selected colors, elegant animations and a beautiful grid.

And still make people miserable.

Because design isn't decoration.

Design is the behavior of a system.

A website that looks beautiful but doesn't work on a reasonable range of devices isn't good design.

A form that looks beautiful but destroys your input when the network fails isn't good design.

An interface that looks minimalist but hides basic functionality behind mysterious icons isn't necessarily good design.

A product that requires a manual to understand how to perform its most basic operation might have a documentation problem, but it might also have a design problem.

Good design starts with UX.

Visual design matters. Branding matters. Typography matters. Motion matters.

But they are layers on top of the fundamental question:

Can people actually use this thing?

Ask "What if?" before your users do

One of the simplest design exercises is also one of the most effective.

Take a feature.

Then start asking:

What if?

What if the user doesn't understand it?

What if they misunderstand it?

What if they click twice?

What if they don't click it?

What if they can't see it?

What if they can't hear it?

What if they can't touch it?

What if they use a keyboard?

What if they have a tiny screen?

What if they have a huge screen?

What if the browser is old?

What if JavaScript fails?

What if the network disappears?

What if the server is slow?

What if the request fails?

What if the user leaves?

What if they come back tomorrow?

What if they forget what they were doing?

What if they are in a hurry?

What if they're distracted?

What if they're not you?

That last one is probably the most important.

When I look back at that website from the 2000s, the problem wasn't really Internet Explorer 7.

The problem was that I had confused my environment with the user's environment.

I had built something that worked.

I hadn't built something that could fail gracefully.

And those are very different things.

Mistake-proof design is ultimately about accepting a simple fact about technology:

Something will go wrong.

The user's understanding will be different from yours.

The device will be different from yours.

The network will be different from yours.

The browser will be different from yours.

The user's attention will be somewhere else.

The question isn't whether something will go wrong.

The question is whether your design has already thought about what happens when it does.