%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'clusterBkg': '#ECF0F1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph TD
A[Prototyping Fidelity Spectrum] --> B[Low-Fidelity]
A --> C[Medium-Fidelity]
A --> D[High-Fidelity]
B --> B1[Paper Prototypes]
B --> B2[Cardboard Mockups]
B --> B3[Storyboards]
B --> B4[Wizard of Oz]
C --> C1[Digital Mockups]
C --> C2[Breadboard Circuits]
C --> C3[Hybrid Prototypes]
D --> D1[Custom PCBs]
D --> D2[3D-Printed Enclosures]
D --> D3[Pilot Deployments]
B1 -.-> E[Purpose: Explore concepts<br/>Time: Hours<br/>Cost: $]
C1 -.-> F[Purpose: Validate approach<br/>Time: Days<br/>Cost: $$]
D1 -.-> G[Purpose: Refine details<br/>Time: Weeks<br/>Cost: $$$]
style B fill:#16A085
style C fill:#E67E22
style D fill:#2C3E50,color:#fff
1520 Prototyping Techniques for IoT
1520.1 Learning Objectives
By the end of this chapter, you will be able to:
- Select Appropriate Prototyping Fidelity: Choose paper, digital, or functional prototypes based on design stage and questions
- Create Low-Fidelity Prototypes: Build paper prototypes, physical mockups, storyboards, and Wizard of Oz simulations
- Build Medium-Fidelity Prototypes: Develop interactive digital mockups and breadboard circuits
- Develop High-Fidelity Prototypes: Design custom PCBs, 3D-printed enclosures, and pilot deployments
- Apply Prototyping to Real Projects: Follow a complete case study from empathy through shipping
1520.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- Interactive Design Principles: Understanding core design principles helps you know why different fidelity levels matter
- Interactive Design Process: Knowledge of the six-phase process shows where each prototyping technique fits
- Sensor Fundamentals: Basic understanding of sensors and actuators is useful for creating functional IoT prototypes
1520.3 Introduction
IoT systems combine physical hardware, embedded software, cloud services, and user interfaces, making prototyping more complex than traditional software. This chapter provides detailed techniques for each fidelity level and demonstrates application through a complete case study.
1520.4 Prototyping Fidelity Spectrum
{fig-alt=“Prototyping fidelity spectrum showing three levels: Low-Fidelity (paper prototypes, cardboard mockups, storyboards, Wizard of Oz - hours, low cost, explore concepts), Medium-Fidelity (digital mockups, breadboard circuits, hybrid prototypes - days, medium cost, validate approach), High-Fidelity (custom PCBs, 3D-printed enclosures, pilot deployments - weeks, high cost, refine details).”}
1520.5 Low-Fidelity Prototypes
Early-stage prototypes focus on core concepts and interactions, not technical implementation.
1520.5.1 Paper Prototypes and Sketches
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'clusterBkg': '#ECF0F1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph LR
A[Sketch<br/>Interface Ideas] --> B[Cut Out<br/>Paper Screens]
B --> C[Create<br/>Interactive Buttons]
C --> D[User Testing:<br/>Person acts as computer]
D --> E{User taps button}
E --> F[Facilitator swaps<br/>paper screen]
F --> G{User feedback}
G -->|Works| H[Keep design]
G -->|Confused| I[Sketch new version]
I --> B
style A fill:#E67E22
style D fill:#16A085
style H fill:#2C3E50,color:#fff
{fig-alt=“Paper prototyping workflow: Sketch interface ideas, cut out paper screens, create interactive buttons, conduct user testing where facilitator acts as computer swapping screens when user taps buttons. User feedback determines whether to keep design or sketch new version and iterate.”}
Purpose: Explore interface layouts and interaction flows very rapidly
Method: Hand-drawn screens with clickable paper buttons, team member acts as “computer”
Advantages: - Extremely fast and cheap (minutes, not hours) - Encourages exploration of many alternatives - Non-technical stakeholders can participate
Limitations: - Cannot test real-world context - No physical device interaction - No system performance testing
When to use: First week of design process, exploring 5-10 different concept directions
1520.5.2 Physical Mockups
Purpose: Test physical form factor, size, placement, and ergonomics
Materials: Cardboard, foam, 3D-printed shells, found objects
Example: Create cardboard “smart lock” to test whether users can operate it while holding grocery bags
WarningTradeoff: Low-Fidelity vs High-Fidelity Prototyping
Option A (Low-Fidelity): Paper sketches, cardboard mockups, and Wizard of Oz prototypes that can be created in hours for $0-50. User studies show 85% of usability issues are discoverable with lo-fi prototypes. Encourages rapid iteration and stakeholder participation regardless of technical skill. Option B (High-Fidelity): Functional prototypes with custom PCBs, 3D-printed enclosures, and working firmware that take weeks and cost $500-2000+. Reveal issues invisible in mockups: latency perception, physical ergonomics under real conditions, sensor accuracy, and battery life concerns. Decision Factors: Use low-fidelity when exploring concept viability, testing user flows, and early in the design process (weeks 1-4). Use high-fidelity when validating physical interactions, testing with real environmental conditions, or presenting to investors/executives who need polished demos. Best practice: progress through fidelity levels sequentially, only investing in hi-fi after lo-fi validation. A $2000 prototype that tests an unvalidated concept wastes money; a $50 paper prototype that eliminates a bad idea saves months.
1520.5.3 Storyboards and Comics
Purpose: Illustrate user journey and context of use
Method: Sequential illustrations showing user interacting with system over time
Use case: Presenting design concepts to stakeholders or user study participants
1520.5.4 Wizard of Oz Prototypes
Purpose: Test intelligent behaviors before implementing complex AI/ML
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'clusterBkg': '#ECF0F1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph TD
A[User Interacts<br/>with System] --> B[Sensors Detect<br/>User Action]
B --> C[Hidden Operator<br/>Observes]
C --> D[Operator Makes<br/>Smart Decision]
D --> E[System Responds<br/>Appears Intelligent]
E --> F[User Believes<br/>AI is Working]
F --> G[Researcher Observes<br/>User Reaction]
G --> H{Does user trust<br/>automation?}
H -->|Yes| I[Build real AI]
H -->|No| J[Redesign approach]
style C fill:#E67E22
style D fill:#E67E22
style G fill:#16A085
style I fill:#2C3E50,color:#fff
{fig-alt=“Wizard of Oz prototyping workflow: User interacts with system, sensors detect action, hidden operator observes and makes smart decision, system responds appearing intelligent, user believes AI is working. Researcher observes user reaction to determine if users trust automation, informing decision to build real AI or redesign approach.”}
Method: Human operator secretly controls system, simulating smart behavior
Example: Smart home system where researcher manually triggers lights and music based on user location, testing context-aware automation before building the real system
Advantages: Can test user response to intelligent features without months of ML development
Ethics note: Always debrief participants after study, explaining human control
1520.6 Medium-Fidelity Prototypes
As concepts solidify, prototypes incorporate real technology but may fake or simplify complex subsystems.
1520.6.1 Interactive Digital Mockups
Tools: Figma, Adobe XD, InVision
Purpose: Test mobile app or web dashboard interactions with realistic appearance
Capabilities: Clickable buttons, screen transitions, basic animations
Limitations: No actual device communication, no real data
When to use: After basic concept validated, before writing production code
1520.6.2 Breadboard Prototypes
Components: Arduino, Raspberry Pi, breakout sensor boards, jumper wires
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'clusterBkg': '#ECF0F1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph LR
subgraph Breadboard Prototype
A[Sensor Module<br/>DHT22 Temp/Humidity] --> B[Arduino Uno]
B --> C[Wi-Fi Module<br/>ESP8266]
C --> D[Cloud Service<br/>MQTT Broker]
B --> E[LED Indicator]
B --> F[LCD Display]
end
G[Jumper Wires<br/>Connect Everything] -.-> A
G -.-> B
G -.-> C
D --> H[Mobile App<br/>Dashboard]
style A fill:#16A085
style B fill:#2C3E50,color:#fff
style C fill:#16A085
style D fill:#E67E22
{fig-alt=“Breadboard prototype architecture showing sensor module (DHT22 temp/humidity) connected via Arduino Uno to Wi-Fi module (ESP8266), publishing to cloud MQTT broker, with LED indicator and LCD display for local feedback. Jumper wires connect all components. Data flows to mobile app dashboard.”}
Purpose: Prove technical feasibility, test sensor accuracy, validate actuator response
Example: Temperature monitoring system with DHT22 sensor, Arduino Uno, and jumper wires—tests sensing but not final form factor
1520.6.3 Hybrid Prototypes
Combine real hardware with simulated backend services.
Example: Real sensors publishing to MQTT broker, but data analysis happening in Excel spreadsheet instead of cloud ML service
Advantage: Can test user-facing features while backend is still under development
1520.7 High-Fidelity Prototypes
Later prototypes closely resemble final product but may lack production-level polish, scalability, or reliability.
1520.7.1 Custom PCB Prototypes
Services: OSH Park, PCBWay, JLCPCB
Purpose: Test production-ready form factor and electronics
Timeline: 1-2 weeks from design to assembled board
When to use: After breadboard prototype validated, before committing to manufacturing tooling
1520.7.2 3D-Printed Enclosures
Materials: PLA/ABS for rapid iteration, resin for high detail, nylon for functional parts
Advantage: Can produce complex geometries impossible with traditional manufacturing
Limitation: Surface finish and material properties differ from injection molding
1520.7.3 Pilot Deployments
Scale: Small-scale real-world deployment (5-50 units)
Purpose: Tests system in realistic conditions with actual users
Reveals: Issues invisible in lab testing (environmental factors, usage patterns, network conditions)
Example: Deploy smart irrigation system in 10 homes for 3 months before commercial launch
1520.8 Case Study: Smart Medication Adherence
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'clusterBkg': '#ECF0F1', 'clusterBorder': '#2C3E50', 'edgeLabelBackground':'#ffffff'}}}%%
graph TD
A[Week 1: Empathize] --> A1[Interview 15 elderly patients<br/>Observe medication routines]
A1 --> B[Week 2: Define]
B --> B1[Problem: Complex schedules<br/>confuse patients<br/>HMW make taking meds obvious?]
B1 --> C[Week 3: Ideate]
C --> C1[Idea 1: Smart pill bottle<br/>Idea 2: Wearable reminder<br/>Idea 3: Visual calendar<br/>Idea 4: Phone app alerts<br/>+ 20 more ideas]
C1 --> D[Week 4: Prototype]
D --> D1[Paper prototype: Visual calendar<br/>Cardboard mockup: Smart bottle<br/>Wizard of Oz: Voice reminders]
D1 --> E[Week 5: Test]
E --> E1[5 users test each prototype<br/>Smart bottle wins!<br/>But confusing LED colors]
E1 --> F[Week 6: Iterate]
F --> F1[Simplify LEDs to Red/Green<br/>Add audio beep option<br/>Larger pill compartments]
F1 --> G[Week 7-8: Test v2]
G --> G1[10 users, 2-week trial<br/>90% adherence improvement<br/>Users love it!]
G1 --> H[Week 9-12: High-Fidelity]
H --> H1[Custom PCB, 3D enclosure<br/>Pilot with 20 homes]
H1 --> I[Ship Product]
style A fill:#16A085
style C fill:#E67E22
style E fill:#16A085
style F fill:#E67E22
style I fill:#2C3E50,color:#fff
{fig-alt=“12-week Smart Medication Adherence case study timeline: Week 1 Empathize (interview 15 patients, observe routines), Week 2 Define (complex schedules confuse patients), Week 3 Ideate (generate 24+ ideas), Week 4 Prototype (paper calendar, cardboard bottle, Wizard of Oz voice), Week 5 Test (smart bottle wins but LEDs confusing), Week 6 Iterate (simplify to red/green LEDs, add audio, larger compartments), Week 7-8 Test v2 (90% adherence improvement), Week 9-12 High-Fidelity (custom PCB, 3D enclosure, pilot 20 homes), then ship product.”}
1520.8.1 Key Learnings from Case Study
- Low-fidelity prototypes eliminated bad ideas quickly (voice reminders were annoying)
- User testing revealed unexpected issues (LED color confusion)
- Iteration improved results dramatically (90% adherence improvement)
- Only invested in high-fidelity after validation (weeks 9-12)
- Pilot deployment revealed final issues before commercial launch
1520.9 Summary
Key Takeaways:
Match prototype fidelity to design questions:
- Paper prototypes for exploring concepts
- Breadboards for validating technical feasibility
- High-fidelity for refining details
Wizard of Oz prototypes enable testing intelligent features before building complex AI/ML systems
Progress through fidelity levels sequentially—don’t invest in expensive prototypes before validating concepts
Pilot deployments reveal issues invisible in lab testing—environmental factors, real usage patterns, network conditions
Each prototype should answer specific questions—design prototypes intentionally, not just to “build something”
1520.10 What’s Next
The next chapter covers User Testing Best Practices, providing detailed guidance on recruiting participants, creating effective tasks, conducting sessions, and analyzing results to drive design improvements.