Wi-Fi Planner Pro

The difference between a small office and a factory floor isn't the map. It's what each of them opened the map to find out.

A small office is a single floor you can take in at a glance, and the question behind it is narrow: should I move this access point, or not? A plant is multiple floors and multiple zones, with metal racking and production-line interference in the way, and the question is a different shape: which stretch of this floor can't be allowed to drop? The plant user also often isn't looking for themselves — they're assembling something to show a manager or a client, which makes the output a document, not just a view.

The counter-intuitive part is which one is harder to serve. It's the small office. The plant engineer is a professional: they know what −67 dBm means, they don't want it interpreted for them, and the best thing the tool can do is hand over the data and get out of the way.

The small-office owner can't read dBm and shouldn't have to. For them the measurement has to be translated into a recommendation — and that translation carries all the risk in this product. Overstate it and the tool has told someone to move hardware on evidence that didn't support it. Understate it and you've handed back a colourful picture that answers nothing. Calibrating that sentence was the hardest single thing in the project.

Does this piece of information change what the user does next? If it does, it stays on screen. If it doesn't, it collapses. That's the whole rule, and having only one made the hundred small arguments resolvable.

So the default view carries four things: the floor plan, the heatmap, the access point positions, and the legend. Channel, transmit power and wall attenuation all went into advanced — not because they're unimportant, but because knowing the channel doesn't change whether you move the AP.

Engineering disagreed, and their reason was a fair one. They can read every parameter, so hiding them looks like a loss; and a feature nobody can see gets remembered as a feature nobody built.

I didn't argue about whether to show them. That question can only be answered with an opinion, and we both had one. I replaced it with a different question — what does the primary user need answered in the first thirty seconds of opening this page? — and then ran task-based tests on a prototype instead of continuing the discussion.

Where it landed: minimal by default, and advanced mode remembers your setting. An expert turns it on once and never sees the simple view again; a first-timer is never dropped into the deep end. Nobody gave anything up permanently, which is usually the sign that the disagreement was about defaults rather than about capability.

Two colour scales went up: red-to-blue, and green-to-red.

Green-to-red is the one people reach for first, because it maps onto good and bad without anyone explaining it. It also has a known problem — it's the pairing most likely to collapse for anyone with a red-green colour vision deficiency, which on a map whose entire job is discriminating between bands is not a small caveat.

We went with red → orange → yellow → green → blue, and the reason was neither elegance nor theory. It's the scale this audience already reads. B2B network software has used that ramp for long enough that IT staff and engineers don't have to look at the legend to know which end is which — and on a screen someone opens to answer one question fast, a legend you don't have to consult is worth more than a palette that's defensible in the abstract.

That decision came out of a conversation with IT and engineering rather than out of the design tool, which is the honest way to describe it. The scale a specialist audience already has in their head is a constraint, not a preference — you can overrule it, but you're then spending the user's attention on relearning something they already knew, and this product didn't have that to spare.