UXGrid_small

Deconstructing IoT Part 2
In a previous post, I had a modest goal of introducing a simple functional vocabulary for smart devices. Too many journalists were discussing science fiction scenarios about swarms of devices without realizing that there were much simpler, yet very valuable alternatives. This post moves into user experience, proposing a simple grid of types. There are of course, many ways to break things down, this is just one that I’m finding useful. I hope this prompts a discussion of other approaches. If you have any suggestions, please let me know.

Device vs Style
This UX Grid is a classic 2×2 matrix of device type vs interaction type. Solo vs swarm is on the vertical axis and a direct interaction style vs an ambient background styles on the horizontal. I’ll discuss each quadrant in turn.

DirectDeviceDirect Device
This is the primary product concept we use today, products like the Nest, or Sonos, or the iGrill, or the Withings Scale (you get the idea…) are devices you interact with directly using a dedicated application on your phone. Mike Kuniavsky was the first to point out that the internet of things was unleashed primarily as the smart phone ecosystem has grown. Smart phones enable two very powerful things: 1) offload the cost of complex UX hardware (such as a touch screen) and 2) Extend the distance we can interact with a device. These make it much cheaper as easier to add functionality to a smart device.

But this Direct Device model is really only an extension of what we’ve been doing for 30 years. We, as an industry, have almost exclusively worked on direct devices, from VT100 displays, to web pages to smart phones. We don’t mess around, we go mano a mano with our devices: it’s a very direct and physical approach. While the interaction details have certainly changed, the basic model of one person, one device has not.

There is nothing at all wrong with this. I’m only making the rather obvious point that it is the dominant one. By exploring the other three quadrants, we can discuss and explore alternatives.

DirectSwarmDirect Swarm
Now this is a very different beast. Instead of talking directly to a single device, you interact with a swarm of devices. The most straight forward example would be smart lighting systems such as Phillips Hue. You push a button and dozens of light bulbs spring to life. That is a simple fan out of control where one command effects many devices.

Apple’s iBeacon is already proposing applications that flip this approach around. Take for example a restaurant that has put a cheap Bluetooth LE box under each customer table. When a customer opens their phone, they don’t want to see dozens of devices in the store, but a single unified application. They just order their food and pay. The restaurant figures out which table they’re at through the Bluetooth boxes and delivers it to the correct location. This feels like a Direct Device but is implemented as a Direct Swarm. To the customer, it’s not even clear there are other devices.

Another example would be a museum where you wander from exhibit to exhibit. As you open the phone you always use the ‘museum app’ but what is on your display is the exhibit you happen to be in front of (or a list if there are a few to choose from)

What is unique about the Direct Swarm is that in order to be direct, it needs a single point of contact for you to interact with, a ‘master device’ that represents the others. This interaction is, in effect, a virtual Direct Device, built out of the many individuals in the swarm.

BackgroundDeviceBackground Device
Now we move into the background axis, exploring what it is like for a device to work automatically without direct interaction. The first wave of devices in this category were ambient displays, like the Ambient Orb, Nabaztag, or more recently Blink1. These devices try to embed information in your environment so they are just there when you need them. No interaction required, you just notice.

But we are starting to flip this type of device from output to input. A device that can detect actions and just do the right thing automatically. This is what smart doorlocks like the original Lockitron aspired to be but couldn’t. You had to walk up to your house, open the phone, open an app, and push the ‘unlock’ button. A perfectly direct approach but clearly not very convenient. It was built on the Direct Device model but secretly wanted to be a Background Device. You’d much rather just walk into your home as if it were unlocked.

But the new Lockitron is taking advantage of Bluetooth LE’s proximity model to automatically unlock the door when you get close (and automatically relock it when you walk away) This is promising and getting much closer to the true nature of a Background Device. It monitors activity and attempts to do the right thing.

The move from output to input for Background Devices will be tricky. It is far too easy to get false positives and do things at the wrong time. This is likely a huge area to learn and explore as we build more of these devices.

Notice that these device categories are a bit fluid. When you first buy a Lockitron, you’ll likely use it as a Direct Device to set it up, but once it is configured you then use it as a Background Device. That is the purpose of the UX Grid, it allow us to discuss how the same product can have multiple types of behaviors at different times.

BackgroundSwarmBackground Swarm
This is the hardest type of product to build. It is also the one that most journalists love to talk about. The ‘smart house’ that raises and lowers temperature, opens blinds, and even makes coffee. Devices in this category are likely composed of many types of devices, some just sensors, others actuating doors or lights. We will be effectively programming with hardware. Our machine language will be these devices that can read and write into our physical world.

We will get there but if you thought there were issues will false positives in the Background Device category, you ain’t seen nothing yet. When an entire house or industrial floor can have a bug and open and close doors at the wrong time, all sorts of problems can occur. While this category is still nascent, one thing is very clear: you want this collection of devices to ‘just work’ without significant interaction. This means no surprises! These things need to cooperate and coordinate in ways that feel smart and respectful.

Key UX Pattern: Offering instead of doing
Over time, Background Swarms will eventually feel like they are reading our minds and doing the right thing. However, in the short term, I’m quite sure we will discover all sorts of disastrous false positives that will create some backlash in this category. It’s so tempting to think we can create rules or triggers to make everything magical. People are complex, quixotic beasts that defy logic and fixed rules. We define ourselves by our exceptions. At least initially, we are going to have to be a bit more conservative, designing systems that ‘offer’ instead of ‘do’. A system that sets things up, prompting the user to complete the action with as little effort as possible.

So for example, instead of having the lights go on when you walk into the house (and thereby waking up your cousin sleeping on the couch) have the system gently turn on the floor lights so you can navigate in the dark but a voice system waits for you to say ‘lights’ before actually turning on the main lights.

In the case of Lockitron, while the bluetooth trick may work, a more robust approach would be to detect your arrival and prep the door but to not actually unlock it until you touch the doorknob (using a capacitive and/or vibration sensor). That physical interconnect is a much higher value signal that you want to enter the door and aren’t just, for example, walking by.

Background Swarms that meet me half way, bring the functionality I need to my attention but wait for me to actually pull the trigger are likely to be the most robust way to approach smart devices design. It still gives the user power but keeps them firmly in control.

Conclusion
These four categories of smart devices: Direct Device, Direct Swarm, Background Device, and Background Swarm are just a basic, slightly artificial breakdown. As I pointed out, products can even move between these types from setup to actual use. But they do provide us a better vocabulary and way to discuss.

Direct Devices are dominant model so far and we need to break out of that approach. It’s also clear that false positives are going to be a significant growing pain. So many products are going to think in terms of clunkly rule based systems and attempt to build background products that will fail rarely but spectacularly. If we want to build background devices, we need to start with offering and then build up slowly to doing. The world of smart devices is dazzling, the potential is there but what’s holding us back isn’t technology but our ability to know what to do with it.

 

 

 

 

 

11 thoughts on “UX Grid of IOT

  1. I was intrigued by your suggestion of meeting half way, which while not good for all use cases definitely ought to be thought about for a given application. It kind of removes the cockiness and inserts a sense of humility.

    • Exactly. Right now we are in a situation where companies are taking a fairly naive ‘condition/trigger’ approach which is fairly fragile. The idea of trying this more, as you say, humble approach really just highlights how hard it is to get autonomous systems right.

  2. Brilliant post Scott. I loved your UX grid, and also your suggestion of meeting half way. I am sure you are familiar with the notion of intelligibility, which advocates that systems are intelligible (or scrutable) to allow users to understand “what the systems know, how they know it, and what they are doing” and should put end-users at the center of control by empowering them to better co-ordinate, control, and personalize systems. It would be interesting to know how you feel about this.

Leave a Reply