ux and service design for connected products€¦ · get in touch: iotuk.org.uk [email protected]...

Produced byJUNE2018

UX AND SERVICE DESIGN FOR CONNECTED PRODUCTS

Claire Rowland

IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected productsGet in touch:

Summary ........................................................................... 1

UX, service design, and IoT.............................................3

What is UX and service design?....................................3

UX and service design for IoT .......................................4

Technical factors: how decisions about architecture, connectivity and power constraints shape user value and UX ....................................................................5

How does it work? How could it fail? Architecture and reliability ..................................................................5

Battery life, connectivity patterns ...................................7

Latency and responsiveness .........................................7

API design and fit for UX................................................8

How does it interoperate with 3rd party devices? .......8

Distributed UX/interusability ...........................................9

Composition ...................................................................9

Consistency .................................................................. 10

Continuity .......................................................................11

From products to services .............................................. 14

Is it a product or a service? .......................................... 14

Why think about services ............................................. 15

The changing nature of ownership ............................. 15

Designing services ....................................................... 15

Commercial factors: how business models and value propositions underpin UX ................................... 17

Giving users transparency and control ........................ 19

Helping users grapple with complexity ...................... 19

How it works, and how it can fail ................................ 19

Ownership, and the right to modify ............................ 19

Security ......................................................................... 19

Data privacy ................................................................. 19

Automation and algorithms ........................................ 21

Communicating complexity ........................................ 22

Design methods and prototyping ............................... 23

Making the right thing ................................................ 23

Making the thing right ................................................ 26

Summary: planning UX for an IoT project .................. 34

Ongoing user research ............................................... 34

Prototype and test early .............................................. 34

Design for the system, and the service ...................... 34

Foster good team collaboration ................................. 34

In summary ................................................................. 34

Table of contents

IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected productsGet in touch:

Claire Rowland is a London-based product/UX strategy consultant specialising in IoT and hardware-enabled services. She is the lead author of Designing Connected Products: UX for the consumer internet of things (designingconnectedproducts.com) published by O’Reilly.

She has a particular interest in taking connected products from an early adopter user base to the mass market. Before launching her own consultancy (clairerowland.com), she worked on energy management and home automation products as the service design manager for AlertMe.com, since acquired by British Gas Hive. Previously, she was head of research for design consultancy Fjord, where she led EU-funded R&D work investigating UX for interconnected embedded devices. She has worked in UX design and research for mobile, multiplatform and web services since 1997.

Summary

There are a huge variety of applications in IoT spanning connected products and hardware enabled services. Consumer products such as home lighting and heating controllers are growing in popularity. Across many industry verticals, sensing, tracking and actuation are enabling smarter use of resources, just in time processes and predictive maintenance.

All of these have users, who want products and services which are useful, usable and satisfying to use. Mass-market consumers may have quite different needs from industry specialists. But there are many common challenges in designing the user experience of products which span both hardware and software.

In this Insight Report, we’ll look at the factors which make UX for IoT particularly challenging. We’ll discuss how technical architecture and business models shape UX, and how IoT blurs the line between product and service experiences. We’ll look at the need to give users transparency around how complex systems work and share data, in particular in relation to GDPR. And we’ll set out the challenges of designing distributed user experiences across multiple UIs, and show how some companies are tackling the challenges of designing for both hardware and software in parallel.

NB: we interpret IoT loosely to refer to connected products and services enabled by connected hardware in general, whether or not they communicate using open internet protocols or have a direct internet connection.

IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected productsGet in touch: 3

User experience design is concerned with creating products and services which are:

Valuable/useful: they fulfil a genuine need for a particular group of users or customers;

Usable: the target users can use the product effectively to achieve their objectives; and

Engaging: satisfying or pleasurable to use

People often assume UX refers to software UIs. But a user’s experience with a product or service is usually shaped by many factors, for example:

The product’s fit for their needs

How reliably it works

How fair pricing is perceived to be

Other offline or online interactions with the provider alongside the main applications, for example purchasing, order fulfilment, and customer support.

Some of these factors are beyond the conventional remit of UX designers. They illustrate that UX involves collaboration between the entire product team. Even if there is no-one on the team with ‘UX’ in their job title, the product or service provides an experience to users. This needs careful planning and development.

“We’re passionate about making products for women that really improve their lives, so anything that we do is going to be reflected in how we’ve thought about the user experience. And that doesn’t just mean the physical product or the software, it also means the packaging, it means the manual, it means all the touch points, it means wherever you’re going to see it in a store that we’ve thought about the point of sale. So user experience is the whole thing, it is the product, the product should be the experience. And the better that is, the better the product feels like a real experience then the better it feels like one product and not multiple things stuck together.” Ben Levy, Chiaro Technology: makers of the Elvie pelvic floor trainer and another new product due for release in 2018.

Fig 1. The Elvie pelvic floor trainer from Chiaro Technology https://www.chiaro.co.uk

The discipline of service design is closely related to UX. It looks at the whole lifecycle of a user’s experience with a service, and how all the different components of the UX function together to deliver the service. It also identifies the people, infrastructure, communications and other enablers required to support the service.

Designing a service is a team effort. Service design provides methods and tools intended to align teams around crafting the best possible customer experience, from purchase through to end of life.

What is UX and service design?


Experience design for IoT products is more complicated than it is for software or conventional physical products. There may be more customer UIs or ‘touchpoints’: perhaps multiple devices, mobile or web or voice applications, customer support, and interoperating products. Physical devices exist in a real world setting, posing new challenges to tackle. For example, hubs in the home are often unplugged when someone needs a socket to plug in a vacuum cleaner, and doesn’t realise that this plain white box is keeping the heating or lighting working. Network connections introduce potential points of delay or failure. And the relationship between the customer and provider is not a one-off transaction but the ongoing delivery of a service.

UX for connected products is not just about UIs, but the whole experience of the product. It requires a different mindset and approach from conventional software UX. UX needs to take into account the way in which the user experiences the whole system, as well as the detail of each UI.

UX and service design for IoT


In a distributed system, there are many places in which design decisions can be baked into code, from front-end apps, to APIs, cloud services, gateways and embedded device firmware. Decisions about which code runs where shape how the product functions. Decisions about how each part connects, and how often, can shape the value proposition and even the UI.

“The user experience has got to drive the technology and the technology is there to facilitate the UX.” Russell Ward, EDF Blue Lab innovation accelerator, part of EDF Energy

“When you start the focus is very much on the physical product … but we’ve seen repeatedly working with connected products that often the reason they ship late is because of software: firmware on the device, the app and the backend, and also testing. Just to get the product in your hand is one thing, but to get it in your hand and be confident that it’s working well enough to ship is quite different.” Jon Marshall, Map Project Office, a product design consultancy specialising in connected products.

How does it work? How could it fail? Architecture and reliabilityThe first question to consider is the relationship between technical architecture and UX. Which code runs on your edge (embedded) devices? If there is a hub or gateway, what role does that play? What happens in the cloud?

You might think that non-technical users shouldn’t have to care, and when everything is working well that’s mostly true. But decisions you make about architecture will shape the reliability of the product, and the effect on the user when things occasionally go wrong. Any computer, device or network connection will sometimes experience power or connectivity outages, or other issues. IoT systems often have many interconnected parts, and the more parts and connections are involved in running the system, the more potential points of failure there are. The question for UX

is what the impact of temporary outages may be. For example, some connected lighting systems – like Philips Hue – have automated rules which run both in the cloud and in a local hub. Others, like LIFX, have no hub and run entirely in the cloud. In the event of loss of connectivity, the system with local rules will continue to run, the system without will not.

If users rely on your product, it should maintain some basic function in the temporary absence of connectivity, at least allowing local users to continue to use it even if remote access is disabled. No-one should ever be locked out of their house, or unable to turn their lights on, because their home internet connection went down.

“We want to make a product that works as well offline as well as online, so it’s quite important to have the local chime for the doorbell so it will work even if your internet’s down or you don’t have your phone”. John Nussey, Ding, connected home startup and makers of the Ding smart doorbell.

Fig 2: The Ding doorbell, chime, and app (www.dingproducts.com)

Technical factors: how decisions about architecture, connectivity and power constraints shape user value and UX


Reliability issues mean that the user may not always have up to date data about the state of the system. Sometimes, this matters. This can determine the way that data and updates are provided to the user. For example, designer/engineer Ross Atkin’s Liftcheck system for the Greenwich and Woolwich foot tunnels provides simple updates via a web app showing whether the lifts at the tunnel are in use or not. The tunnel stairs have over 100 steps, so if the lifts are out of action then the tunnels are not accessible to people with motor disabilities or many cyclists, and a long detour may be required. Sometimes the sensors lose connectivity, and at those times it’s not possible to know whether the lifts are working or not. When that happens, the app shows that the status of the lift is unknown, which helps would-be tunnel users decide whether to take a risk or find an alternative route. It is better to show that there is no information, than to provide the wrong information.

“This is a “No information” state. Probably the lift’s broken, but it might not be, the monitor might just have lost power.” Ross Atkin, Ross Atkin Associates

Fig. 3: The Greenwich Foot Tunnel Liftcheck app, showing a ‘no information’ state for the south lift (Ross Atkin Associates, http://g.liftcheck.uk/ ).

Another example of the need to handle indeterminate states is Stannah Connect (also a partnership with Ross Atkin Associates). This helps offer peace of mind to family and carers of elderly or vulnerable people. Sensors in smartplugs and a stairlift track provide updates on the person’s activities at home.

If the system does not report any new updates for a while, that could be cause for concern. But it could also mean that there’s a temporary connectivity problem with one or more sensors. The team considered sending notifications to carers if a problem was detected, or if no activity was detected for a while. But there were two risks with this. Firstly, if the system experienced an outage it might not be able to alert a carer to a problem. Secondly, notifying carers every time there was a lack of data caused by individual sensors being offline (instead of a genuine problem) would quickly become irritating for both carers

and the client. Instead of promising to alert carers in case of a problem, which might sometimes fail, or be a mistake, the team decided not to send alerts at all. This set the expectation that the onus was on the carers to check on the older person via the app themselves, and to decide for themselves whether they seemed to be OK.

“We originally planned on having notifications or alerts in the system. So if there was no activity for a certain period of time then we would notify the carer. But if the system goes down for any reason [and cannot send alerts] where do we stand from a liability point of view as a business? And also we want this to be about everything’s OK, so we want people who are monitoring the app to actively open the app to check everything’s all right.” Tom Smith, Stannah

Fig 4: Stannah Connect: control unit plus devices, and app screenshots (Stannah, Ross Atkin Associates)

In the distributed UX section below, we’ll consider further how reliability issues can be handled in UX design.


Battery life, connectivity patternsThe absence of connectivity is not always an edge case. Many connected devices, particularly those powered by batteries, spend much of their lives offline by design. They connect only occasionally to send data or check for new instructions. This minimises power consumption and maximises battery life.

“A lot of our competitor products need a stable connection all the time because people dial into them. We’ve shut ours down as far as we can so it’s in a deep sleep hibernation mode, it wakes up and connects as fast as any of the others do to WiFi, it just means the product can last for longer, there’s only activity when something happens to it. So the battery will last longer without being recharged, like six months rather than maybe a month at best.” John Nussey, Ding

This means that data and instructions can take time to percolate around the system. Not everything will always be perfectly up to date or in sync.

Fig 5: EDF CAD device. CAD – consumer access device. Used to get users in-day data from their smart meters, which on their own will only report data at a day’s delay. The device typically takes 5 minute readings but can be prompted to take 3 second readings (near live data) for bursts of a few minutes. This shaped the UX design, discussed in the ‘Continuity’ section below.

Maintaining some order in the face of these discontinuities is a challenge for system developers, e.g. maintaining accurate time series data.

It also has knock-on effects on UX. For example it may be necessary to timestamp data, make it clear that instructions might not be acted on instantly. It may also be necessary to communicate with the user in a different way. A connected smoke detector might have last sent data that no smoke was detected 15 minutes ago. That does not necessarily mean that everything is OK right now. It should be designed to wake up and send an alert if smoke is detected, of course, but it’s possible that might not work, or that in the interim a fire has started.

So instead of ‘Everything is OK’, the message the app can communicate is ‘No smoke detected at 10.15am’.

UX designers from web service backgrounds usually assume that all parts of a system are connected and online by default. The realisation that that is often not true in IoT is one of the main adjustments in mindset required to work with hardware enabled services. If you’re hiring a designer who is new to IoT, introduce them to the connectivity patterns of your system upfront to help set the correct assumptions.

“I thought that we would just be getting a flow of data, it would be never-ending. And then I learned it didn’t work like that. That completely changed how I had to approach this as a user experience.”Kerry Malone, Head of UX & Design, Connected Homes, EDF Energy Blue Lab

Latency and responsivenessA related issue with networked hardware is the latency with which messages are passed around. Any internet user knows that sometimes problems will occur, such as downloads running slowly or Skype calls failing. But latency (and reliability) can feel very strange when experienced through the real world. Millions of years of evolutionary experience of real world physics have taught humans that objects respond immediately and reliably when interacted with. When you flip a light switch, it does not take 30 seconds for the light to come on. When you push an unlocked door, it opens, and does not ‘lose’ your instruction. Over internet networking, neither of these things are guaranteed. There can be delays in instructions getting through, and occasionally they may go missing altogether. Even very short delays of a few seconds are enough to break the illusion of direct manipulation, and can introduce the fear that the instruction has been lost.

““In our case it was also a conscious decision just to do voice for the product because we were thinking more about instant response and communication rather than surveillance. What you tend to get with the video doorbells is you press the button, the light goes on for a little bit, it connects to the WiFi, it loads up on your phone, you swipe in, you open up the app, it loads the pixels… you’ve had about 20 seconds by the time you’ve got to that. The delivery person will already be filling out a “Sorry we missed you” red notice to your door by that time.” John Nussey, Ding

Good technical design, e.g. using local networks where possible, can help reduce the risk of latency. Identifying where potential delays may occur in the early stages of technical prototyping is important to develop mitigation approaches:

“First we build a simulator for the hardware, so before we’ve got the hardware we have an app that has a Bluetooth interface like we expect the hardware to have.


And then as we build the hardware we refine this so it always has the right Bluetooth interface. That lets us start testing things like communication between devices, so you can have a simulator connect to a phone a metre away and start sending session data, and see how long it takes. We do that quite early, trying to think about how long is it going to take to get the data from the device to the phone, for instance, and then also what strategies can we adopt in our whole design that will aid that. With the new product we know that there’s loads of data but in fact for the user there’s only a few bits of data that they’re interested in, so we can request just the data that the user is interested in and make sure that that’s the sparsest dataset so that it can get to them really quickly.” Ben Levy, Chiaro Technology

But it’s not always possible to avoid it altogether when messages are being passed over the internet. The UX design may need to account for interstitial states. For example, an instruction has been sent to a device but the device has not yet confirmed that it has received and acted upon it. We cover the design impact of this in more detail in the Distributed UX section below.

This is another issue which designers from software UX backgrounds may not anticipate. See the Design Methods section for suggestions for design techniques which can help identify where in the UX flows this may be an issue, and figure out how best to deal with it.

API design and fit for UXUser interfaces are underpinned by APIs. These are the glue by which IoT systems pass instructions and data to other parts of the system, including front-end applications. To provide a user experience with the right functionality and level of responsiveness, API design and UX design need to be aligned. This means considering the functions which are supported, and the granularity of data and instructions which will be needed. As a very simple example, a network of pollution sensors (check) in a city would each have individual data to report. But it might also be useful to know the average reading for certain areas, or to identify any readings which are above (or below) certain thresholds. To ensure that the correct readings can be retrieved easily and quickly by the front end web app, each of these readings should correspond to an API call. API and UX design should go hand in hand, based on a shared understanding of user needs and priorities.

How does it interoperate with 3rd party devices? A final technical factor in shaping UX for IoT is interoperability. Products which interoperate with 3rd party products can do so in different ways: typically by connecting directly over local networks, by connecting to the same hub or gateway, or cloud to cloud. This can be a fantastic extension of the UX: giving the user the ability to ‘turn the living room on’ and control multiple devices via a voice assistant. But there are several considerations for the user experience.

Firstly, adding interoperating products to a system extends the technical architecture questions – how does it work, and how can it break. There are more things for the user to understand, more complexity to how it works, and more interconnections that might occasionally not work. Your Amazon Echo may confirm that it has sent an instruction to a connected bulb to turn the light on, but it cannot know whether the bulb has actually responded.

Fig. 6: devices may not respond to commands instantaneously, or 100% reliably

There may also now be more than one route to achieve a particular task, leading to potential confusion when interfaces are different. This is especially the case if the 3rd party interface supports only a limited set of functionality. For example, a lighting manufacturers app may support features that other interoperating apps do not. It’s possible to set the lights to a state from one app that is not possible in the other one, which raises the challenge of how the 3rd party app displays that status.

Similarly, there may be more than one place where application logic, such as automated rules, can sit. Continuing with the connected home example, rules for turning lights and appliances off could sit in more than one place, with the result that Apple Homekit or IFTTT is trying to turn a light off at the same time that LIFX is trying to turn it on.

With all these issues, giving the user visibility of what is going on with the system is enormously helpful. Having a place in the UI where the user can go to find out what happened and why (e.g. ‘light turned on from IFTTT rule’) can help them identify and fix any issues.


IoT products often present multiple devices and interfaces for users to interact with. A connected heating controller may have its own UI, and a smartphone app, both of which can be used to change settings. A connected industrial drill will have all the basic controls an operator needs for standard use. But it may also have an app to log usage data, enable easier monitoring when the drill is on a rig, and provide additional ways to modify settings, such as torque.

Users don’t use these interfaces in isolation, they experience them together as part of a system. Certain use cases may involve switching between them or using them together. Changes made via one UI will need to be reflected somehow on the other. Interfaces which make sense in isolation can cause confusion and misunderstanding when they are poorly aligned with each other. So the UX design needs to consider how they work together.

Even if users only interact with a single UI, the communication patterns by which the data reaches the user from the distributed sensors can still have a dramatic impact on design and functionality. For example, a web app used to monitor environmental sensors around a farm may show recent data from some sensors, older data from others, and some data readings which are missing.

This is what we refer to as distributed UX, or ‘interusability’1 .

Design decisions include:

Determining which functions sit where in the system (composition)

Designing for appropriate consistency across interfaces

Designing for cross-device interactions and the surprising effects of networks (e.g. latency, reliability) and connectivity patterns on UX and value propositions (continuity)2

CompositionAs discussed in the technical factors section, decisions about the technical architecture of a connected product can dramatically influence the user experience. At the most visible design layer, this includes deciding which user-facing controls need to be available on which UI. For a common app/device combination, this means deciding which controls are on the hardware, which on the app, and which may be needed on both.

Similar products may follow different patterns. For example, the Tado heating controller is a simple box with very few hardware controls. Most user interactions with the system are handled by the smartphone app.

Fig. 7: The Tado heating controller and app (http://www.tado.com)

The key advantage of this approach is that it keeps the bill of materials down: physical UI components add cost. The product is also easier to update in future: software UIs can easily be changed to support new features, but hardware UIs cannot. But it means the user must have access to the app in order to control the device.

Distributed UX/interusability

1 The term inter-usability was first used in C.Denis and L.Karsenty, “Inter-Usability of Multi-Device Systems—A Conceptual Framework,” in Multiple User Interfaces: Cross-Platform Applications and Context-Aware Interfaces, eds.A.Seffah and H.Javahery (Hoboken, NJ: Wiley).2 The 3 part model of composition, consistency and continuity originates from M.Wäljas, K.Segerståhl, K.Väänänen-Vainio-Mattila, and H.Oinas-Kukkonen, “Cross-Platform Service User Experience: A Field


By contrast, the Ecobee HVAC controller has both a full onboard UI and a companion app, with features mirrored across both. Devices like this can support all features locally whether the app is available and able to connect or not. But they are more expensive to manufacture, and it is more difficult to roll out new features through updates.

Fig 8: The Ecobee HVAC controller and app (http://www.ecobee.com)

There are several variations to this pattern. Some products provide a subset of common controls on the device itself, with these and other more advanced controls in the app. The GoPro camera is an example of this. This pattern works well because the camera needs its own controls for basic functions but the form factor, and the way it is worn (e.g. on a helmet), makes it unsuitable for more complex interactions.

Sometimes a device UI may support core tasks, with different, supplementary features handled via the app. The Nintendo Switch gaming console has a companion app specifically for parental controls, allowing the parent to set time limits on gaming without interrupting play.

There may be more than one viable option; it depends on the context of use. But it is often safest to make a product which stands alone and can continue to work effectively in absence of cloud service.

ConsistencyA connected product may have UIs spanning very different types of device and form factor. Finding the appropriate degree of consistency helps them feel like a family. It also sets expectations for what the user can do with each one, and the product as a whole.

“Look at the way an interface for a physical thing is designed and the app’s design in terms of similarity between the experience. Designing the physical thing in isolation from the app, is only going to introduce more cognitive load on a person, because they’ve now got to learn two things at once. What happens on the physical thing should be signalled somewhere on the app, ensuring the user has a coherent experience.” Tim Daines, Senior Experience Designer at Cambridge Consultants

This is an easy issue to grasp in theory, but a challenging one to implement in practice. The interfaces can’t be the same, and consistency works on many levels. To what extent should a web or mobile app be consistent with platform conventions (e.g. iOS/Android or web)? To what extent should your own service/device UIs be consistent with each other? Are there industry standards or conventions from competitor or legacy hardware devices with which your devices need to be consistent?

Compromises will need to be made. The design task is to identify the most appropriate balance. Perhaps the most important priority is ensuring that users know which features are the same on each device, even if they are used in different ways. Giving features the same name across all interfaces is critical in this regard. But even this can sometimes be a challenge when, for example, different versions of legacy hardware use different terminology (e.g. ‘auto’ or ‘timer’ or ‘schedule’). In this situation, it’s best to ensure the user’s mobile UI is consistent with their device, even if that means having to maintain several slightly different UIs.

The second priority is to make sure that each UI is appropriate for the device it is experienced on. A native smartphone app should follow iOS or Android guidelines. Power tool controls should be a good fit for the user’s expectations. Skeuomorphism, e.g. mirroring a hardware UI on a phone, is usually ugly, awkward and results in poor usability. But even if users don’t interact in the same way on each device, there can be elegant ways to tie to the UIs together and make them feel like a family. For example, on the Nest thermostat, the temperature is adjusted by turning a rotating bezel. On the companion app, the user can tap up and down arrows, or tap on the dial. This is a much more precise and accurate interaction for a touchscreen than dragging an imaginary dial. But the designers have tied the experience together through visual design styling, and the subtle touch of making the app emit the same audible click as the thermostat bezel when the temperature is changed.

Study and an Initial Framework,” Proceedings of the 12th International Conference on Human Computer Interaction with Mobile Devices and Services, MobileHCI 2010, p.219.ACM, New York (2010).


Fig. 9: Nest thermostat and app, http://www.nest.com

““On the new product we were trying to work out how effectively you could have two interfaces which could do the same actions and that would not confuse the user. … I think that was the critical stage for us in the design, working through that conceptually, how to make sure that it’s consistent when you’re using the app and using the hardware, how to make sure that both the app and the hardware UI can confirm the action and that they live together as a single product and don’t feel discordant.” Ben Levy, Chiaro Technology

ContinuityContinuity refers to the experience of interactions which span multiple devices. For example, using a voice assistant to turn on the lights, or turning on a smart plug and watching the power consumption reading change on an energy monitor.

Product designers usually aspire to make these interactions feel instantaneous and seamless. But the latency, reliability and intermittent connectivity issues discussed in the technical factors section above often mean that seamlessness isn’t realistic. There will often be short delays, sometimes longer ones, and occasionally something will go awry. Instead, the goal is to ensure that the user always knows what is happening, even if it can’t happen instantly.

Fig. 10: The loading screen on the EDF CAD app, shown while the app retrieves energy consumption data from the server

For actuating devices, the key issue is handling delays between the user’s request to change something, and the device responding. In a direct manipulation interface, when the user presses a button, the button changes state both to show that it has been pressed, and to confirm that the action has been carried out. A response time of 0.1 seconds or under is needed to feel instantaneous and preserve the sense of direct manipulation. A response time of between 0.1 and 1 second feels clunky. Above 1 second, the UI needs to provide some indication that the action is in progress, to avoid the sense that something has gone wrong.


If the user is turning on an appliance which may take a few seconds to respond, there is enough time to worry that it is broken. The user needs to see some sort of response confirming receipt of their request, even if the system can’t yet confirm whether it has successfully responded.

There are two options here. When actions aren’t particularly critical, for example, turning on a light, a white lie might be appropriate. This means pretending the action has been completed, and backtracking if something goes wrong. Philips Hue app does this. If the user drags the slider to turn a light on, the slider moves up as if the command has been executed. If, for some reason, the light does not come on, the slider moves back down. Though Hue does not do this, for many applications it would be advisable to offer the user an error message and perhaps an explanation of what went wrong.

For more safety critical use cases, it’s important not to give the user the impression that their request has been acted upon until you are sure it has. In that case you might design your control to have three states – on, off, and sending instructions. Belkin WeMo smartplugs follow this approach. If the user turns the plug on, the app acknowledges the request, then shows that instructions are being sent, and only shows that the plug is on when it receives confirmation from the plug itself.

Fig. 12: The Belkin Wemo app showing the off, interstitial and on (confirmed) states

Fig. 11: Philips Hue app


Delays due to latency are sometimes compounded by intermittent connectivity. Battery powered heating controllers may only check into the network every 90 seconds [needs another example]. During this time, a user standing in front of them might have two displays (an app and the device itself) giving conflicting information about the state of the system. This is very confusing. There may also be edge case situations where two different users happen to be making conflicting changes at the same time via different interfaces.

The appropriate approach to handling these issues depends on the use case and context of use. The aim is to ensure the user is always appropriately informed of what is going on and aware of the actual state of the system, without overloading them with too much communication.

For sensors, the continuity challenge is what to do when data may not be up to date and therefore may not be correct. If you’re not able to guarantee that information is up to date, which is common, then clearly timestamp it so that it is clear what is happening.

The value and significance of data can change dramatically depending on the granularity with which it is connected and the frequency of reads. This is a key question which underpins both UX and value proposition. Electricity sensors are mains powered, and can often send readings every few seconds. This is good enough for the user to turn on a specific device and get an idea of its power consumption. But a gas sensor is likely to be battery powered, as this is safer than running mains electricity next to a gas pipe. It therefore has to connect less often, and may send cumulative readings of total energy usage every 15 or 30 minutes. This is useful on a high level to show, for example, daily patterns of heating use. But it isn’t frequent enough to see the impact of a single appliance in real time, for example to alert the user that the gas cooker has been left on as they are leaving the house.

As physical appliances gain connectivity, the choice of physical controls, such as dials, buttons and switches, may need to evolve. Controls often do two things: changing settings but also communicating status. An oven dial might show that the temperature is set to 200C. If the temperature can be changed to 220C from a remote app, then the oven UI needs to be updated to reflect the new status. This could mean motorising 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 digital display.

Fig. 13: The EDF CAD app, showing electricity (very frequent readings) and gas (less frequent readings)

Fig. 14: The EDF CAD app offers the user ‘experiments’ to help them understand the energy consumption of daily activities. Starting an experiment triggers the hardware to take near-live data readings for a few minutes, so that the user can see the impact of using an appliance.


Is it a product or a service?All IoT systems involve a combination of hardware components and a software service to keep the system operational. Both play an important role in shaping the user experience. But the extent to which each is visible to the user, and central to their understanding of the product, varies from one system to another.

Some IoT systems are connected products, for which the hardware is front and centre. The key value for the user rests in a connected device, like a connected door lock or light bulb.

Others may be hardware-enabled services. With these the user value rests principally in the service, not the

hardware, but the service depends on connected hardware. This may be very low profile to the user, for example a smart energy meter in the basement, or a network of air quality sensors.

“We’re building cloud software that accepts custom orders from fashion brands’ websites all over the world, and then converts those choices into manufacturing files and distributes them to factories with connected machinery at the other end. It has flavours of the Internet of Things, but we are trying to take advantage of the connectivity to the machines to build on-demand supply chains, rather than making machines that are connected.“ Martin Charlier, Unmade: a platform enabling brands to offer customisable clothing via on-demand manufacturing

From productsto services

Fig. 15: Unmade’s platform enables customised fashion manufacturing (http://www.unmade.com)


There are many classes of product/service in between, with varying relationships between hardware and software. Some are even platforms, like a connected car:

both a visible piece of connected hardware (composed of many subsystems) but also the enabler for a wide range of digital services. The extent to which the hardware, or service, is in focus will shape your priorities for user experience design.

Why think about servicesProviding a cloud service to keep the system operational also shapes the nature of the user (or customer) relationship. A conventional hardware product relationship is often a one-off purchase, perhaps with the option of customer support if something goes wrong. A connected product creates a more complex ongoing relationship with the user, extending beyond purchase through ongoing use and support, all the way to end of life (what happens if you stop supporting the cloud service, or the user wants to transfer ownership to someone else?).

“Most people just think an app’s an app. You have to think about who’s going to maintain servers, who’s going to deal with technical problems, what happens if we need to update the app, how does that run through the business. “ Tom Smith, Stannah

“Designing connected systems is a huge challenge with existing consumer business models - “we only sell physical things”. In that current mindset, the journey ends once the consumer gets the thing out of the box. Now we have connected systems, once the thing is out of the box and connects to the cloud, this is the beginning of a new journey where the consumer is now experiencing a digital service.” Tim Daines, Cambridge Consultants

Some of these interactions may happen with the product itself. Others will take place through other on- or offline channels such as websites, callcentres, messaging, physical stores, or service personnel. Some may even involve 3rd party companies who access data from the product. For example, an insurance company may offer cheaper cover on a car in exchange for data about driving habits. In service design language, these are ‘touchpoints’ for the user. Ensuring a good experience at each touchpoint requires coordination across many business functions, and planning for the whole lifecycle of the product.

The changing nature of ownershipPutting connectivity into a product, and therefore building a service around it, does not just create an ongoing relationship between user and provider. It also changes the nature of that relationship, and challenges the nature of what it means to ‘own’ a product in the first place.

Owning a non-connected product is simple. You buy a product, whether it’s a TV, tractor, or rubbish bin, with a fixed set of features which suit your requirements. It continues to provide the same features (breakages and repairs aside) for the duration of its life. If you buy a kettle, you expect it to continue to be a kettle.

But connected products don’t remain static in the way that non-connected things do. They have the potential to be modified through software updates. A heating controller, or a modern connected TV, is a tiny microcomputer. The supplier can release firmware or software updates which allow it to perform other functions.

When we use software, we expect it to evolve and be updated over time. Most software is now paid for through a SAAS model which reflects the dynamic relationship with the provider. But we still expect that physical products will remain static. IoT challenges this dichotomy: physical products have the potential to morph into things which are no longer the thing we originally bought. If that’s the case, do we really own them? What rights do we have over them? What rights does the provider have to modify them? The idea of ownership is changing, and the legal implications are going to be interesting.

One way of dealing with this is to change the business model, so that the customer is not paying to own a physical product, but paying for the provision of an ongoing service, with the potential for the terms of service to change over time. This is covered in the Commercial factors section below.

Designing servicesA good customer experience requires a coordinated design approach across devices and supporting service elements. This may span installation, product UIs, updates, sales and customer service interactions. Designing the parts in isolation may result in a disjointed experience.

Service design provides useful methods for planning and delivering coherent user experience across ecosystems of devices, services and other ‘moving parts’. It addresses the bigger picture of how the touchpoints should work together, as well as the detailed design and planning required for each one.

For example, a supplier of connected equipment to diabetics may have a core offering of glucose monitors and insulin pumps. These may be supported by dedicated displays, and/or phone and web apps. There will also be packaging, instructions, and maintenance to consider.

The core user is the diabetes patient themselves. The company might map their needs as a user journey from first noticing symptoms through to diagnosis, treatment, formulating a care plan, management and dealing with potential changes in condition. Type 1 and Type 2 patients will have different needs and journeys.


But the patient is not the only user, or stakeholder. Doctors, nurses, and insurance companies may all have an interest in what the devices do, how the patient uses them, and what data they produce. This picture can of course vary depending on healthcare provision in the patient’s country. The patient’s loved ones also have an interest and a role to play in the ongoing management of the condition. This may impact the design of the service (for example, allowing parents to monitor a child’s glucose levels remotely).

The wider ecosystem will include a variety of data, connectivity, customer support and medical services needed to support the devices’ functioning and monitoring, and potential interoperability with 3rd party systems (e.g. Apple HealthKit or Electronic medical record systems). These will require coordination from many different business units, and providers, to ensure reliable operation.

One important key interaction will be helping a new patient learn to understand the readings and manage their condition. Another key interaction will be alerting them to unusual readings that might indicate a dangerous situation or change in condition. The devices, apps and user instructions have a key role to play here. But so do medical staff and potentially other online information or remote support services. A potential deterioration in condition might need to be communicated (sensitively) to the user, trigger an alert to their doctor and set in motion a process for changing the treatment plan. This is not the sole remit of the device manufacturer, but the devices play a central role in supporting this. Products which support patients and medical staff in managing the disease effectively would have an edge over those which fit less naturally into the process.

Another example of an ecosystem is the Unmade customised clothing platform. Unmade worked to complement existing clothing manufacturing processes within factories, while introducing some small changes necessary to manufacture one-off garments.

Introducing new services through connected devices may also change existing work processes. For example, the Unmade customised clothing and manufacturing platform requires interfaces designed for several user groups. An online editor allows consumers to customise clothing, and may be placed on a 3rd party retailer’s website (as in the collaboration with Opening Ceremony, sold through Farfetch.com). Orders are sent through to factories via an order management system, where factory workers can sort them by material type to minimise changeovers on knitting machines. As many factories are paper-based, this system automatically generates the necessary paperwork. The pieces of each garment are knitted with a unique ID so that they can be tracked through the factory and sewn together correctly. Shipping and customs labels are generated automatically. Finally, the brands themselves need their own user interface for tracking sales data.

“What we didn’t anticipate at the beginning when we built the very first version of the order management system for factories was that actually the main “interface” for the factory is not the digital UI, it’s the piece of paper we generate that they print and that then travels through the factory. So the design focus was suddenly shifted from the UI on the screen to actually designing a piece of paper. Until the point it’s finished and shipped, nobody actually touches the digital UI.“ Martin Charlier, Unmade

The most important takeaway about service design is the mindset shift: from designing the components of the service, to designing for the relationships between them. A single component, like the Unmade production paperwork, or a setup guide, can play a role in facilitating the service, but needs to be made with an understanding of the wider process it supports.

In the design methods section below we provide some examples of methods and tools for designing services.


A good product (connected or otherwise) needs to be based on a fair value exchange between the customer/user and the provider. This requires a solid value proposition: the product solves a real problem for a particular audience of user. It also means that the value the customer provides to the supplier in return should be a fair exchange for the value the customer gets.

Because IoT systems blend products and services, a wide range of business models are possible – from both conventional device purchase through to subscription models, and many variations in between (e.g. device purchase plus freemium service). Many companies see service models as a valuable opportunity to develop direct, sustained relationships with customers. Services are not as easy to copy as hardware. And many also collect user data with the intention of someday monetising it via 3rd parties, e.g. by licensing aggregated data.

The choice of business model is important to the provider’s financial success. IoT products often have complex cost structures due to the upfront costs of developing and shipping hardware and the recurring costs of supporting an ongoing cloud service. Underestimating these costs is a major risk to the viability of a business. Ensuring the revenue model supports the cost model can be challenging but is necessary to keep the product up and running for the customer’s benefit as well as the provider’s.

“A Garmin will cost you about £300. We thought if we can make something under £100 that’s a very different proposition than the hardcore satnavs out there. At the moment it is just an upfront cost so you buy the device and then you’ve got it for life. We will look to build stuff into the software that can be premium services, extra add-ons and things you can buy through there, adventures and content in the same way that you buy a Lonely Planet guide.” Tom Putnam, Beeline, maker of a bike navigation device

Fig. 16: The Beeline bike navigation device https://www. beeline.co

Ding produced a working prototype very quickly using phone technology, but the ongoing costs were too expensive to make this solution viable as a commercial product. The hardware and software ecosystem was developed around the need to produce a product with minimal running costs:

“Originally, we had some technology working that was basically a SIM card. The system was incredibly simple, the hardware was predictable and had been on the market a long time. But in a business plan sense it didn’t work. We would be paying pounds per minute to whichever cellphone provider is in the country or region or in signal. So the technology made sense but the costs were too high.” John Nussey, Ding

The business model also underpins the user experience through shaping perceptions of value and fairness. The revenue model needs to fit with the user’s perception of the value of the product.

If your offering to customers is perceived to be a service enabled by a (lower profile) device, they will perceive the value to rest with the service. Recurring charges are likely to seem reasonable.

If the offering is perceived to be a device (which is enhanced by a service), an upfront payment is likely to seem more appropriate. They will expect to get access to any data from their devices for free.

Commercial factors: how business models and value propositions underpin UX


Sometimes, providers may need to work around customers’ entrenched ideas about paying for products. The best fit for a connected lighting company’s cost structure might be a subscription. But customers can feel uncomfortable when a product they think of as a one-off hardware purchase requires an ongoing monthly commitment. No-one wants to pay a subscription for the benefit of turning their lights on and off, or opening their front door. With services, users pay for the right to use, rather than the right to own. Customers aren’t always ready to give up the sense of ownership, nor the legal rights that come with it.

“Looking at a lot of the reviews of competitors, often people were really hot on complaining about things like the subscription and battery life.” Avril O’Neil, Ding

An ongoing subscription may be more attractive to customers if bundled with other services. A connected industrial machine might come with a maintenance contract. A door lock might be an enabler for a security monitoring service, or AirBnB management services.

A service/subscription model may also be fairer to the user if the functionality of the product may change over time. Even if you charge for hardware upfront, some element of a subscription model also gives you the flexibility to offer additional functionality over time and to charge for these, e.g. offering different tiers of use.

Finally, if customers are also providing value to the provider through their data, it’s important that they are able to understand and consent to the exchange (see privacy section).


Helping users grapple with complexityWe often equate UX with simplicity. Users, particularly mass-market consumers, often have low technical knowledge. So we seek to create very simple UIs which mask the complexity of the computer system underneath. This is often the right way to go. But it poses challenges when dealing with IoT systems. These, as set out earlier in this report, are often complex ecosystems of devices, services, data and application logic and business models. They can involve the user in relationships with multiple parties, as either service providers or recipients of their data.

Users may struggle with complexity. But hiding complexity denies them the possibility to understand how the system works, why it behaves in the way it does, who is benefiting from their usage of it and in what ways. If they do not understand it, they cannot have agency or control over it, and they cannot give meaningful consent to the value exchange (reword).

This affects a number of areas related to the product or service experience.

How it works, and how it can fail As discussed in the technical factors section above, the onus is on the user to choose the most appropriate product or service, which connects in the appropriate ways, for their needs. They also need to understand how to overcome or mitigate any potential issues (such as loss of connectivity).

Ownership, and the right to modifyThe functionality of connected products can be modified over time, which has the potential to change the nature of ‘owning’ a physical product. There are also questions of how the provider can or cannot limit what the customer can do with the product (for example, agricultural machinery manufacturer John Deere now restrict farmers from repairing their own equipment). To what extent do users understand or expect this, and do they consider it to be fair?

SecurityNo product is 100% secure, and IoT systems are exposed both to internet and information security threats (malicious hacking), and to physical compromise (e.g. sabotage). And the impact of an IoT system being compromised is not just to information, but extends to potentially deadly real world effects, such as losing control of a car, or a contaminated water supply.

Consumers in particular are poorly educated about potential threats and product developers are not always consistent in identifying vulnerabilities in systems. This is a UX issue in that increasing security often comes at the risk of adding friction to the user experience, for example requiring authentication.

The more complicated security measures are, the less likely they are to be used properly. Recent statistics show that fewer than 10% of Gmail users use two factor authentication. Sophisticated security measures used badly (because they are too confusing) are often less secure in practice than less sophisticated, more usable measures used properly. It is better not to rely on users to know what to do. Try to limit the damage that can be done and t provide security by default: not exposing devices on the network that don’t need to be exposed, ensuring that devices can do as little harm as possible when compromised, designing automatic updates into the system.

Data privacy Data privacy is concerned with collecting information about other people, processing it, and making it available, in appropriate ways. What is appropriate is highly contextual. One person’s notion of a privacy violation is another person’s opportunity to get a cheaper service. You might not like the idea of an ad-supported fridge that tracked everything you put in it. But another person may be short enough on cash and desperate enough for a new fridge to consider that an acceptable trade-off. There is no legal breach of privacy if informed consent has been given to use the information in the way that it is being used.

Giving users transparency and control


Designing a good user experience around privacy involves:

Careful consideration of what is captured and shared

Providing clear and transparent communication with users about what is captured, and for what purpose, and with whom it may be shared

Providing options to opt in/out, even if these may mean that the user cannot benefit from certain service features

This sounds straightforward, but is fiendishly complicated to implement effectively. In IoT, there is a wealth of new data which can be captured. And the complexity of anticipating, communicating and gaining consent to all possible uses is prohibitive. Fully informing users of every potential use of data is not realistic, especially when data which may have been captured for innocuous purposes can be combined with other data to reveal much more than anticipated. For example, security analysts recently identified that exercise app Strava’s global heat map of exercise routes inadvertently reveals the location of US military bases3.

Even if it were possible to anticipate every possible consequence of sharing data, it would be overwhelming to present this to users.

Minimising the amount of data which is captured and shared is advisable. Keeping data on local devices instead of storing in the cloud (as e.g. NetAtmo security cameras do), is the safest model. But there is often a commercial incentive for providers to capture as much data as possible in the hope that it can be monetised.

Current regulations mandate that providers obtain informed consent from the user for use of their data. But this is often buried in long EULAs full of legal language, which no-one reads.

Incoming European regulations (GDPR), enforceable from May 2018, increase protection for data subjects, or end users. GDPR is based around the concept of privacy by design: building data protection into the design of the system from the offset, instead of adding it on. Companies need a valid reason to collect a piece of data, and must provide transparency about what can be done with it. Users have the right to ask what the company knows about them, and to force the company to correct wrong information or delete the user’s data on request. Companies are also prohibited from profiling users on the basis of data.

GDPR also increases the geographical scope of the law to any company providing services to EU customers, and imposes more severe penalties for non-compliance.

GDPR is so far reaching that some provisions may extend beyond the current technical means to implement them.

“The ability to retract your permission to use data sounds good, but once that data is sold to a third party or combined to create new insights, how can that data be controlled? How can the new knowledge go away? ”Stacy Higginbotham, Stacey on IoT4

A key factor for UX is that GDPR also puts the onus on the provider not just to obtain informed consent, but to prove that the user’s consent was informed. Long EULAs, which no-one reads and very few understand anyway, will no longer suffice.

“…companies will no longer be able to use long illegible terms and conditions full of legalese, as the request for consent must be given in an intelligible and easily accessible form, with the purpose for data processing attached to that consent. Consent must be clear and distinguishable from other matters and provided in an intelligible and easily accessible form, using clear and plain language. It must be as easy to withdraw consent as it is to give it.”https://www.eugdpr.org

“GDPR says you can’t just have a huge swathe of terms and conditions and get somebody to tick the box because that’s not meaningful consent. You have to demonstrate that they understand and the only way you’re going to do that is actually to rethink what terms and conditions look like, how they’re presented, whether they come through as part of the service, how they evolve, how you can change them… I think those are huge design challenges that are just not there with a bunch of this stuff at the moment. …. I think the whole thing of just tick and you can do what you like with my data is rapidly disappearing.“ Professor Paul Coulton, Chair of Speculative and Game Design, Lancaster University

There are no simple answers to this yet, but the industry needs to find new ways of communicating what is happening with data and obtaining consent. It may not be possible to anticipate all the potential consequences of a piece of data being shared. But companies need to provide better transparency so that users can be more in control of their data. This will require radically different approaches to communication. Describing the use of data in more humane language is a start. Providers might also give users a visual overview of the ecosystem in which the product sits (see constellation model below). Or they might find ways for end users to see what data is being shared as it is being shared. The Polly design fiction project from the University of Lancaster mocks up the example of a connected kettle which provides a more user-friendly licence agreement coupled with an event log of data, showing with whom it has been shared.

3Fitness app Strava lights up staff at military bases, http://www.bbc.co.uk/news/technology-428530724https://staceyoniot.com/how-to-protect-privacy-in-a-world-awash-in-data/


Fig 17: Image from “On the Internet Everybody Knows You’re a Whatchamacallit” by Joseph Lindley, http://eprints.lancs.ac.uk/84761/4/Polly_Design_Fiction_Booklet.pdf

Another approach may be for the industry to develop common tools which allow users to make decisions about data sharing across multiple products. The [smart lock] project, also from Lancaster University, postulates an app which allows users to trade off greater privacy against increased functionality by dragging a slider. Moving the slider up or down enables different levels of data sharing but also different levels of device functionality.

Fig. 18: Imagined smart lock app trading off privacy for functionality, from Anticipating GDPR in Smart Homes Through Fictional Conversational Objects. / Lindley, Joseph Galen; Coulton, Paul; Akmal, Haider; Knowles, Brandin Hanson. 2017.

These are design provocations rather than commercial designs, but they indicate some of the directions that commercial providers could consider.

Automation and algorithmsIoT is often seen to bring with it the promise of automation and intelligence: using information sensed from the environment, learning about our needs, and figuring out how to respond and adapt. The idea of ‘no UI’ – being able to walk into a room and have the environment magically adapted to your needs with no explicit interaction – is appealing. However, it requires serious effort in terms of modelling of user needs and appropriate responses. If it is not 100% right almost all the time (which is very likely), it will be at best frustrating. In some situations (such as flipping a light switch when there is a gas leak) it could be actively dangerous.

And it’s not too much of a stretch to imagine that algorithms like those which are used to determine who gets access to credit, or who gets parole, might also be used to decide who is permitted or not permitted to access certain real world locations, or drive cars, or deemed a security risk in a public place.

In Japan, there have for a long time been vending machines that vary the drinks offered depending on the age and sex of the person standing in front of them. Men who like sweet tea, or young women who like coffee or beer, may never know those options are even available5. This is a relatively benign example, but it shows how the stereotypical assumptions others make about us can shape the options we are given.

Algorithms that decide who we are, what we can do and what to show us are, like us, products of our society and tend to reflect its biases. This is not uniquely an IoT problem, but IoT allows the reach of sinister unseen algorithmic prejudices to shape our interactions and deny or grant opportunities in the real world, as well as in software.

Even simple, non ‘smart’ automation such as configuring rules for connected lighting application, can go awry. When there are clashes between rules – the energy saving program is trying to turn light off while the security program is trying to turn it on – there can be bizarre consequences – e.g. the light flashing on and off.

In all these situations, the user needs a way to demand an explanation as to why the system is behaving as it does. What are the unseen rules governing its behaviour? How can you debug your home automation system to stop it behaving oddly? This isn’t feasible with no UI – there has to be a UI somewhere where you can see this.

How do you get behind the scenes to understand why the system is doing what it is doing, and what inferences it has made about you, your needs, and how to respond?

5Ninja promote ‘cool’ vending machines, https://www.japantimes.co.jp/news/2015/02/19/national/ninja-promote-cool-vending-machines/


When the smart signage of your workplace directs you to the wrong place because it assumes you are a cleaner, not an executive, or the security system locks you out, how do you know what happened? This can be especially challenging when machine learning algorithms are involved, which may have arrived at conclusions with no human-readable logic to explain why.

Communicating complexityWe need to help users become better informed about how IoT products work. This means thinking of them not just in terms of the parts that they can see, but the parts they can’t. How does this product work? What data does it share? What is its relationship to other products and service? How do the unseen forces of business models and algorithms shape its value and function?

“There’s a more than human thing going on with this, that algorithms have an influence, business models have an influence, there are other non-human actors in the network that have a profound effect and it’s how you also reveal that.” Professor Paul Coulton, Lancaster University

This is complex. Perhaps in designing user experiences for connected products, the notion that we can ever make everything ‘simple’ is disingenuous. We are doing users a disservice and disempowering them if we oversimplify complex products to the extent that they cannot be understood. Perhaps our primary aim, instead of trying to make the experience as simple as possible, should be to empower users so that they have agency and control over the connected products around them. This is not an excuse for poor design or unnecessary complexity. It is not an argument in favour of products with thousands of configuration options to suit every user whim, which are overwhelmingly complex and unusable to anyone. Products still need to be focused on solving a core set of user needs well. What it does mean though, is that instead of passing off connected products as ‘app-enabled devices’ (Apple’s term) we should try to make the ecosystems around products more transparent and fair to users.

Joseph Lindley, Paul Coulton and Rachel Cooper6 propose an approach which treats IoT products as star-like constellations of devices, providers, 3rd parties, algorithms, data sources and standards.

This is known as ‘more-than-human centred design’. The intention is not to downplay the importance of serving the end user’s needs, but to acknowledge that the system may look very different viewed from the perspective of the provider, or a 3rd party, than it does to the user.

The example above shows a sample constellation for a connected heating controller, such as the Nest (an Alphabet/Google company). From the user’s perspective, the controller, and the devices in the home which interoperate with it, are the product. Their value is in controlling heating and lighting. From Google’s perspective, their value is as data gathering devices: a view to what is happening in the offline world of the home, which extends Google’s in-depth knowledge of what most of us do online (and thus their ability to target services and sell advertising).

“The Internet of Things isn’t just the physical things that you see. It’s things like business models, regulation, algorithms. They’re all things within the network, it’s just that their effects are almost hidden, they are things in the background that exert this huge influence. But there’s a concentration on these physical things that you can see, which often are the least problematic aspects of what you’re trying to do. So, we’ve been using this idea that you sit within this constellation, and the constellation is different depending on where you’re looking from. If you’re Google looking at your Nest thermostat, Nest thermostats are a great way of gathering data. For the user you’re interested in turning your heating up and down. It’s the same constellation but it looks completely different depending on your perspective.” Professor Paul Coulton, Lancaster University

The early example above may not be a mass-market consumer-friendly tool for clarifying the system around a connected product, just yet. But it points to the need for providers to help users better understand what they are buying into, and to be able to make informed decisions about how to use it, and how much permission to grant it. Something like this may form the basis of one approach to communicating data use better, under GDPR regulation.

6Why the internet of things needs object orientated ontology; J Lindley, P Coulton, R Cooper - The Design Journal, 2017 (http://eprints.lancs.ac.uk/85080/1/OOO_Full_paper.pdf)

Fig.19: The constellation around a connected heating controller. Image from https://www.petrashub.org/ukjapan-workshop-on-iot/.


IoT products combine software and hardware, which have very different approaches to design. A key factor in the difference between the two approaches is the ease with which the design can be iterated.

In software development, the product can be iterated even after release, so the UX design is never ‘finished’. Physical products cannot be changed in the same way. So physical product design projects have a ‘design freeze’ point, when the product design is handed over for manufacturing. After this point, design changes would mean postponing or re-planning manufacturing, incurring of substantial delays and additional cost. Physical product design teams therefore tend to do more upfront user research and exploring multiple design directions, to get the product design right before manufacturing. Software design teams, especially in the modern lean startup model, often aim to release an MVP and then iterate and improve it. Testing alternatives in the wild through A/B or multivariate testing is increasingly common. But this does not lend itself well to hardware products. And constant iteration of design and functionality may not play well with users in certain settings. Changing the way their thermostat or door lock works may be a disconcerting experience.

Designing an IoT product means bridging the two approaches to consider the whole experience, as well as the customer experience beyond the app and device.

There are two key goals. The first is ‘designing the right thing’ - ensuring the value proposition, business model and requirements are on target. The second is ‘designing the thing right’ - making it appropriately easy to use and appealing. Hardware, software and broader service design methods are different. But they share a common goal: maximising learning about the right thing to make, and the right way to make it, while minimising effort spent making the wrong thing.

Making the right thingThe difficulty of iterating hardware products means that it’s important to test the value proposition, and uncover core user requirements, early on. This can be done in parallel with hardware development. While design and product are exploring whether anyone needs it, and what requirements it needs to fulfil, at the same time electronics and design engineers can be exploring whether it is feasible to build. But that means finding ways to prototype and simulate the product experience that don’t rely on functioning hardware.

Exploratory user research

The first step in understanding the need for the product is user research. If time ad budget is tight, this need not be formal. Good quality research will give you much more reliable results, but informal ‘guerrilla’ research is better than none at all. If you are your users, your own insights can be useful, but be careful of making assumptions about the needs of others. Bike navigation startup Beeline’s founders were cyclists themselves, so had first hand insights into needs around cycle navigation. Stannah and their designers conducted research with older people, occupational therapists, and carers to understand first-hand the needs of older/vulnerable people and their care networks.

“When we had those conversations it became apparent that to the stairlift users the stairlift was a way moving between floors. But to the people around them it’s reassurance that they are safe. That was the core insight that the project came from and then the key challenge in terms of design was creating something that’s reassuring and not creepy, and playful and not unpleasant, and something that doesn’t make the person feel surveilled but does provide the people around them with the reassurance that they want.” Ross Atkin, Ross Atkin Associates

Design methods and prototyping


Fig. 20: Materials shown to Stannah interviewees to explore which information would be acceptable for others to know (Ross Atkin Associates, Stannah)

“We spoke to some occupational therapists around what they thought the key areas of monitoring might be. Are they eating and drinking, are they moving about the house were the two key bits of information that they felt would give them enough reassurance. And that’s how we got to the system we have today where we monitor three appliances, an entertainment, a beverage, a food appliance and the stairlift.” Tom Smith, Stannah

Approaches suited to early stages can include observation, interviews, competitor evaluation, surveys and focus groups. Try to visit potential users in the place they would use your product, and do at least some observation of them doing the tasks that your product will support. What people actually do, and what they say they do or remember to tell you (for example in interviews

and focus groups) are not always the same thing and the context in which your product will be used may throw up interesting challenges.

“We did a lot of testing of compass navigation and found that generally it was great. But if you are trying to go from northeast London to southeast London and there were no bridges at that point, you can get very stuck. So that’s where the need for waypoints came in.” Tom Putnam, Beeline

In the early stages, qualitative methods such as observation and interviews will give you more useful insights for design. Surveys may capture feature requests but not necessarily why people want them – information which can help you figure out whether the feature is really what users want, or whether they indicate an underlying need for something else. Quantitative methods are helpful later on when you need to prioritise features based on how many people may want them, or demonstrate to investors that there is solid demand for a product.


“In order to work out how the care networks around people were working I did these maps with each of the people: who were they seeing in a month and what means of communication were they using? I asked everyone who would you call if you had a problem, if you had some good news and if you needed cheering up. We were able to segment the market into four different kinds of network, and for each of those four different kinds of network a slightly different service design made sense.” Ross Atkin, Ross Atkin Associates

Fig. 21: care network diagrams produced by Stannah interviewees (Ross Atkin Associates, Stannah)

If there is an existing product or equivalent which people currently use to get the job done, you can interview potential users about that and observe how they use it.

“We ran interviews with potential customers as well who were looking into purchasing a product. So what they think they might find useful from a doorbell, the problems they have with their current doorbell.” Avril O’Neil, Ding

Prototyping for proposition testingIf your product is in an entirely new category, it can be hard to get good insights about what people would want from it. You need some way of showing people what the product could do for them, in order to have a meaningful discussion about whether they would use it and what they would want from it. To be efficient, you want to spend the minimum time mocking up the product concept, in order to learn what you need to learn, and not waste time building the wrong thing.

It may be relatively simple to mock up a quick prototype that does a good enough job, even if it doesn’t work quite like the eventual product. For example, before making any hardware, Beeline mocked up an app which simulated the device experience:

“I got somebody to make an app where you could do a Google Map search and then it had a simple ring on the

screen, with a big number and an arrow. One of us would without showing the other one just type in a destination into a phone, strap it onto the handlebars, and the other person would have to go there and send a picture. We recorded it on Strava and could see what the routes were like. And both of us kept coming back with big grins on our faces because it was kind of a game of trying to follow the arrow and trying to pick a route. Then the next step before making any hardware we tested that with lots of friends. We’d sign up friends to do 2 hours of testing and get them to test anything from Google Maps in your ear to Google Maps on the screen, a Garmin and this form of navigation.” Tom Putnam, Beeline

The initial prototype of the system that became Stannah Connect was a simple sensor on an Arduino, placed on a stairlift, hooked up to Twitter to tweet when the stairlift was used. This was enough to explore the idea of sharing activity information with loved ones.

When that isn’t feasible, experience prototyping techniques are useful. These help both users and the internal team imagine what the product could be and how it should work, to refine the proposition and concept without the need to invest time in a ‘working’ prototype.

The simplest method is to write an imaginary press release for the product. This can be enough to gauge initial customer interest in the product.

For a very new product concept, a press release might not be enough to help users imagine themselves using the product. A next step might be to produce storyboards: like short comic strips that show how the product might be used for key use cases. Storyboards allow you to demonstrate the whole picture of product interaction - with physical devices, apps, customer services and more. These are usually a better way to communicate the proposition than diving into concept app screens to start with. Storyboards can help communicate the proposition and concept to both potential customers and internal stakeholders. Even if you can’t sketch well yourself, it will often be cheaper and easier to get a designer who can to spend a day or two helping you do this than to build a basic prototype.

“We did these really nice kind of comics to illustrate that there’s different kinds of service design that could go with it, and they again helped to have conversations later on both with people that might be using it and people within the company and OTs. The next phase after that was actually building the prototype and testing that and that was nice because we found that people were using it in the way that we had hoped. These were extremely valuable in terms of allowing people that weren’t interested in technology to get their heads around what we were thinking about doing and whether they thought it was useful or appropriate…” Ross Atkin, Ross Atkin Associates


Fig. 22: Stannah Connect comic strip (Ross Atkin Associates, Stannah)

A more advanced experience prototype might go even further to simulate the experience of using the product. Video mockups can be compelling ways to explore the proposition. Beeline released a video of an imagined product on YouTube to test the proposition. This was high-fidelity enough to double up as part of their pitch to win funding. However, versions for design exploration or user testing do not have to have the polish of an investor pitch. The key is just enough fidelity to learn what you need to learn. A simulation made with cardboard mockups on a smartphone might be enough to get the feedback you need.

Making the thing rightIterative software and hardware prototyping and testing

The key to good UX in product development is ongoing iterative prototyping and testing. The main goal of early prototyping and user testing is to test the proposition. Over time, your confidence in the proposition increases, and the emphasis switches to understanding key requirements, and then to testing design solutions.

It’s often easiest to do this by considering user research as an ongoing activity throughout the project, speaking to users and testing whatever prototypes you have as a continuous process.

Chiaro Technology have a full time dedicated user researcher, who builds up a network of women, visits them in their own homes and gets to know them and their experiences before introducing product concepts.

“I think we’re forced into that situation with the type of products we’ve developed. Convincing people to test something so intimate is challenging, so you need to invest time just to find people, and you need to keep on building your user base of testers. That whole cooperation with the users, finding user testers, recruiting them and interacting with them is constant and we keep on using them just to ask questions.” Ben Levy, Chiaro Technology

In terms of prototyping, industrial and software UX approaches conventionally operate separately. But with IoT, the two should run hand-in hand as much as possible to ensure a holistic approach to design. (If you’re making a service enabled by sensors the user will never see, industrial design may not be an issue and you may be focused primarily on software UX. But you still need to consider software UIs as part of a system, not in isolation, to allow for the delays and discontinuities inherent in IoT systems.)

Fig. 23: A still from Beeline’s early prototype video. The product was simulated using video compositing. Awaiting permission. Taken from https://www.youtube.com/watch?v=pNguieZ4cTc.

All of these can serve as a springboard for conversations with potential customers around whether and how they might use the product, what it might need to do for them, and how they would feel about various ways to pay for it.


The process of prototyping hardware typically moves through moodboards and CMF (colour, material, form explorations) to sketches, developing a design language, low-fi model making (e.g. in polystyrene) to CAD modelling, 3D printing and finally design for manufacturing.

The process of software prototyping typically moves through exploration of user scenarios, to flows, to a rough UX architecture (how functionality is organised in the app) and screen designs of increasing fidelity. These may start from sketches and proceed through wireframes to more visually advanced UI designs. Designers often make clickable prototypes in tools such as InVision or Adobe XD and sometimes build functional prototypes with developers. This latter is particularly helpful when user testing with real data is required, for example, showing a participant in a smart meter test real energy data from a real home (whether or not it is their own home).

Neither process is well suited to designing the whole experience of both hardware and software. Conventional industrial design prototyping focuses on the device alone. And conventional digital prototyping software focuses on interactions with a single app UI. Conventional prototyping techniques cover only screen interactions, not voice or other modalities. But for the connected product, each of these is designing only half the conversation.

IoT designers often need to consider how users will interact with apps and devices at the same time. Interdependencies between device UIs and software UIs mean that the old approach of making a device, and then developing the UI later, often won’t lead to a good result.

A common pattern amongst companies developing connected products is to produce an early device prototype for feasibility, then to discover that the device UI design cannot proceed much further without a concept of what will happen in the software. Once this is in place, the device UI can be developed, and the software UX iterated.

“We did a bit of the app experience, then we designed the product, they we did a first stab at the electronics, redesigned the product with the electronics, and then worked on the app again. So it was in stages but then there was a point when the things started coming together.“ John Nussey, Ding

Good communication between the different design disciplines is vital to identify and manage these interdependencies. Small changes to design techniques can make a big difference.

UX designers can map out user flows as swimlane diagrams spanning multiple UIs or touchpoints.

Fig. 24: An example dual flow for a smartphone app and Bluetooth device

Sketching storyboards (in more detail than those used for the proposition testing), instead of screens alone, is a great way to map out interactions with the whole system and consider the context of use.


Fig. 25: Ding storyboard (excerpt)

Low-fi videos for customer testing interactions across devices and apps can be mocked up very easily. Unmade product manager Martin Charlier has written and presented extensively about techniques using cardboard mockups and Instagram video (https://speakerdeck.com/marcharlier/video-as-a-prototyping-tool-for-connected-products).

Position it in your home.

Bring Ding home. Input details and phone number online.

Take out the box...

Ding arrives in the post

Ding arrives in the post

Go to the shops the choose Ding amoungst door bells.

Browse doorbells online, choose & buy Ding. Input details and phone number on pruchase.

Your a vodafone customer, they call you to offer a Ding doorbell as a part of your subscription.

...or your a new to vodafone, whilst ordering your new contract Vodafone offers you a bundle whcih includes a Ding doorbell.

£2 per moth subscription

£80 - £120

OR

Sounder rings in your home. Someone comes to the door... As well as ringing your phone Aswer the phone

At home but don’t know who it is...

Out of reach in the garden...

Away at work...

The stairlift is slow & can’t make the door in time...

“Who is it?......I’ll be right there.”

“Just coming!”

I can’t come to the door, leave it next door”

“Give me a min, I’ll come down”

Fig. 26: Filming a simple prototype for a plant sensor using Instagram video (Martin Charlier). See videos at https://instagram.com/explore/tags/solidprototyping/

It is natural part of the design process to explore and test alternative designs. Allow time to explore different alternatives, to test them, learn from mistakes and improve, and be prepared to throw the ones that don’t work away.

Low fidelity materials such as sketches and wireframes can help evaluate the proposition, and ensure that the product meets key requirements, and that the basic interaction logic (user flows, and the way functionality is organised) makes sense. Low fi testing is easier with software and interactions than industrial design. Moderators need to work harder to help users imagine what it would be like to use the product and get the best feedback. But testing at this stage helps flush out major mistakes early.


Fig. 27: excerpt from a document of low fidelity sketched wireframes (Ding)

With industrial design, to get meaningful feedback the product needs to look somewhat like a finished product. This could be as simple as making a 3D printed model.

A medium fidelity software prototype would have some visual elements but not the polish of a real UI design. It is usually quite easy for users to imagine using a medium fidelity prototype as if it were the real thing.

High fidelity prototypes look, if not behave, like the real thing. They take more time to develop and can lead users to think that the product is more finished than it is.

2 workouts completed

LV scoreSTRENGTH

TargetINCREASED

Start your workout

60.9 45%

Elvie is ready Elvie is ready

Start your workout

2 workouts completed

8687 86

85

8887

06

/12

05/1

2

04

/12

03

/12

02

/12

01/

12

07/

12

86

45%Target

Start your workout

Elvie is ready

Intermediate 2/10 workouts

Lift 86 LVs

Pulse8/10

Hold18 secs

Speed12 in 10 secs

01/12 03/12 04/12 08/12 11/12 12/12 14/12 23/12 29/12 01/01

8786

84

88 8887

86

89

8788

LiftAverage: 86LVs Personal Best: 98LVs

Making progress

Doing g

reat

!

Aw

esom

e results!

Strength

34LVs

Speed

Step

Lift

Pulse

Hold

Last ten workouts

Start your workout

LVs

05 Mar

21

TodayFebJan

Average

Best

Trend Average

34LVs

Best

39LVs

Strength

1. Just one metric, no hierarchy 2. Still one metric, hierarchy and progression 3. Multiple metrics, hierarchy and progression 4. Multiple metrics for current state, splitting progression into a separate screen, showing trend and overall metrics

Fig 28: Screens excerpted from high fidelity prototypes of Chiaro’s Elvie trainer app. The screens show progressive iterations (from left to right) of the design of pelvic floor workout data, in response to multiple rounds of user testing. Users wanted to know how they were progressing, but did not like very data-heavy presentations. The final design (two screens on the right) was well received.


“There’s always value in testing at all phases, from literally pencil drawings, wireframes, all the way through to prototype. … For hardware you’re kind of stuck in some ways in that you’ve got to get higher resolution a bit quicker to prove things, but it’s got to look a bit more like you think it might look, but it doesn’t have to do anything, whereas with software it can maybe not look so close to what you think it might look but it’s got to do something. There’s a difference in how you have to approach it I think. With the software it is often a bit easier to test.“ Ben Levy, Chiaro Technology

Doing an internal pilot before testing with potential users is helpful to flush out errors in the prototype, or very obvious usability issues.

Early testing in the lab or office is useful in early stages. But as the product evolves testing in context is needed to expose issues that may occur during real use.

“We did a pre-production run of the hardware and a beta test with a version of the app using Testflight. It became clear that you can use it when you’re walking around and it tested brilliantly but when you put it on a bike the magnetic field of the steel frame caused the needle to point in slightly the wrong direction. So there was a whole additional workflow needed in the app. You have to lift your bike up and move it around, to calibrate it to your bike.” Jon Marshall, Map Project Office, re Beeline

Starting with small numbers and qualitative testing is the best way to learn how to improve the design. Quantitative measures are useful when monitoring a live service, or to assess how many people may be interested in a specific feature. To get the best data while using as little of users’ time as possible, Chiaro develop a research app which is

tailored to the questions they want to explore at that point. This controls the product, collects usage information and user feedback all in one.

“We tailor the app to the research phase. For example with the new product, the app that’s for research just lets people control the hardware and it lets them answer questions about the session that they just did so that we can get feedback directly with data from the device. So the hardware data is combined with their qualitative feedback like how they feel about it, what they were doing during the session. I think that’s important for us, that when we are going to take up people’s time and they’re going to follow a protocol that we make sure we can get everything that we want, or as much as we can get, using as little of their time and as easily as possible for them.” Ben Levy, Chiaro Technology

A key pitfall to avoid is taking feature requests too literally during testing. Test users will always ask for features which address their specific needs. But taking all of these at face value will result in a confused product with too many features. Look at the underlying reasons why users are asking for those features, and whether they are likely to be of benefit to others. Note feature requests but consider them in context of your wider proposition.

“One of the main pitfalls of connected products is overspeccing everything and losing your North Star. In the Beeline beta testing people said “It would be great if it could do turn by turn navigation as well” or “Can I see notifications from my phone on it?” But what Beeline did is stayed really true to their goal.” Jon Marshall, Map Project Office


Service design

Prototyping techniques for connected products also need to consider the broader service experience. Service design, with its focus on orchestrating interactions around an ecosystem of parts, offers some of the best techniques for IoT concept design, even when you are exclusively considering digital interfaces. Some of the techniques described above for interaction design, such as swimlane mapping, are derived from service design.

Beyond product hard¬ware and software, service design experiences for prototyping and evaluation might include:

Unboxing and/or setup experience (including instructional materials)

Customer support mechanisms during use

Support for environmentally responsible disposal and recycling

Service design requires you to switch between thinking from the bottom up and from the top down—that is, to move between considering the ser¬vice as a whole and addressing individual interfaces or components.

A core element of service design involves mapping the ecosystem of devices, UIs, and other touchpoints which the user will directly interact with (frontstage), and the supporting people, infrastructure and other enablers required to support the service (backstage). This is a holistic picture of the system and surrounding service, which helps map the scope of the service, figure out which parts may be needed and how data flows around, and ensure that the various enablers can all be put in place to deliver a good experience.

Fig. 29: Tapp is a medication tracking product from Cambridge Consultants, which won an iF Product Design Award in 2018. In conjunction with smartphone app, a low-cost sticker with integrated flexible electronics and passive NFC attaches itself to a drug blister pack, helping promote medication adherence through behavioural change by periodically ‘nudging’ the user. (https://www.cambridgeconsultants.com/press-releases/design-awards-roll)

Fig. 30: Before designing the Tapp hardware and app, the team considered the holistic view of data movement around the system between different stakeholders and technology, in response to different triggers and situations in order to understand the necessary service interactions required. (Cambridge Consultants/Tim Daines)

Another core element is creating a service blueprint. This considers customers’ needs and key interactions with and around the product from first hearing about it, through purchase, setup, in-life use, updates/upgrades, through to end of life. The starting point is a user journey based on user research insights, usually created by mapping user needs at each stage on a wall with post-its, looking for potential pain points and opportunities.


Fig. 31: The Tapp team mapped the user journey of a patient being prescribed antibiotics (Cambridge Consultants/Tim Daines)

The following step is the blueprint, which shows how the user experience in support of that journey needs to take shape. This maps different touchpoints and interfaces, such as apps, device UIs, customer support, service engineers and more, as swimlanes on the diagram, with the key interactions at each point mapped to each. It may also include operational elements needed to ensure that experience is delivered successfully.


Fig. 32: Excerpt from the service blueprint for Tapp (Cambridge Consultants/Tim Daines).

The service blueprint diagram can then act as the basis for specifying key design requirements for individual touchpoints, for example, ensuring that it is easy to access the devices serial number while on a support call, or designing how emergency alarm notifications might be cascaded to different user types via app and SMS.

The methods shown here are a means to an end, not the end point of design in themselves. The delivery of a service design is in the service itself. In a small team without a dedicated service designer, you may not have time to maintain beautiful diagrams. But knowing how to represent and map out service level thinking can be useful for communication. The key is to enable the team to grapple with the high level view of the service experience in parallel with focusing in on the detail of each interface and other touchpoint.


The design methods above are suggestions for possible approaches. Design methods for IoT are still emerging, and there’s no single correct approach that fits all teams and projects.

However, there are a few key practices which successful teams follow:

Making the right thingFrom defining a strong proposition through to ensuring the design makes sense, understanding user needs is essential. Good teams do this by learning from users throughout the project. A little research, done often, is usually better than one or two big studies.

Prototype and test earlyDon’t waste more time than you need to making things that might turn out to be wrong. Use whatever methods are most efficient to simulate what it would be like to use your product just well enough to learn whether you’re on the right track or not. Then test it. In the early stages, that need not mean having either functioning hardware or software.

Design for the system, and the serviceUsers will experience your product as a system. Approach the design in the same way. Consider how individual devices and UIs will be used together to design how the whole experience works. Step back and consider the service experience surrounding your product: have you thought of everything users will need? What operations need to be put in place to deliver the best experience?

Foster good team collaborationUX is not just something to be done by designers. Designers, developers and business people all make decisions which shape the experience of a product.

Building whole team communication into the project process is critical. IoT teams are more multi-disciplinary than pure software or hardware teams, and team members are often still learning about some of the other roles they are working with. Teams need a shared understanding of what each member is doing, to identify where collaboration is needed.

For example, UX designers and firmware engineers won’t naturally know that they may need to collaborate around the metadata used to describe a smartplug, because this affects both the software UI, and the firmware of the plug. So regular knowledge sharing and facilitating mutual understanding is essential to ensure the team work effectively.

“We meet at least weekly for a review. We keep each other up to date with what we’re doing. And people get a chance to say whether they want someone else’s help or input. The product manager is there to hear all of that and make sure that we talk to each other when we should. It happens often that we’ll bring the hardware engineering team to look at the digital design because what we’re doing is trying to reflect maybe what they’re doing.” Ben Levy, Chiaro

Summary: planning UX for an IoT project

In summaryWe are just beginning to explore the potential in IoT. And we are just beginning to explore how the methods we have evolved for designing physical devices, and software services, will (and won’t) scale to designing products which combine both of those things, in complex networked systems, with the potential for real world consequences if we get something wrong. In IoT, everyone is learning. But if we listen to users as much as possible, try to make things which improve their lives, and consider the context in which designs are experienced, we will be off to a very good start.


Digital Catapult, 101 Euston Road, London,

NW1 2RA

IoTUK.org.uk • [email protected]

Produced by

ux and service design for connected products€¦ · get in touch: iotuk.org.uk [email protected]...

Documents