Get a link to read and download your free copy of our eBook here!
Chapter
5
UI & UX
So far we’ve covered the sensors/devices that are out in the world collecting data and performing actions. We’ve covered the connectivity that enables those sensors/devices to send data to and receive data from the cloud. And in the previous section we saw how that data is ingested and transformed to provide valuable insights and automate processes.
But for any given IoT system, there needs to be a way of interacting with it. And just as we saw with sensors/devices, connectivity standards, and IoT platforms, there are many options you can pursue depending on your specific application and business needs.
“We live in a time full of opportunity for imaginative individuals. In our lifetime, we will witness the emergence of more and varied forms of human-computer interaction than ever before.” - Learning and Thinking with Things by O’Reilly Media
Users need a way to view and understand the data captured by IoT. That’s where the user interface comes in. In the simplest terms, a user interface (UI for short) is the means by which a user and a computer system interact. Many think of UIs as just software or apps on phones and computers, but a user interface could be anything from a smartwatch to voice-controlled Amazon Echo to the buttons on a smart tractor dashboard.
Apple pioneered the first graphical user interface (GUI) in 1983 with the introduction of Lisa. A graphical user interface is a visual way of interacting with a computer using items like buttons, windows, and icons. This meant that people didn’t have to learn complex command languages to interact with computers and thus made the computer more accessible to everyday users. When they made the leap to touch interfaces and smartphone technology in 2009, Apple helped to further open up the door for new types of interfaces.
When it comes to mobile interfaces, there are a few important distinctions that you should be aware of:
Native apps are what most people think of when they think of mobile UIs. Native apps are applications that you download directly onto your phone. The advantage of native apps is that you have greater access to the phone’s capabilities and can create a better overall user experience (we’ll talk more about user experience below). The disadvantage is that they can take more time and resources to build, particularly because you need to build for both iOS and Android (iOS is the operating system created by Apple for iPhones and Android is an open-source operating system from Google) since they’re not compatible with each other.
Like a website, a web app is accessed by going to a certain url (e.g. https://examplewebapp.com). However, while websites are largely informational (like Wikipedia), web apps are built to have certain functionalities (like controlling a device remotely). The advantage of web apps is that they can work on both iOS and Android because you’re just using a web browser instead of actually downloading something. Also, because you don’t need to download anything, it can make it easier to get into the hands of users (just send them the url link). The disadvantage is that you have somewhat limited access to the phone’s full capabilities (like the inability to send push notifications) and less control over the overall user experience.
As the name implies, hybrid apps are between native apps and web apps. You still download something, like a web app, but when you open the app it is essentially opening a web page meaning that it can act like a web app. This can be a good option if you know you’ll be creating native apps eventually, but you want to get a minimum viable product into the hands of users early, and can therefore benefit from the speedier development offered by web apps.
The above distinctions are for mobile apps, but as we mentioned above there are many different types of user interfaces beyond just mobile.
Let’s use Nest as an example to show how user interfaces have evolved past phones and computers.
In the picture on the left, you can see Nest’s thermostat. It’s controlled by touch, displays relevant data, and it’s connected to the internet. It is therefore a user interface because it’s a way in which a human interacts with a computer (i.e. setting the temperature). On the right, we have Nest’s App, which is a native app like we covered above. Both of these are user interfaces that must be designed to suit their specific medium and user’s needs when interacting with that medium.
User interfaces are constantly evolving, with entirely new interfaces made possible by technology. In 2005, Blackberries were cutting edge technology. Now, we have voice assistant interfaces entering our homes with Google Home and Amazon Alexa. Technological change will continue to enable new ways of interacting with objects and IoT systems, but each of these ways will still be a user interface.
Returning to our Nest example, both of the interfaces pictured are only part of the overall user experience of Nest. Per designer and author Don Norman, user experience is, ““all aspects of the end-user’s interaction with the company, its services, and its products.”
For Nest, that’s everything from their native app and website to the actual thermostat and the packaging it comes in. It’s the user’s journey from the moment they make an account, to buying the thermostat, to opening the package, to installing it, and to every other interaction they have with it after installation and until they get eventually get rid of it. This includes things like notifications and alerts, which are critical pieces of many IoT systems and count as part of the overall user experience.
The most universal example of a designed user experience is the Apple store. Every interaction, every product placement, every interior design choice, has been chosen to provide you with the best Apple experience. The staff are called geniuses, the wait area has the latest apple gadgets, and the most expensive products are front and center. All of this is by design.
The important takeaway here is that user interfaces do not exist in a vacuum. As you’re pursuing your specific application, make sure to consider who your users are and every step of their overall interaction with your system.
In the next section we’ll examine some best practices as you approach UIs in IoT
In the last chapter you learned what a user interface is and what user experience means. But just having a UI isn’t enough. No matter how incredible your underlying technology (be it hardware, connectivity, or software), if humans can’t easily access, control, and interact with your IoT solution, it will fail. In this chapter we cover some of the key considerations for the UIs and UX of your IoT solution.
Although this may seem like an easy question to answer, the implications are often more complex than you might realize. This is because you not only need to identify who the different users are, but then you need to determine how each user can and should be able to interact with your IoT solution.
For example, let’s say that you have an asset tracking application that places trackers on thousands of vehicles on an auction lot so you know exactly where they are at all times. You want employees on the auction lot to be able to set geofences so they can get an alert if certain vehicles move outside of those areas. But do you want all of the employees to be able to set those geofences? It could get pretty confusing if dozens of employees are all setting their own geofences. So you might want to have an admin user who can take actions like setting geofences and adding contacts to get those alerts, and then a regular user who has more limited access to features.
However, as you put this IoT solution in place, you realize that you can add a lot of value if you open this up to your dealers and transporters. They may not be direct employees of the auction lot, but if they can find their cars directly, they won’t need to bother your employees to do so. But to provide this to the dealers and transporters, you’re going to need to make this information publicly available. Can your competitors use this information to gain an advantage? Could bad actors use this information to steal vehicles? Again, you need to consider how these public users should be able to interact with your IoT solution.
User stories are an extremely useful tool for gaining clarity here. A user story is a sentence that takes the form: “As a [role], I want [feature] so that [reason]”. Though it may seem like unnecessary work, taking the time to write out as many detailed user stories as possible is well worth it.
Many IoT solutions provide the majority of their value passively rather than actively. As we saw in the example above, it’s much more valuable to get notified when cars move where they shouldn’t, rather than having to manually check each car to make sure it’s where it’s supposed to be.
Although alerts and notifications aren’t necessarily a part of your UI (since the user might be getting an alert outside of your UI, like in a text or email), they are still a crucial part of the overall user experience. When do users get alerts (One minute after a trigger event? One hour? Can the user configure this themselves?) How do users get alerts (email, text, push notification, phone call)? What happens if a user doesn’t react to an alert in a certain period of time?
Much of these considerations circle back to who your users are and how they can and should be interacting with your overall IoT solution.
Many IoT solutions use a dashboard to provide the user with information and insights. These dashboards need to be responsive, which means they work on whatever device, browser, or operating system that the user is using.
You’ll want to do extensive testing across different browsers like Chrome, Safari, Firefox, and Internet Explorer; different tablets like the iPad and Microsoft Surface; and different phones including varied models of iPhones and Androids. By using a responsive design system, your dashboard should work flawlessly across all of these. In the mobile age, users should be able to access their information anytime, anywhere.