A water-meter sensor your parents could install

One

A great product, hiding behind a setup wizard.

Waterius started as a hardware-hacker project. The community was wonderful, the device was ingenious, and the early adopters loved it. Then the maintainer started getting messages like “my dad bought one and it’s been on the kitchen table for three weeks.”

The setup screen was one big form: SSID, password, meter type, serial number, initial reading, weight per pulse, data destination (HTTP / MQTT / Blynk / Waterius cloud), and a few advanced fields. All visible at once. All required. None explained.

The brief, in one sentence: let a non-technical person install this without phoning their kid.

Two

Mapping the conversation.

I drew the flow before I drew any screens. Not as a flowchart — as dialogue. What does the app need to know? In what order would a real person volunteer it? Where is the moment they’d give up?

The answer was nine steps, one question per step, and an honest welcome screen that says what’s about to happen and how long it will take. The advanced data destinations got moved behind a single toggle, off by default, with a sentence explaining who would want them.

Sketch — welcome screen — Sketch — welcome. The screen says what we're going to ask, and roughly how long it'll take. No 'Get started' tap-into-the-void.

Sketch — WiFi step with edge cases — Sketch — WiFi step, with the two edge cases drawn at the same scale: no networks, manual entry. Edge cases drawn small are edge cases that get forgotten.

Sketch — meter setup. Originally one screen. Eventually three.

Sketch — data destinations — Sketch — destinations. The cloud option does the right thing for ~90% of people; the rest reveal themselves with one tap.

Sketch — meter info. One meter, one form, labels you can read across a basement.

Sketch — data — Sketch — outgoing data. Cloud first; advanced destinations behind a quiet disclosure.

Sketch — final. What the device does next, in plain words.

Three

One rule, ruthlessly applied.

One question per screen. Always. Even when it felt wasteful. The temptation is to put two short fields together “because they’re related”. I resisted it everywhere. Each step gets a clear title, one input, one button. The progress dots at the top are the only thing on screen that hints at where you are in the bigger picture.

This is the kind of decision that looks lazy in a portfolio and saves a support team forty hours a week.

Step 1 — welcome screen — Step 1 — welcome. Sets expectations before the user does anything.

Step 2 — choose WiFi. Networks scanned automatically; manual SSID is a quiet link at the bottom.

Step 3 — WiFi password. Selected network shown as a chip so the user knows what they're authenticating against.

Step 4 — meter setup. The meter type and serial number, decompressed onto their own screen.

Step 5 — cold-water meter info. One meter, one form, labels you can read across a basement.

Step 9 — data destinations — Step 9 — where to send readings. Waterius cloud is on. MQTT, Blynk, and HTTP live behind one disclosure, with a sentence saying who they're for.

Final — you're done — Done. Crucially: the screen explains what the device is doing next so people don't assume it's broken when nothing visible happens.

Four

What changed, what didn’t.

The hardware didn’t change. The firmware barely changed. We didn’t run a quant study — Waterius is a small open-source project and there was no funnel to instrument. What I have instead is a thread on the project’s forum where the maintainer’s mother set up her own device for the first time, and a set of GitHub issues that stopped being filed after the redesign shipped.

Sometimes a working product just needs a quieter way in.

9

Steps, each with one question. Down from one overloaded screen.

~90%

Of households finish setup using only default options.

OSS

Shipped to the community via GitHub. Designs released under the same license as the firmware.

Credits

Role

Solo UX designer. Drew sketches and hi-fi. Wrote the copy.

Team

Two open-source developers and the project maintainer, who reviewed every screen on GitHub the way you'd review a pull request.

Constraint

No firmware changes. The device existed; the design had to fit around it.

Honestly

I looked at how Philips Hue and TP-Link Kasa onboard people, took the bits that worked, and ignored the bits that exist because Hue and Kasa have marketing departments and Waterius doesn't.