5 UX Connected Products Management Tip

People tend to think of UX for connected products in three ways:

· The industrial design of embedded devices (like the iconic Nest thermostat)

· The UI design of companion smartphone or web apps

· Exploring novel, alternative UI paradigms. That could mean voice, gesture, or responsive environments which minimize explicit interaction.

These are all important. But they miss one major issue. Connected products are systems, which require a holistic approach to design. It’s possible to do a good job of industrial and UI design as individual parts, yet still to end up with a poor overall experience. If the parts are designed in isolation, they often won’t hang together as a coherent whole.

Creating a good UX for a connected product also goes much deeper than the visible design touch points of devices and apps. Poor commercial and technical architecture decisions can undermine the perceived value of the product. They can also bubble up to shape physical and app UI design. Aligning commercial, technical and experience design factors is critical to any type of product or service. But there are particular challenges that are different about working with connected embedded hardware.

Here are 5 fundamental questions connected product developers should consider to ensure great user experience.

1. How does your product work… and how can it fail?

Introducing connectivity into hardware products introduces new possibilities. But it also creates new ways for them to fail. What were once simple everyday objects now have dependencies on power, connectivity, other devices and cloud services. All of these can (at least occasionally) fail.

Some connected products have the potential to fail in worse ways than the non-connected products they replace. Automated pet feeders can stop working because of AWS outages. Connected door locks can fail to take account of contextual factors and may lock or unlock at inappropriate times.

To be fit for purpose, the perceived benefit of your product must outweigh the impact of any failures. Any product that users rely on should maintain some basic function in the temporary absence of connectivity. Will automated rules, e.g. for connected lighting, still run? Can you allow for basic local authentication of known users so that they can still control local devices in the absence of internet connectivity? For example, a connected power tool which may be used in a deep basement should not require constant cloud access to operate.

Decisions as to which code runs where — in the edge devices, in a local gateway, or in the cloud — can be critical to product and UX. They determine what will still work if parts of the system are unavailable. Explaining this to users in simple terms can be a challenge.

2. Is your business model a good fit for user expectations?

Connected products carry a different cost structure to conventional hardware products. On top of the cost of manufacturing and distributing the hardware, there are ongoing costs involved in maintaining the service for the expected lifespan of the product. Underestimating these is a major risk to the viability of a business.

In October 2017, Canary slashed the level of service provided to free customers because it was proving too expensive to maintain. Removing night time recording, and cutting video clips of motion detection instances to 10 seconds, understandably made customers angry. Canary are now reinstating some of this functionality.

Increasingly, companies seek to cover ongoing costs through service subscriptions. Service offerings are also seen as a valuable opportunity to develop direct, sustained relationships with customers. But it can be tricky to persuade customers that a product they think of as a one-off hardware purchase should justify an ongoing monthly fee. A subscription to a door lock — paying a monthly fee just to open your own front door — is a hard sell.

A connected product business model needs to be a good fit for where users perceive the value to be. If you can frame your product as a service enabled by a (lower profile) device, consumers will perceive the value to rest with the service. They may then be more prepared to pay recurring charges.

If they perceive the value principally to rest in a device (which benefits from a service), ongoing payments are a harder sell. They will expect to get access to any data from their devices for free. To make a service subscription palatable, the service may need to be bundled with other benefits which are attractive in their own right. A thermostat might come with a heating maintenance contract. A door lock might be an enabler for a security monitoring service, or AirBnB management services.

3. How often do devices connect? How responsive are they?

Product developers aspire to create connected products that feel seamless. But this is often unrealistic. Delays and glitches are part of normal use for most connected products, and creating a good UX for IoT is often about handling this gracefully.

The need to conserve power means that many battery-powered devices connect only intermittently. So it can take time to get new data from them, or for them to wake up and check in for new instructions.

And when they do, the nature of internet networking means that they may take a little time to respond (latency) or occasionally messages may go missing (reliability).

People have mental models of the conventional internet that allow them to understand that sometimes downloads will run slowly, or Skype calls will fail. But we also have millions of years of evolutionary experience which tells us that physical objects respond to us immediately and don’t ‘lose’ our instructions. Internet-like glitches, experience through the real world, can feel very disconcerting.

This can be serious enough to undermine a value proposition. The first generation of a popular connected doorbell took over 30 seconds to connect to the cloud service before even alerting the home’s occupier: enough time for most couriers to give up and leave on the assumption that no-one was responding.

Even if the product is working correctly, delays introduce doubts about reliability. If you turn a light on and it takes even a couple of seconds to respond, that’s long enough to wonder whether it’s actually going to work or not. Through a combination of latency and intermittent connectivity, some devices, such as battery-powered heating controllers, could take up to a couple of minutes to respond to an instruction. During this time, a user standing in front of them might have two displays giving conflicting information about the state of the system: which breaks some fundamental usability guidelines.

Product developers need to establish how quickly — at a minimum — a product needs to respond to users in order to fulfill its basic purpose, and ensure the technical design can meet that need. Where delays are unavoidable, ensure users know that something is happening: confirm to the user that their request is in progress, even if you can’t yet confirm whether it has been completed. If a device’s status may be out of date because it hasn’t checked in for a while, timestamp its data so it’s clear what’s happening.

Connectivity patterns also shape the data that connected devices gather, and thus the value and nature of the insights they can support. Smart meter electricity sensors are mains powered, and can send updated readings about 7 seconds apart. This is close enough to a reading of live power consumption to determine with some accuracy which appliances are likely to be on right now. A smart meter’s natural gas sensor is likely to be battery powered, because that is safer than running mains electricity next to a gas pipe. As a result it may only send readings of cumulative energy usage every 15 minutes. This can show patterns of use throughout the day but cannot reliably indicate whether an appliance has been left on by mistake.

And data from connected devices may often be recent, but isn’t always guaranteed to be 100% up to date. It’s important to communicate how old data is: for example, a fire alarm service that says ‘Everything’s OK’ in the absence of fire should offer a timestamp. If the data is 5 minutes old, that means there was no fire 5 minutes ago — not that everything is guaranteed to be OK right now.

4. Design not just for individual UIs but for interusability

Connected product UX is often thought of as the industrial design of devices, and the UI design of companion web or mobile apps. The two are treated as separate. But this often creates incoherence. Users experience them together as part of a system, and design needs to consider them at the same time.

A key design decision is determining which user-facing controls need to be on the hardware, vs in web/mobile apps, or both. Products of very similar types may take very different design decisions. For example, the Tado heating controller is a simple box with very few hardware controls. Most of the user interaction is handled by a smartphone app. By contrasts, the Ecobee mirror UI controls between a full-featured device and an app. Keeping hardware simple keeps the bill of materials down, because physical UI components add cost. It also makes the product easier to update over time, as features aren’t baked into a hardware UI. But if the user can’t access the app for some reason, they lose control of the device. Devices with full onboard UIs can support all features locally. But they will be more expensive to manufacture, and provide less flexibility for future updates.

Other options include putting a subset of key interactions on a hardware UI, with a full-featured app (e.g. the Willow breast pump, the GoPro camera). Or a device UI may support core tasks, with supplementary features offloaded to the app. For example, parental controls on the Nintendo Switch are available in a companion app.

Putting connectivity in a device can also change the nature of the physical UI it needs. Many physical controls, such as dials and switches, are used both to control the device but also to communicate its status. A washing machine dial shows that the machine is set to the delicates program. If the program can be changed from a remote app, then the machine UI needs to be updated. This could mean motorizing the dial so it can reflect that change. Or it could mean replacing it with a different type of interface which can change more easily, such as a touchscreen.

A second issue is figuring out how different UIs across what may be very different types of device can feel like a family. Appropriate consistency across terminology, visual language, interaction patterns is important. But although this is an easy issue to grasp, it is a challenging one to implement. What’s more important? Consistency with platform conventions (e.g. iOS/Android)? Consistency between your own service/device UIs? Or consistency with industry standards or hardware conventions? The result is often a juggling act with many compromises. At the most basic level, it’s important to give the same features the same name across all interfaces. But even this can be a challenge when the same app needs to support multiple versions of legacy hardware. Perhaps device designers had different ideas about whether ‘auto’ or ‘timer’ was the ‘best’ name for the heating schedule function. Subtle touches can help to tie the experience together; such as the Nest app which emits the same click as the thermostat bezel when the temperature is changed.

5. How can we prototype experiences in parallel with technical feasibility?

In software, iteration is easy. The current trend for lean product development encourages companies to rush out an MVP, learn from how it is used and evolve and improve it over time. Even if the value proposition turns out to be wrong, there is the option to pivot.

This rarely works with hardware. Devices need to be designed, specified, built and tested to fulfill specific requirements. Changing your mind about those requirements half way through the hardware development process can be prohibitively expensive in terms of time and rework. Pivoting can be nigh on impossible.

So it’s important to test the value proposition, and uncover core user requirements, early on. Doing this in parallel with hardware development means that changes can be made. But it means finding ways to prototype and simulate the product experience that don’t rely on functioning hardware.

Experience prototyping techniques for connected products do just this: simulating the experience of using the product for both design exploration and testing with users.

Video mockups can be compelling ways to explore the proposition. Bike navigation startup Beeline released a video of an imagined product on Youtube to test the proposition and win early investment. But even something as simple as writing the press release for an imagined product can be enough to gauge initial customer interest. And videos for customer testing interactions can be very low fidelity (c.f. Method alumnus Martin Charlier’s techniqueusing cardboard mockups and Instagram video).

Prototyping techniques for connected products also need to consider the whole experience. Conventional digital prototyping software focuses on interactions with a single app UI. But for the connected product, this is designing only half the conversation. IoT designers need to consider how users will interact with apps and devices at the same time. Again, simple changes to techniques make a big difference. Designers can map out process flows as swimlane diagrams spanning multiple UIs. Sketching storyboards, instead of screens alone, is a great way to map out interactions with the whole system and consider the context of use. Service design, with its focus on orchestrating interactions around an ecosystem of parts, offers some of the best techniques for IoT concept design.

In summary… always design for the ecosystem

IoT technology is evolving, and new business models and prototyping methods may emerge. But we think one thing about connected product design won’t change. If you want your product or service to offer users a coherent and compelling experience, you can’t design the components in isolation. You need to understand, and design, how they work together as networked parts of a system.