Connected Product and Service Design · Study deck
Ecosystem Integration: Evidence Contracts
Imagine one smart lamp shown in two apps.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- review ecosystem integration as a product contract, not only a protocol feature
- map device capabilities into rooms, groups, scenes, automations, dashboards, and support views
- identify local, hub, cloud, account, and platform boundaries in a multi-device experience
- evaluate ownership, sharing, transfer, migration, and multi-controller risks
Major section
Start Simple
A protocol is a shared set of rules for sending messages.
- The second can only turn it on or off.
- Both apps say the lamp is supported, but they do not give the user the same result.
- A shared protocol can help parts connect, but it does not prove that each part shows the same controls or state.
Major section
Start Simple (continued)
Sharing and transfer need the same care.
- An ecosystem is the set of devices, hubs, apps, accounts, and services that work around one task: Integration means linking those parts so the task still makes sense as it moves between them.
- At each place, mark what works, what is missing, and who owns the gap.
- Finish with a change rule.
Major section
Start Simple (continued)
A scene is a saved set of actions.
- An automation starts an action when a rule is met.
- If one app says the lamp is off while the room is lit, the system should show which view is old.
- If the cloud is down, say whether local control still works.
- A shared icon is not enough proof.
Major section
Start Simple (continued)
If a command fails, say where the user can see the cause and try again.
- A reset should not leave an old owner linked to the lamp.
- A move to a new home should not erase facts that support staff still need.
- Recheck it after an app, hub, cloud service, device version, or account rule changes.
Major section
Start Simple (continued)
Real platforms may expose finer permissions, delayed state, or several controllers at once.
- Both should show the same room and state, or mark the known limit in plain words.
- If one view keeps an old state, it should mark that state as old.
- A new part may have fewer controls or a new version.
Major section
Start Simple (continued)
The record must state the gap.
- It must also name who will fix the app, hub rule, or help text.
- One goal, one set of parts, one owner for each gap, and one result per path are enough to expose most early faults.
- Old proof does not cover a path that has changed.
Major section
Start Simple (continued)
If “off” means no light in one app, it should not mean “not linked” in another.
- If a control is missing, say that it is not supported.
- A user should know whether a value came from the device, hub, or cloud.
- They should know when the last good update took place.
Major section
Start Simple (continued)
This makes a wait or fault much easier to explain.
- The help tool should name the device, app, account, and last step that passed.
- It should not ask the user to reset the whole home when only one cloud link is down.
- A user may retry a command, wake a device, or check the home link.
Major section
Integration Capability Contracts
An ecosystem integration is the product's promise that a device behaves coherently across controllers, accounts, hubs, automations, and support tools.
- The standard or platform logo is only the start.
- The user experience depends on which capabilities are exposed, which controller owns state, which actions work locally, and how limits are explained.
- A smart lock can appear in a manufacturer app, a Matter controller, a property-management dashboard, a voice assistant, and a support console.
Major section
Integration Capability Contracts (continued)
Those surfaces may disagree about battery state, guest access, firmware update, door position, event history, and emergency unlock.
- The review has to name those differences before users rely on the ecosystem.
- A light may expose brightness and color temperature in one controller, only on/off in another, and a stale health state in a support tool.
- Compatibility is useful only when the difference between full support, partial support, degraded support, and unsupported behavior is visible.
Major section
Compare Controller Models
For a gateway, list endpoint admission, bridge health, firmware, local fallback, remote access, and support diagnostics.
- Partial compatibility can be acceptable when it is deliberate and visible.
- A thermostat that exposes temperature setpoint but not installer diagnostics in a voice assistant may be fine; a lock that hides guest-code revocation or reports stale door state is a different risk.
- The review should include a normal workflow and a degraded workflow.
Deck summary
Key takeaways
A protocol is a shared set of rules for sending messages.
- Sharing and transfer need the same care.
- A scene is a saved set of actions.
- If a command fails, say where the user can see the cause and try again.
- Real platforms may expose finer permissions, delayed state, or several controllers at once.
Retrieval practice
Recall check 1 of 4
UX Uma says: answer from memory, then check your reasoning.
Q1A smart lamp is moved to a new household after a reset. What must the integration review verify?
Show answer
Answer: B Old owner access is revoked, new roles are bound, and support keeps needed transfer evidence.
Retrieval practice
Recall check 2 of 4
UX Uma says: answer from memory, then check your reasoning.
Q2A team is reviewing a smart-light integration that exposes brightness in one app but only on/off in a second controller. Which ecosystem record is strong enough to make the decision reviewable?
Show answer
Answer: C A reviewable ecosystem decision ties the user goal, capability map, controller boundary, ownership model, state authority, local/cloud behavior, support evidence, accepted limit, owner, open issue, and change condition together before the design is trusted.
Retrieval practice
Recall check 3 of 4
UX Uma says: answer from memory, then check your reasoning.
Q3A room scene includes an offline lamp. What should the capability map and support view show?
Show answer
Answer: D A scene must show partial support and give support enough evidence to explain it.
Retrieval practice
Recall check 4 of 4
UX Uma says: answer from memory, then check your reasoning.
Q4A hub light works from a wall switch during an internet outage, but remote schedules stop. What should the integration record say?
Show answer
Answer: D Local and cloud duties differ, so the record must name both paths and failure behavior.
Print reference
Answers
Answer key.
- B · Old owner access is revoked, new roles are bound, and support keeps needed transfer evidence.
- C · A reviewable ecosystem decision ties the user goal, capability map, controller boundary, ownership model, state authority, local/cloud behavior, support evidence, accepted limit, owner, open issue, and change condition together before the design is trusted.
- D · A scene must show partial support and give support enough evidence to explain it.
- D · Local and cloud duties differ, so the record must name both paths and failure behavior.