Design Methodology · Study deck
Empathize and Define
Picture a cold-room operator who notices a warning after stock has already warmed.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Plan field research for an IoT product without biasing users toward a preselected device or feature.
- Separate what users say, think, do, and feel so the team can distinguish evidence from inference.
- Convert observations into pain points, personas, journey moments, and clear problem frames.
- Write Point-of-View statements and How Might We prompts that keep the solution space open.
Major section
Empathy Changes Architecture
In IoT, empathize and define work should change what the team builds.
- For example, a facilities team that asks for a "smart freezer sensor" may really need a freezer-loss recovery workflow.
- The problem frame then becomes an operational handoff problem with sensing, networking, escalation, and accountability parts.
Major section
Empathy Changes Architecture (continued)
That frame may lead to a DS18B20 probe plus door switch, local buzzer mute, battery-backed gateway, MQTT QoS 1 publish, SMS escalation, and a support playbook instead of only a nicer dashboard.
- If the evidence says the pain is two minutes of uncertain setup during installation, the first prototype may be a paper provisioning flow, a Figma status screen, or a bench ESP32 that shows pairing states clearly.
- If the pain is auditability after an incident, the prototype may be an event log and acknowledgement model before any enclosure design.
- Those sources preserve what people and systems did before the team names a pattern.
Major section
Empathy Changes Architecture (continued)
The same discipline prevents over-engineering.
- Empathy work is therefore not a soft preface to real engineering; it is the mechanism that decides which engineering risk is worth spending time on next.
- The next step states the person, wanted change, and key limit.
- The proof gate then allows only a trial that can test the largest open risk.
Major section
Research the Whole Service Path
Strong field notes connect a quote or observation to a decision the team must make.
- For a cold-room alert, that path may include probe placement, door state, local display, gateway connectivity, MQTT publish, cloud rule, APNs or FCM notification, shift handoff, acknowledgement, support ticket, and incident closeout.
- For a home-energy monitor, the sample may need a renter, homeowner, installer, call-centre agent, utility program manager, and someone who opts out of sharing fine-grained data.
- A support-ticket cluster about failed pairing informs BLE provisioning recovery, QR-code fallback, captive-portal wording, and what diagnostics the agent needs in Zendesk.
Major section
Research the Whole Service Path (continued)
Each interview should separate observed facts from interpretation: "the gateway LED was red for three hours" is evidence; "operators do not care about reliability" is usually a weak inference.
- A telemetry gap around shift changes informs alert throttling, role routing, and acknowledgement ownership.
- The output should be a traceable board of evidence, assumptions, open questions, and prototype tests, not a decorative persona poster.
- Recruit by role and scenario: Include the person who installs, uses, maintains, receives alerts, appears in data, and owns operational risk.
Major section
Findings to System Constraints
Translate each insight into actors, states, events, and measurements.
- Actors may include device, gateway, user, installer, automation rule, support agent, and external service.
- States may include unpaired, provisioning, normal, pending, offline, stale, faulted, acknowledged, overridden, and recovered.
- Events need timestamps, source, confidence, freshness, and ownership so later prototypes can test the real workflow.
Major section
Findings to System Constraints (continued)
A vague finding such as "users need trust" is not testable.
- A stronger constraint says that after a sensor misses three reporting intervals, the interface must show stale status, last successful heartbeat, battery estimate, network path, and next recovery action within one screen.
- If research shows that the device observes a shared corridor, the data model needs purpose limitation, field-level retention, access roles, and possibly edge redaction before cloud upload.
- If an alert can trigger a physical response, the system needs confidence thresholds, duplicate suppression, audit records, manual override, and clear ownership for who acts.
Major section
Why Empathize Comes First
A device may be installed by one person, configured by another, monitored by a third, and affect people who never touch the app.
- Discovery therefore has to include the full service context, not only the buyer or the most enthusiastic user.
- The main risk is not that the team cannot build the device.
- The main risk is building a device that fits the team's imagined workflow instead of the real one.
Major section
Research Methods
Field trials reveal what changes under real constraints.
- Seeing how the task is actually performed in the real environment.
- Quotes, stories, recurring needs, objections, and unresolved questions.
- Finding handoffs, waiting, repeated effort, alert fatigue, and support burden.
- Capturing repeated events that do not happen during one visit.
Major section
Empathy Maps
An empathy map is a synthesis tool, not a decoration.
- It helps the team compare direct quotes, inferred thoughts, observed behaviors, and emotional signals.
- Below, Does records observed actions, while Feels captures emotional signals.
- Direct quotes from interviews, support calls, or field sessions.
- The user may believe the device is hard to reset after a fault.
Major section
From Evidence to Pain Points
Pain points should connect evidence to a user outcome.
- "The operator cannot tell whether an alert is urgent without walking to the equipment.".
- "The maintainer cannot locate which part of the machine changed state before the fault.".
- Focuses on the decision gap that sensing might address.
- Explains why history and aggregation may matter.
Major section
Define the Problem
Line supervisors need to recognize repeated vibration changes before a shift ends because repairs are only practical during scheduled downtime.
- The Define stage turns research into a problem frame that can guide ideation and prototype testing.
- The need should be a verb phrase, not a product.
- The insight should come from evidence, not the team's preference.
Major section
Shared Cold-Room Monitoring
The original request is "add more sensors and a dashboard." The team pauses to empathize and define before choosing hardware.
- The alarm may be correct but poorly timed.
- The technical alert is not enough; ownership is unclear.
- Slow response even when data is available.
- The system must support accountability, not only alerts.
Major section
Evidence Record
A research finding becomes useful when its context can be carried into a testable choice.
- The risk is slow response even when data exists, so the requirement names escalation roles and visible acknowledgement.
- A future change in after-hours responsibility is the retest trigger.
- Separates evidence from the team's interpretation.
- Pattern or mismatch that changes the team's understanding.
Deck summary
Key takeaways
In IoT, empathize and define work should change what the team builds.
- That frame may lead to a DS18B20 probe plus door switch, local buzzer mute, battery-backed gateway, MQTT QoS 1 publish, SMS escalation, and a support playbook instead of only a nicer dashboard.
- The same discipline prevents over-engineering.
- Strong field notes connect a quote or observation to a decision the team must make.
- Each interview should separate observed facts from interpretation: "the gateway LED was red for three hours" is evidence; "operators do not care about reliability" is usually a weak inference.
Retrieval practice
Recall check 1 of 6
Blueprint Bina says: answer from memory, then check your reasoning.
Q1A team already wants to build a smart freezer sensor. How should it plan field interviews?
Show answer
Answer: C Open questions expose the actual workflow and constraints.
Retrieval practice
Recall check 2 of 6
Blueprint Bina says: answer from memory, then check your reasoning.
Q2A cold-room team calls its prototype a success because alerts appear on a phone. What else belongs in the success rule?
Show answer
Answer: D Success combines a user outcome with technical and lifecycle constraints.
Retrieval practice
Recall check 3 of 6
Blueprint Bina says: answer from memory, then check your reasoning.
Q3Field notes show night staff miss alarms during handoff. Which Point-of-View and How Might We pair leaves the solution open?
Show answer
Answer: C The need is grounded in field notes and the prompt allows several solutions.
Retrieval practice
Recall check 4 of 6
Blueprint Bina says: answer from memory, then check your reasoning.
Q4A team observes that operators silence a machine alert several times per shift. What should the team do first in the Empathize stage?
Show answer
Answer: C The Empathize stage uses observation and interviews to understand behavior before selecting a solution.
Retrieval practice
Recall checks 5–6 of 6
Blueprint Bina says: answer from memory, then check your reasoning.
Q5What open challenge wording invites several solutions to a defined user need?
Show answer
Answer: D How Might We wording opens multiple solution directions around the defined need.
Q6Complete the helper that extracts research notes that are ready to become design insights:
Show answer
Answer: A A useful insight record should include the evidence, the user role or context, and the design consequence.
Print reference
Answers
Answer key.
- C · Open questions expose the actual workflow and constraints.
- D · Success combines a user outcome with technical and lifecycle constraints.
- C · The need is grounded in field notes and the prompt allows several solutions.
- C · The Empathize stage uses observation and interviews to understand behavior before selecting a solution.
- D · How Might We wording opens multiple solution directions around the defined need.
- A · A useful insight record should include the evidence, the user role or context, and the design consequence.