I broke a client’s website on purpose

Most websites get tested on the developer’s fast connection, where everything loads perfectly. That’s the one condition your visitors can’t be relied on to have.

South African connections aren’t always kind, and servers have bad days. So for the Diamond Peak site I built a simulator that loads the site under the worst conditions I could think of, and I designed what a visitor sees in each one.

Five ways to break a page

• A 30-second connection. The page takes half a minute to arrive.
• The design file never arrives. The HTML loads, the stylesheet just hangs.
• The design file fails. The server answers with an error.
• Every photo fails. The text is there, the images aren’t.
• A normal connection. The control test: the loader should stay out of the way.

What the visitor sees instead

The default in every bad case is a white screen or a page of unstyled text. Someone looking for an estate agent won’t wait to find out why. They’ll press back and try the next name on Google.

So on a slow connection, a branded cover appears straight away, so there’s never a white flash. The logo draws in. Facts about the agent rotate while you wait. At 15 seconds the page stops asking for patience and offers help: call her, email her, or try again.

If the design file fails, the visitor gets a clear message and the same options, plus a basic version of the page. If the photos fail, the hero falls back to the brand colour, with no broken image icons.

On a normal connection, the page is ready in about a second, and none of this gets in the way.

Why it matters

An error state is still a page of your website, and for the person seeing it, it’s the only page. Designing it costs far less than losing that visitor, and it still ends with a way to reach the business.

I now plan failure states the same way I plan the homepage. You can play the real recordings in the Diamond Peak case study.