An internet provider site where the first question is coverage

The situation

A regional fibre provider with a growing footprint and a website that described packages, speeds and prices in some detail.

None of that is the visitor’s first question. The first question, universally, is whether the service reaches their building. Everything else is contingent on that answer, and the old site made people read three sections and fill in a contact form before finding out.

The design consequence

Once you accept that the site exists to answer one question, the structure follows.

The coverage check goes first, above everything, before any marketing. Packages come after, because they only matter to somebody who has had a yes.

The interesting part is what happens on a no, which most sites treat as a dead end.

A visitor outside the footprint is not worthless. They are a data point about where demand exists, in a business whose central decision is where to build next. So a no became: not yet, here is where we are heading, tell us where you are and we will contact you when it changes.

A no that captures intent is worth far more than a no that ends the visit, and it costs one form field.

The constraint that shaped the build

The people most in need of this service are the ones on the worst connections, which is an obvious irony and a genuine design constraint. Somebody checking coverage on a struggling mobile connection must not be met with a heavy interactive map.

So the coverage check is a text input against a list of served areas, server rendered, working with no JavaScript at all. It returns a plain answer in one request.

The map exists, and it loads afterwards, lazily, as an enhancement for people who want to see the shape of the network. Nobody needs it to get their answer.

That ordering is the whole lesson: the primary answer must survive the worst connection, and everything visual is an enhancement on top of it.

What I got wrong

I built the map first. It was the visually impressive part, it demonstrated the footprint well, and it was the thing that would look best in a screenshot.

Then I tested it on a throttled connection and it took nine seconds before the visitor could learn anything at all. On the connection quality of the audience most likely to be searching for a better one.

The rebuild put the text check first and demoted the map to progressive enhancement. Same information, delivered in one request instead of after a large download.

Where it landed

Enquiries got better rather than more numerous, which is the right outcome. The people making contact were mostly people the company could actually serve, which meant sales time stopped being spent explaining unavailability.

And the out of area list became genuinely useful, because it is a ranked map of demand, which is exactly the input the build out decision needs.

What I would do differently

Test on the worst plausible connection before deciding what the first screen contains, not after. I know this rule. I still built the map first, because it was the more interesting problem, and that is the bias worth naming rather than pretending I do not have.