UX Design · Study deck
Personas and Journey Maps for IoT
Imagine a housing officer called Mina helping a tenant after a water alarm.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: A shared-access coordinator may invite a guest, revoke a credential, see activity history, and contact support, but a guest may only see whether their credential is active and how to recover at the door.
- Explain: A journey map should show how those roles meet the product over time: purchase, installation, pairing, permissions, first success, shared use, alert, failure, maintenance, support, transfer, and removal.
- Explain: Firmware is the built-in software that controls a device.: A firmware change can move a button, alter an alert, or change the meaning of a light.
- Explain: Evidence: what was observed.
Major section
Start Simple
The alarm is raised, seen, checked, acted on, handed over, closed, and reviewed.
- At each state, name what the person sees, what the device knows, what the service knows, and what can go wrong.
- The tenant has poor signal.
- Mina's phone battery is low.
- The wall unit shows an old state.
Major section
Start Simple (continued)
A repair worker arrives after the office closes.
- Firmware is the built-in software that controls a device.: A firmware change can move a button, alter an alert, or change the meaning of a light.
- A journey is not only an app flow.
- A family member, night worker, cleaner, or new tenant may meet the service in another way.
Major section
In 60 Seconds
It should show how a user, device, app, service, environment, and support path interact over time.
- Personas and journey maps are research synthesis tools.
- A persona should not be a fictional character the team invents to win arguments.
- It should be a compact record of repeated patterns found across research participants.
Major section
IoT Personas as System Roles
An IoT persona is most useful when it names the role a person plays in a connected system.
- The same product can involve a buyer, installer, daily user, guest, caregiver, technician, dispatcher, administrator, bystander, and support agent.
- Those roles see different states, have different rights, and experience different failures.
Major section
IoT Personas as System Roles (continued)
A journey map should show how those roles meet the product over time: purchase, installation, pairing, permissions, first success, shared use, alert, failure, maintenance, support, transfer, and removal.
- For IoT, the journey is not complete until it includes device state, cloud state, local fallback, data freshness, ownership, and recovery.
- The useful output is therefore not a vague instruction to improve access.
- For a leak sensor, the primary resident, landlord, plumber, and neighbor are not interchangeable.
Major section
IoT Personas as System Roles (continued)
The owner may need to see invite status, credential validity, reader readiness, offline behavior, and revoke confirmation.
- The guest may need only arrival instructions, active credential status, local fallback guidance, and a recovery path that does not expose household history.
- The resident needs clear wet/offline/low-battery state, placement advice, alert acknowledgement, and a way to mute a resolved alarm.
- The landlord may need maintenance evidence without unnecessary private activity detail.
Major section
Rights and Recovery Journeys
A shared-access coordinator may invite a guest, revoke a credential, see activity history, and contact support, but a guest may only see whether their credential is active and how to recover at the door.
- A caregiver may see acknowledgement status, but not every private activity detail.
- A technician may need diagnostics without becoming the account owner.
- In a smart-lock journey, useful states may include invite_sent, invite_accepted, credential_active, credential_expired, credential_revoked, reader_online, reader_offline, battery_low, local_cache_active, and support_escalated.
Major section
Journey Maps Need State Names
A journey row should expose which state the interface can know, which state support can verify, and which state requires physical inspection.
- The implementation record should preserve privacy as well as debugging value.
- That distinction lets the persona and journey map drive engineering fields, support tooling, retention rules, and access-control checks instead of remaining UX-only documentation.
- System boundary: separate app copy, device firmware, cloud service, integration, and support-process responsibilities for each critical moment.
Major section
Persona Record Contents
Role: user, buyer, installer, caregiver, guest, operator, technician, administrator, affected bystander, or support agent.
- Goal: what the person is trying to achieve or avoid.
- Device relationship: owns, shares, configures, monitors, maintains, trusts, avoids, or is affected by the device.
- Current workaround: what the person does now when the system does not help.
- Boundary: what the persona does not represent.
Major section
Prioritize Roles Without Hiding Others
IoT products often have more than one relevant role.
- Primary role: the role whose core task the design must serve first.
- Secondary role: a role the design should support without compromising the primary task.
- Affected role: a person who may not operate the device but is affected by sensing, alerts, access, privacy, or physical placement.
Major section
Turn Journey Findings Into Requirements
"Setup is frustrating.".
- "During setup, users cannot tell whether the failure is caused by wrong Wi-Fi credentials, device offline state, app permission denial, or an account ownership problem.
- The setup flow must distinguish these states and give a safe next action before the next pilot.".
- Evidence: what was observed.
Major section
Shared Access Coordinator
They need clear state across app, physical reader, visitor, and support handoff.
- They do not want every household member to have full administrative control.
- Failure sensitivity: high when a visitor arrives and the credential is not active.
- Design implications: clear invite state, reader readiness, role permissions, revoke path, activity history, and support escalation.
Major section
Worked Journey: Water Leak Sensor
Pair: app must distinguish discovered, paired, placed, online, and battery-ready states.
- Daily use: device should stay quiet unless state changes or maintenance is needed.
- Maintain: battery, placement, cleaning, and test reminders must not be hidden.
- Placement guidance should include common physical constraints and a way to confirm the sensor is still reachable.
Major section
Common Defects
Hero personas: ideal users who are patient, motivated, trained, and forgiving.
- Early-adopter drift: making the primary persona a technical enthusiast when the product needs mainstream reliability.
- Happy-path mapping: ignoring setup errors, stale data, offline state, support, maintenance, and ownership transfer.
- Role collapse: treating buyer, installer, user, guest, caregiver, technician, and support agent as one person.
Deck summary
Key takeaways
The alarm is raised, seen, checked, acted on, handed over, closed, and reviewed.
- A repair worker arrives after the office closes.
- It should show how a user, device, app, service, environment, and support path interact over time.
- An IoT persona is most useful when it names the role a person plays in a connected system.
- A journey map should show how those roles meet the product over time: purchase, installation, pairing, permissions, first success, shared use, alert, failure, maintenance, support, transfer, and removal.
Retrieval practice
Recall check 1 of 2
UX Uma says: answer from memory, then check your reasoning.
Q1A smart-lock team is turning shared-access research into a persona and journey map. Which artifact set is strong enough to guide the design?
Show answer
Answer: A Persona and journey artifacts are useful when they synthesize repeated role patterns, critical touchpoints, connected states, requirements, boundaries, and update conditions.
Retrieval practice
Recall check 2 of 2
UX Uma says: answer from memory, then check your reasoning.
Q2A team creates a persona from one memorable interview and then maps only the happy path from purchase to first successful use. What is the main quality problem?
Show answer
Answer: A Personas and journey maps are useful when they synthesize repeated research patterns and show the critical touchpoints, states, failures, and evidence boundaries that shape design.
Print reference
Answers
Answer key.
- A · Persona and journey artifacts are useful when they synthesize repeated role patterns, critical touchpoints, connected states, requirements, boundaries, and update conditions.
- A · Personas and journey maps are useful when they synthesize repeated research patterns and show the critical touchpoints, states, failures, and evidence boundaries that shape design.