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.

 

 

 

 

 

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

  3. The level of hype around the “Internet of Things” (or IoT) is getting a bit out of control. It may be the technology that crashes into Gartner’s trough of disillusionment faster than any other. But that doesn’t mean we can’t  figure things out. Quite the contrary, as the trade press collectively loses its mind over the IoT, I’m spurred on further to delve deeper. In my mind, the biggest barrier we have to making the IoT work comes from us. We are being naive as our overly simplistic understanding of  how we control the IoT is likely going to fail and generate a huge consumer backlash.
    But let’s backup just a bit. The Internet of Things is a vast sprawling concept. Most people refer to just the consumer side of things: smart devices for your home and office. This is more precisely referred to as Home Automation but to most folks, that sounds just a bit boring. Nevertheless, when some writer trots out that tired old chestnut:  ”My alarm clock turns on my coffee machine!”, that is home automation.
    But of course, it’s much more than just coffee machines. Door locks are turning on music, moisture sensors are turning on yard sprinklers, and motion sensors are turning on lights. The entire house will flower into responsive activities, making our lives easier, more secure and even more fun.
    However, I am deeply concerned these Home Automation scenarios are too simplistic. As a UX designer, I know how quixotic and down right goofy humans can be. The simple rule-based “if this then that” style scenarios trotted out are doomed to fail. Well, maybe fail is too strong of a word. They won’t fail as in a “face plant into burning lava” fail. In fact, I’ll admit that they might even work 90% of the time. To many people that may seem fine, but just try using a voice recognition system with a 10% failure rate. It’s the small mistakes that will drive you crazy.
    I’m reminded of one of the key learnings of the artificial intelligence (or AI) community. It was called Moravec’s Paradox:
    It is comparatively easy to make computers exhibit adult level performance on intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception and mobility.
    Moravec’s paradox created two types of AI problems: HardEasy and EasyHard.
    HardEasy problems were assumed to be very hard to accomplish, such as playing chess. The assumption was that you’d have to replicate human cunning and experience in order to play chess well. It turns out this was completely wrong as a simple brute force approach was able to do quite well. This was a hard problem that turned out to be (relatively) easy.
    The EasyHard problem is exactly the opposite: a problem that everyone expects to be simple but turns out to quite hard indeed. The classic example here is language translation. The engineers at the time expected the hardest problem was just finding a big enough dictionary. All you had to do was look up the words just plop them down in perfect order. Obviously, that problem is something we’re still working on today. An EasyHard problem is one which seems simple but never….quite….works…..the….way….you…..want.
    I claim that Home automation is an EasyHard problem. The engineer in all of us assumes it is going to be simple: walk in a room, turn on the lights. What’s the big deal? Now, I’ll admit, this rule does indeed work most of the time but here are series of exceptions that break down:
    Problem: I walk into the room and my wife is sleeping, turning on the lights wakes her up.Solution: More sensors: detect someone on the bed.
    Problem: I walk into the room and my dog is sleeping on the bed, my room lights don’t turn onSolution: Better sensors: detect human vs pets
    Problem: I walk into the room, my wife is watching TV on the bed. She wants me to hand her a book but as the the room is dark I can’t see it.Solution:  read my mind
    Don’t misunderstand my intentions here. I’m not luddite! I do strongly feel that we are going to eventually get to home automation. My point is that as an EasyHard problem, we don’t treat home automation with the respect it deserves. Just because we can automate our home doesn’t mean we’ll automate it correctly. The real work with home automation isn’t with the IoT connectivity, it’s the control system that will make it do the right thing at the right time.
    Let’s take a look at my three scenarios above and discuss how they will impact our eventual solutions to home automation.
    1. MORE SENSORS
    Almost every scenario today is built on a very fault intolerant structure. A single sensor controls the lights. A single door knob alerts the house I’m coming in. This has the obvious error condition that if that sensor fails, the entire action breaks down. But the second, more likely, case is that it just infers the wrong conclusion. A single motion sensor in my room assumes that I am the only thing that matters, my sleeping wife is a comfort casualty. I can guarantee that as smart homes roll out, saying ‘sorry dear, that shouldn’t have happened’  is going to wear very thin.
    The solution of course is to have more sensors that can reason and know how many people are in a room. This isn’t exactly that hard but it will take a lot more work as you need to build up a model of the house, populate it with proxies, creating, in effect a simulation of your home . This will surely come, but it will just take a little time for it to become robust and tolerate of our oh so human capability to act in unexpected ways.
    2. BETTER SENSORS
    This too should be soon in coming. There are already sensors that can tell the difference from humans and pets, they just aren’t widely used. This will feed into the software simulation of my house, knowing where people, pets and things are throughout the space. This is starting to sound a bit like an AI system, modeling my life and making decisions based on what it thinks is needed at the time. Again, not exactly impossible, but tricky stuff that will, over time, get better and better.
    3. READ MY MIND
    But at some point we reach a limit. When do you turn on the lights so I can find the book and when do I just muddle through because I don’t want to bother my wife? This is where the software has to have the ‘humility’ to stop and just ask. I discussed this a bit in my UX grid of IoT post: background swarms of smart devices will do as much of the ‘easy stuff’ as they can but will eventually need me to signal intent so they can cascade a complex set of actions that fulfill my goal.
    Take the book example again. I walk into the room, the AI detects my wife on the bed. It could even detect the TV is on but still know she is not sleeping. But because it’s not clearly reasonable to turn on the lights to full brightness, it just turns on the low baseboard lighting so I can navigate. So far so good, the automatic system is being helpful but conservative. When I walk up to my wife and she asks for the book, I just have to say “lights” and the system turns the ‘lights on” which could be a complex set of commands turning on 5 different lights at different intensities.
    Of it may not be voice commands, they too have issues. A classic button or even a gesture will also work. These ‘intent cliffs” are needed because human interaction is too subtle to be fully encapsulated by an AI. Humans can’t always do it, what makes us think computers can?
    SUMMARY
    My point here is to emphatically support the idea of home automation. However, the UX designer in me is far too painfully aware that humans are messy, illogical beasts and simplistic if/then rules are going to create a backlash against this technology. It isn’t until we take the coordinated control of these IoT devices seriously that we’ll start building more nuanced and error tolerate systems. They will certainly be simplistic at first but at least we’ll be on the right path. We must create systems that expect us to be human, not punish us for when we are.
    Share this:TwitterFacebookGoogleGoogle+Scott Jenson

Comments are closed.