17  Design Thinking for IoT

17.1 Learning Objectives

After completing this chapter, you will be able to:

  • Apply the five-phase design thinking methodology (Empathize, Define, Ideate, Prototype, Test) to IoT product development
  • Conduct effective user research using contextual inquiry, interviews, and journey mapping during the Empathize phase
  • Formulate problem statements and “How Might We” questions that focus on user needs rather than technical features
  • Evaluate and prioritize solution concepts using scoring criteria during the Ideate phase
  • Design appropriate fidelity prototypes matched to specific validation goals
  • Assess user testing results using task success rates, completion times, and severity classifications

Design thinking is a structured approach to solving problems that starts with understanding the people who will use your product, not with the technology. It follows five phases: Empathize (observe real users), Define (frame the actual problem), Ideate (brainstorm solutions), Prototype (build quick test versions), and Test (validate with users). For IoT, this is critical because engineers often build what is technically impressive rather than what users actually need. Design thinking forces you to ask “What problem are we solving for real people?” before asking “What sensors should we use?”

“I want to build a smart plant watering system, but where do I start?” asked Sammy the Sensor. Max the Microcontroller pulled out a five-step plan. “Design thinking! Step one: Empathize – go watch how people actually water their plants. What do they struggle with? Forgetting? Overwatering? Traveling?”

“Step two: Define the problem clearly,” continued Lila the LED. “Maybe the real problem is not ‘I need a watering gadget’ but ‘My plants die when I go on vacation.’ That changes what you build! Step three: Ideate – brainstorm lots of ideas. Moisture sensor plus pump? Timer-based drip system? Self-watering pot?”

Bella the Battery finished, “Step four: Prototype – build a quick, rough version to test. Use cardboard, tape, and a basic circuit. Do not make it perfect! Step five: Test it with real people. Watch them use it. Do they get confused? Does it actually save plants? Then go back and improve. The secret is that you repeat these steps over and over until it is great!”

17.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Key Concepts

  • Design Model: Abstract representation of system behaviour, user interaction, and data flow used to guide implementation decisions.
  • Calm Technology: Design philosophy creating technology that informs without demanding attention, residing at the periphery of user awareness.
  • Design Thinking: Human-centred innovation process: empathise, define, ideate, prototype, and test in iterative cycles.
  • Reference Architecture: Documented, validated design pattern for a class of IoT systems, reducing design time and avoiding known pitfalls.
  • Facet Model: Framework decomposing IoT system design into orthogonal dimensions (physical, cyber, social) for structured analysis.
  • Context Awareness: System capability to sense and respond to its physical, social, and operational environment.
  • System-of-Systems: IoT architecture where multiple autonomous systems interact to produce emergent capabilities no single system provides alone.

17.3 Introduction to Design Thinking for IoT

Design thinking provides a human-centered approach to IoT product development. Unlike traditional engineering approaches that start with technical specifications, design thinking starts with understanding user needs and iterates through rapid prototyping and testing.

Design thinking process diagram showing five iterative phases - empathize, define, ideate, prototype, and test - with feedback loops connecting all phases in a cyclical workflow
Figure 17.1: Design thinking process for IoT showing five iterative phases: empathize with users, define problem statements, ideate solutions, prototype quickly, and test with real users, with feedback loops connecting all phases.

Why Design Thinking for IoT?

IoT products face unique challenges that make design thinking especially valuable:

  • Physical + Digital: Users interact with both hardware and software
  • Multiple Touchpoints: Mobile apps, voice interfaces, physical devices, web dashboards
  • Environmental Context: Devices operate in real-world settings with constraints
  • Long-term Usage: Unlike apps, IoT devices may be used for years

17.4 Phase 1: Empathize

Understand user needs, pain points, and context

The Empathize phase is about deeply understanding the people you’re designing for. For IoT products, this means understanding not just user behaviors but also their physical environment, daily routines, and technical comfort level.

17.4.1 Research Methods for IoT

Contextual Inquiry (Observe users in their natural environment)

  • Watch how users interact with existing solutions (or work around their absence)
  • Note environmental factors: lighting, noise, physical layout, other devices
  • Observe workarounds and “hacks” that reveal unmet needs
  • Example: Observing how elderly users manage medication reveals they often forget doses when routine is disrupted (travel, visitors)

User Interviews (Understand motivations and frustrations)

  • Ask about goals, not features (“What are you trying to accomplish?”)
  • Probe for pain points (“What’s the hardest part about…?”)
  • Understand context (“Walk me through your typical morning…”)
  • Example interview questions for smart home:
    • “What’s the most frustrating thing about your current thermostat?”
    • “When do you feel most comfortable at home? What contributes to that?”
    • “Have you ever come home to a problem you wish you’d known about earlier?”

Journey Mapping (Identify pain points and opportunities)

User journey map for smart thermostat showing emotional states across phases - awareness, purchase, setup, daily use, maintenance - with setup phase highlighted in red as key pain point requiring design attention
Figure 17.2: User journey map for smart thermostat showing emotional states at each phase - setup phase (red) identified as key pain point requiring design attention.

Creating Personas (Represent key user archetypes)

Create 2-4 personas representing distinct user types:

Persona Profile Goals Pain Points
Tech-Savvy Tom 35, software engineer Automate everything, integrate with existing smart home Frustrated by closed ecosystems, wants API access
Busy Parent Priya 42, working mom of 3 Simple solutions that “just work” No time to configure, needs reliability
Senior Sam 68, retired teacher Stay independent at home Intimidated by technology, needs large buttons/text
Eco-Conscious Emma 28, sustainability advocate Reduce energy consumption Wants detailed usage data and environmental impact

17.5 Phase 2: Define

Articulate the problem clearly

The Define phase synthesizes Empathize research into actionable problem statements. The key is focusing on user needs, not jumping to solutions.

17.5.1 Synthesizing Insights

Look for patterns across research:

  • What frustrations came up repeatedly?
  • What workarounds did multiple users employ?
  • Where did observed behavior differ from stated preferences?

Example Insight: During Empathize, elderly medication users said they wanted smartphone notifications, but observation showed phones were often in other rooms. The insight: “Users need reminders they’ll notice regardless of phone location.”

17.5.2 Creating Problem Statements

Use the format: [User] needs a way to [accomplish goal] because [insight about why current solutions fail].

Examples:

  • “Busy parents need a way to monitor home temperature remotely because they can’t check on their home during work hours and worry about comfort when they return.”
  • “Elderly users living alone need a way to receive medication reminders they’ll notice because smartphone notifications are missed when phones aren’t nearby.”

17.5.3 “How Might We” Questions

Reframe problems as opportunities:

  • “How might we help busy parents feel confident their home is comfortable without requiring constant monitoring?”
  • “How might we deliver medication reminders that reach users regardless of where their phone is?”

17.5.4 Balancing Trade-offs

IoT design involves inherent trade-offs. Document these during Define:

Design trade-off matrix showing key IoT design tensions - battery life vs features, security vs usability, local processing vs cloud connectivity, cost vs capability - positioned on axes based on user priorities and market positioning
Figure 17.3: Key IoT design trade-offs that must be balanced during the Define and Ideate phases based on user priorities and market positioning.

17.6 Phase 3: Ideate

Generate multiple solution concepts

Ideation is about generating many ideas before narrowing down. Resist the urge to evaluate too early.

17.6.1 Brainstorming Techniques

Quantity Over Quality (Initially)

  • Aim for 20-50 ideas before evaluating any
  • Build on others’ ideas (“Yes, and…”)
  • Defer judgment–wild ideas often lead to practical innovations

SCAMPER Method

Technique Application to IoT Thermostat
Substitute Replace touch screen with voice control
Combine Combine thermostat + air quality sensor + humidity control
Adapt Adapt smartwatch interface patterns for wall device
Modify Modify display to show energy cost instead of temperature
Put to other use Use motion sensor for security, not just occupancy
Eliminate Remove app requirement–device works standalone
Reverse Instead of user programming schedule, device proposes schedule

Crazy 8s (Rapid sketching)

  • Fold paper into 8 sections
  • Sketch 8 different solutions in 8 minutes (1 minute each)
  • Forces rapid ideation without overthinking
  • Works for both interface concepts and physical form factors

17.6.2 Evaluating Ideas

Score ideas against criteria:

Idea User Value (1-5) Technical Feasibility (1-5) Novelty (1-5) Total
Voice-only thermostat 4 3 3 10
Thermostat learns from neighbors 3 2 5 10
Ambient light display for status 5 5 2 12
Thermostat with local AI 4 3 4 11

Select top 3-5 concepts for prototyping.

17.7 Phase 4: Prototype

Create quick, low-fidelity prototypes

Prototypes answer questions. The key is matching prototype fidelity to the question you’re trying to answer.

Prototype fidelity progression diagram showing evolution from low-fidelity paper sketches (hours, minimal cost) through breadboard prototypes (days, moderate cost) to high-fidelity production-ready designs (weeks, high cost)
Figure 17.4: Prototype fidelity progression from paper sketches (hours, minimal cost) through breadboard prototypes to production-ready designs.

17.7.1 Prototype Types for IoT

Paper Prototypes (Test interface concepts)

  • Sketch screens on paper, user “taps” to navigate
  • Designer swaps papers to simulate transitions
  • Time: minutes to create
  • Validates: Information architecture, user flows, terminology

Cardboard Mockups (Test physical form)

  • Create physical mockup of device size/shape
  • Users hold it, place it in intended location
  • Time: 1-2 hours
  • Validates: Form factor, placement, physical interaction

The cost-benefit of different prototype fidelities follows a power law. For a smart mailbox sensor project:

Paper prototype (2 hours, $0):

  • Tests: UI layout, notification wording
  • Learns: Users want “package arrived” vs “mail arrived” distinction (10 test users, 2 hours)

Breadboard prototype (3 days, $85 in parts):

  • Tests: Sensor placement, detection accuracy
  • Battery life estimate: CR2032 coin cell (220 mAh) with ESP32 deep sleep \[t_{\text{battery}} = \frac{220 \text{ mAh}}{I_{\text{avg}}} = \frac{220}{0.15 \text{ mA}} \approx 61 \text{ days}\] where \(I_{\text{avg}} = \frac{(5 \text{ mA} \times 2 \text{ s}) + (10 \mu\text{A} \times 598 \text{ s})}{600 \text{ s}} \approx 0.15\) mA for 10-minute wake intervals.

3D-printed enclosure (1 week, $340):

  • Tests: Weatherproofing, mounting
  • Learns: Mailbox metal blocks Wi-Fi; pivot to LoRaWAN ($12 added BOM cost but 3x range)

ROI formula: \(\text{Cost per insight} = \frac{\text{Prototype cost}}{\text{Number of design flaws discovered}}\). Paper = $0/insight, breadboard ≈ $12/insight for critical flaws.

Wizard of Oz (Test intelligent behaviors)

  • Fake the “smart” part with human behind the scenes
  • User interacts with prototype; human simulates AI responses
  • Time: hours to days
  • Validates: User understanding of automated behaviors, trust in system decisions

Functional Breadboard (Validate technical feasibility)

Example ESP32 functional prototype for smart lock:

#include <WiFi.h>
#include <PubSubClient.h>
#include <Wire.h>
#include <Adafruit_SSD1306.h>

// Prototype configuration
const char* WIFI_SSID = "prototype_network";
const char* MQTT_SERVER = "test.mosquitto.org";

// Hardware pins
const int PIR_PIN = 14;
const int SERVO_PIN = 13;

// Display
Adafruit_SSD1306 display(128, 64, &Wire, -1);

// MQTT client
WiFiClient espClient;
PubSubClient mqtt(espClient);

void setup() {
  Serial.begin(115200);

  // Initialize hardware
  pinMode(PIR_PIN, INPUT);
  pinMode(SERVO_PIN, OUTPUT);

  // Initialize display
  if(!display.begin(SSD1306_SWITCHCAPVCC, 0x3C)) {
    Serial.println("Display failed");
  }
  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(0, 0);
  display.println("Smart Lock v0.1");
  display.display();

  // Connect to Wi-Fi
  WiFi.begin(WIFI_SSID);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  // Connect to MQTT
  mqtt.setServer(MQTT_SERVER, 1883);
  mqtt.setCallback(mqttCallback);
  connectMQTT();
}

void loop() {
  if (!mqtt.connected()) connectMQTT();
  mqtt.loop();

  // Simple motion detection
  int motion = digitalRead(PIR_PIN);

  if (motion == HIGH) {
    Serial.println("Motion detected");
    displayMessage("Motion Detected");
    mqtt.publish("smartlock/motion", "detected");
    delay(1000);  // Simple debounce
  }
}

void displayMessage(const char* msg) {
  display.clearDisplay();
  display.setCursor(0, 20);
  display.println(msg);
  display.display();
}

void mqttCallback(char* topic, byte* payload, unsigned int length) {
  String message;
  for (int i = 0; i < length; i++) {
    message += (char)payload[i];
  }

  Serial.printf("MQTT: %s = %s\n", topic, message.c_str());

  if (String(topic) == "smartlock/unlock") {
    analogWrite(SERVO_PIN, 180);
    displayMessage("Unlocked");
    delay(3000);
    analogWrite(SERVO_PIN, 0);
    displayMessage("Locked");
  }
}

void connectMQTT() {
  while (!mqtt.connected()) {
    if (mqtt.connect("SmartLockPrototype")) {
      mqtt.subscribe("smartlock/unlock");
      Serial.println("MQTT connected");
    } else {
      delay(5000);
    }
  }
}

17.8 Phase 5: Test

Validate prototypes with users

Testing closes the loop, revealing whether your design actually solves user problems.

17.8.1 Planning User Tests

Define Testing Tasks (Match real use cases)

  • Bad: “Click the settings button”
  • Good: “Your house feels cold. Make it warmer.”

Select Representative Users

  • 5-8 users per iteration is sufficient to find major issues
  • Include users from each persona type
  • Don’t test with colleagues or friends (they’re not representative)

Prepare Testing Protocol

  1. Welcome and explain purpose (2 min)
  2. Background questions (5 min)
  3. Task scenarios (20-30 min)
  4. Debrief and open questions (10 min)

17.8.2 Conducting Tests

Think-Aloud Protocol

  • Ask users to verbalize thoughts while using prototype
  • “Tell me what you’re thinking as you try to accomplish this…”
  • Reveals mental models and points of confusion

Observe Behavior, Not Just Opinions

What Users SAY What Users DO
“This is pretty intuitive” Clicked wrong button 3 times before finding correct one
“I would definitely use this” Gave up on task after 2 minutes
“The setup was easy” Required 15 minutes and 3 restarts

Measure Success

  • Task success rate: % who completed task correctly
  • Time to completion: How long tasks took
  • Error rate: Wrong clicks, restarts, confusion points
  • User satisfaction: Post-task rating (1-5)

17.8.3 Interpreting Results

Success Rate Guidelines

  • 80%+ success: Design is working, minor refinements needed
  • 50-80% success: Significant issues, iterate on specific problems
  • <50% success: Fundamental problems, may need to revisit Define/Ideate

Prioritize Findings

Severity Description Example
Critical Prevents task completion User couldn’t figure out how to arm security system
Major Significantly slows task User took 5 minutes to find temperature setting
Minor Causes confusion but doesn’t block User wasn’t sure if change was saved
Enhancement Would improve experience User suggested voice confirmation

17.8.4 Iteration

Based on test findings:

  • Minor issues: Refine prototype, test again with same or new users
  • Major issues: Return to Ideate phase, generate new approaches
  • Fundamental problems: Return to Define phase, reframe the problem

Design thinking is iterative–expect 3-5 cycles before production-ready design.

17.9 Worked Example: Design Thinking for a Smart Medication Dispenser

Scenario: MediRemind is designing a smart medication dispenser for elderly users (age 70+) living independently. The device must manage up to 8 daily medications, alert users when doses are due, and notify caregivers of missed doses.

Iteration 1: Research reveals the real problem

Phase Activity Time Key Finding
Empathize In-home observation of 12 elderly users 3 days Users don’t “forget” medication – they get confused about which pill to take and whether they already took it
Define Affinity mapping of 47 observations 1 day Problem statement: “Elderly users need certainty that they’re taking the right pill at the right time without reading small text or pressing complex buttons”
Ideate Crazy 8s session with 4 team members 2 hours 32 concepts generated; top 3: (A) voice-guided dispenser, (B) light-up compartment, (C) phone app with large buttons
Prototype Paper mockup of concept B 1 day Cardboard box with colored LEDs indicating which compartment to open
Test 5 users, think-aloud protocol 2 days 4/5 users understood “open the lit compartment.” But 3/5 couldn’t close it properly, causing double-dose risk

Iteration 2: Fix the closure problem

The closure issue sent the team back to Ideate. New concept: the compartment locks after dispensing and only unlocks at the next scheduled time.

Metric Iteration 1 Iteration 2
Task success rate 80% (open correct compartment) 100% (locked mechanism prevents errors)
Time to take medication 45 seconds average 12 seconds average
Double-dose incidents 3 out of 15 test sessions 0 out of 15 test sessions
User satisfaction (SUS) 62 (below average) 78 (above average)

Iteration 3: Address caregiver notification

Testing revealed caregivers wanted to know why a dose was missed (device unplugged? user not home? user chose to skip?) – not just that it was missed. This led to a context-aware notification system.

Notification Type When Sent Information Included
Gentle reminder (to user) 5 min after scheduled time Audio chime + lit compartment
Escalation (to user) 15 min after scheduled time Louder chime + voice message “Time for your blue pill”
Caregiver alert 30 min after scheduled time Push notification with reason: “Dose missed – device detected user is home”
Informational Daily at 8 PM Summary: “3/3 doses taken today on time”

Total design thinking investment: 4 weeks, 3 iterations, $2,800 in prototype materials. This caught the double-dose safety risk (Iteration 1) before any electronics were built – fixing it in cardboard cost $0 versus an estimated $45,000 for a post-production recall.

Common Pitfalls

Adding too many features before validating core user needs wastes weeks of effort on a direction that user testing reveals is wrong. IoT projects frequently discover that users want simpler interactions than engineers assumed. Define and test a minimum viable version first, then add complexity only in response to validated user requirements.

Treating security as a phase-2 concern results in architectures (hardcoded credentials, unencrypted channels, no firmware signing) that are expensive to remediate after deployment. Include security requirements in the initial design review, even for prototypes, because prototype patterns become production patterns.

Designing only for the happy path leaves a system that cannot recover gracefully from sensor failures, connectivity outages, or cloud unavailability. Explicitly design and test the behaviour for each failure mode and ensure devices fall back to a safe, locally functional state during outages.

17.10 Summary

This chapter presented the design thinking methodology for IoT product development:

Key Takeaways:

  1. Empathize First: Deeply understand users through observation, interviews, and journey mapping before defining solutions

  2. Define the Right Problem: Synthesize insights into problem statements focused on user needs, not technical features

  3. Ideate Broadly: Generate many ideas before evaluating; use techniques like SCAMPER and Crazy 8s to expand thinking

  4. Prototype to Learn: Match prototype fidelity to the questions you’re answering–paper for concepts, breadboard for technical feasibility

  5. Test with Real Users: Observe behavior (not just opinions), measure success rates, and iterate based on findings

  6. Embrace Iteration: Design thinking is cyclical–expect multiple cycles through phases before achieving production-ready designs

  7. Balance Trade-offs: Document and consciously balance IoT-specific trade-offs (battery vs features, security vs usability, local vs cloud)

17.11 Knowledge Check

Design Thinking for IoT relates to:

Where Design Thinking Fits: Architecture defines structure (layers, components). Design thinking validates that structure meets real user needs through iterative testing. Without design thinking, you risk building technically sound systems nobody wants to use.

Key dependency: You cannot skip Empathize. Many failed IoT products result from teams jumping straight to Ideate (“Let’s build a smart fork!”) without understanding actual user problems.

Design Thinking Resources:

IoT-Specific Design Thinking:

Prototyping Tools:

  • Figma - UI/UX prototyping for mobile apps and dashboards (free tier available)
  • Balsamiq - Low-fidelity wireframing tool (intentionally rough to avoid premature polish)
  • Arduino + Tinkercad Circuits - Functional breadboard prototyping (physical + simulated)
In 60 Seconds

This chapter covers design thinking for iot, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

Academic Papers:

  • Brown & Katz (2009) - “Change by Design” - Foundational design thinking methodology
  • Zimmerman et al. (2007) - “Research Through Design as a Method for Interaction Design Research in HCI” - Academic grounding for iterative prototyping

17.12 What’s Next

Previous Current Next
IoT Design Facets & Calm Tech Design Thinking for IoT Design Patterns and Components

The next chapter explores Design Patterns and Components, examining reusable architectural patterns (Gateway, Digital Twin, Command, Observer), component-based design approaches, and model-driven development for IoT systems.

Design Model Series:

Prototyping:

Human Factors: