IoT Experience Design

A connected product may be encountered through a screen, a physical button, a sound, a notification, a customer-service conversation, or something that changes in the environment.

Those parts need to make sense together.

A device might use an unfamiliar technical identifier while the app uses a friendly name. A physical control might change a setting without the screen immediately reflecting it. A notification might report an issue without explaining whether the person using the product or the team maintaining it should respond.

We want to understand where those relationships matter before deciding how the interface should look.

Who is using the product? Who installed it? Who owns the account? Who shares the space? Who is responsible when something needs attention? These may be different people with different levels of access, knowledge, and concern.

The design should not require them all to become system administrators.

Connectivity needs a purpose.

It might help someone act at a distance, understand a condition, coordinate a service, personalize a setting, or notice something that requires attention. It can also introduce setup, permissions, dependencies, and new responsibilities.

We ask what the connection makes better for the people involved—and what should remain understandable or usable without it.

Sometimes the answer is an app. Sometimes it is a simpler local control, clearer information, a better staff workflow, or a carefully chosen combination. Adding another screen is not the only way to improve a connected experience.

Our Design Thinking approach helps us investigate the circumstances around the request. We consider the person, the business, the environment, and the work required to support the idea after it has been introduced.

Unboxing, installation, account creation, pairing, naming, permissions, and first use can all shape someone's confidence in the product.

We look at what a person needs to know, what the system can explain, and which responsibilities belong to an installer or administrator rather than an everyday user. We consider how someone identifies the right device and what happens if setup is interrupted or a prerequisite is missing.

Onboarding Design helps turn those requirements into a useful sequence. The aim is not to hide every technical detail. It is to reveal the relevant detail when someone can do something with it.

This also includes return visits. A person replacing a phone, joining a shared workspace, or taking over responsibility for a system should not be treated as though the product has no history.

Connected experiences need an honest account of state.

There is a difference between selecting a new setting, sending a request, receiving an acknowledgment, and knowing the physical device has applied the change. Depending on the system, some of those conditions may be unavailable or delayed.

We work with technical collaborators to understand what can actually be confirmed. Then we design the interface and language around that reality.

A display of the last reported condition should not quietly imply a fresh reading. A failed connection should not be presented as a successful change. An animated control should not create certainty that the underlying system cannot support.

The person should not need to understand the network architecture. They do need to understand enough to decide what to do next.

This is a point where Interaction Design, content, and implementation become inseparable.

When we shape connected lighting for a project room, we bring members' everyday use and the operating team's responsibilities into the discussion. Focused work, presentations and collaborative sessions can call for different conditions; people still need to understand how to make an ordinary adjustment.

The design question is broader than how to arrange brightness controls in an app.

How does someone entering the room discover the controls? Do they need an account for an ordinary adjustment? What happens when two people try to change the same setting? How does a scheduled setting interact with a temporary choice? Can a staff member understand a reported problem without relying on the member's phone?

We might explore a recognizable physical control alongside a digital interface, with appropriate access for different roles. The exact behavior would need to be agreed with the hardware and implementation specialists, not promised by the visual design alone.

The environment matters too. A control's placement, readable labels, visual contrast, feedback, and relationship to the room affect how people encounter it. The desired atmosphere should be considered alongside practical access and operation.

We coordinate experience decisions with the appropriate technical specialists. Safety-critical lighting and building requirements need qualified assessment, and any proposed fallback must be verified against the equipment and system rather than assumed from the interface.

Working through those situations together makes the relationship between interface, architecture, shared use, service and maintenance visible.

Support is part of the product experience, not a separate event that begins after the design has ended.

We consider lost connections, unavailable services, low power where relevant, interrupted updates, changed accounts, and conditions the system cannot confidently identify. Different problems need different explanations and recovery paths.

“Something went wrong” gives a person very little to work with. A useful response can distinguish what is known, what the person can safely try, and when another team needs to take responsibility. The guidance must match the actual device and service.

We also consider the employee receiving the request. Can they identify the product or location? Can they see appropriate diagnostic information? Is there a clear path from reported issue to responsible specialist?

Service Blueprinting helps connect those responsibilities. A Dashboard may help an operator understand conditions, while Custom Software Development may connect information or workflows that currently sit apart.

Neither should be added simply because it is possible. The need comes first.

The purchaser is not always the only person affected by a connected product.

Visitors, employees, other occupants, and people sharing an account may encounter its sensing, notifications, or automated behavior. We ask what information is needed, who can see it, how its purpose is explained, and what choices or alternatives are appropriate.

A sensor reading should not automatically be treated as a complete explanation of a person's behavior. We need to distinguish the information collected from the interpretation the business hopes to make.

Security also involves real device and system capabilities—not simply a reassuring interface. NIST's IoT device cybersecurity baseline provides a starting point for identifying those capabilities. Relevant technical, security, privacy, and domain specialists need to assess the actual product and its circumstances. An experience-design engagement does not, by itself, establish compliance, certification, or a secure implementation.

Our role includes making the human-facing requirements and implications visible so they are part of the work from the beginning.

Depending on the need, Abstraction can develop experience maps, setup and onboarding flows, interface concepts, control and notification behavior, content, service touchpoints, prototypes, and the documentation needed to carry design intent into implementation.

We can help connect a companion application, an operational view, a physical environment, and the supporting customer relationship. Digital Accessibility and the needs of people using physical controls should inform those choices, with appropriate specialists involved where assessment requires them.

We may lead, collaborate, or coordinate within the wider team. Device engineering, industrial or mechanical design, electronics, firmware, installation, and certification require their own expertise and defined responsibilities. We do not imply that designing the surrounding experience makes Abstraction the manufacturer or engineer of the physical product.

The shared task is to make the parts work together for people. Co-Creation brings the right knowledge into that task.

Ownership changes. Staff leave. Components need replacement. Features evolve. A service may be renewed, changed, or discontinued.

We consider how the experience explains those transitions: transferring appropriate access, removing a device from an account, understanding ongoing service requirements, and knowing what support remains available. The answers depend on the actual product and agreements; they should not be hidden behind an attractive first-use experience.

Our process remains:

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover.

Appropriate observation, feedback, product behavior, and support learning can help us refine the experience over time. That knowledge contributes to Product Intelligence, built with the client and applied to the next improvement.

Abstraction can help with a defined IoT experience need or participate in a wider connected-product, service, or environment project.

Bring us the product and the people it needs to work for. We can help connect the rest of the experience.

Contact Us