2 Human-Centred Design for IoT

2.1 Worked Example: One Person in One Place

This section: Worked Example: One Person in One Place — Imagine a technician ignoring a “smart” alert because it arrives during the wrong task, names the wrong equipment, or asks for action they cannot take.

Imagine a technician ignoring a “smart” alert because it arrives during the wrong task, names the wrong equipment, or asks for action they cannot take. Design thinking starts there: with the person, place, decision, and consequence that make connectivity useful or unnecessary. The IoT design work comes after the team can explain whose problem is being solved and what evidence would prove the first build slice is worth continuing.

Inspect the story panels and ask what the team must learn before changing the technician’s alert workflow.

Read the four story panels from the ignored alert to the evidence gate. The first two show why a technically delivered message can still fail: it interrupts the wrong task, names the wrong machine, and requests an action outside the recipient’s authority. The third panel turns that failure into a design frame by naming the person, place, decision, and intended result. The final panel makes continuation conditional on evidence that one connected slice actually helps. This sequence establishes the chapter’s starting discipline. Hardware and interface choices come after the workflow claim is explicit enough to test, and an unfavorable result can simplify or stop the connected design.

2.2 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Explain why design thinking matters for connected products with hardware, software, data, and field operations.
• Distinguish technology-push ideas from user-centred problem framing.
• Describe the seven design thinking phases used in this module.
• Write a problem statement using the pattern: user, need, and insight.
• Map assumptions to evidence before committing to expensive implementation decisions.
• Identify early validation artifacts that reduce IoT product risk.

2.3 Design Thinking Controls Risk

This section: Design Thinking Controls Risk — Connected products fail when the team proves the technology before proving the situation.

Connected products fail when the team proves the technology before proving the situation. Design thinking starts with the person, place, task, and consequence, then asks what sensing, connectivity, automation, and support actually need to exist.

For a shared cold-room monitor, the first design question is not which dashboard to build. It is who notices spoilage risk, where the probe can be trusted, how staff respond during a shift handoff, what happens when Wi-Fi is weak, and who owns the alarm after hours. The answer may still lead to a connected sensor, but the product decision starts from workflow risk rather than from the sensor catalog.

Inspect Figure 2.1 and ask where field evidence can overturn the team’s original problem frame.

+

Read Figure 2.1 from users to the problem and possible options. The first move turns observed work and limits into a need worth solving. It does not assume that a network is the answer. Tests then compare each option with both user and system proof. A sound device may still fail on trust, access, upkeep, or who owns the response. Safe release is another gate, not the end of design. Field signals send the team back when real use breaks an assumption. The loop controls IoT risk only when what people want, what can be built, and what the field shows can all change the choice.

The same discipline applies to less obvious products. A school air-quality project should ask who can act on a ventilation warning, whether teachers can trust a CO2 threshold during a crowded lesson, how the device behaves after a power cut, and whether data should be stored by room, class, or anonymous zone. A medication reminder should ask whether the user needs a cap sensor, a phone reminder, caregiver escalation, a pharmacy workflow, or a simpler printed routine. These questions keep the team from confusing connectivity with usefulness.

Design thinking is therefore a risk-control loop. Desirability checks whether a named person has a real decision, pain point, or trust barrier. Feasibility checks whether hardware, firmware, radio, cloud service, app, support, and update paths can work in the real setting. Viability checks whether the organization can pay for installation, operations, incident response, compliance, and maintenance after the prototype demo is over. A team should not treat any one of those as optional; an IoT product has to satisfy all three to survive the field.

• Desirability: The connected feature must improve a real decision or action for a named user.
• Feasibility: The device, firmware, radio, cloud path, app, and support process must fit the installation context.
• Viability: The organization must be willing and able to operate the product after the prototype works.

2.4 Prototype the Riskiest Unknown First

This section: Prototype the Riskiest Unknown First — The practical move is to choose the smallest prototype that can change the team’s mind.

The practical move is to choose the smallest prototype that can change the team’s mind. A journey map may test whether the problem frame is real. A Figma flow may test whether a nurse, technician, or facilities manager understands the alarm path. An ESP32 board with an SHT31 sensor may test enclosure placement and sampling stability. A Node-RED dashboard or MQTT broker mock may test who receives the message and what they do next.

Each prototype should name its boundary. A BLE provisioning demo does not prove LoRaWAN coverage. A cloud dashboard does not prove an OTA update path. A paper workflow does not prove identity, audit, or data-retention behavior. The team should match the prototype to the assumption, then stop before it becomes production by accident. The boundary should be written into the review note so later stakeholders do not overclaim what was learned.

A useful design-thinking pass produces artifacts that engineers and operators can use. Interview notes become user needs and constraints. A journey map becomes alert-state requirements. A storyboard becomes setup and recovery screens. A bench prototype becomes sensor-placement evidence, calibration notes, battery observations, and packet traces. A field pilot becomes release criteria, support scripts, and telemetry definitions. The point is not to slow engineering down; it is to make the first build slice answer a real question instead of creating disconnected work for hardware, firmware, cloud, and app teams.

Practitioners should also test simpler alternatives before committing to a connected product. A restaurant freezer problem may be solved by a better inspection routine, a mechanical thermometer with a sign-off sheet, or a local audible alarm. IoT becomes justified when the connected path changes the outcome: it reaches the right person faster, catches a hidden condition, provides evidence for compliance, or coordinates multiple sites. If the simpler alternative works, the design-thinking result is still useful because it prevents unnecessary device, data, security, and support burden.

1. Frame the user decision. State the person, context, action, and consequence before naming the device.
2. Select the cheapest credible test. Use sketches, clickable flows, bench firmware, gateway mocks, or field pilots only when they answer the current unknown.
3. Capture what changes. Decide whether the result changes the user need, sensor choice, communication path, service model, or release plan.

2.5 IoT Design Evidence Has Technical Shape

This section: IoT Design Evidence Has Technical Shape — IoT design evidence is not only interview notes.

IoT design evidence is not only interview notes. It can include radio survey results, battery discharge curves, calibration drift observations, packet-loss logs, broker message traces, OTA update outcomes, and support-ticket patterns. Those artifacts matter because the user experience is distributed across hardware, firmware, network, cloud service, interface, and operations.

The method therefore needs technical checkpoints. Sampling rate affects whether the product can detect the event. Link margin and gateway placement affect whether the user sees the alert. Device identity, credential rotation, and access control affect whether the product can be safely supported. Data retention and deletion rules affect whether collecting a signal is acceptable at all. Those checkpoints are design constraints, not late engineering cleanup.

Under the hood, design thinking turns vague risk into testable state. A connected pump controller should model normal, scheduled, manual override, dry-run lockout, offline, firmware-update, and fault states before the interface is drawn. A BLE medication cap should distinguish opened, missed, duplicate-open, low-battery, clock-drift, phone-not-nearby, caregiver-notified, and privacy-paused states. If the team only sketches the happy path, the first field trial will discover recovery behavior by accident, often after trust has already been damaged.

The evidence also has data contracts. A prototype may publish MQTT messages with timestamp, device_id, firmware_version, reading_value, battery_mv, and fault_code. That is enough to test a flow, but a release plan must decide which identifiers are personal data, which values are retained, which dashboard fields support a decision, and which logs support support diagnostics. AWS IoT Device Shadow, Azure IoT Hub device twins, LwM2M objects, or a simple fleet table can all represent device state; the design question is what state the user, operator, and support team actually need.

Security and privacy decisions belong inside the design loop because they change user trust and product viability. Provisioning, certificate rotation, role-based access, audit logs, consent copy, data deletion, and incident escalation are not separate from the experience. A design that asks a parent, nurse, tenant, or technician to trust automation must also show how authority, recovery, and accountability work when the device is wrong, offline, or compromised.

• State: Model normal, pending, offline, stale, failed, overridden, and recovered conditions before designing screens.
• Authority: Decide whether action belongs to the device, user, technician, automation rule, or external system.
• Recovery: Design the manual fallback and support path before relying on automation.

2.6 Why Design Thinking Matters for IoT

This section: Why Design Thinking Matters for IoT — IoT products do not fail only because a sensor is inaccurate or a network packet is dropped.

IoT products do not fail only because a sensor is inaccurate or a network packet is dropped. They also fail when the team solves the wrong problem, creates a workflow users do not trust, collects unnecessary data, or ships a device that cannot be installed, updated, supported, or recovered in the field.

Design thinking addresses that risk by forcing the team to ask three questions before it commits:

2.7 Technology Push vs User Pull

This section: Technology Push vs User Pull — A technology-push idea starts with a capability: a new sensor, model, radio, dashboard, or automation feature.

A technology-push idea starts with a capability: a new sensor, model, radio, dashboard, or automation feature. User pull starts with a real context and asks what intervention would improve it. IoT teams need both technical imagination and user evidence, but the order matters.

2.8 The Seven Phases

This section: The Seven Phases — This module uses seven phases because IoT products continue beyond prototype testing into release, operations, telemetry, and field iteration.

This module uses seven phases because IoT products continue beyond prototype testing into release, operations, telemetry, and field iteration.

The route in Figure 2.2 runs from empathize through implement and iterate; notice that later field learning can send the team back to an earlier phase.

+

The map in Figure 2.2 starts with interviews and ends with field learning; notice the return path.

2.9 The Problem Statement Pattern

This section: The Problem Statement Pattern — A strong design thinking problem statement is specific enough to guide solutions without naming the solution too early.

A strong design thinking problem statement is specific enough to guide solutions without naming the solution too early.

2.10 Assumption Mapping

This section: Assumption Mapping — Every IoT idea depends on assumptions.

Every IoT idea depends on assumptions. Design thinking makes those assumptions visible before the team spends effort on the wrong part of the system.

Inspect Figure 2.3 and ask which untested assumption could invalidate the product even if the sensor works.

+

Read Figure 2.3 across user value, build fit, operations, privacy, and cost. Each area turns a hidden belief into a question with an owner and test. The strength of proof differs by claim. An interview may support a work-flow claim. A bench trace can support timing, while a service drill can test who owns an alert. The gate on the right asks if the team should proceed, narrow the idea, or look again. A working sensor cannot fix an unowned support path or a harmful privacy plan. Keeping all five areas together stops the team from testing only the most visible technical risk.

2.11 Early Validation Artifacts

This section: Early Validation Artifacts — The first validation artifact should answer the riskiest open question, not impress the team.

The first validation artifact should answer the riskiest open question, not impress the team.

Inspect Figure 2.4 before treating a prototype as the centre of the plan. The Design Thinking Time Budget (10-Week Project) assigns 20% to Empathize and 15% to Define, so 35% of the schedule is deliberately spent understanding users, observing work, framing the problem, and writing point-of-view statements before the team invests in a build.

+

Across Figure 2.4, compare that 35% evidence investment with the remaining 65% for Ideate, Prototype, and Test. Ideate receives 10%, Prototype 25%, and Test the largest single allocation at 30%; the labels explicitly call for iterative low-fidelity models and repeated feedback rather than one large build. For the cold-room monitor, the first 3.5 weeks should therefore produce named staff roles, observed handoffs, network and mounting constraints, a bounded spoilage-risk statement, and assumptions ranked by consequence. The later 6.5 weeks can then test the smallest alarm, acknowledgement, offline, and escalation slices against those findings. Record the evidence source, unresolved assumption, prototype owner, acceptance result, and decision to continue, revise, or stop at each phase. At the Empathize gate, require field notes and a named actor; at Define, require a bounded outcome and the non-IoT alternative; at Ideate, retain compared options and rejection reasons; at Prototype, name the single uncertainty each artifact addresses; and at Test, preserve participant context, failures, recovery, and the changed decision. The product and operations owners sign the phase record together so delivery evidence cannot be separated from support responsibility. Schedule drift should not silently steal time from those gates. If access to users is delayed, the plan must expose the missing evidence and reduce downstream commitment rather than filling the calendar with implementation. The figure’s warning about failed projects inverting the ratio becomes a practical gate: procurement, enclosure work, and dashboard polish cannot compensate for an unverified workflow or an alarm no responsible person can act on.

2.12 Shared Cold-Room Monitoring

This section: Shared Cold-Room Monitoring — That idea is not yet a problem statement.

Initial idea:

That idea is not yet a problem statement. It names a device before it names the user need.

Empathize evidence:

• Supervisors check the cold room when they remember, not on a fixed schedule.
• Staff sometimes ignore alerts because door openings can create temporary changes.
• People want to know the next action, not only a measurement.
• The support path matters because no one wants another system that creates unclear responsibility.

Defined problem:

Early assumption map:

Design thinking lesson:

The team does not start by choosing a temperature sensor or cloud dashboard. It starts by proving whether alert clarity, placement, connectivity, and support ownership are the real blockers.

2.13 Knowledge Check

This section: Knowledge Check

2.14 Code Challenge: Problem Statement Check

This section: Code Challenge: Problem Statement Check

2.15 Common Pitfalls

This section: Common Pitfalls

2.16 References

This section: References — First: ISO 9241-210:2019: human-centred design principles and lifecycle activities for interactive systems.

First: ISO 9241-210:2019: human-centred design principles and lifecycle activities for interactive systems.

Next: GOV.UK Service Manual: User research: practical guidance for planning, running, and using user research.

Then: Google Design Sprint Kit: structured approach for moving from challenge framing to prototype and test.

After that: NIST SP 800-213: IoT cybersecurity guidance that helps shape connected-product risk and release gates.

Also inspect: NISTIR 8259A: IoT device cybersecurity capability baseline for considering secure device behavior early.

2.17 See Also

This section: See Also

• Project Planning
• Empathize and Define
• Ideate, Prototype, and Test
• Implement and Iterate
• IoT Validation Framework

2.18 What’s Next

This section: What’s Next — Continue to Empathize and Define to turn user evidence into a focused IoT problem frame.

Continue to Empathize and Define to turn user evidence into a focused IoT problem frame.

2.19 Summary

This section: Summary — Design thinking gives IoT teams a structured way to move from human needs to tested technical solutions.

Design thinking gives IoT teams a structured way to move from human needs to tested technical solutions. It is especially useful because IoT products combine physical context, software behavior, data, and long-term operations.

2.20 Key Takeaway

This section: Key Takeaway — Design thinking keeps IoT projects from becoming technology-first demos.

Design thinking keeps IoT projects from becoming technology-first demos. The method works when each technical decision remains tied to a user need and a validation test.