Connected Product and Service Design · Study deck
Design Thinking for IoT
Design thinking for IoT starts with a messy field problem, not a tidy screen brief.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Review design thinking as evidence, not only as a five-step label.
- Connect empathy research to IoT context, physical setting, routines, devices, and constraints.
- Frame problem statements that avoid early sensor, app, cloud, or automation assumptions.
- Select prototype detail based on the question being tested.
Major section
Design Thinking for Devices
In IoT, design thinking must leave the workshop and reach the real site.
- A team can run a perfect workshop and still miss a label that no one can reach.
- The useful result is not a poster naming Empathize, Define, Ideate, Prototype, and Test.
- User evidence covers roles, routines, language, physical access, accessibility, trust, and support handoffs.
Major section
Design Thinking for Devices (continued)
The team then chooses an idea and builds a prototype, which is a model made for learning.
- For an IoT review, every pass through the loop should include both user evidence and system evidence.
- System evidence covers device placement, radio conditions, power source, sensing limits, data path, permissions, local fallback, update behavior, and service ownership.
- If either side is missing, the design may be pleasant in a demo and still fail in deployment.
Major section
Test Hardest Assumptions
A QR/BLE onboarding flow should be tested where the label is mounted, under the lighting and posture users will actually face.
- A maintenance alert should be tested with operator workload, handoff rules, escalation timing, and false-alarm tolerance.
- If a human is simulating automation, call it Wizard-of-Oz.
- If data is mocked, label it as mocked.
Major section
Test Hardest Assumptions (continued)
If a device is tethered to USB power, do not infer battery life.
- A sensing concept should be tested against sensor placement, calibration, power, enclosure effects, and data quality before the dashboard is polished.
- Prototype interaction risk: Use paper sketches, Figma flows, physical labels, NFC tags, QR codes, BLE pairing mocks, and accessibility checks to test setup language, reach, permission, and recovery.
- If support logs are not wired, do not claim the issue is diagnosable.
Major section
Test Hardest Assumptions (continued)
Prototype technical risk: Use ESP32, nRF52, Arduino, Raspberry Pi, or a bench sensor rig to test sensing, latency, battery draw, enclosure placement, and connectivity claims.
- Prototype service risk: Use Mosquitto or another MQTT broker, Node-RED, Home Assistant, mock APIs, or a support dashboard stub to test alert routing, stale state, ownership transfer, and escalation paths.
- It also helps engineering separate UX evidence from technical feasibility evidence, so a team does not treat a successful Figma flow as proof that provisioning, telemetry, or support routing is production-ready.
- This record prevents a prototype from becoming an undocumented promise.
Major section
Research Data as Product Risk
The technical prototype also changes what can be learned.
- IoT research can collect sensitive traces even during early prototypes.
- Presence, location, voice, image, health, home routines, worker behavior, and machine status can reveal more than a participant expects.
- BLE setup tests reveal proximity and permission friction but not long-term network reliability.
Major section
Research Data as Product Risk (continued)
Design thinking for IoT therefore needs data minimization, consent boundaries, retention limits, and safe test environments before prototypes leave the lab.
- A researcher watching a setup task may also capture bystander behavior, room occupancy, worker performance, or household routines that were never needed for the design question.
- MQTT dashboards can reveal stale-state and topic-design issues but not enclosure fit.
- Under the hood, the best design-thinking records behave like lightweight traceability.
Major section
Research Data as Product Risk (continued)
A pilot deployment can reveal maintenance and support load but may expose users to real false alarms or privacy harm.
- The chapter reviewer should therefore ask which claims are supported by the prototype fidelity and which claims still need engineering, security, privacy, or operations evidence.
- Separate signals: distinguish user observation, sensor reading, inferred state, system log, support event, and participant quote summary.
- Bound claims: tie each finding to the prototype fidelity, participant role, environment, and failure states actually tested.
- Control drift: reopen the design when the device form, deployment context, data path, permission model, automation rule, or support workflow changes.
Major section
Design Thinking Evidence Map
Ideate opens several possible answers, and Prototype makes one question tangible enough to test.
- Problem frame: user need, trigger, consequence, current workaround, non-goal, and assumption.
- User test evidence: tasks, observations, errors, hesitation, recovery, accessibility barriers, and support clues.
- Change condition: new user group, device form, environment, automation, data path, permission model, or support workflow.
Major section
Empathize: Observe The Real Situation
Empathy in IoT includes more than opinions.
- Observation should capture what people do, what devices do, and what the environment makes possible or difficult.
- For IoT, the field context is often the product requirement.
- Lighting, distance, wall material, shared access, noise, wet hands, gloves, weak connectivity, low battery, and household routines can matter as much as screen layout.
Major section
Match Fidelity to the Question
Prototypes should answer specific questions.
- A polished prototype can be wasteful if the question is still about terminology, placement, or trust.
- A rough prototype can be dangerous if the question is about physical safety, power behavior, or failure recovery.
- The review should ask whether the prototype teaches the next decision, not whether it looks impressive.
Major section
Design Thinking Record
Field context names the people, setting, constraints, and limits of the evidence.
- The problem frame states the need and barrier; the idea set preserves alternatives and why one was chosen.
- The final ownership and reopen fields prevent a single positive session from becoming a permanent design claim.
- Field context: users, roles, setting, routine, constraints, workarounds, and evidence limits.
Major section
Design Thinking Record (continued)
Prototype question: uncertainty tested, fidelity, scenario, and represented failure states.
- Risk review: privacy, safety, security, consent, inclusion, reliability, support, and lifecycle risks.
- Decision follow-up: accepted tradeoff, owner, known limit, open issue, and change condition.
- The record should remain short enough to update after each meaningful research or test cycle.
Major section
Worked Review: Shared Appliance Setup
A team is designing setup for a shared connected appliance used by residents, maintenance staff, and support.
- The first proposal assumes each resident will install an app and scan a code.
- Field notes on how residents, maintenance staff, and support identify, access, and fix the appliance.
- Problem frames that separate "add the appliance to an app" from the real need: confirm the appliance, authority, status, and recovery.
Major section
Worked Review: Medication Adherence Concept
Pills may look confusing and alike.
- Routines may be dull and easy to forget.
- Alarms may feel like nagging and be dismissed.
- Patients may also reject constant monitoring by family or caregivers.
- They preferred a caregiver alert only when help was needed to constant tracking.
Major section
Common Findings
The team labels the process "design thinking" but starts with a chosen technology.
- Problem statements describe a feature rather than a user need.
- Prototype fidelity is higher than needed for the question being tested.
- Testing measures satisfaction but not task success, recovery, or misunderstanding.
- IoT-specific failure states are omitted from prototypes and tests.
Deck summary
Key takeaways
In IoT, design thinking must leave the workshop and reach the real site.
- The team then chooses an idea and builds a prototype, which is a model made for learning.
- A QR/BLE onboarding flow should be tested where the label is mounted, under the lighting and posture users will actually face.
- If a device is tethered to USB power, do not infer battery life.
- Prototype technical risk: Use ESP32, nRF52, Arduino, Raspberry Pi, or a bench sensor rig to test sensing, latency, battery draw, enclosure placement, and connectivity claims.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A team wants residents to set up a shared laundry-room sensor by scanning a QR code on the device. What finding should most change the next prototype?
Show answer
Answer: A Design thinking is strongest when field observations change the next prototype question instead of simply confirming that a polished flow can work in ideal conditions.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A team says they completed design thinking because users said they liked a connected-device prototype. The notes do not show field context, task behavior, failure states, or what changed after testing. How should reviewers decide whether this design cycle is complete?
Show answer
Answer: A Design thinking is useful when decisions are traceable to observed context, problem framing, prototype questions, task behavior, iteration decisions, and risk checks.
Print reference
Answers
Answer key.
- A · Design thinking is strongest when field observations change the next prototype question instead of simply confirming that a polished flow can work in ideal conditions.
- A · Design thinking is useful when decisions are traceable to observed context, problem framing, prototype questions, task behavior, iteration decisions, and risk checks.