Manuals for connected products that cover the app as well as the device

Connected products have two interfaces, and a manual that covers only one will leave users stranded. A thermostat has a device on the wall, with buttons and a display, and an app on a phone, with schedules, settings, and alerts. A user may set a schedule in the app, change it on the device, or lose both after a power cut, and the manual must explain how those two interfaces interact, not merely how each one works in isolation.

The manual should therefore start with a map: what can be done on the device, what can be done in the app, and what happens when the two disagree. That map, presented early, prevents the most common connected product confusion, which is a user changing a setting in one place and wondering why the other place still shows the old setting.

Power cuts are a revealing test for a connected manual. After a power cut, a thermostat may restart with a default schedule, may lose a schedule set only in the app, or may take time to reconnect and show an outdated temperature. The manual should explain, in order, what the device does after power returns, what the app does, how long reconnection may take in general terms, and what a user should check before trusting the displayed schedule again.

Schedule recovery should be written as steps, not as reassurance. A manual that says schedules are saved, without saying where they are saved, how to restore them, or what to do if restoration fails, will not help a user whose home is cold because a schedule was lost. Steps, with a clear check at the end, turn reassurance into guidance.

Illustration: a brand tests a thermostat manual with 40 users and imagines that 20 of them, in round illustration terms, cannot restore a schedule after a power cut using only the manual. Those figures, as presented in Manuals for connected products that cover the app as well as the device, are invented, not measured. They show why manuals must be tested with users, in realistic situations, rather than read by the writer who already knows how the product works. A manual that only works for its writer is not a manual at all.

Testing should include power cuts, app updates, and device and app disagreement, because those are the situations where users actually open a manual, rather than the smooth first setup that manuals usually describe well.

Troubleshooting should be ordered by likelihood and by user action, not by technical system. A user whose thermostat shows the wrong temperature should first be told simple checks, such as power, connection, and schedule, before being told about advanced settings or resets that may erase a schedule. That order prevents a troubleshooting step from causing a worse problem than the one it was meant to fix.

• Map device actions, app actions, and what happens when they disagree.
• Explain power cut behaviour, reconnection, and schedule checking in steps.
• Write schedule recovery as steps with a final check, not as reassurance.
• Order troubleshooting by likelihood, starting with simple checks.

Connected manuals often fail by describing the device beautifully and the app briefly, or vice versa. A manual that spends pages on device buttons, but only a paragraph on app schedules, will leave app users without guidance, while a manual that focuses on the app will leave device only users confused. Balance should follow user behaviour, not the writer's familiarity with one interface.

Another failure is to write a manual for launch software only, and never update it when the app changes. App updates can move settings, rename features, or change schedule behaviour, and a manual that describes an old app will mislead users who have the new app. Manuals for connected products should be reviewed with every app update, not only at launch.

Close by using the thermostat manual to recover from a power cut, to change a schedule in the app, and to change it on the device, following the manual exactly. If those three tasks succeed without extra help, the manual works for connected use. If any task fails, the manual section for that task needs rewriting.

Review the manual whenever the app, device, or schedule behaviour changes, and test it again with users in difficult situations. A connected manual stays useful only if it keeps pace with the connected product it describes.