It’s a bit different to doing pure software UX. You have all the challenges of pure software UX, plus some extra things as well. And the extra things tend to stem from three underlying causes.
So the things themselves, the specialised devices, are often sort of relatively low-end computing devices. They’re out there in the real world. They’re specialised to do a particular thing. They either allow us to capture data from the real world. Or they allow us to act on the real world in some way. So of course, if it’s just a low profile sensor, that’s something that might be hidden away somewhere. And you might not see it. If it’s something like a thermostat or it’s something like a lamp in your house or it’s an appliance, obviously that has a physical form. And so some of those things, obviously, have existed in unconnected forms.
But the way that we now need to design them needs to take account of the fact that they’re connected. They might need some extra LEDs on them, for example, to tell us that they’re online or offline, or they’re running low on power. So if you think, for example, about something like a thermostat or a washing machine, historically, you would buy that thing as a product, and it would do one set of things. And that functionality would never change. But it’s now possible, because as soon as that thing has an Internet connection, to deliver software updates to it, to change the functionality over time.
And so you might decide to design the physical interface in a different way to take account of the fact that functionality could change. And you might also need to check to design it differently because you might be able to control that device from somewhere else, as well. So you might say, for example, that actually, a conventional lighting dimmer switch, which you can turn up to a certain level and turn down to a certain level, if you have a smartphone app that can also control that dimmer switch, what happens if the switch is all the way down, you turn the light all the way up from the smartphone app. And then suddenly, the light is on and it’s on full power.
But actually, you’ve got nowhere to go on the physical switch to turn it down. So you might need to design some of the physical interfaces differently to take account of the fact that they might need to communicate a state that’s been set from another device. Or they might need to allow you to control them in different ways. So if you look at the design of connected dimmer switches, quite often it might be just some up and down arrows and perhaps some LEDs that tell you how far the light is on. So that physical interface is able to respond to commands from the smartphone app.
So this brings us on to things like what we call interusability. And this is the idea that if you have a system that people are interacting with via multiple devices, there’s a need for them to understand what each of those devices is doing to a certain extent, what kind of role it plays in the system, what kind of things they can do with each device, and for the interfaces on those devices to be consistent with each other to an appropriate degree, given the differences between the devices, and for any other interactions that may start on one device and flow over to others, to feel what we call continuous.
So the third complicating aspect of designing for the Internet of Things is about the Internet part, or certainly, the networks part. And this is because what happens when you put– I think people may perhaps be probably unprepared to experience some of the quirks of networking and the Internet in physical devices. So if you think about it. We all have an experience of the Internet that allows us to understand why that webpages are sometimes slow to load and Skype calls sometimes fail. And those things are frustrating. But we know that they happen. And we can understand roughly why they happen. And we have strategies for dealing with that.
When you put those kinds of behaviours into things in the world, that may sometimes feel very strange because our expectation of things like turning the lights on is that you flip the switch and the light comes on straightaway. It’s not that you press the button and then you wait 10 or 20 seconds, and then eventually the light comes on. So one of these problems of things that are inherent to a certain extent in various types of networks, like latency and reliability issues, cause some uncertainty in design, which means that we have to take account of those things in the user interface layer sometimes, and perhaps indicate that instead of, brilliant, you turned the light on.
Actually, you’ve turned the light on. And it’s thinking about it for a bit. And I’m sending that command. And now I’ve had confirmation of it. And the light is actually on. And the other thing is that many embedded devices, because they’re quite low power, often run on batteries. So a lot of these things are spending a lot of time offline. What that means is that you get intermittent data readings, or occasionally that some devices will not have caught up, will not have synced up, with the rest of the system. So one example might be that you could adjust the temperature of your heating system from your smartphone, standing in front of the thermostat.
And it might actually take anything up to two minutes before the thermostat updates with that new temperature. So you might be standing there for a while, saying, well, I’ve turned the temperature up to 21 Celsius. This thing is only saying 19. And suddenly, you’ve got two machines giving you different information about the status of the system. And that breaks some fairly fundamental principles of usability that we’ve had for a long time, that it has to be very clear what the system is doing. So again, that has a knock-on effect at the system design level. We have to think about ways of handling that.