Design Methodology · Study deck
Ideate, Prototype, and Test
Imagine a team debating three IoT ideas around a whiteboard while the riskiest assumption is still unknown.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Convert How Might We prompts into multiple solution directions before selecting an architecture.
- Screen ideas with impact, effort, risk, and evidence criteria instead of enthusiasm alone.
- Choose a prototype fidelity that answers the current learning question without overbuilding.
- Design Wizard-of-Oz, breadboard, and functional trials for IoT workflows.
Major section
Prototype the Uncertainty
For IoT, a prototype can target the service path, interface, device behavior, connectivity path, data model, or support workflow.
- After Define, the team should have a problem frame, not a chosen architecture.
- The first prototype should expose the biggest unknown without pretending to be the final product.
- A Figma flow may answer whether a technician understands an escalation.
Major section
Prototype the Uncertainty (continued)
Ideation keeps several paths alive long enough to compare them: no-device service change, local indicator, phone workflow, gateway rule, cloud alert, computer-vision check, predictive model, or custom hardware.
- A Wizard-of-Oz test may answer whether an automation pattern is useful.
- An ESP32, RP2040, nRF52840, Raspberry Pi, or Wokwi prototype may answer whether a sensor, radio, or power assumption is credible.
- A strong ideation session therefore starts with evidence constraints rather than feature wishes.
Major section
Prototype the Uncertainty (continued)
A clickable Figma flow can test whether the next action is understood.
- For a warehouse safety concept, compare floor markings, wearable haptics, forklift telematics, UWB ranging, camera analytics, and supervisor workflow changes.
- Low fidelity is acceptable when it protects learning quality.
- A storyboard can test whether a user trusts an alert.
Major section
Prototype the Uncertainty (continued)
The point is not to make every option equally likely; it is to keep the team from choosing the most familiar implementation before testing the risk that matters.
- A Node-RED mock connected to Mosquitto can test alert timing.
- A bench prototype with a BME280, load cell, or ToF sensor can test whether raw readings separate real events from noise.
- Option boundary: Generate different mechanisms before screening so the team does not default to sensor plus dashboard.
Major section
Match Fidelity to the Failure Mode
The right prototype depends on what could make the concept fail.
- If users cannot classify alert urgency, build a clickable workflow.
- If the automation does not exist yet, run a Wizard-of-Oz scenario.
- If the sensor reading is noisy, build a bench rig with known inputs.
Major section
Match Fidelity to the Failure Mode (continued)
If the radio path is uncertain, test range, packet loss, RSSI/SNR, retry behavior, and gateway recovery before polishing the app.
- Figma, Framer, Miro, FigJam, Node-RED, Home Assistant, Mosquitto, AWS IoT Core, Azure IoT Hub, Grafana, InfluxDB, Wokwi, PlatformIO, Arduino IDE, Saleae-style logic capture, Joulescope, and Playwright can all be useful.
- The useful part is the learning boundary: what assumption is being tested, what counts as success, and what the team will change if the result is poor.
- An alert study should include a true positive, false positive, stale sensor value, delayed notification, escalation to the wrong role, and manual override.
Major section
Match Fidelity to the Failure Mode (continued)
A provisioning study should include a good QR scan, failed scan, denied Bluetooth permission, wrong Wi-Fi password, gateway offline state, and factory-reset recovery.
- A field pilot should define who installs the device, what logs are collected, how consent is handled, when support intervenes, and which defects stop the pilot.
- The winning prototype is the smallest credible artifact that makes the next decision less speculative.
- Script realistic faults: Include offline device, stale data, low battery, denied permission, blocked sensor, delayed notification, and manual override states.
Major section
Tests Need State, Payload, Timing
Even a low-fidelity prototype should model the states that matter.
- For an alert workflow, use pending, watch, act, escalate, acknowledged, muted, offline, stale, recovered, and support-needed states.
- These states make user tests and technical tests comparable.
- A workflow prototype should log task success, alert classification, acknowledgement time, recovery path, accessibility issue, and participant confusion.
Major section
Tests Need State, Payload, Timing (continued)
A sensing prototype should log signal range, calibration condition, false positive, false negative, latency, power draw, thermal behavior, and environmental sensitivity.
- If a demo hard-codes cloud credentials into firmware, that is a security and manufacturing finding.
- If an alert depends on an always-online phone, that is a reliability finding.
- If a dashboard shows an inferred occupancy state without confidence, freshness, or source, that is a data-quality finding.
Major section
Tests Need State, Payload, Timing (continued)
The final test record should include the scenario, participant or device context, artifact version, firmware hash if applicable, input data, observed state transitions, payload examples, failures, and decision.
- A Playwright trace, MQTT capture, Grafana panel, CSV log, video clip, support-ticket note, and participant quote can all belong in the same evidence packet when they answer the same assumption.
- That packet is what lets the team decide whether to pivot the concept, revise the interaction, change sensor placement, alter the data path, add a support control, or proceed to a higher-fidelity prototype.
- That detail prevents a successful demo from hiding an untestable architecture.
Major section
Why This Stage Matters · Ideate From Evidence
After Empathize and Define, the team should have a user, a need, and an insight.
- The job of this stage is to create options and test assumptions before the project commits to expensive architecture decisions.
- Ideation should start from the Point-of-View statement and How Might We prompts created in the previous chapter.
- The goal is divergence first, then evidence-based screening.
Major section
Ideation Techniques · Ideation Red Flag
The team needs many interface, device, or service variations quickly.
- Include local feedback, maintenance, setup, and offline states, not only the app screen.
- The team is stuck improving an existing product or workflow.
- Substitute, combine, adapt, modify, put to another use, eliminate, reverse ideas.
- Alternative ways to change the journey moment.
Major section
Screen Ideas Without Freezing Too Early · Prototype Fidelity
Custom hardware is usually not the first test.
- Impact-effort screening is useful, but IoT teams also need to examine risk and evidence.
- A high-impact idea can still be a poor first prototype if it hides safety, privacy, support, or manufacturability risk.
- The riskiest assumption is named and owned.
Major section
Worked Example: Equipment Alert Redesign · Evidence Record
Medium: helps on-site staff.
- Proceed to technical feasibility only if users can classify the alert, explain the action, and identify who owns the next step.
- If they cannot, improve the alert language and escalation workflow before adding sensing complexity.
- Each test should produce a compact record that can travel with the backlog item.
Deck summary
Key takeaways
For IoT, a prototype can target the service path, interface, device behavior, connectivity path, data model, or support workflow.
- Ideation keeps several paths alive long enough to compare them: no-device service change, local indicator, phone workflow, gateway rule, cloud alert, computer-vision check, predictive model, or custom hardware.
- A clickable Figma flow can test whether the next action is understood.
- The point is not to make every option equally likely; it is to keep the team from choosing the most familiar implementation before testing the risk that matters.
- The right prototype depends on what could make the concept fail.
Retrieval practice
Recall check 1 of 5
Blueprint Bina says: answer from memory, then check your reasoning.
Q1A team has a flashy alert idea and a simple service change. How should it choose the next prototype?
Show answer
Answer: B The first trial should reduce the most important uncertainty.
Retrieval practice
Recall check 2 of 5
Blueprint Bina says: answer from memory, then check your reasoning.
Q2A team wants to know whether technicians understand a proposed alert escalation workflow. The automation does not exist yet. What prototype should they use first?
Show answer
Answer: C Prototype fidelity should match the learning question.
Retrieval practice
Recall check 3 of 5
Blueprint Bina says: answer from memory, then check your reasoning.
Q3During a usability test, users say they like the prototype, but several fail to recover from a simulated network loss. Which evidence should drive the next iteration?
Show answer
Answer: D Observed user behavior in realistic conditions is stronger than general preference comments.
Retrieval practice
Recall checks 4–5 of 5
Blueprint Bina says: answer from memory, then check your reasoning.
Q4What frames an ideation challenge broadly enough for several plausible responses?
Show answer
Answer: B An open challenge statement creates room for several plausible responses.
Q5Complete the helper that checks whether a prototype test record has enough evidence for a proceed decision:
Show answer
Answer: A The gate requires core test evidence fields, then allows proceed only when the recorded decision is proceed and no unresolved blocker remains.
Print reference
Answers
Answer key.
- B · The first trial should reduce the most important uncertainty.
- C · Prototype fidelity should match the learning question.
- D · Observed user behavior in realistic conditions is stronger than general preference comments.
- B · An open challenge statement creates room for several plausible responses.
- A · The gate requires core test evidence fields, then allows proceed only when the recorded decision is proceed and no unresolved blocker remains.