Designing Connected Products: UX for the Consumer Internet of Things (2015)
Chapter 12. Supporting Key Interactions
BY CLAIRE ROWLAND WITH MARTIN CHARLIER
This chapter sets out some practical requirements for key interactions that are common to different types of connected products.
There will be many aspects of your design that are not covered here as they will be unique to your product or market. But regardless of what your product does it will almost certainly need ways to do some of the following:
§ Get the system set up and devices connected
§ Access controls and data
§ Manage devices and alerting behavior
§ Configure and manage automated behaviors
In some interactions, such as device pairing, technical requirements will mean that your design has to follow a tightly scripted flow. We’ve described these in detail. In other interactions, such as accessing controls, there may be many possible design solutions. Here, we’ve shown examples of common design approaches currently used in live products to provide starting points for solutions.
We would not want to limit your creativity by suggesting that any current design reflects the “best” way of doing things. The field of IoT is far from ready for any defining design patterns since we have so many suboptimal situations in both hardware and design, as the rest of this book discusses.
However, requirements and design problems across various types of system in the market right now have similarities. And we can draw from existing approaches in the interaction design arena to increase our confidence in drawing up these issues. As with much of this book, the examples here come heavily from connected homes with some from different contexts, such as wearables. Not all of these will be relevant to all types of system, but there are commonalities across different systems.
Use this chapter as a checklist of possible requirements and source of examples. We hope it will save you some effort specifying and designing the necessary functionality to get and keep your system up and running.
This chapter introduces:
§ Practical design requirements for getting up and running with the system, connecting devices and user accounts (see Setup)
§ Typical design requirements for in-life “housekeeping” functionality: the unglamorous but important admin functions your system will need in order for users to get and keep it up and running, such as managing devices, handling notifications, user management, and system maintenances (see Test It’s Working)
§ Emerging design approaches for system discovery (see Discovery) and control (see Control Experiences), experiences that are common to many systems on the market today
§ Designing for platforms: if your system supports multiple applications, you’ll need to consider common design components to make your UX feel coherent (see Platforms)
§ In-depth technical information on connecting up and pairing devices (see Automation)
This chapter addresses the following issues:
§ Why flexible, modular setup processes help users on first time and subsequent use (see Preconfiguration Versus User Effort)
§ Why you need to consider the flow of setup instructions across print, UI, and packaging (see Instructions)
§ Why users need a way to manage devices, but showing signal strength is misleading (see Device Management)
§ Why dashboard-type designs for controls don’t scale (see Prioritizing Key Controls)
§ Why your platform needs a consistent design language (see A common design language for UI elements)
§ How to get devices with and without screens and keyboards connected to the network (see Automation)
§ How pairing works, and the different patterns Bluetooth supports (see Pairing Devices)
Ease of installation is vital to a good experience, especially if consumers are expected to complete it themselves. A good setup experience by itself is not the only thing needed to make a service successful, but a bad setup experience can be enough to make it fail. If the setup experience of a product or service is bad, the customer may lose enthusiasm for the product or give up on it altogether. They may also install it incorrectly, so it never functions quite as it should. For example, a well-known brand of video baby monitor received poor reviews when even engineers could not figure out how to connect it to WiFi. Returns of devices such as broadband routers and cellphones where no fault is found with the equipment are estimated to cost the global electronics industry billions of dollars per year. A significant proportion of these are likely just to have been misconfigured, often due to the poor usability of the setup process. We can probably expect IoT systems to follow similar patterns.
Setup is hard to cover in general terms, as it varies so much from product to product. The process of installing devices in a home or other location is very dependent on the device and what it does (and of course the characteristics of the user’s home and their personal goals for using the product). Some devices, particularly those being wired into the fabric of a building, may require professional installation.
One of the most critical activities is getting devices connected to each other and/or the Internet. Once devices are connected, there will often be some configuration and customization to do to get them working the way you want. Services involving multiple devices and automated behaviors or rules, such as home monitoring kits, can require quite intensive configuration.
A good setup UX is important. But what happens after setup—the in-life experience—needs careful design too. When you’re figuring out how your system should work, there may be certain technical decisions you make to enable easier setup. (Adding support for out of band pairing, described in the Getting Things Connected section, is one example.) But you also need to have a very good idea of what the in-life experience will be. Designing an effective setup experience requires the user to understand what they are setting up and why, and you can’t do that unless you know that too.
In this section, we’ll look at overall patterns for helping users with setup.
Creating Good Setup Experiences
Setup is hard to simplify. It often forces users to engage with some activities or parts of the system that they don’t understand very well. Key questions to ask when you’re designing a setup experience are:
§ Are there elements of the system we can supply preconfigured, or must the user set everything up? What defaults, if any, will create problems if not changed? (For example, not changing the default admin username and password on a router will leave it open to malicious use.)
§ How much flexibility can we allow the user in terms of the setup process? Must everything be done in a very precise sequence, or can the user be allowed to complete the steps in any order?
§ What are the best ways to provide instructions and feedback?
§ Is anyone else involved in setting the system up?
§ What’s the end point of setup? How can you support the user to a point where they are getting real value from the system?
§ How easy is it for the user to make changes after initial setup and configuration? Users may need to duck back into parts of setup later on to add or remove devices, reconfigure functionality, or even pass on ownership of the system.
Preconfiguration Versus User Effort
The ideal user experience is as little setup as possible (i.e., “plug and play”). Devices might come with batteries preinstalled, or be already paired to the hub. But the additional effort and cost for the supplier may make this unrealistic. And the more preconfiguration you do, the more you have to make assumptions about what the user wants... which may be wrong.
Pilgrim Beart, in his role as founder of AlertMe, a UK-based connected home technology company, talks about the challenges of designing the setup of the company’s original consumer home monitoring kits (see Figure 12-1):
“Ideally you’d open up the box and it’s configured for you, the sensors would have the right names, but this adds a lot of complexity to the supply chain. So you have to get the customer to do the customization. One variation could be that you could preconfigure the kit for the most typical home, and then the user would customize it. But there’s no such thing as the typical home, and people can get upset when you imply they are not typical or make assumptions.”
Flexibility and Modularity
Most systems take the procedural approach of walking users step by step through a process. In theory, they can succeed in setting up the system without needing fully to understand what’s happening. This approach can be slow for more knowledgeable users but for a one-time interaction for inexperienced users, clarity is usually more important than speed.
The chief drawback of a rigid process is the risk of the user running into difficulties if they do something out of sequence, either by mistake or by accident. Users often don’t sit down and work through your instructions step by step: they often expect to be able to muddle through without reading them at all. If they have done things outside your predetermined sequence, the system may now be in a state that does not match anything in the instructions. They may be unable to resume where they left off.
Figure 12-1. The original AlertMe home monitoring kit
It’s better, if possible, to provide a degree of flexibility. Certain sequences of actions, such as connecting up a gateway, might have to happen in a certain order. But it probably doesn’t matter whether the user pairs all their devices before seeing the app homescreen. If you can detect what the user has already done and still needs to do, you can allow them to complete those steps in whatever order (see Figure 12-2). This supports the high proportion of users who will pile into setting up the system without bothering to read the instructions... until they get stuck.
As Pilgrim Beart says:
Forcing the user to set up their new system in one particular “logical” order just doesn’t work. We originally thought there was an “obvious” order: plug in the hub, register it with the cloud, put batteries into devices, name the devices. So that’s what we designed for, and put in the instructions. But it turned out that this was just not intuitive to many users, many of whom didn’t read the instructions either, which led to them getting stuck and needing customer support, which doesn’t scale. So to make setup truly a no-brainer we had to put in a lot more thought and engineering work, to allow users to do things in whatever order makes sense to them, with the system reacting to give them appropriate guidance on how to complete the process. This puts the user in charge, with the system as helper, not the other way around.
Figure 12-2. The Lowes setup process (based on the AlertMe platform) allows users to break off and resume setup later (image: Lowes)
Where possible design for interruptions: allow users to complete part of the process, pause, and return to it later. If users have to complete the entire process in one sitting, they must have all the necessary information and materials on hand, and find a time when they can safely ignore the doorbell, incoming phone calls, and any other interruptions. With the best of intentions, this is often impractical. They will also need to have a good understanding of what they are doing, as making (and undoing) mistakes or stopping to refer to the instruction manual or contact customer support will break the flow. This could further increase confusion, and thus the risk of getting into more serious trouble. Stuck in a rigid, poorly designed process to set up a broadband router, one of the authors of this book managed to lock herself out of all commands including the factory reset. She had to buy a new router.
One connected home system we encountered required users to complete setup in a single sitting, taking up to an hour. If you only managed part of it, it wasn’t possible to resume where you left off. If you had set up your user account before pairing all the devices and were then interrupted, the system would log you out. Logging back in would take you to an empty homescreen, showing no devices, without any status information or obvious action to add them. The system just looked broken. A better experience would be to show the homescreen with a prominent link saying, for example, “have you added all your devices?”
However you choose to walk users through setup, ensure it’s always clear exactly where they are in the process, what’s just happened, and what will happen next.
It can help to set some upfront expectations about what will happen at the start of setup. Having an understanding of the overall process and objectives will make users feel more confident and help them orient themselves better if things go wrong. This plays to different cognitive approaches that users may take. Some may need a map to orientate themselves; others (especially novices) will still need step-by-step instructions.
Some of the functions that are part of setup may be things the user will need to go back and do again in the future. Examples include replacing batteries, adding or removing devices, and running software updates; even changing owner, linking to a new account, or moving house. A flexible and modular approach to designing the setup experience, that allows the user to dip in and out if necessary, may help you design those standalone functions more easily.
Many systems provide instructions via a combination of media, such as printed instructions, videos, in-app (web or mobile) guidance, and physical labels on devices (see Figure 12-3). Each of these has valuable uses. For example, a video can be a great way to show complex actions like removing a battery cover, or sequences of interactions, like just how an LED will flash during pairing. Color-coded physical labels can be a nearly foolproof way to indicate which cable needs to be plugged into which port. Contextual instructions that provide onscreen guidance as part of the setup process are ideal. For example, the guidance that tells you how to put the battery in the motion sensor should be available on the same screen that indicates whether the motion sensor has been detected by the system.
Figure 12-3. Product instructions, like those for Wink, can be spread across packaging, apps, and any connected devices that have screens
But the fact that instructions are distributed across multiple places can also add complexity. You need to take a holistic, service design approach to designing setup experiences. Consider the sequence of actions required; the packaging, devices, UIs, and instructional media that may be used at each stage; the handoffs or transitions between them; and the context of use at each point. (The BRCK case study in between Chapter 12 and Chapter 13 describes how the designers went about designing the setup UX, spanning hardware, software, and packaging/instructions.)
If the same instructions are available in more than one format, for example, print and web, ensure that either both sets are complete and clearly carry the same content, or that each has a clearly defined and different role. This means it’s clear which part is handled by which medium. For example, the print guide helps you get the device powered up and the control app installed, from which point onward you see instructions in the app itself. Users should not have to waste time comparing print and onscreen guidance and worrying about which they should be following.
If you use partial instructions in different formats, ensure there is clear signposting across media. For example, a printed quickstart guide in the product box might give the user just enough information to get the product connected (see Figure 12-4). After that, they should be using a mobile/web interface or the embedded device interface itself if it has one. The switch between the two should be an explicit handover—for example, the print guide should say “now refer to the setup instructions in the mobile app.” Bear in mind that once users have a working system to interact with, their attention will be on that and they may stop looking at print instructions. Keep instructions close to their line of sight for performing the action if possible.
Figure 12-4. A cross-media handover in instructions on the Pebble
In particular, ensure wording and diagrams used on different media are 100% consistent with each other and the actual product. The print diagram used to illustrate how to put the battery into a contact sensor should look like the actual sensor, and be the same one you use in the UI. This can be a challenge, as it’s much harder to make updates to print instructions than to onscreen ones. For example, a set of printed setup instructions was supplied with a home monitoring kit composed of security and safety sensors. The provider had commissioned artwork for the setup instructions at the time the kit was first released, but over time had switched to another manufacturer for one of the sensor components. The device was now subtly different to the older version of the diagram. However, they had not had time to update the artwork or the printed instructions. The printed setup instructions showed a diagram of the older version of the sensor, and while it looked similar, the method for opening the battery casing was slightly different. This caused confusion: it wasn’t clear whether users had correctly identified the component, or why the casing wouldn’t open as per the instructions. Were they doing something wrong or was it broken?
If there are lots of components, such as multiple motion sensors, or components are likely to be unfamiliar to users, consider putting physical labels on them so users can identify them out of the box.
UX designers Harry Brignull and Pete Gale’s presentation “Out of Box Experience Design” provides user research–based advice on the design of broadband router setup instructions. Much of the advice would also be applicable to a multidevice IoT system.
Context of Use
With any system that’s designed to be used in a specific place, consider the context of use of setup. For example, in a connected home system, users may be required to connect all the sensors or devices to a hub or gateway, then physically place them around the home. Depending on the size of the home and range of the network, as they are placed around the home, some may lose connectivity to the hub. If the user has to walk around the home, installing devices, it would be useful to track whether or not they are still connected. If the device itself is too limited in capability to display this, this is an ideal opportunity to use a mobile device over a desktop. Even if setup is long and involved and some of it is better suited to a desktop computer, it’s worth allowing users to switch input devices during installation.
Is Anyone Else Involved?
For certain types of home system, such as heating, professional installers may be involved. You’ll then have to decide which tasks are best done by the installer and which by the user. The installer may have greater technical knowledge but it may not be appropriate for them to complete certain steps themselves. Contractors may be short on time, and their employers may only allow them limited Internet access on their work devices. And the householder may feel more comfortable doing certain steps (such as setting their online account password) themselves.
Getting Things Connected
The most critical stage of setup is getting everything connected. If there’s a dedicated gateway, it will need to be connected to the Internet, over WiFi, Ethernet, or perhaps cellular data. It will need to be associated with a user account on the Internet service. For edge devices that go directly online, the steps are similar. There are different ways of approaching the design, depending on whether the device or gateway has a screen and input capabilities, or not. If edge devices connect via a gateway or to each other, they will need to be paired, perhaps over ZigBee, ZWave, or Bluetooth.
It’s useful to understand some of the technical requirements for getting things online and pairing, as these will determine much of the interaction flow. We’ve discussed the technical requirements in detail toward the end of this chapter, in The Technology of Getting Things Connected.
Getting Real Benefit Out of the System
Setup doesn’t end when the user has physically connected all the devices. Quite often, extra configuration is needed before the system can deliver real benefit to the user. For example, once a user has connected up all their security sensors, they will need to identify the most likely entry points for an intruder and place the sensors around the house. Or, having set up a lighting system, they may at some point want to configure groups and scenes of lights. Users are likely to need guidance with this, but don’t overwhelm them with too many options all at once. Get them to configure the basics first, then link to more guidance as they are ready. Sometimes it may be better to let them get used to using the basics for a while, then make suggestions for getting more out of it. Think of this not as presenting everything at once, but designing a journey through which users learn more about the system, and it becomes better adapted to their needs.
Test It’s Working
Once everything’s connected, you may want to include a test mode to verify everything is working. That might include testing connections, controls, or notifications (see Figure 12-5).
Figure 12-5. Pebble offers an option to test notifications
Once the system is up and running, there are some other basic housekeeping functions that users are likely to need.
Users are likely to need ways to add more devices, remove ones they no longer want, and manage the settings of devices. If there are multiple devices to manage, then a central location for viewing and managing all of them makes sense (even if this functionality can be accessed from multiple places in the system).
A typical approach is to have a list of all the devices on the system showing some basic information (see Figure 12-6 and Figure 12-7), with more detail available on dedicated screens for each device (see Figure 12-8 and Figure 12-9). What information you choose to show and where will depend on the type of system you’re creating. But common elements include the device type, name, whether it’s connected OK or not, any current status information (e.g., on/off or last sensor data reading), when it last checked in/sent data, battery status, any metadata you have added (like its location), and, if appropriate, any functionality with which it is associated (such as automated rules). There might also be the option to identify it, through a beep or LED flash (this is useful if there are multiples of that type of device and you need to know which is which).
Figure 12-6. The Things list in SmartThings
Figure 12-7. The web UI device list from Lowes Iris
Figure 12-8. A device screen for a keyfob from SmartThings; note the option to make the fob beep, to identify or locate it
Figure 12-9. A device screen from the Lowes Iris web UI
Think carefully about how much information users need, and what they can actually make use of. Independent IoT consultant Gawain Edwards offers a tip, learned from testing connected home systems: “Never, ever, show signal strengths to users. It unnecessarily worries people that they don’t have a perfect signal even if their devices work perfectly.” Interference matters more than the strength of the signal: an edge device can often work very well with only a weak signal to the gateway if there is no radio interference from other sources. Just show the user that the device is connected, and warn them when it’s not working.
Notifications, Messages, and Alerts
If your system uses one or more types of notification to alert users to insights or state changes within the system, you may need to provide a place to manage and customize these. These might be forms of mobile notification (e.g., banners, badges, alerts), alerts on the edge device (like a smart watch’s onscreen notification or wearable vibration), or using channels like email, SMS, or even triggering automated phone calls. In Control Experiences, we discuss activity feeds that keep the user informed of overall system functionality.
What you choose to communicate depends on the nature of your system, but some basic, system-related notifications might include low-battery warnings and devices being unavailable. There may be certain functionality that’s so central to your system that you need to let users know right away if it’s not working. For example, if a home security system or fire alarm is offline, it’s very important that the user is aware. The absence of an alarm usually means everything is OK, but if the alarm loses connectivity then no alarm is not necessarily good news. In other cases, a temporary outage might not be a problem. Home heating will continue to work even if Internet connectivity is lost. In that case, rather than notifying the user every time the Internet connection drops out, you might just tell them at the point where they try to use it. The key question is, would the user behave differently if they knew?
Choosing the correct communications channel is a question of how urgently the message needs to get through, how timely the information within it is, and how important it is that user takes action or not. You don’t want to find out your house is on fire via an app badge. And an alert to tell you that your home is currently using an unusually high amount of energy is probably not best delivered by email. If you are at home, you need to know right now, and the email may take time to get through. Consider also whether you need to provide feedback on follow up. For example, if your elderly grandfather has used his emergency alarm, it’s reassuring to know that your uncle has already responded and is on his way to help.
Where you can, link alerts to the means to act on them. For example, “you left home but the heating is on, do you want to turn it off?”
If your system may potentially be used by more than one person, you may need to provide ways to identify them or allocate permissions to access certain functionality. Or the system may simply capture data about different individuals and what they were doing. This could be anything from identifying a particular user on the bathroom scales, who was driving or who turned the heating up, to giving someone the means to unlock the front door and disable the security alarm or assigning a neighbor as an emergency contact if the flood sensor is triggered. Connected home systems may also track presence—who is in and who is out of the house—using keyfobs, personalized alarm panel codes, or mobile location (see Figure 12-10).
Designers also have to think carefully about how different users are identified. A physical device, such as a keyfob, wearable, or smartphone, may be used as a proxy for the user: if Jim’s keyfob just came home, that means Jim just came home. That might work most of the time, but it isn’t necessarily accurate. Jim might have lent the fob (and his keys) to someone else. Jim might sometimes let his kids borrow his phone to watch videos. Gaining access to the phone means they may have access to other apps on there, too. Or the phone may be stolen. Can you assume that it’s OK for anyone in possession of the user’s device to be able to act as the user? If not, how are you going to authenticate them? You could require a PIN code to access certain app functions, but will that make day-to-day interactions feel slow and inefficient?
Figure 12-10. The SmartThings app shows who has arrived home and when (based on the presence of their smartphone)
Guests and visitors pose additional challenges: they may need limited access to parts of the system, or access for a limited time. For example, a houseguest might need to use the door lock, lighting, heating, and security system for a week. But you might want them to have only limited rights. It might seem easier to grant basic system access to anyone who can get onto the WiFi network, but that might cause security risks (see Chapter 15 for a discussion of security).
Some users might need to be treated differently—for example, nonresidents in a home system. A heating system might track the location of every mobile device on which an app is installed to figure out when the house is likely to need heating. A part-time nanny or housekeeper might need access to the heating app while at work, but his or her location should not be tracked when they are not working.
This can be a sensitive area in which to design. Exposing data about who has been doing what, and allocating (or withholding) permissions to do or access particular things can be a source of friction (see Chapter 11 for a discussion of privacy). In a complex system, it can also cause admin headaches: few of us wish to spend our lives being sysadmins and gatekeepers for our friends and family. The right solution depends enormously on the type of system and context of use. A light touch, balanced with the need for security, is often best.
You will also have to consider how to handle system updates. You may need to deliver firmware or software updates to your devices. Will these be pushed automatically to devices (with the option to roll back if the update causes problems)? Or will users need to agree to them explicitly (see Figure 12-11)? There’s potential here for user irritation and confusion as a whole new range of consumer devices suddenly require more active management The set-top box that requires a 10-minute software update just as you sit down to relax in front of the TV is a new frustration of modern life.
Hardware may be an issue, too. How easily can a device be replaced? Does replacing a spent light bulb require the user to reconfigure all the lighting rules that applied to the old bulb, or can it simply be replaced?
Figure 12-11. The Lowes Iris Service Status screen shows that firmware updates are available for the gateway and security camera (image: Lowes)
So far in this chapter, we have focused on the experience of setting up and configuring a system that the user owns, perhaps in the home. But in other cases, consumers will be accessing systems in public or other people’s spaces. How do they discover the system’s presence, what it can do, and understand how to interact?
In a public space, users will need to be notified of the presence of the system in the first place. For example, a sign might inform them that beacons are available to help guide them around the airport (for which they may need to download an app). Or a sign might indicate that an NFC tag is available to provide information linked to a bus stop or point of historical interest (see Figure 12-12).
Figure 12-12. Sign on a London statue of Rowland Hill, postal reformer, indicating that content can be accessed via NFC tag
Perhaps users are aware that the system is present, but need guidance on how to interact. This will become more and more common the more devices in the environment are connected. The bus stop that broadcasts a web URL for bus times (e.g., the Physical Web project outlined in Chapter 2) needs some visible way of indicating that it can be interacted with.
All of these examples require clear signposting. Until this technology becomes familiar and everyday, service providers will need to indicate not just that a system is available, but also how to interact with it. This will need clear affordances, and establishing a shared vocabulary for explaining interactions to users (see Figure 12-13).
In this section, we’ll look at some common approaches to designing controls: the actions that users can take with the system. How can you organize controls so that the actions users most need are quick to access, how do you design the experience of sending commands to other devices, and how can you ensure users always know what’s been happening on the system?
Figure 12-13. Oyster travelcard readers are clearly signposted in London rail and tube stations; Oyster created the vocabulary of “touch in/touch out,” which has become standard London vernacular
Prioritizing Key Controls
If you’re offering controls to users, or any interactions in which they will expect a response from the immediate environment, speed is crucial. The speed with which the system responds is part of this, but the inherent challenges of latency and synchronization (discussed in Chapter 3 and Chapter 9) can make this tricky. But it’s also the speed of getting to the controls in the first place, such as locating and opening an app and tapping several times to find the right command. As Gawain Edwards puts it, “The best way to get a user to interact is to make it faster to use a smartphone than it would be to press controls on a device directly.” In a system they use frequently, users need very rapid access to the most commonly used controls, even if that makes it slower to access less common controls. You can automate this by guessing at the most used functions (see Figure 12-14), but in practice this tends to make UI elements move around.
Figure 12-14. Revolv (now acquired by Nest) tried to make guesses at most used functions on the dashboard (image: Revolv)
This can paradoxically make it harder to find the right controls as users can’t rely on motor memory to find them. Or you can allow users to customize their own top controls, but this creates additional admin overhead and may not be used.
Dashboards, composed of key devices and some basic controls, have become a common design solution, particularly in connected home systems. There is currently no consistent dashboard pattern: some simply display all devices and users have to navigate into each one to interact, while others surface basic interaction options right on the dashboard. The WeMo example in Figure 12-15 includes on/off switches for some of the devices listed.
Figure 12-15. The Belkin WeMo app lets users add a name and a photo of the respective device to include in the overview (image: Belkin)
In a system of relatively few devices and controls, dashboards can be a useful way of providing access to key functionality (see Figure 12-16). But they don’t always scale up very well. Imagine a dashboard for tens or even hundreds of devices in a house: it would be more like a flight deck. Some people might like the idea of a flight deck for the home, but they are not mainstream consumers. Dashboards are a general-purpose design solution, and can lack the clear focus that helps explain complexity to users. For mobile UX, in particular, a more focused approach tends to work better.
Figure 12-16. Different smartphone UIs showing dashboards of multiple connected devices (clockwise from top left: Revolv, Simplewave for Vera, Wink, WeMo)
Connected product systems often provide several ways for users to aggregate and automate system functionality. For example, “rules” can be used to create automated system behaviors, often using “if... then...” conditions, such as: “if motion is detected turn on the light” or “if no one is at home turn down the heating” (see Figure 12-17).
Figure 12-17. Smartphone UIs that allows users to automate behaviors (left: IFTTT, right: Belkin WeMo Switch)
These programming-like experiences are appealing for early adopters but can be very challenging for consumers. We discuss their pros and cons in more depth in Chapter 15.
Connected home systems, perhaps the most complex of the current consumer products, have several conventions for grouping devices and functionality into commonly used patterns, such as modes (e.g., vacation, night) and rooms or scenes (such as lighting settings for dinner parties or movie watching). These are discussed in more detail in Chapter 15.
Sending Commands to Other Devices
Controlling one device from another is not quite as straightforward as controlling actions on a single device. In addition to the interusability considerations discussed in Chapter 9, there are a few additional quirks of which you may need to be aware.
First, you may want to make sure that the user has finished interacting before you send the command across the system. This is particularly the case if the user is adjusting the value of a setting (like a heating temperature or lighting level) rather than just turning something on and off, and if the interaction is going via your Internet service. Actions like this can take multiple taps or key presses. Passing updated instructions after every tap will create a heavy load on the system (especially if hundreds or thousands of users are doing the same thing). It may be better to buffer instructions and wait until you’re certain the user has finished interacting before passing the command to avoid overloading the network/system. For example, adjusting the temperature via the British Gas Hive app involves multiple taps and drags on the target temperature circle (see Figure 12-18). As the user changes the temperature, the circle flashes between the color of the original target and the new setting. Once the user has finished interacting, the command is sent to the system via the Internet and the phone vibrates to confirm this.
Second, consider how confident you can be that the action on the control device has produced the desired effect, and whether it’s necessary to give the user additional feedback. For example, you might turn on a smartplug attached to a lamp, intending to turn on a light. But if the lamp’s own switch has been turned off, or the lamp has been disconnected, the smartplug may be powered but the lamp won’t be on. In this case, it might be useful to tell the user that despite the plug being turned on, no current is being drawn.
When a system is partly controlled by autonomous or user-automated behaviors, it’s important that there’s a way of viewing what the product did when, and why it did it. If it behaved in an unexpected way, users need to know why, and what to change if needed. Activity feeds, or event logs, list system events and explain why they happened.
Figure 12-18. The British Gas Hive app homescreen (image: British Gas)
The events shown might have been initiated by:
§ A user (e.g., Kelly’s keyfob came home, James turned the heating up to 72°F)
§ An automated rule (e.g., the hall light was turned on by the evening security rule)
§ An autonomous decision (e.g., the dishwasher was paused to balance demand on the electricity grid)
In Chapter 15, we discuss activity feeds in more depth in the context of automation and autonomous systems. Figure 12-19 and Figure 12-20 show some examples of activity feeds from current live systems.
A software platform, as we saw in Chapter 3, is a type of software framework that can be used to build multiple remote service applications. Platform software usually runs in the Internet service (and perhaps gateway, if you have one) and controls how devices and software services work together.
Figure 12-19. The SmartThings activity feed (image: SmartThings)
Figure 12-20. Tado displays recent activity on the homescreen
Platforms provide the common functionality that all the applications or services running on top will need: such as getting devices onto the system, configuring them to work together, handling user accounts. This can help to ensure a consistent experience.
In a simpler system, the platform may provide direct access to device data or controls through APIs, so the frontend UI is talking more or less directly to the devices themselves. In a more complex system, there may be middleware that provides an abstracted view of system components and specifies some logic about how they should work together. This gives you more flexible and efficient ways of organizing and coordinating your applications and devices as your system grows.
If you’re making a very simple system, you may not yet need to think about platform design issues. However, as you add more devices and functions, you may very soon feel the need to think about creating a coherent experience across multiple devices and end user applications.
The UX design work that goes into a platform covers two key areas:
§ Provide common design components that help create consistency and coherence in the UX across different functions and applications
§ Data models and logic that describe how all the components in the system relate. These can be used to organize controls, automate system functions, and interpret data in more meaningful ways.
The first need you’ll run into is for common design components. We’ll cover those in this chapter. You’ll need to think about data models and logic as your system scales and becomes more complex. We’ll cover those in Chapter 15.
Your platform will need to provide a set of common functional components that support all your devices and services. In UX terms, these will help ensure a consistent experience and make it easier and quicker for you, or other designers, to create applications on your platform. These components will probably include basic admin functionality, such as adding and removing devices and perhaps managing users (covered in In-Life Housekeeping). Next, we’ll consider some additional components for more complex systems, as well as ways of making the overall UX design feel coherent.
A common design language for UI elements
The more complex the system, and the more controls there are, the more important it is to establish a common design language. This will help ensure an appropriate level of consistency throughout the design. For example, you may need common ways to represent controls or states such as on/off, up/down, less/more, timer or schedule/manual, hot/cold, set/unset, locked/unlocked. You may also need common ways to handle notifications: like emergency alarms, low-battery notifications, text messages, app notifications (of various types, depending on mobile platform), emails, outbound calls, and status information.
Design templates and patterns
You may need to create a variety of different UX templates or patterns (structures that repeat) in the design. They might enable you to support different types of devices, organize functionality in different ways, or provide common ways of handling behaviors that are similar. For example, that might include devices (e.g., a light, a radiator control), services (e.g., the security alarm), activities (e.g., watching a film), insights (e.g., you’re wasting energy running the heating when no one’s home), people (e.g., Jimmy is home from school), or location (e.g., the living room is 72 degrees with four lights on, and Jimmy is there playing on the Xbox).
You probably won’t need all of these (if you do, you’re dealing with a very complex system that would benefit from the kinds of data models described in Chapter 15). But you might need a mixture of approaches. If your system supports multiple applications, templates and patterns are also an easy way to ensure they are presented in consistent ways. The more complex your system, the more important templates become. Your system might support several different types of lighting, all with slightly different features—for example, dimming, color changing, or the ability to be controlled alongside other lights as part of “scenes.” But the screens and user interactions for controlling all those lights need to feel like a family. The aesthetic styling, layout, and behaviors need to be appropriately consistent: things that work the same should look and behave the same, any differences should be due to the unique capabilities of a particular light. (You might even need to have a screen to handle a generic device: a Z-Wave gateway will control any Z-Wave device to a basic level, even if it’s just to provide an on/off switch. Users might use your system to control devices you haven’t even thought of.) Another challenge to consider for designing templates is scale. If users may have anything between one or two devices up to 100, does the UX design need to adapt, and if so, how?
Handling instructions from multiple users/devices
If a system has multiple users, you’ll need to consider what happens if they are trying to send contradictory instructions at the same time. One person may try to turn the heating up as someone else turns it down. One person may try to turn a light on from a smartphone app as the other turns it off from a physical switch, making it flash on briefly then off again immediately. Deciding which takes priority can be tricky or even impossible. This makes it important to design things that go to set states (i.e., on, off, etc.) rather than just a toggle switch. If you are trying to turn a light off with a toggle switch, but someone else has already turned it off (without your knowledge), the toggle switch will just turn it on again.
Conflicting controls can also come from automated rules, or autonomous systems. You may be turning the TV or a light on, but a rule says it ought to be turned off after 11 p.m. What happens then? Does the system defer to the user, or insist on turning it off? Would you want to enforce the rule for a TV in a child’s bedroom, but allow overrides for the landing light? What if the child is ill, can’t sleep, and the parent wants to turn it on? (In Chapter 15, we discuss the challenges of designing automation and “programming-like” experiences in more depth.)
Viewing interrelationships between devices, services, and rules
If you have many devices, controlled by different services or applications, users will need a way of viewing these interrelationships. That might mean, for example, a way of viewing information about a device, showing which services it is used with, which rules it’s being controlled by, which other devices it may be controlling or controlled by, what they do, and any data it reports (and to where). If you have multiple users on the system, you might even want to see and control who has permission to use it, or to see its data.
Users need a central way to configure, view, and manage automation and the platform can deliver this. In UX terms, this will involve an interface for configuring them, clear visibility of any rules that are running and next scheduled actions and an event log that explains what has recently happened and why. You might even want proactively to suggest ways that devices can work together.
Designing for automation means asking users to engage in programming-like activities. This can be extremely challenging to get right. We discuss this in more detail in Chapter 15.
The Technology of Getting Things Connected
In this section, we’ll dive into some technical requirements for connecting and pairing devices. If you’re designing a setup process, these will determine chunks of the interaction flow. Bluetooth in particular supports a number of alternative pairing patterns.
Set Up Gateway or Directly Internet-Connected Device
This section deals with connecting up devices that connect directly to the Internet over Ethernet or WiFi. This includes dedicated gateways (which provide connectivity to low-powered edge devices), and edge devices that connect directly. We describe the process of setting up gateways later, but the process is much the same.
To set up a gateway, the user must power up the gateway, connect it to the Internet, and associate it with a user account on the provider’s Internet service. The gateway may or may not work without the Internet service account.
Gateways are often connected via an Ethernet cable to a broadband router, or WiFi. It’s easy to connect a gateway to a broadband router using an Ethernet cable. Many connected home gateways are “headless.” That might conjure up images of ghostly horsemen, but it just means they don’t have an integral UI. Where the gateway needs to connect to a WiFi network and does not have Ethernet, the process is more complex, as there’s no “onboard” way to enter the desired WiFi network’s SSID and password. These devices often have a WiFi radio that can function in two modes. On first use (or reset), when it doesn’t have any network details stored, it functions as an access point. The user connects to this local network to configure the WiFi settings on the device (see Figure 12-21 and Figure 12-22).
Figure 12-21. Configuring a device that acts as an access point
Figure 12-22. The Ninja Sphere gateway in access point mode; the LED image shown on top indicates that the gateway is waiting for the user to connect their smartphone to the Sphere’s temporary network to configure the WiFi (image: Ninja Blocks)
The setup process can be device-led: the user powers up and connects the gateway or device then has the option of associating it with an account on an Internet service. Or it can be service-led: the user logs into an Internet service account first, then associates the gateway or device with the account.
Device-led setup can be useful when the system could be used offline (i.e., the gateway is connecting local devices to each other and can function without the Internet). If the user has bought your device “off the shelf,” it may seem more logical to get the hardware up and running first rather than start by setting up an account.
Service-led setup may be simpler for end users, especially for a headless gateway and/or if an operator wishes to provision apps and update software/firmware on setup. Service-led setup allows accounts to be set up in advance by service provider, useful for complex services or subscription models.
Even if the user doesn’t need an account at first, you might still want them to use a mobile or web app as part of setup. This might be the only way to give the correct WiFi details to a headless gateway (as we’ll explain later).
Figure 12-23 shows an example of service-led setup for a headless Ethernet device.
Figure 12-23. A service-led (cloud-based) flow for a headless Ethernet device
Using a web or mobile app UI, the user sets up and/or logs into a preexisting user account on the Internet service. They plug the gateway into the router and turn on the power. The hub will have some way of indicating whether it has an Internet connection, such as an LED.
In the web/mobile app, they need to enter an ID number, which is printed on the hub or supplied in the box (as an alternative, they could scan a QR code or NFC tag on the device).
The hub is associated with their account on the Internet service. The service will then check the gateway’s firmware/software version and perform any updates needed. It may also download application software to the gateway to enable particular functionality according to the user’s profile (for example, they may have subscribed to a home security package).
Pebble (see Figure 12-24) is an example of a service-led setup. It requires the user to log into or create a cloud account before connecting up devices.
Figure 12-24. Pebble setup is service led: the user sets up an account before configuring the device
It’s much less likely that a product would require a consumer user to set up a headless Ethernet device without a cloud account first, as it’s considerably more complicated. But this is the model by which broadband routers are generally configured, and it’s possible you might encounter it. Figure 12-25 shows how this works.
Figure 12-25. Setting up a headless Ethernet device that does not require a cloud account
The user needs to plug the gateway into the router and turn on the power:
§ Using a web browser on a mobile device or computer, they visit the local URL of the gateway, which should show a login screen.
§ From this local web interface, the user can configure and perhaps also control the device.
§ If the device needs to be accessed on the Internet, the user can then set up and/or log into an Internet service account. This associates the gateway with their account.
§ From then on, they can use the “normal” mobile or web app to control the device.
Setting up a headless WiFi device is more complicated. The user needs to provide the device with the WiFi network name (SSID) and password, but the device doesn’t have a screen or keyboard by which to enter these. A common approach, as described previously, is for a device that has no WiFi network configured to act as an ad hoc WiFi hotspot (refer back to Figure 12-21).
This is how products such as the Nest Protect and Belkin WeMo Switch work (see Figure 12-26).
Figure 12-26. Getting the Nest Protect onto WiFi (image: Nest)
Switching WiFi networks on your smartphone or PC is fiddly, and takes the user outside the areas of UX design that you control. It may be a good idea to supply printed instructions for this phase, as the user will be leaving your app and may forget what to do next or get lost. This is especially risky on a mobile device where they will have to switch between your app and their phone’s settings to read and execute instructions.
You could potentially put the WiFi details in a named file on a USB stick and stick this in the gateway, but the gateway firmware would be configured to expect a file with exactly the right name and the contents would have to be formatted exactly right (see Figure 12-27). This is fine for expert users but isn’t a very friendly option for mass-market consumers.
Figure 12-27. Adrian McEwen and Russell Davies’s Soundbox project (which experiments with the use of sound as an ambient notification channel) allows the user to add WiFi network information as well as software upgrades via a USB stick. The system was based around a Chumby embedded computer (Chumby Ltd is now defunct). The Chumby would find the right files for network configuration automatically from the USB stick (image: Russell Davies).
Push-button configuration is a standard supported by WPS (WiFi Protected Setup) that theoretically makes it easier to add devices to a network. Pressing a button on the WiFi router and on a compatible device should get them connected. For example, the Samsung SCX-3405W printer can be connected to a network by first pressing the button on the access point, then pressing a series of buttons on the printer itself (see Figure 12-28).
Some systems attempt to get round the challenge of getting WiFi details into a headless device by using “out of band” methods to transmit the details. For example, the Electric Imp uses a method called BlinkUp (described in Chapter 8) to convert WiFi details stored on a smartphone to a series of flashes of the phone screen. A light sensor on the imp “reads” the flashes.
Figure 12-28. The Samsung SCX-3405W laser printer has a WPS button, circled here (image via Samsung.com)
Standards are in development for out of band (OOB) pairing for WiFi over NFC, but at the time of writing are not widely available in consumer products. The WiFi pairing through the NFC Android app is an early instance (see Figure 12-29). This allows users to send WiFi network details over NFC to another device with one tap, and could be of particular use in setting up devices with limited input mechanisms, such as printers or other embedded devices. OOB pairing using NFC is discussed in more detail in Bluetooth pairing options.
Even if your device lacks a screen, it is still useful to use LEDs or other means to communicate status information about connectivity, during setup and afterwards. States you might need to convey include:
§ Device has no network access/credentials that need setting up (configuration mode)
§ Attempting to connect to network/Internet service
§ Successfully connected to network/Internet service
Figure 12-29. Android devices sharing WiFi details over NFC
§ Error connecting to network/Internet service (e.g., the service might be unavailable or the network might be down)
§ Gateway/hub devices may also need to indicate whether local connectivity to edge devices (e.g., Bluetooth, ZigBee) is working OK or not
The Wink HUB uses different color and blink patterns to show the current status of the hub (see Figure 12-30). The BRCK case study in between Chapter 12 and Chapter 13 also describes the use of different LED color and blink patterns to show connectivity and battery status.
Once the gateway is set up, you can move on to pairing edge devices with the gateway.
Setting up a device or gateway to use mobile data is much easier. If the device ships with a SIM card, the user may not need to do anything at all to get it connected other than turn it on, and it may already be connected to their account.
Figure 12-30. The light on the front of the Wink HUB is used to show the current status of the HUB. Flashing pink means it is disconnected from the WiFi network and waiting for credentials (configuration mode). Flashing yellow means it is attempting to connect to your WiFi network and the Wink Internet service. Solid blue means it is online and connected to Wink. Other color/flash patterns are used to indicate when a device is being paired or removed, successful pairing or problems with pairing, and changes in state of connected devices (e.g., a light has been turned on).
Using mobile data can be an easy option for setup: at most, the user has to insert a SIM card, and many devices may ship with the SIM preinstalled. The network operator handles provisioning. But it is an expensive option: either the service provider or the user will have to pay for mobile data. Good Night Lamp chose to supply their initial 100 run of device pairs with a five-year mobile data subscription as customers wanted to give lamps to elderly relatives who might not have WiFi or be confident setting up devices (see Figure 12-31).
Figure 12-31. The Good Night Lamp ships with an integral SIM card; it requires no setup to get online and works anywhere in the world (image: goodnightlamp.com)
“Pairing” is the action of creating a shared security association between two devices over a local network, such as ZigBee, ZWave, or Bluetooth. In other words, you are telling them to trust each other (for certain, possibly limited, purposes). This allows them to share data with each other, or trigger functionality. This may mean pairing an edge device with a gateway, or with another edge device.
In general, pairing for the first time requires explicit user interaction. One device is instructed to search for other nearby devices (aka it is in “search,” “discovery,” or “acquire” mode). The other is set to a discoverable mode in which it broadcasts its identity and basic capabilities to any searching device that asks. If one device is a gateway, this will generally be the one doing the searching. Some devices (particularly those with no onboard UI) will be discoverable by default, and others (such as a smartphone) may need to be set to be discoverable. See Figure 12-32 for a typical device pairing flow.
Figure 12-32. A typical device pairing flow for ZigBee/ZWave
Where devices have very limited UIs, a device may pair to any other device that comes within range while it is in search mode. The SureFlap cat flap (see Figure 12-33) can be programmed to open only for “authorized” cats, as identified by the pet ID microchips (passive RFID tags) embedded in the cats’ necks. Authorized microchips are paired to the flap by putting the flap in search mode and holding the cat near the reader. When all cats are added to the system, the flap is taken out of search mode.
Figure 12-33. Pairing a cat with the SureFlap cat flap. This process can take some time and effort if the cat has a forceful personality. During this time there is the slight risk that an “unauthorized” cat will attempt to enter the flap while it is in search mode, unwittingly pairing and authorizing themselves while you are chasing your own cat around the house.
If the system has a screen UI, the user may need to choose from a list which devices should pair. Some additional method of authentication, such as entering or comparing PINs (see Bluetooth pairing options), may be needed. The user may need to give a device a name or configure it to work with particular system functionality (see Figure 12-34).
Once paired, the devices may be able to connect to each other automatically in the future when in range, or this may require explicit user interaction each time.
Figure 12-34. Pairing devices with the hub in the AlertMe system (image: AlertMe)
Devices are usually paired one by one, but if there are a lot of devices to be paired (for example, security alarm sensors) they could all be paired in one go. The searching device (in this case, usually a gateway) would be put in search mode while multiple edge devices are powered up, devices would then appear in a list as they are discovered and can be authorized from the list. If there are several devices of the same type, the user will need some way of identifying them to figure out which is which. This might be an “identify” button that flashes an LED, as used on the Lowes Iris smart home system (refer back to Figure 12-9).
Network types such as Bluetooth, ZigBee, and ZWave use device or application profiles to make pairing easier. These are software standards in the application layer of the network (see Chapter 3). They define a set of standard device/application types, and how these should communicate. Devices that support the same profiles will work with one another. For example, in Bluetooth, the Human Interface Device profile is used by mice and keyboards, the Hands Free profile is used for wireless headsets, and the SIM access profile allows devices such as car phones with GSM transceivers to use a mobile phone’s SIM to connect to GSM networks. The technology of profiles is a little different for ZigBee, but in terms of UX the outcome is similar. For example, the Home Automation profile contains a bunch of elements that determine how controls, lighting, HVAC, sensors, and security should communicate, and descriptions of the types of device that are expected. Devices that fall within the expected types should pair and work easily.
In general, good design for pairing experiences should:
§ Allow plenty of time: if discoverability or other device states timeout, ensure that the user has plenty of time to complete their task before the timeout. Bear in mind that they may be slow if they are unfamiliar with the process.
§ Minimize the amount of thought required, such as memorizing information between screens or devices, remembering long number or character strings, and inventing keys, codes, or passwords (users tend to use the same ones over and over again so they are unlikely to be unique).
§ Minimize the number of key presses or interactions, especially for devices with limited input capabilities.
§ Provide good feedback so it’s always clear what’s happening. For example, the Wink HUB LED flashes blue when pairing or removing a device, then displays a long green or red flash to indicate whether pairing has been successful or not.
§ Ensure adequate security: help users ensure they are connecting to the correct devices, and ensure sensitive data exchanges are encrypted.
Pairing devices requires explicit user interactions, because this is currently the best way to ensure that devices trust only the devices they ought to trust. But this may become a burden the more devices the user has. Some researchers are looking at automated methods of detecting and pairing with trustworthy devices. For example, a 2014 study by Markus Miettinen and colleagues investigated ways to detect trusted devices that are kept together by comparing the contextual data measured by their sensors (light and noise). But this is very early stage research.
Bluetooth pairing options
Bluetooth offers several alternative options for pairing interactions. The choice of which is most appropriate will depend on the input and output capabilities of the devices you are pairing, and the level of security required.
Pairing two devices should be quite straightforward for the user, if both have compatible “profiles” and support the same version of Bluetooth. (Profiles are specifications for different communication patterns between devices, optimized for different purposes. For example, the Human Interface Device profile provides low-latency links for mice, keyboards, and game controllers. The Heart Rate profile is designed to transmit heart rate data.)
The type of security required is determined by the profile. Some profiles, such as Object Push (which is used to send a vCard between mobile devices), don’t require any authentication or encryption as that would make the UX very inefficient and there’s no real security risk to mitigate.
Once paired, devices can reconnect automatically when in range or require explicit user interaction to do so.
Every device has a unique network address, but it is generally identified by a user-friendly Bluetooth name (e.g., “Pebble Watch”) in search results and lists of paired devices. The default name is usually set by the manufacturer but the user can often change this device name (e.g., to “Claire’s Pebble”) if they wish.
Some devices can only be connected to one other device at a time. While connected to one device, they will not appear in searches or be able to connect to other devices until they disconnect from the first device. For example, peripherals such as smart watches may be paired with both a tablet and a smartphone, but only able to connect to one at a time. However, the tablet and smartphone are defined as hubs, and able to connect to multiple devices. Bluetooth 4 (Smart) allows devices to act as both peripherals and hubs, so for example a smart watch could act as a hub to gather information from a heart rate monitor, while also connecting as a peripheral to a smartphone, displaying incoming calls and message notifications. (Bluetooth connectivity is discussed in more detail in Chapter 3.)
Beacons (such as iBeacons and Estimote) are Bluetooth devices, but don’t need to be paired for normal use. Beacons broadcast small data packets, which the user’s smartphone (for example) can use to triangulate their location. The phone does not send any data in return. (See Chapter 2 for more on beacons.)
The “just works” approach (see Figure 12-35) is used when one or more of the devices pairing are not capable of displaying (or allowing the user to enter) a six-digit PIN or passing information via another channel (see Out of band pairing). This is commonly the case for embedded devices such as activity trackers. The user searches for devices on a screened device (such as a smartphone), selects the desired device from a list of search results, then connects. Pairing is complete.
Figure 12-35. “Just works” pairing
If both devices have displays and some kind of input mechanism, the responding device may ask the user to confirm that they wish to accept the connection from the initiating device. In Figure 12-36, an iPhone has initiated a search for a Pebble watch. To complete the pairing, the user must tap “pair” on the iPhone screen, but also press the up button on the Pebble watch.
Figure 12-36. The iPhone/Pebble “just works” Bluetooth pairing confirmation
The numeric comparison approach (see Figure 12-37) can be used when both devices are capable of displaying a numeric passkey. It adds an extra step of security (and where there are multiple devices in the vicinity, helps users ensure that they are pairing the correct ones). As in the “just works” flow, the user searches for discoverable devices from the initiating device (in this example, searching for nearby smartphones from a car), then (if there is more than one) selects the one to which they want to connect. The responding device asks the user to confirm that they wish to accept the connection, then both devices display a six-digit passkey and ask the user to confirm that these are the same.
Figure 12-37. Bluetooth numeric comparison pairing
This approach can be used between a device with a display only and one that can accept numeric input, or two devices with numeric input. In the former example, the display shows a six-digit code to the user, which must be entered on the keypad on the other device. In the latter, each user must enter the same six-digit number.
In Figure 12-38, a Renault Laguna car dashboard displays a PIN to be entered on the phone as part of the pairing process. (This is an older standard, using a four-digit PIN. SSP uses a more secure six-digit PIN, but the method is the same.)
Figure 12-38. iPhone and Renault passkey entry pairing
Out of band pairing
The out of band (OOB) method uses a non-Bluetooth channel (such as NFC) to exchange pairing information (see Figure 12-39). This provides greater security than a “just works” approach, but is simpler for the user than entering a passkey (and suited to devices that may lack keyboards). The user chooses the “add device” option on the initiating device. Both devices must have NFC (or the alternative channel) enabled. Passing the two devices within range causes them to exchange data. They can either automatically be connected, or confirmation may be required from the responding device.
Figure 12-39. An example of Bluetooth out of band pairing via NFC: a user might pair his phone to an exercise bike in a gym to capture information about his workout
IoT products and systems may do all kinds of things. But there is a common set of interactions needed to get and keep them up and running. At least some of these are likely to apply to your system. Some of these, like getting devices connected and pairing, may need to be designed around certain technical standards and requirements. For others, there may be more flexibility. There are some common approaches, but the field is not mature enough yet for design patterns. There is definitely scope for innovation!
A good setup experience helps users all the way from getting things connected to getting real value out of the system. There are technical requirements around getting things connected and pairing that will strongly influence this part of the interaction design. You may be able to simplify this, perhaps supply some things preconfigured, and try to provide a flexible process that allows users to complete steps in different order. Ensure the whole experience of setup works coherently, from presales expectation setting to packaging, print instructions, device labeling, and UI guidance. Don’t forget to help users configure the system to work the way they want, and remember that they may need to come back and reconfigure things later.
All systems will need at least some in-life housekeeping functions, such as device management, notification and message management, user management and system maintenance. You may need to think about ways of organizing controls: what do you prioritize, how do you group them, how do commands flow from one device to another, and how does the user keep on top of everything that’s happening? And if your system is public, you’ll need to think about how users discover it and understand what to do. There aren’t any hard design patterns for these yet, but it’s worth being familiar with some common approaches... and then thinking about ways to improve on them.
Platforms are the basis for building systems that support multiple applications. To ensure a consistent and coherent experience across the different parts of your system, you will need to identify and design some common UI components.
Case Study 5: BRCK: Rugged Portable WiFi Hotspot
BY JEFF MAINA
Designing the Setup of the BRCK
What is BRCK?
“The BRCK is like a backup generator for the Internet.”
The BRCK, shown in Figure 12-40, is a rugged, self-powered, mobile WiFi device that connects people and things to the Internet in areas of the world with poor infrastructure, all managed via a cloud-based interface. The BRCK was designed and prototyped in Nairobi, Kenya by the team who also created the Ushahidi platform for crowdsourcing crisis information.
Away from the world’s most wired urban areas, connectivity and even power can be unreliable. The Ushahidi team realized that what they really needed was a smart, rugged device that could connect to the Internet any way it could, hop from one network to another, create a hotspot for multiple devices, while plugged in or running on battery power.
The portable BRCK is a small, physically robust device designed to provide Internet connectivity in places where power and reliable data may not always be available (see Figure 12-40). It can switch seamlessly between Ethernet, WiFi, and 3G/4G mobile phone networks, to provide a reliable local WiFi hotspot for up to 20 other devices. The onboard battery can power the device for up to eight hours, or six months in Sleep Mode.
The team also created the BRCK to be an onramp for the Internet of Things. It provides hardware interfaces to connect to external sensors and devices and supports IPV6.
Figure 12-40. The BRCK
BRCK is used in a wide variety of settings, to connect both people and sensors to the Internet. Some IoT uses include:
§ Enabling remote temperature monitoring of fridges used to store vaccines to ensure they are maintained at safe temperatures even when power is unreliable
§ Remote monitoring of the temperature and humidity of warehouses used to store food for distribution by the World Food Programme, to ensure the food stays safe to eat
§ Monitoring remote water pumps to ensure they are fixed promptly when they break down
The BRCK’s team’s motto has always been “if it works in Africa, it will work anywhere.”
Designing for BRCK
A software UI designer’s focus is only on a user’s screen. Designing for connected devices is tougher, because designers have to think of the product holistically.
The BRCK is made up of the following:
The physical BRCK
Firmware/operating system that sit on the hardware and the cloud used to manage the BRCK remotely via the Internet
Packaging box and user guide material
All this has to merge seamlessly so as to ensure the end user gets a product that’s easy to use right out of the box (see Figure 12-41).
Figure 12-41. The BRCK UX spans software, print, and hardware design
User Learning Curve
All products have a learning curve when it comes to user interaction. Some products may have a steeper learning curve—for example, those that are new in the market or reinventions of what already exists.
It’s much simpler to build a new product in a category that already exists. Users are likely to have some expectations about how to interact with it, and designers can build on that mindset.
The BRCK falls into the reinvented bracket. Conventional WiFi routers are designed for markets with reliable mains power and connectivity. The BRCK team is building a product that solves the problem of Internet connection in emerging markets using a solution that’s tailored for those environments. This means unreliable power, power surges, and a failover from “normal” Ethernet Internet to wireless 3G.
We had to look at the typical pain points people face while trying to get online, then design and build a product tailored to those needs. We had to do away with the typical stereotypes of what a router looked like and how they worked, creating a product that would be:
For when you’re mobile
Made to work where others won’t
Powered (rechargeable battery)
Thinking through power as much as connectivity
A platform to build on with software or hardware
Manage your BRCK from anywhere
The BRCK was a product that was designed and functioned totally differently from other WiFi routers. We had to communicate well in order to minimize the learning curve and make it as easy as possible to set one up.
The Unboxing Process
A year after we began the process of creating the BRCK, almost all the work was done and the first batch of the BRCKs had been shipped. Our team put a lot of attention in designing and building a product we believe will deliver a great experience. However, as with all other products, there is always something new to be learned once a customer interacts with your product for the first time.
Having interacted with the product for months ourselves, we had clear thoughts about design based on our understanding of how users would interact with what we had built. But we knew we might have to make some minor changes based on the feedback we got after running UX testing sessions at the iHub in Kenya (see Figure 12-42).
Figure 12-42. Testing at the iHub in Kenya
What we learned was that some of the steps during setup that we thought were obvious were not necessarily obvious to end users.
BRCK is a merger of hardware and software, with the setup process explained on a single A4 sheet of paper (the Quick Start Guide—the document in the packaging that explains the steps you take to set up your BRCK for the first time). While the BRCK worked great, the steps for getting the BRCK working, as printed in the Quick Start Guide, had to be thought through again.
This forced us to go back to the drawing board and solve some communication pain points that hindered users in getting their BRCKs up and running in minimal time. We needed to give more detail in the Quick Start Guide, yet not clutter the page with extra information.
What We Learned and Changed
After opening the packaging most people grabbed the BRCK, and only briefly browsed the Quick Start Guide without reading the content. It was only after they couldn’t figure out what to do that they picked up the Quick Start Guide again.
Some of the core lessons we learned from the users were:
§ They weren’t sure which side of the micro-USB cable (used to power the BRCK) went where.
§ When the BRCK was charging most thought it was ON.
§ They weren’t sure how long it would take to get the WiFi connection up and running.
After getting this feedback, wet set out a goal of minimizing the setup process time. Our goal was for users to be able to unbox their BRCK and fully register it somewhere between 10 to 20 minutes.
To achieve this, we had to reduce the steps and explain each in better detail. This doesn’t mean we had to add text: an image can be worth 1,000 words. So we decided to improve the diagrams included in the Quick Start Guide to better illustrate the steps necessary for setting up the BRCK.
We replaced certain graphics and added some in order to achieve this. Figure 12-43 shows some of the changes we made.
Figure 12-43. Before-and-after visual of the first setup steps
The status light was confusing to users when they first plugged in their BRCK. So we added a graphic to better explain this (Figure 12-44).
Figure 12-44. Graphic explaining the status light
We then set out to remove the setting of the WiFi from the registration process so as to reduce the steps.
Our greatest challenge was communicating what the status light color codes meant. The top light of the BRCK is the main physical communication point between the hardware and the user. Different states are communicated using different colors spinning and pulsing. The Quick Start Guide was printed in grayscale and we needed a way of conveying this information to our user without using text. We then came up with the color code charts.
These are business card–sized charts that visually illustrate what each color is and does (Figure 12-45).
Figure 12-45. The color code charts are business card-sized cards which illustrate what each LED state means
Figure 12-46 and Figure 12-47 show the full versions of both Quick Start Guides.
Figure 12-46. The Quick Start Guide before testing and design iteration
Figure 12-47. The Quick Start Guide after testing and design iteration
 Thanks to Gawain Edwards, Alex von Feldmann, Anders Mellbratt, Niel Bornstein, Liz Goodman, and Mike Kuniavsky.
 “‘No Fault Found’ returns cost the mobile industry $4.5 billion per year,” WDS, http://www.wds.co/no-fault-found-returns-cost-the-mobile-industry-4-5-billion-per-year/, and “Reducing Product Returns: U.S. Consumers Want More Product Information from Manufacturers & Retailers,” Appliance Magazine, October 2002: http://ubm.io/1I5Ly0W.
 In conversation.
 M. Miettinen, N. Asokan, T.D. Nguyen, A.-R. Sadeghi, and M Sobhani, “Context-Based Zero-Interaction Pairing and Key Evolution for Advanced Personal Devices,” ACM Conference on Computer and Communications Security, 2014: http://www.icri-sc.org/fileadmin/user_upload/Group_TRUST/ccsfp443s-miettinen.pdf.
 The mechanisms described here are those supported by Secure Simple Pairing, available in Bluetooth 2.1 onward, and Bluetooth Smart. For more details, including detailed interaction flows, see “Bluetooth Secure Simple Pairing User Interface Flow Whitepaper,” available from Bluetooth.org (https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=86173) and https://developer.bluetooth.org/TechnologyOverview/Pages/LE-Security.aspx for information on Bluetooth LE pairing.
 Adapted from “Bluetooth Secure Simple Pairing User Interface Flow Whitepaper,” https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=86173.
 Adapted from Part 1 of the “Bluetooth Secure Simple Pairing Using NFC” Workshop by Tore Austad of Nordic Semiconductor ASA at NFC World Congress, October 2014: http://bit.ly/1I5NsP8.
 Adapted with permission from Jeff Maina’s blog post “After the User Experience,” http://www.brck.com/2014/09/after-the-user-experience/.