8 IoT Research Methods: Fieldwork and Synthesis

8.1 Start With the Decision

A home visit may reveal workarounds that an interview misses. Field notes must capture the act, setting, device, and reason.

8.2 Route Overview

This is part 2 of 2. Review IoT Research Methods: Evidence and Selection for the preceding evidence.

8.3 Learning Objectives

• Conduct contextual inquiry, interviews, and diary studies.
• Synthesize field evidence into design decisions.

8.4 Chapter Roadmap

• Contextual Inquiry
• Interviews
• Diary Studies
• Prototype and Usability Tests
• Surveys
• Telemetry and Support Logs
• Field Pilots
• Mixed-Method Evidence Plan
• Incremental Examples
• Try It Now: Choose a Method Mix
• Micro-Exercise: Reject the Mismatch
• Method Planning Checklist
• Common Defects
• Concept Check: Pick the Research Plan
• Concept Check: Match Methods to Evidence
• Concept Check: Order the Method Plan
• Summary
• Key Takeaway
• See Also
• What’s Next

8.5 Contextual Inquiry

Contextual inquiry means observing people in the environment where the product, task, or workaround happens.

Use it when the team needs to understand:

physical placement, reach, lighting, noise, weather, power, mounting, or cleaning. shared use between account owners, household members, visitors, workers, caregivers, or technicians. setup behavior under realistic interruption, time pressure, and connectivity constraints. maintenance routines such as charging, battery replacement, testing, calibration, or cleaning. workarounds that people may not remember or may not mention in an interview.

Good contextual inquiry records:

task and setting. participant role. relevant devices and infrastructure. observed actions. interruptions and workarounds. device, app, service, and support states. questions asked after observation. evidence boundary and follow-up needs.

Do not interrupt every action with questions. Watch first, then ask targeted follow-up questions such as:

“I noticed you checked the app before touching the device. What were you looking for?”. “What told you the setup was working?”. “What would you do if this message appeared when someone was waiting outside?”.

8.6 Interviews

Interviews help explain goals, decisions, language, trust, expectations, and past experiences. They are less reliable for predicting future behavior.

Use interviews to learn:

how people describe a task or failure. what they believe the system should know or control. which alerts feel urgent, useful, confusing, or intrusive. how roles and responsibilities are understood. how people decide whether to trust an automated action. what support or maintenance path they expect.

Avoid leading questions.

Weak question:

“Would this smart reminder make your life easier?”.

Stronger question:

“Tell me about the last time you missed, delayed, ignored, or changed a reminder.”.

The stronger question asks for evidence from a real situation instead of inviting approval of a concept.

8.7 Diary Studies

Diary studies ask participants to record events over time. They are useful when the experience is intermittent, private, distributed, or hard to observe in one session.

Use diary studies for:

• alert response across days or weeks
• comfort, noise, or environmental changes
• caregiver or household coordination
• device maintenance and battery events
• changing trust in automation
• situations where participants cannot host long observations

Keep diary prompts short and tied to events:

• What happened?
• Where were you?
• Who was affected?
• What did the device/app/service show?
• What did you do next?
• What was unclear or missing?

Avoid asking for long essays. Frequent lightweight records are more useful than a perfect diary that participants stop completing.

8.8 Prototype and Usability Tests

Prototype tests answer whether a design representation is understandable before the team commits to implementation.

Use prototype tests for:

• setup flows
• permission and consent screens
• role invitation and revocation
• alert language and escalation
• device state and data freshness displays
• maintenance reminders
• support handoff
• ownership transfer and decommissioning

Test with realistic states, not only the happy path. For IoT, include:

• device not found
• credential pending
• permission denied
• offline state
• stale data
• low battery
• muted alert
• update required
• shared-role conflict

Prototype fidelity should match the question. A sketch may be enough for sequence and wording. A clickable prototype may be needed for flow comprehension. A bench prototype or field prototype may be needed when physical sensing, placement, timing, or feedback affects behavior.

8.9 Surveys

Surveys are useful after the team understands the pattern it wants to measure.

Use surveys to estimate:

how common a known task, constraint, or role is. which contexts or devices participants have. how people rank trade-offs after the trade-offs are clearly described. whether a finding from qualitative research appears in a broader group.

Do not use surveys to replace discovery when the team does not yet know what to ask.

Weak survey item:

“Would you use automatic home access?”.

Stronger survey item:

“In the past month, how many times did you need to grant temporary access to someone while you were away from the entrance?”.

The stronger item asks about past behavior and context. It can still be imperfect, but it is more useful than hypothetical enthusiasm.

8.10 Telemetry and Support Logs

Telemetry and support logs can show field signals that research sessions miss.

Useful signals include:

• setup drop-off stages
• repeated pairing attempts
• alert mute patterns
• manual overrides after automation
• device offline duration
• low-battery and stale-data events
• support categories and resolution paths
• update failures and recovery loops

Telemetry does not explain itself. A spike in overrides might mean the automation is wrong, the UI is unclear, the context changed, or users do not trust the system. Combine logs with observation, interviews, or support review before turning the signal into a requirement.

Privacy review is part of telemetry planning. Collect the least precise signal that supports the decision, and make the data practice understandable.

8.11 Field Pilots

Field pilots test how product, context, service, support, and maintenance behave together over time.

Use pilots when:

physical placement affects sensing or actuation. shared roles need to coordinate. the support path is part of the experience. maintenance or failure recovery matters. telemetry needs interpretation in real context. automated rules need trust-building and override evidence.

A field pilot should have a clear scope:

what decision it will inform. who is included and excluded. what data is collected. what support is available. what failure and maintenance states will be reviewed. what conditions would stop, revise, or expand the pilot.

8.12 Mixed-Method Evidence Plan

Before deciding how Context shapes mixed-method evidence plan, inspect Figure 8.1 beside the research. Together, Context and the research frame the mixed-method evidence plan claim: iot mixed-method evidence plan linking decision, method, participant role, context, evidence, boundary, and action record.

In the diagram, check Context and the research separately in Figure 8.1; together they make iot mixed-method evidence plan linking decision, method, participant role, context, evidence, boundary, and action record auditable. For mixed-method evidence plan, Context supplies visible evidence; the research constrains the decision. In Figure 8.1, retain Context beside the research so mixed-method evidence plan remains explicit.

8.13 Incremental Examples

8.14 Try It Now: Choose a Method Mix

Pick one IoT design decision and fill in this method plan:

8.15 Micro-Exercise: Reject the Mismatch

For each plan, name the mismatch and a better method:

A survey asks whether users would trust automatic unlocking, but no one observes setup, proximity, or shared-access behavior. A field pilot records MQTT drop-offs but never interviews users or support staff about what the failures meant. A polished prototype test uses only happy-path device states even though the release decision depends on offline recovery.

8.16 Method Planning Checklist

Before starting research, confirm:

the design decision is specific. the method matches the evidence gap. primary, secondary, affected, and excluded roles are named. context constraints are included in the plan. consent and data boundaries are clear. observation and interpretation will be recorded separately. the team knows what evidence would change the design. telemetry or survey data will not be overclaimed. failure, maintenance, support, and shared-use states are included where relevant. evidence boundaries, requirements, owners, validation needs, and change conditions will be recorded.

8.17 Common Defects

Watch for:

Method mismatch: using a survey when the team needs field observation. Convenience sampling: recruiting only coworkers, early adopters, or available users. Leading questions: asking participants to agree with the intended feature. Happy-path testing: testing setup success but not failure, maintenance, support, or shared use. Telemetry overclaim: treating logs as proof of intent without interpretation. Prototype theater: testing a polished flow after the decision has already been made. No evidence boundary: writing conclusions that sound broader than the research supports. Stale conclusion: keeping research conclusions after the product, context, sensing, or policy changes.

8.18 Concept Check: Pick the Research Plan

8.19 Concept Check: Match Methods to Evidence

8.20 Concept Check: Order the Method Plan

8.21 Summary

Research methods help IoT teams make better design decisions when they are matched to the evidence gap. Observation shows behavior and context. Interviews explain meaning. Diary studies show repeated events. Prototype tests reveal comprehension and recovery problems. Surveys and telemetry help estimate scale after patterns are understood. Field pilots test product, context, service, and maintenance together.

The best research plan is not the largest plan. It is the plan that provides enough evidence for the decision, states its boundaries, protects participants and affected roles, and creates a record that the team can revisit.

8.22 Key Takeaway

Research methods should be selected for the question, context, risk, and evidence needed to guide IoT design decisions.

8.23 See Also

Research methods connect to the people/context sequence:

User Research Fundamentals explains why research starts with real behavior. Context-of-Use Analysis identifies the constraints that field methods need to capture. Personas and Journey Maps for IoT synthesizes method findings into artifacts. Pitfalls and Ethics for IoT User Research reviews consent, privacy, sampling, and automation risks. People and Context Assessment for IoT checks whether you can apply the full review sequence.

8.24 What’s Next

Continue with:

User Research Fundamentals, which explains the evidence principles behind these methods. Context-of-Use Analysis, which helps turn method findings into context requirements. Personas and Journey Maps for IoT, which shows how to synthesize research findings. Pitfalls and Ethics for IoT User Research, which helps review method quality and participant risk.

8.25 Continue Your Route

This final part closes the route from Contextual Inquiry through What’s Next. Return to IoT Research Methods: Evidence and Selection or continue from the ux-design module index.