Your IoT device works. Can someone set it up from their phone?

A sensor sends data to a phone on the developer’s desk. Great. Now hand both devices to someone who hasn’t seen them before.

Do they know how to turn the sensor on? Which item should they select if three devices appear? What should they do when nothing appears at all?

That first five minutes deserves its own place in the project scope. For a connected product, setup is part of the product experience.

Describe the first useful result

Imagine a simple room sensor and a companion mobile app. This is a hypothetical example, not a client case study. The first useful result might be: the user connects their sensor and sees its first temperature reading, with a unit and an update time.

That gives the team a finish line. A screen saying “Connected” is only an intermediate step if the customer still cannot use the device.

I’d write the initial flow in plain language before designing screens: prepare the sensor, find it, confirm its identity, connect, and receive a reading. Each step needs an observable result and a recovery option.

Choose the connection around the actual use

Does the phone need to read a nearby device, configure it for a home network, or reach it while the owner is away? Those are different requirements. A product may need more than one communication path.

For nearby exchanges of small amounts of data, Bluetooth Low Energy is one option. Android’s BLE APIs support discovering devices, finding their services, and exchanging information. The device’s services and characteristics determine what the app can read or write. Android BLE overview

Before estimating the app, I’d ask for the device’s communication specification and access to representative hardware. A nice interface cannot fill in an undocumented command format.

Help people select the right device

A list of technical names is easy to build and sometimes difficult to use. If two sensors have the same advertised name, the user needs another way to identify theirs.

Depending on the hardware, that could be a code printed on the enclosure or a physical confirmation step. These are product decisions to agree with the firmware team. Don’t promise an identification flow the hardware cannot support.

Finding a nearby device also shouldn’t automatically grant someone ownership of it. Decide how the app establishes authorization, and what happens when a device is transferred to a new owner.

Give setup failures different explanations

“Something went wrong” leaves the user doing your troubleshooting for you.

I would define separate states for permission denied, no device found, connection interrupted, and connection established without a valid reading. Show only the cause the app can establish. If the cause is unknown, say what can be checked instead of inventing an explanation.

For our example sensor, “Connected, waiting for the first reading” is more useful than an endless spinner. After an agreed timeout, offer a retry and explain whether the user needs to restart any part of setup.

Make the first milestone testable

A small onboarding milestone could require these checks:

• A new user reaches a valid reading on each agreed test phone.
• Two nearby sensors can be distinguished using the agreed identification method.
• Denying permission leaves a clear way to recover.
• Interrupting setup doesn’t leave the app claiming that setup finished.
• An already configured device behaves predictably on the next connection.

Record the phone models, operating-system versions, and firmware version used. That makes the demonstration useful evidence without turning it into a promise about every possible device.

If you’re planning a connected product, start with this complete first-use journey. For the implementation boundary between Flutter and platform code, see when Flutter needs Kotlin or Swift. Once readings arrive, the next question is how to show whether IoT data is still current.