UX AND SERVICE DESIGN FOR CONNECTED PRODUCTS

Claire Rowland

JUNE Produced by 2018 Table of contents

Summary...... 1 Commercial factors: how business models and value propositions underpin UX...... 17 UX, service design, and IoT...... 3 Giving users transparency and control...... 19 What is UX and service design?...... 3 Helping users grapple with complexity...... 19 UX and service design for IoT...... 4 How it works, and how it can fail...... 19 Technical factors: how decisions about architecture, Ownership, and the right to modify...... 19 connectivity and power constraints shape user Security...... 19 value and UX...... 5 Data privacy...... 19 How does it work? How could it fail? Architecture and reliability...... 5 Automation and algorithms...... 21 Battery life, connectivity patterns...... 7 Communicating complexity...... 22 Latency and responsiveness...... 7 Design methods and prototyping...... 23 API design and fit for UX...... 8 Making the right thing...... 23 How does it interoperate with 3rd party devices?...... 8 Making the thing right...... 26 Distributed UX/interusability...... 9 Summary: planning UX for an IoT project...... 34 Composition...... 9 Ongoing user research...... 34 Consistency...... 10 Prototype and test early...... 34 Continuity...... 11 Design for the system, and the service...... 34 From products to services...... 14 Foster good team collaboration...... 34 Is it a product or a service?...... 14 In summary...... 34 Why think about services...... 15 The changing nature of ownership...... 15 Designing services...... 15

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

There are a huge variety of applications in IoT spanning In this Insight Report, we’ll look at the factors which connected products and hardware enabled services. make UX for IoT particularly challenging. We’ll discuss Consumer products such as home lighting and heating how technical architecture and business models shape controllers are growing in popularity. Across many UX, and how IoT blurs the line between product and industry verticals, sensing, tracking and actuation are service experiences. We’ll look at the need to give users enabling smarter use of resources, just in time processes transparency around how complex systems work and and predictive maintenance. share data, in particular in relation to GDPR. And we’ll set out the challenges of designing distributed user All of these have users, who want products and services experiences across multiple UIs, and show how some which are useful, usable and satisfying to use. Mass- companies are tackling the challenges of designing for market consumers may have quite different needs both hardware and software in parallel. from industry specialists. But there are many common challenges in designing the user experience of products NB: we interpret IoT loosely to refer to connected products which span both hardware and software. and services enabled by connected hardware in general, whether or not they communicate using open internet protocols or have a direct internet connection.

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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products What is UX and service design?

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 Fig 1. The Elvie pelvic floor trainer from Chiaro Technology remit of UX designers. They illustrate that UX involves https://www.chiaro.co.uk collaboration between the entire product team. Even if there is no-one on the team with ‘UX’ in their job title, the The discipline of service design is closely related to UX. It product or service provides an experience to users. This looks at the whole lifecycle of a user’s experience with a needs careful planning and development. service, and how all the different components of the UX function together to deliver the service. It also identifies “We’re passionate about making products for women the people, infrastructure, communications and other that really improve their lives, so anything that we do is enablers required to support the service. going to be reflected in how we’ve thought about the user experience. And that doesn’t just mean the physical Designing a service is a team effort. Service design product or the software, it also means the packaging, it provides methods and tools intended to align teams means the manual, it means all the touch points, it means around crafting the best possible customer experience, wherever you’re going to see it in a store that we’ve from purchase through to end of life. 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.

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

Experience design for IoT products is more complicated UX for connected products is not just about UIs, but the than it is for software or conventional physical products. whole experience of the product. It requires a different There may be more customer UIs or ‘touchpoints’: mindset and approach from conventional software UX. perhaps multiple devices, mobile or web or voice UX needs to take into account the way in which the user applications, customer support, and interoperating experiences the whole system, as well as the detail of products. Physical devices exist in a real world setting, each UI. 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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 4 Technical factors: how decisions about architecture, connectivity and power constraints shape user value and UX

In a distributed system, there are many places in which is what the impact of temporary outages may be. For design decisions can be baked into code, from front-end example, some connected lighting systems – like Philips apps, to APIs, cloud services, gateways and embedded Hue – have automated rules which run both in the cloud device firmware. Decisions about which code runs where and in a local hub. Others, like LIFX, have no hub and run shape how the product functions. Decisions about how entirely in the cloud. In the event of loss of connectivity, each part connects, and how often, can shape the value the system with local rules will continue to run, the system proposition and even the UI. without will not.

“The user experience has got to drive the technology and If users rely on your product, it should maintain some the technology is there to facilitate the UX.” basic function in the temporary absence of connectivity, Russell Ward, EDF Blue Lab innovation accelerator, part of at least allowing local users to continue to use it even EDF Energy 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. “When you start the focus is very much on the physical product … but we’ve seen repeatedly working with “We want to make a product that works as well offline as connected products that often the reason they ship late well as online, so it’s quite important to have the local chime is because of software: firmware on the device, the app for the doorbell so it will work even if your internet’s down or and the backend, and also testing. Just to get the product you don’t have your phone”. in your hand is one thing, but to get it in your hand and John Nussey, Ding, connected home startup and makers of be confident that it’s working well enough to ship is quite the Ding smart doorbell. different.” Jon Marshall, Map Project Office, a product design consultancy specialising in connected products.

How does it work? How could it fail? Architecture and reliability The 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 Fig 2: The Ding doorbell, chime, and app (www.dingproducts.com) 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

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 5 Reliability issues mean that the user may not always have and the client. Instead of promising to alert carers in up to date data about the state of the system. Sometimes, case of a problem, which might sometimes fail, or be a this matters. This can determine the way that data and mistake, the team decided not to send alerts at all. This updates are provided to the user. For example, designer/ set the expectation that the onus was on the carers to engineer Ross Atkin’s Liftcheck system for the Greenwich check on the older person via the app themselves, and to and Woolwich foot tunnels provides simple updates via decide for themselves whether they seemed to be OK. 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 “We originally planned on having notifications or alerts in lifts are out of action then the tunnels are not accessible the system. So if there was no activity for a certain period to people with motor disabilities or many cyclists, and a of time then we would notify the carer. But if the system long detour may be required. Sometimes the sensors lose goes down for any reason [and cannot send alerts] where connectivity, and at those times it’s not possible to know do we stand from a liability point of view as a business? whether the lifts are working or not. When that happens, And also we want this to be about everything’s OK, so we the app shows that the status of the lift is unknown, which want people who are monitoring the app to actively open helps would-be tunnel users decide whether to take a risk the app to check everything’s all right.” or find an alternative route. It is better to show that there is Tom Smith, Stannah 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. Fig 4: Stannah Connect: control unit plus devices, and app screenshots (Stannah, Ross Atkin Associates) 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 In the distributed UX section below, we’ll consider further individual sensors being offline (instead of a genuine how reliability issues can be handled in UX design. problem) would quickly become irritating for both carers

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 6 Battery life, connectivity patterns So instead of ‘Everything is OK’, the message the app can communicate is ‘No smoke detected at 10.15am’. The absence of connectivity is not always an edge case. Many connected devices, particularly those powered UX designers from web service backgrounds usually by batteries, spend much of their lives offline by design. assume that all parts of a system are connected and They connect only occasionally to send data or check for online by default. The realisation that that is often not true new instructions. This minimises power consumption and in IoT is one of the main adjustments in mindset required maximises battery life. to work with hardware enabled services. If you’re hiring a designer who is new to IoT, introduce them to the “A lot of our competitor products need a stable connection connectivity patterns of your system upfront to help set the all the time because people dial into them. We’ve shut ours correct assumptions. 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 “I thought that we would just be getting a flow of data, it others do to WiFi, it just means the product can last for would be never-ending. And then I learned it didn’t work longer, there’s only activity when something happens to it. like that. That completely changed how I had to approach So the battery will last longer without being recharged, like this as a user experience.” six months rather than maybe a month at best.” Kerry Malone, Head of UX & Design, Connected Homes, John Nussey, Ding EDF Energy Blue Lab This means that data and instructions can take time to percolate around the system. Not everything will always Latency and responsiveness be perfectly up to date or in sync. A 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.

Fig 5: EDF CAD device. CAD – consumer access device. Used to get ““In our case it was also a conscious decision just to do users in-day data from their smart meters, which on their own will voice for the product because we were thinking more only report data at a day’s delay. The device typically takes 5 minute about instant response and communication rather than readings but can be prompted to take 3 second readings (near surveillance. What you tend to get with the video doorbells live data) for bursts of a few minutes. This shaped the UX design, is you press the button, the light goes on for a little bit, it discussed in the ‘Continuity’ section below. 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 Maintaining some order in the face of these discontinuities about 20 seconds by the time you’ve got to that. The is a challenge for system developers, e.g. maintaining delivery person will already be filling out a “Sorry we missed accurate time series data. you” red notice to your door by that time.” John Nussey, Ding It also has knock-on effects on UX. For example it may be necessary to timestamp data, make it clear that Good technical design, e.g. using local networks where instructions might not be acted on instantly. It may also possible, can help reduce the risk of latency. Identifying be necessary to communicate with the user in a different where potential delays may occur in the early stages of way. A connected smoke detector might have last sent technical prototyping is important to develop mitigation data that no smoke was detected 15 minutes ago. That approaches: does not necessarily mean that everything is OK right now. It should be designed to wake up and send an “First we build a simulator for the hardware, so before alert if smoke is detected, of course, but it’s possible that we’ve got the hardware we have an app that has a might not work, or that in the interim a fire has started. Bluetooth interface like we expect the hardware to have.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 7 And then as we build the hardware we refine this so it How does it interoperate with 3rd party always has the right Bluetooth interface. That lets us start devices? testing things like communication between devices, so you can have a simulator connect to a phone a metre A final technical factor in shaping UX for IoT is away and start sending session data, and see how long interoperability. Products which interoperate with 3rd it takes. We do that quite early, trying to think about how party products can do so in different ways: typically by long is it going to take to get the data from the device to connecting directly over local networks, by connecting to the phone, for instance, and then also what strategies the same hub or gateway, or cloud to cloud. This can be can we adopt in our whole design that will aid that. With a fantastic extension of the UX: giving the user the ability the new product we know that there’s loads of data but in to ‘turn the living room on’ and control multiple devices via fact for the user there’s only a few bits of data that they’re a voice assistant. But there are several considerations for interested in, so we can request just the data that the user the user experience. is interested in and make sure that that’s the sparsest dataset so that it can get to them really quickly.” Ben Levy, Firstly, adding interoperating products to a system extends Chiaro Technology the technical architecture questions – how does it work, and how can it break. There are more things for the But it’s not always possible to avoid it altogether when user to understand, more complexity to how it works, messages are being passed over the internet. The UX and more interconnections that might occasionally not design may need to account for interstitial states. For work. Your Amazon Echo may confirm that it has sent an example, an instruction has been sent to a device but instruction to a connected bulb to turn the light on, but it the device has not yet confirmed that it has received and cannot know whether the bulb has actually responded. 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 UX User interfaces are underpinned by APIs. These are the glue by which IoT systems pass instructions and Fig. 6: devices may not respond to commands instantaneously, or data to other parts of the system, including front-end 100% reliably 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 There may also now be more than one route to achieve the functions which are supported, and the granularity a particular task, leading to potential confusion when of data and instructions which will be needed. As a very interfaces are different. This is especially the case if simple example, a network of pollution sensors (check) the 3rd party interface supports only a limited set of in a city would each have individual data to report. But functionality. For example, a lighting manufacturers app it might also be useful to know the average reading for may support features that other interoperating apps do certain areas, or to identify any readings which are above not. It’s possible to set the lights to a state from one app (or below) certain thresholds. To ensure that the correct that is not possible in the other one, which raises the readings can be retrieved easily and quickly by the front challenge of how the 3rd party app displays that status. end web app, each of these readings should correspond Similarly, there may be more than one place where to an API call. API and UX design should go hand in hand, application logic, such as automated rules, can sit. based on a shared understanding of user needs and Continuing with the connected home example, rules for priorities. 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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 8 Distributed UX/interusability

IoT products often present multiple devices and interfaces Composition for users to interact with. A connected heating controller may have its own UI, and a smartphone app, both of As discussed in the technical factors section, decisions which can be used to change settings. A connected about the technical architecture of a connected product industrial drill will have all the basic controls an operator can dramatically influence the user experience. At the needs for standard use. But it may also have an app to most visible design layer, this includes deciding which log usage data, enable easier monitoring when the drill is user-facing controls need to be available on which UI. For on a rig, and provide additional ways to modify settings, a common app/device combination, this means deciding such as torque. which controls are on the hardware, which on the app, and which may be needed on both. Users don’t use these interfaces in isolation, they experience them together as part of a system. Certain Similar products may follow different patterns. For use cases may involve switching between them or example, the Tado heating controller is a simple box with using them together. Changes made via one UI will very few hardware controls. Most user interactions with need to be reflected somehow on the other. Interfaces the system are handled by the smartphone app. 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 Fig. 7: The Tado heating controller and app (http://www.tado.com) Designing for cross-device interactions and the surprising effects of networks (e.g. latency, reliability) The key advantage of this approach is that it keeps the bill and connectivity patterns on UX and value propositions of materials down: physical UI components add cost. The 2 (continuity) 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.

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

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 9 By contrast, the Ecobee HVAC controller has both a full Consistency onboard UI and a companion app, with features mirrored across both. Devices like this can support all features A connected product may have UIs spanning very locally whether the app is available and able to connect or different types of device and form factor. Finding the not. But they are more expensive to manufacture, and it is appropriate degree of consistency helps them feel like a more difficult to roll out new features through updates. 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? Fig 8: The Ecobee HVAC controller and app (http://www.ecobee.com) Compromises will need to be made. The design task There are several variations to this pattern. Some products is to identify the most appropriate balance. Perhaps provide a subset of common controls on the device itself, the most important priority is ensuring that users know with these and other more advanced controls in the app. which features are the same on each device, even if The GoPro camera is an example of this. This pattern they are used in different ways. Giving features the works well because the camera needs its own controls for same name across all interfaces is critical in this regard. basic functions but the form factor, and the way it is worn But even this can sometimes be a challenge when, for (e.g. on a helmet), makes it unsuitable for more complex example, different versions of legacy hardware use interactions. different terminology (e.g. ‘auto’ or ‘timer’ or ‘schedule’). In this situation, it’s best to ensure the user’s mobile UI is Sometimes a device UI may support core tasks, with consistent with their device, even if that means having to different, supplementary features handled via the app. maintain several slightly different UIs. The Nintendo Switch gaming console has a companion app specifically for parental controls, allowing the parent The second priority is to make sure that each UI is to set time limits on gaming without interrupting play. appropriate for the device it is experienced on. A native smartphone app should follow iOS or Android guidelines. There may be more than one viable option; it depends on Power tool controls should be a good fit for the user’s the context of use. But it is often safest to make a product expectations. Skeuomorphism, e.g. mirroring a hardware which stands alone and can continue to work effectively in UI on a phone, is usually ugly, awkward and results in absence of cloud service. 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).

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 10 Continuity Continuity 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. 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

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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 11 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. 11: Philips Hue app

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

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 12 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 Fig. 13: The EDF CAD app, showing is connected and the frequency of reads. This is a key electricity (very frequent readings) question which underpins both UX and value proposition. and gas (less frequent readings) 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: Fig. 14: The EDF CAD app changing settings but also communicating status. An offers the user ‘experiments’ oven dial might show that the temperature is set to 200C. to help them understand If the temperature can be changed to 220C from a remote the energy consumption app, then the oven UI needs to be updated to reflect the of daily activities. Starting new status. This could mean motorising the dial so it can an experiment triggers the reflect that change. Or it could mean replacing it with a hardware to take near-live data readings for a few different type of interface which can change more easily, minutes, so that the user such as a digital display. can see the impact of using an appliance.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 13 From products to services

Is it a product or a service? hardware, but the service depends on connected hardware. This may be very low profile to the user, for All IoT systems involve a combination of hardware example a smart energy meter in the basement, or a components and a software service to keep the system network of air quality sensors. operational. Both play an important role in shaping the user experience. But the extent to which each is visible “We’re building cloud software that accepts custom orders to the user, and central to their understanding of the from fashion brands’ websites all over the world, and product, varies from one system to another. then converts those choices into manufacturing files and distributes them to factories with connected machinery at Some IoT systems are connected products, for which the the other end. It has flavours of the Internet of Things, but hardware is front and centre. The key value for the user we are trying to take advantage of the connectivity to the rests in a connected device, like a connected door lock or machines to build on-demand supply chains, rather than light bulb. making machines that are connected.“ Others may be hardware-enabled services. With these Martin Charlier, Unmade: a platform enabling brands to the user value rests principally in the service, not the offer customisable clothing via on-demand manufacturing

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

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 14 There are many classes of product/service in between, Owning a non-connected product is simple. You buy a with varying relationships between hardware and product, whether it’s a TV, tractor, or rubbish bin, with software. Some are even platforms, like a connected car: a fixed set of features which suit your requirements. It continues to provide the same features (breakages and both a visible piece of connected hardware (composed of repairs aside) for the duration of its life. If you buy a kettle, many subsystems) but also the enabler for a wide range you expect it to continue to be a kettle. of digital services. The extent to which the hardware, or service, is in focus will shape your priorities for user But connected products don’t remain static in the way that experience design. 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 Why think about services supplier can release firmware or software updates which Providing a cloud service to keep the system operational allow it to perform other functions. also shapes the nature of the user (or customer) When we use software, we expect it to evolve and be relationship. A conventional hardware product updated over time. Most software is now paid for through relationship is often a one-off purchase, perhaps with a SAAS model which reflects the dynamic relationship the option of customer support if something goes wrong. with the provider. But we still expect that physical products A connected product creates a more complex ongoing will remain static. IoT challenges this dichotomy: physical relationship with the user, extending beyond purchase products have the potential to morph into things which through ongoing use and support, all the way to end are no longer the thing we originally bought. If that’s the of life (what happens if you stop supporting the cloud case, do we really own them? What rights do we have service, or the user wants to transfer ownership to over them? What rights does the provider have to modify someone else?). them? The idea of ownership is changing, and the legal “Most people just think an app’s an app. You have to think implications are going to be interesting. about who’s going to maintain servers, who’s going to One way of dealing with this is to change the business deal with technical problems, what happens if we need to model, so that the customer is not paying to own a update the app, how does that run through the business. physical product, but paying for the provision of an “ Tom Smith, Stannah ongoing service, with the potential for the terms of service “Designing connected systems is a huge challenge with to change over time. This is covered in the Commercial existing consumer business models - “we only sell physical factors section below. 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 Designing services connects to the cloud, this is the beginning of a new journey A good customer experience requires a coordinated where the consumer is now experiencing a digital service.” design approach across devices and supporting Tim Daines, Cambridge Consultants service elements. This may span installation, product UIs, updates, sales and customer service interactions. Some of these interactions may happen with the product Designing the parts in isolation may result in a disjointed itself. Others will take place through other on- or offline experience. channels such as websites, callcentres, messaging, physical stores, or service personnel. Some may even Service design provides useful methods for planning and involve 3rd party companies who access data from the delivering coherent user experience across ecosystems product. For example, an insurance company may offer of devices, services and other ‘moving parts’. It addresses cheaper cover on a car in exchange for data about the bigger picture of how the touchpoints should work driving habits. In service design language, these are together, as well as the detailed design and planning ‘touchpoints’ for the user. Ensuring a good experience required for each one. at each touchpoint requires coordination across many business functions, and planning for the whole lifecycle of For example, a supplier of connected equipment to the product. 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 The changing nature of ownership packaging, instructions, and maintenance to consider. Putting connectivity into a product, and therefore building The core user is the diabetes patient themselves. The a service around it, does not just create an ongoing company might map their needs as a user journey from relationship between user and provider. It also changes first noticing symptoms through to diagnosis, treatment, the nature of that relationship, and challenges the nature formulating a care plan, management and dealing with of what it means to ‘own’ a product in the first place. potential changes in condition. Type 1 and Type 2 patients will have different needs and journeys.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 15 But the patient is not the only user, or stakeholder. Introducing new services through connected devices may Doctors, nurses, and insurance companies may all have also change existing work processes. For example, the an interest in what the devices do, how the patient uses Unmade customised clothing and manufacturing platform them, and what data they produce. This picture can of requires interfaces designed for several user groups. An course vary depending on healthcare provision in the online editor allows consumers to customise clothing, patient’s country. The patient’s loved ones also have an and may be placed on a 3rd party retailer’s website (as in interest and a role to play in the ongoing management of the collaboration with Opening Ceremony, sold through the condition. This may impact the design of the service Farfetch.com). Orders are sent through to factories via an (for example, allowing parents to monitor a child’s glucose order management system, where factory workers can levels remotely). sort them by material type to minimise changeovers on knitting machines. As many factories are paper-based, The wider ecosystem will include a variety of data, this system automatically generates the necessary connectivity, customer support and medical services paperwork. The pieces of each garment are knitted with a needed to support the devices’ functioning and unique ID so that they can be tracked through the factory monitoring, and potential interoperability with 3rd party and sewn together correctly. Shipping and customs systems (e.g. Apple HealthKit or Electronic medical record labels are generated automatically. Finally, the brands systems). These will require coordination from many themselves need their own user interface for tracking different business units, and providers, to ensure reliable sales data. operation. “What we didn’t anticipate at the beginning when we built One important key interaction will be helping a new the very first version of the order management system patient learn to understand the readings and manage for factories was that actually the main “interface” for their condition. Another key interaction will be alerting the factory is not the digital UI, it’s the piece of paper we them to unusual readings that might indicate a dangerous generate that they print and that then travels through the situation or change in condition. The devices, apps and factory. So the design focus was suddenly shifted from the user instructions have a key role to play here. But so do UI on the screen to actually designing a piece of paper. medical staff and potentially other online information Until the point it’s finished and shipped, nobody actually or remote support services. A potential deterioration in touches the digital UI.“ Martin Charlier, Unmade condition might need to be communicated (sensitively) to the user, trigger an alert to their doctor and set in motion The most important takeaway about service design is a process for changing the treatment plan. This is not the the mindset shift: from designing the components of sole remit of the device manufacturer, but the devices play the service, to designing for the relationships between a central role in supporting this. Products which support them. A single component, like the Unmade production patients and medical staff in managing the disease paperwork, or a setup guide, can play a role in facilitating effectively would have an edge over those which fit less the service, but needs to be made with an understanding naturally into the process. of the wider process it supports.

Another example of an ecosystem is the Unmade In the design methods section below we provide some customised clothing platform. Unmade worked to examples of methods and tools for designing services. complement existing clothing manufacturing processes within factories, while introducing some small changes necessary to manufacture one-off garments.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 16 Commercial factors: how business models and value propositions underpin UX

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 Fig. 16: The Beeline bike navigation device https://www. beeline.co are not as easy to copy as hardware. And many also Ding produced a working prototype very quickly using collect user data with the intention of someday monetising phone technology, but the ongoing costs were too it via 3rd parties, e.g. by licensing aggregated data. expensive to make this solution viable as a commercial The choice of business model is important to the product. The hardware and software ecosystem was provider’s financial success. IoT products often have developed around the need to produce a product with complex cost structures due to the upfront costs of minimal running costs: developing and shipping hardware and the recurring “Originally, we had some technology working that was costs of supporting an ongoing cloud service. basically a SIM card. The system was incredibly simple, the Underestimating these costs is a major risk to the viability hardware was predictable and had been on the market of a business. Ensuring the revenue model supports the a long time. But in a business plan sense it didn’t work. cost model can be challenging but is necessary to keep We would be paying pounds per minute to whichever the product up and running for the customer’s benefit as cellphone provider is in the country or region or in signal. So well as the provider’s. the technology made sense but the costs were too high.” “A Garmin will cost you about £300. We thought if we John Nussey, Ding can make something under £100 that’s a very different The business model also underpins the user experience proposition than the hardcore satnavs out there. At the through shaping perceptions of value and fairness. The moment it is just an upfront cost so you buy the device and revenue model needs to fit with the user’s perception of then you’ve got it for life. We will look to build stuff into the the value of the product. software that can be premium services, extra add-ons and things you can buy through there, adventures and content If your offering to customers is perceived to be a service in the same way that you buy a Lonely Planet guide.” enabled by a (lower profile) device, they will perceive the Tom Putnam, Beeline, maker of a bike navigation device 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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 17 Sometimes, providers may need to work around An ongoing subscription may be more attractive to customers’ entrenched ideas about paying for products. customers if bundled with other services. A connected The best fit for a connected lighting company’s cost industrial machine might come with a maintenance structure might be a subscription. But customers can feel contract. A door lock might be an enabler for a security uncomfortable when a product they think of as a one- monitoring service, or AirBnB management services. off hardware purchase requires an ongoing monthly commitment. No-one wants to pay a subscription for the A service/subscription model may also be fairer to the benefit of turning their lights on and off, or opening their user if the functionality of the product may change over front door. With services, users pay for the right to use, time. Even if you charge for hardware upfront, some rather than the right to own. Customers aren’t always element of a subscription model also gives you the ready to give up the sense of ownership, nor the legal flexibility to offer additional functionality over time and to rights that come with it. charge for these, e.g. offering different tiers of use.

“Looking at a lot of the reviews of competitors, often Finally, if customers are also providing value to the people were really hot on complaining about things like provider through their data, it’s important that they are the subscription and battery life.” able to understand and consent to the exchange (see Avril O’Neil, Ding privacy section).

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 18 Giving users transparency and control

Helping users grapple with complexity Security We often equate UX with simplicity. Users, particularly No product is 100% secure, and IoT systems are exposed mass-market consumers, often have low technical both to internet and information security threats (malicious knowledge. So we seek to create very simple UIs which hacking), and to physical compromise (e.g. sabotage). mask the complexity of the computer system underneath. And the impact of an IoT system being compromised is This is often the right way to go. But it poses challenges not just to information, but extends to potentially deadly when dealing with IoT systems. These, as set out earlier real world effects, such as losing control of a car, or a in this report, are often complex ecosystems of devices, contaminated water supply. services, data and application logic and business models. They can involve the user in relationships with multiple Consumers in particular are poorly educated about parties, as either service providers or recipients of their potential threats and product developers are not always data. consistent in identifying vulnerabilities in systems. This is a UX issue in that increasing security often comes at the Users may struggle with complexity. But hiding complexity risk of adding friction to the user experience, for example denies them the possibility to understand how the requiring authentication. system works, why it behaves in the way it does, who is benefiting from their usage of it and in what ways. If they The more complicated security measures are, the less do not understand it, they cannot have agency or control likely they are to be used properly. Recent statistics over it, and they cannot give meaningful consent to the show that fewer than 10% of Gmail users use two factor value exchange (reword). authentication. Sophisticated security measures used badly (because they are too confusing) are often less This affects a number of areas related to the product or secure in practice than less sophisticated, more usable service experience. 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 How it works, and how it can fail devices on the network that don’t need to be exposed, As discussed in the technical factors section above, ensuring that devices can do as little harm as possible the onus is on the user to choose the most appropriate when compromised, designing automatic updates into product or service, which connects in the appropriate the system. ways, for their needs. They also need to understand how to overcome or mitigate any potential issues (such as loss of connectivity). Data privacy Data privacy is concerned with collecting information about other people, processing it, and making it available, Ownership, and the right to modify in appropriate ways. What is appropriate is highly The functionality of connected products can be modified contextual. One person’s notion of a privacy violation is over time, which has the potential to change the nature of another person’s opportunity to get a cheaper service. ‘owning’ a physical product. There are also questions of You might not like the idea of an ad-supported fridge that how the provider can or cannot limit what the customer tracked everything you put in it. But another person may can do with the product (for example, agricultural be short enough on cash and desperate enough for a machinery manufacturer John Deere now restrict farmers new fridge to consider that an acceptable trade-off. There from repairing their own equipment). To what extent do is no legal breach of privacy if informed consent has been users understand or expect this, and do they consider it to given to use the information in the way that it is being be fair? used.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 19 Designing a good user experience around privacy GDPR is so far reaching that some provisions may extend involves: beyond the current technical means to implement them.

Careful consideration of what is captured and shared “The ability to retract your permission to use data sounds good, but once that data is sold to a third party or Providing clear and transparent communication with combined to create new insights, how can that data be users about what is captured, and for what purpose, controlled? How can the new knowledge go away? ” and with whom it may be shared Stacy Higginbotham, Stacey on IoT4

Providing options to opt in/out, even if these may A key factor for UX is that GDPR also puts the onus on the mean that the user cannot benefit from certain service provider not just to obtain informed consent, but to prove features that the user’s consent was informed. Long EULAs, which This sounds straightforward, but is fiendishly complicated no-one reads and very few understand anyway, will no to implement effectively. In IoT, there is a wealth of new longer suffice. data which can be captured. And the complexity of “…companies will no longer be able to use long illegible anticipating, communicating and gaining consent to all terms and conditions full of legalese, as the request possible uses is prohibitive. Fully informing users of every for consent must be given in an intelligible and easily potential use of data is not realistic, especially when data accessible form, with the purpose for data processing which may have been captured for innocuous purposes attached to that consent. Consent must be clear and can be combined with other data to reveal much more distinguishable from other matters and provided in an than anticipated. For example, security analysts recently intelligible and easily accessible form, using clear and identified that exercise app Strava’s global heat map of plain language. It must be as easy to withdraw consent exercise routes inadvertently reveals the location of US as it is to give it.” 3 military bases . https://www.eugdpr.org

Even if it were possible to anticipate every possible “GDPR says you can’t just have a huge swathe of terms and consequence of sharing data, it would be overwhelming conditions and get somebody to tick the box because that’s to present this to users. not meaningful consent. You have to demonstrate that they Minimising the amount of data which is captured and understand and the only way you’re going to do that is shared is advisable. Keeping data on local devices actually to rethink what terms and conditions look like, how instead of storing in the cloud (as e.g. NetAtmo security they’re presented, whether they come through as part of cameras do), is the safest model. But there is often a the service, how they evolve, how you can change them… commercial incentive for providers to capture as much I think those are huge design challenges that are just not data as possible in the hope that it can be monetised. 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 Current regulations mandate that providers obtain with my data is rapidly disappearing.“ informed consent from the user for use of their data. But Professor Paul Coulton, Chair of Speculative and Game this is often buried in long EULAs full of legal language, Design, Lancaster University which no-one reads. There are no simple answers to this yet, but the industry Incoming European regulations (GDPR), enforceable needs to find new ways of communicating what is from May 2018, increase protection for data subjects, or happening with data and obtaining consent. It may not end users. GDPR is based around the concept of privacy be possible to anticipate all the potential consequences by design: building data protection into the design of a piece of data being shared. But companies need to of the system from the offset, instead of adding it on. provide better transparency so that users can be more Companies need a valid reason to collect a piece of data, in control of their data. This will require radically different and must provide transparency about what can be done approaches to communication. Describing the use of with it. Users have the right to ask what the company data in more humane language is a start. Providers might knows about them, and to force the company to correct also give users a visual overview of the ecosystem in wrong information or delete the user’s data on request. which the product sits (see constellation model below). Companies are also prohibited from profiling users on the Or they might find ways for end users to see what data basis of data. is being shared as it is being shared. The Polly design fiction project from the University of Lancaster mocks up GDPR also increases the geographical scope of the law the example of a connected kettle which provides a more to any company providing services to EU customers, and user-friendly licence agreement coupled with an event log imposes more severe penalties for non-compliance. 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-42853072 4https://staceyoniot.com/how-to-protect-privacy-in-a-world-awash-in-data/

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 20 These are design provocations rather than commercial designs, but they indicate some of the directions that commercial providers could consider.

Automation and algorithms IoT 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 Fig 17: Image from “On the Internet Everybody Knows You’re a responses. If it is not 100% right almost all the time Whatchamacallit” by Joseph Lindley, (which is very likely), it will be at best frustrating. In some http://eprints.lancs.ac.uk/84761/4/Polly_Design_Fiction_Booklet.pdf situations (such as flipping a light switch when there is a gas leak) it could be actively dangerous.

Another approach may be for the industry to develop And it’s not too much of a stretch to imagine that common tools which allow users to make decisions about algorithms like those which are used to determine who data sharing across multiple products. The [smart lock] gets access to credit, or who gets parole, might also project, also from Lancaster University, postulates an app be used to decide who is permitted or not permitted which allows users to trade off greater privacy against to access certain real world locations, or drive cars, or increased functionality by dragging a slider. Moving the deemed a security risk in a public place. slider up or down enables different levels of data sharing but also different levels of device functionality. 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 Fig. 18: Imagined smart lock app trading off privacy for functionality, stop it behaving oddly? This isn’t feasible with no UI – from Anticipating GDPR in Smart Homes Through Fictional there has to be a UI somewhere where you can see this. Conversational Objects. / Lindley, Joseph Galen; Coulton, Paul; Akmal, Haider; Knowles, Brandin Hanson. 2017. 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/

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 21 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 complexity We 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 Fig.19: The constellation around a connected heating controller. Image from https://www.petrashub.org/ukjapan-workshop-on-iot/. and algorithms shape its value and function?

“There’s a more than human thing going on with this, The example above shows a sample constellation that algorithms have an influence, business models have for a connected heating controller, such as the Nest an influence, there are other non-human actors in the (an Alphabet/Google company). From the user’s network that have a profound effect and it’s how you also perspective, the controller, and the devices in the home reveal that.” which interoperate with it, are the product. Their value Professor Paul Coulton, Lancaster University is in controlling heating and lighting. From Google’s This is complex. Perhaps in designing user experiences perspective, their value is as data gathering devices: for connected products, the notion that we can ever make a view to what is happening in the offline world of the everything ‘simple’ is disingenuous. We are doing users home, which extends Google’s in-depth knowledge of a disservice and disempowering them if we oversimplify what most of us do online (and thus their ability to target complex products to the extent that they cannot be services and sell advertising). understood. Perhaps our primary aim, instead of trying “The Internet of Things isn’t just the physical things that to make the experience as simple as possible, should be you see. It’s things like business models, regulation, to empower users so that they have agency and control algorithms. They’re all things within the network, it’s just over the connected products around them. This is not an that their effects are almost hidden, they are things in the excuse for poor design or unnecessary complexity. It is background that exert this huge influence. But there’s a not an argument in favour of products with thousands concentration on these physical things that you can see, of configuration options to suit every user whim, which which often are the least problematic aspects of what are overwhelmingly complex and unusable to anyone. you’re trying to do. So, we’ve been using this idea that Products still need to be focused on solving a core set of you sit within this constellation, and the constellation user needs well. What it does mean though, is that instead is different depending on where you’re looking from. of passing off connected products as ‘app-enabled devices’ If you’re Google looking at your Nest thermostat, Nest (Apple’s term) we should try to make the ecosystems thermostats are a great way of gathering data. For the around products more transparent and fair to users. user you’re interested in turning your heating up and Joseph Lindley, Paul Coulton and Rachel Cooper6 propose down. It’s the same constellation but it looks completely an approach which treats IoT products as star-like different depending on your perspective.” constellations of devices, providers, 3rd parties, algorithms, Professor Paul Coulton, Lancaster University data sources and standards. The early example above may not be a mass-market This is known as ‘more-than-human centred design’. The consumer-friendly tool for clarifying the system around a intention is not to downplay the importance of serving the connected product, just yet. But it points to the need for end user’s needs, but to acknowledge that the system providers to help users better understand what they are may look very different viewed from the perspective of the buying into, and to be able to make informed decisions provider, or a 3rd party, than it does to the user. 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)

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 22 Design methods and prototyping

IoT products combine software and hardware, which have Making the right thing very different approaches to design. A key factor in the difference between the two approaches is the ease with The difficulty of iterating hardware products means that which the design can be iterated. it’s important to test the value proposition, and uncover core user requirements, early on. This can be done in In software development, the product can be iterated parallel with hardware development. While design and even after release, so the UX design is never ‘finished’. product are exploring whether anyone needs it, and what Physical products cannot be changed in the same way. requirements it needs to fulfil, at the same time electronics So physical product design projects have a ‘design and design engineers can be exploring whether it is freeze’ point, when the product design is handed over for feasible to build. But that means finding ways to prototype manufacturing. After this point, design changes would and simulate the product experience that don’t rely on mean postponing or re-planning manufacturing, incurring functioning hardware. of substantial delays and additional cost. Physical product design teams therefore tend to do more upfront user Exploratory user research research and exploring multiple design directions, to get the product design right before manufacturing. Software The first step in understanding the need for the product design teams, especially in the modern lean startup is user research. If time ad budget is tight, this need not model, often aim to release an MVP and then iterate and be formal. Good quality research will give you much improve it. Testing alternatives in the wild through A/B or more reliable results, but informal ‘guerrilla’ research multivariate testing is increasingly common. But this does is better than none at all. If you are your users, your not lend itself well to hardware products. And constant own insights can be useful, but be careful of making iteration of design and functionality may not play well assumptions about the needs of others. Bike navigation with users in certain settings. Changing the way their startup Beeline’s founders were cyclists themselves, so thermostat or door lock works may be a disconcerting had first hand insights into needs around cycle navigation. experience. Stannah and their designers conducted research with older people, occupational therapists, and carers to Designing an IoT product means bridging the two understand first-hand the needs of older/vulnerable approaches to consider the whole experience, as well as people and their care networks. the customer experience beyond the app and device. “When we had those conversations it became apparent There are two key goals. The first is ‘designing the right that to the stairlift users the stairlift was a way moving thing’ - ensuring the value proposition, business model between floors. But to the people around them it’s and requirements are on target. The second is ‘designing reassurance that they are safe. That was the core insight the thing right’ - making it appropriately easy to use and that the project came from and then the key challenge in appealing. Hardware, software and broader service terms of design was creating something that’s reassuring design methods are different. But they share a common and not creepy, and playful and not unpleasant, and goal: maximising learning about the right thing to make, something that doesn’t make the person feel surveilled and the right way to make it, while minimising effort spent but does provide the people around them with the making the wrong thing. reassurance that they want.” Ross Atkin, Ross Atkin Associates

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 23 Fig. 20: Materials shown to Stannah interviewees to explore which and focus groups) are not always the same thing and the information would be acceptable for others to know (Ross Atkin context in which your product will be used may throw up Associates, Stannah) interesting challenges.

“We spoke to some occupational therapists around what “We did a lot of testing of compass navigation and found they thought the key areas of monitoring might be. Are that generally it was great. But if you are trying to go from they eating and drinking, are they moving about the northeast London to southeast London and there were house were the two key bits of information that they felt no bridges at that point, you can get very stuck. So that’s would give them enough reassurance. And that’s how where the need for waypoints came in.” we got to the system we have today where we monitor Tom Putnam, Beeline three appliances, an entertainment, a beverage, a food In the early stages, qualitative methods such as appliance and the stairlift.” observation and interviews will give you more useful Tom Smith, Stannah insights for design. Surveys may capture feature requests Approaches suited to early stages can include but not necessarily why people want them – information observation, interviews, competitor evaluation, surveys which can help you figure out whether the feature is really and focus groups. Try to visit potential users in the place what users want, or whether they indicate an underlying they would use your product, and do at least some need for something else. Quantitative methods are helpful observation of them doing the tasks that your product later on when you need to prioritise features based on will support. What people actually do, and what they say how many people may want them, or demonstrate to they do or remember to tell you (for example in interviews investors that there is solid demand for a product.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 24 “In order to work out how the care networks around screen, with a big number and an arrow. One of us would people were working I did these maps with each of the without showing the other one just type in a destination into people: who were they seeing in a month and what a phone, strap it onto the handlebars, and the other person means of communication were they using? I asked would have to go there and send a picture. We recorded everyone who would you call if you had a problem, if you it on Strava and could see what the routes were like. And had some good news and if you needed cheering up. We both of us kept coming back with big grins on our faces were able to segment the market into four different kinds because it was kind of a game of trying to follow the arrow of network, and for each of those four different kinds of and trying to pick a route. Then the next step before making network a slightly different service design made sense.” any hardware we tested that with lots of friends. We’d sign Ross Atkin, Ross Atkin Associates 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 Fig. 21: care network diagrams produced by Stannah interviewees customer interest in the product. (Ross Atkin Associates, Stannah) For a very new product concept, a press release might If there is an existing product or equivalent which people not be enough to help users imagine themselves using currently use to get the job done, you can interview the product. A next step might be to produce storyboards: potential users about that and observe how they use it. like short comic strips that show how the product might be used for key use cases. Storyboards allow you to “We ran interviews with potential customers as well who demonstrate the whole picture of product interaction were looking into purchasing a product. So what they - with physical devices, apps, customer services and think they might find useful from a doorbell, the problems more. These are usually a better way to communicate the they have with their current doorbell.” proposition than diving into concept app screens to start Avril O’Neil, Ding 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 Prototyping for proposition testing often be cheaper and easier to get a designer who can If your product is in an entirely new category, it can be to spend a day or two helping you do this than to build a hard to get good insights about what people would want basic prototype. from it. You need some way of showing people what the “We did these really nice kind of comics to illustrate that product could do for them, in order to have a meaningful there’s different kinds of service design that could go with discussion about whether they would use it and what it, and they again helped to have conversations later they would want from it. To be efficient, you want to spend on both with people that might be using it and people the minimum time mocking up the product concept, in within the company and OTs. The next phase after that order to learn what you need to learn, and not waste time was actually building the prototype and testing that and building the wrong thing. that was nice because we found that people were using It may be relatively simple to mock up a quick prototype it in the way that we had hoped. These were extremely that does a good enough job, even if it doesn’t work quite valuable in terms of allowing people that weren’t like the eventual product. For example, before making any interested in technology to get their heads around what hardware, Beeline mocked up an app which simulated the we were thinking about doing and whether they thought it device experience: was useful or appropriate…” Ross Atkin, Ross Atkin Associates “I got somebody to make an app where you could do a Google Map search and then it had a simple ring on the

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 25 Fig. 22: Stannah Connect comic strip (Ross Atkin Associates, Stannah) Making the thing right Iterative software and hardware prototyping and A more advanced experience prototype might go even testing further to simulate the experience of using the product. Video mockups can be compelling ways to explore the The key to good UX in product development is ongoing proposition. Beeline released a video of an imagined iterative prototyping and testing. The main goal of early product on YouTube to test the proposition. This was high- prototyping and user testing is to test the proposition. fidelity enough to double up as part of their pitch to win Over time, your confidence in the proposition increases, funding. However, versions for design exploration or user and the emphasis switches to understanding key testing do not have to have the polish of an investor pitch. requirements, and then to testing design solutions. The key is just enough fidelity to learn what you need to learn. A simulation made with cardboard mockups on a It’s often easiest to do this by considering user research smartphone might be enough to get the feedback you as an ongoing activity throughout the project, speaking need. 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.” Fig. 23: A still from Beeline’s early prototype video. The product was simulated using video compositing. Awaiting permission. Taken Ben Levy, Chiaro Technology from https://www.youtube.com/watch?v=pNguieZ4cTc. In terms of prototyping, industrial and software UX approaches conventionally operate separately. But with IoT, All of these can serve as a springboard for conversations the two should run hand-in hand as much as possible to with potential customers around whether and how they ensure a holistic approach to design. (If you’re making a might use the product, what it might need to do for them, service enabled by sensors the user will never see, industrial and how they would feel about various ways to pay for it. 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.)

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 26 The process of prototyping hardware typically moves IoT designers often need to consider how users will through moodboards and CMF (colour, material, interact with apps and devices at the same time. form explorations) to sketches, developing a design Interdependencies between device UIs and software UIs language, low-fi model making (e.g. in polystyrene) mean that the old approach of making a device, and then to CAD modelling, 3D printing and finally design for developing the UI later, often won’t lead to a good result. manufacturing. A common pattern amongst companies developing The process of software prototyping typically moves connected products is to produce an early device through exploration of user scenarios, to flows, to a prototype for feasibility, then to discover that the device UI rough UX architecture (how functionality is organised in design cannot proceed much further without a concept of the app) and screen designs of increasing fidelity. These what will happen in the software. Once this is in place, the may start from sketches and proceed through wireframes device UI can be developed, and the software UX iterated. to more visually advanced UI designs. Designers often make clickable prototypes in tools such as InVision or “We did a bit of the app experience, then we designed Adobe XD and sometimes build functional prototypes with the product, they we did a first stab at the electronics, developers. This latter is particularly helpful when user redesigned the product with the electronics, and then testing with real data is required, for example, showing a worked on the app again. So it was in stages but then there participant in a smart meter test real energy data from a was a point when the things started coming together.“ real home (whether or not it is their own home). John Nussey, Ding

Neither process is well suited to designing the whole Good communication between the different design experience of both hardware and software. Conventional disciplines is vital to identify and manage these industrial design prototyping focuses on the device interdependencies. Small changes to design techniques alone. And conventional digital prototyping software can make a big difference. focuses on interactions with a single app UI. Conventional UX designers can map out user flows as swimlane prototyping techniques cover only screen interactions, not diagrams spanning multiple UIs or touchpoints. voice or other modalities. But for the connected product, each of these is designing only half the conversation.

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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 27 Go to the shops the choose Ding amoungst door bells. Bring Ding home. Input details and phone number online. £80 - £120

At home but don’t know “Who is it?... who it is...... I’ll be right there.”

Browse doorbells online, choose & buy Ding. Input Ding arrives in the post details and phone number on pruchase. Out of reach in the “Just coming!” garden...

OR Away at work... I can’t come to the door, leave it next door”

The stairlift is slow & can’t “Give me a min, I’ll come make the door in time... down”

Take out the box... Position it in your home. Someone comes to the door... Sounder rings in your home. As well as ringing your phone Aswer the phone

£2 per moth subscription

Your a vodafone customer, they call you to offer a Ding Ding arrives in the post 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.

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).

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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 28 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.

Elvie is ready Elvie is ready Elvie is ready Last ten workouts Strength 2 workouts completed 2 workouts completed Intermediate 2/10 workouts

Ma Hold ki Lift Pulse ng p r Strength Lift o 05 Mar 86 LVs 8/10 g r e Pulse s 34 s LVs Step 21 s Hold Speed Speed LV .9 % 18 secs 12 in 10 secs 60 45 Best 45% Target Lift Average: 86LVs Personal Best: 98LVs LV score Target A STRENGTH INCREASED w e ! Average s t o a 89 m re 07/12 01/12 02/12 03/12 04/12 05/12 06/12 88 88 88 e g 87 87 87 g re n 86 86 su oi lts D 87 88 84 ! 86 87 86 85 Jan Feb Today 86

01/12 03/12 04/12 08/12 11/12 12/12 14/12 23/12 29/12 01/01 39 34 LVs LVs Start your workout Start your workout Start your workout Start your workout Best Trend Average

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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 29 “There’s always value in testing at all phases, from literally tailored to the questions they want to explore at that point. pencil drawings, wireframes, all the way through to This controls the product, collects usage information and prototype. … For hardware you’re kind of stuck in some user feedback all in one. 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 “We tailor the app to the research phase. For example you think it might look, but it doesn’t have to do anything, with the new product, the app that’s for research just whereas with software it can maybe not look so close to lets people control the hardware and it lets them answer what you think it might look but it’s got to do something. questions about the session that they just did so that There’s a difference in how you have to approach it I think. we can get feedback directly with data from the device. With the software it is often a bit easier to test.“ So the hardware data is combined with their qualitative Ben Levy, Chiaro Technology feedback like how they feel about it, what they were doing during the session. I think that’s important for us, that Doing an internal pilot before testing with potential users when we are going to take up people’s time and they’re is helpful to flush out errors in the prototype, or very going to follow a protocol that we make sure we can get obvious usability issues. everything that we want, or as much as we can get, using as little of their time and as easily as possible for them.” Early testing in the lab or office is useful in early stages. Ben Levy, Chiaro Technology But as the product evolves testing in context is needed to expose issues that may occur during real use. A key pitfall to avoid is taking feature requests too literally during testing. Test users will always ask for features “We did a pre-production run of the hardware and a beta which address their specific needs. But taking all of test with a version of the app using Testflight. It became these at face value will result in a confused product with clear that you can use it when you’re walking around and it too many features. Look at the underlying reasons why tested brilliantly but when you put it on a bike the magnetic users are asking for those features, and whether they are field of the steel frame caused the needle to point in slightly likely to be of benefit to others. Note feature requests but the wrong direction. So there was a whole additional consider them in context of your wider proposition. workflow needed in the app. You have to lift your bike up and move it around, to calibrate it to your bike.” “One of the main pitfalls of connected products is Jon Marshall, Map Project Office, re Beeline overspeccing everything and losing your North Star. In the Beeline beta testing people said “It would be great if Starting with small numbers and qualitative testing is the it could do turn by turn navigation as well” or “Can I see best way to learn how to improve the design. Quantitative notifications from my phone on it?” But what Beeline did is measures are useful when monitoring a live service, or to stayed really true to their goal.” assess how many people may be interested in a specific Jon Marshall, Map Project Office feature. To get the best data while using as little of users’ time as possible, Chiaro develop a research app which is

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 30 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 Fig. 30: Before designing the Tapp hardware and app, the team Service design requires you to switch between thinking considered the holistic view of data movement around the system from the bottom up and from the top down—that is, to between different stakeholders and technology, in response to move between considering the ser¬vice as a whole and different triggers and situations in order to understand the necessary addressing individual interfaces or components. service interactions required. (Cambridge Consultants/Tim Daines)

A core element of service design involves mapping the Another core element is creating a service blueprint. This ecosystem of devices, UIs, and other touchpoints which considers customers’ needs and key interactions with and the user will directly interact with (frontstage), and the around the product from first hearing about it, through supporting people, infrastructure and other enablers purchase, setup, in-life use, updates/upgrades, through required to support the service (backstage). This is a to end of life. The starting point is a user journey based on holistic picture of the system and surrounding service, user research insights, usually created by mapping user which helps map the scope of the service, figure out needs at each stage on a wall with post-its, looking for which parts may be needed and how data flows around, potential pain points and opportunities. 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)

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 31 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.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 32 Fig. 32: Excerpt from the service blueprint for Tapp (Cambridge The methods shown here are a means to an end, not Consultants/Tim Daines). the end point of design in themselves. The delivery of a service design is in the service itself. In a small team The service blueprint diagram can then act as the basis without a dedicated service designer, you may not have for specifying key design requirements for individual time to maintain beautiful diagrams. But knowing how to touchpoints, for example, ensuring that it is easy to access represent and map out service level thinking can be useful the devices serial number while on a support call, or for communication. The key is to enable the team to designing how emergency alarm notifications might be grapple with the high level view of the service experience cascaded to different user types via app and SMS. in parallel with focusing in on the detail of each interface and other touchpoint.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 33 Summary: planning UX for an IoT project

The design methods above are suggestions for possible Building whole team communication into the project approaches. Design methods for IoT are still emerging, process is critical. IoT teams are more multi-disciplinary and there’s no single correct approach that fits all teams than pure software or hardware teams, and team and projects. members are often still learning about some of the other roles they are working with. Teams need a shared However, there are a few key practices which successful understanding of what each member is doing, to identify teams follow: where collaboration is needed.

For example, UX designers and firmware engineers won’t Making the right thing naturally know that they may need to collaborate around From defining a strong proposition through to ensuring the metadata used to describe a smartplug, because this the design makes sense, understanding user needs is affects both the software UI, and the firmware of the plug. essential. Good teams do this by learning from users So regular knowledge sharing and facilitating mutual throughout the project. A little research, done often, is understanding is essential to ensure the team work usually better than one or two big studies. effectively. “We meet at least weekly for a review. We keep each Prototype and test early other up to date with what we’re doing. And people get a chance to say whether they want someone else’s help or Don’t waste more time than you need to making things input. The product manager is there to hear all of that and that might turn out to be wrong. Use whatever methods make sure that we talk to each other when we should. It are most efficient to simulate what it would be like to use happens often that we’ll bring the hardware engineering your product just well enough to learn whether you’re on team to look at the digital design because what we’re the right track or not. Then test it. In the early stages, that doing is trying to reflect maybe what they’re doing.” need not mean having either functioning hardware or Ben Levy, Chiaro software.

Design for the system, and the service In summary Users will experience your product as a system. Approach the design in the same way. Consider how individual We are just beginning to explore the potential in devices and UIs will be used together to design how the IoT. And we are just beginning to explore how the whole experience works. Step back and consider the methods we have evolved for designing physical service experience surrounding your product: have you devices, and software services, will (and won’t) thought of everything users will need? What operations scale to designing products which combine both of need to be put in place to deliver the best experience? 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 Foster good team collaboration we listen to users as much as possible, try to make UX is not just something to be done by designers. things which improve their lives, and consider the Designers, developers and business people all make context in which designs are experienced, we will decisions which shape the experience of a product. be off to a very good start.

Get in touch: IoTUK.org.uk [email protected] @IoTUKNews IoT UK: UX and service design for connected products 34 Produced by

Digital Catapult, 101 Euston Road, London, NW1 2RA IoTUK.org.uk • [email protected]

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