Moving Beyond the Screen for the IoT User Experience

What Does Hybrid User Experience Mean?

The idea of a hybrid user experience needs a couple of clear definitions to understand. We must define what we mean by UI and UX as they relate to both software and hardware in isolation, and the specific conversation they create when we’re talking about IoT devices.UI/UX for software: This is a non-physical space in which users typically provide an input, and receive an output on a digital screen. This space is only limited by what can be rendered into pixels on a screen, and can be updated iteratively, and theoretically scale infinitely. UI/UX for hardware: This is a physical object that users, or other physical objects, interact with to accomplish a task. This type of UI/UX has physical limitations (physics, manufacturing, etc.), and as a rule of thumb, cannot scale unless it has been developed modularly – a manufactured product can no longer be added to, and it is non-extensible.

When we are discussing an IoT user interface, we are talking about the shared methodologies for interacting with the software and hardware portions of the product. This includes both the interface of the IoT application or software and the physical connected device, as we work to translate things from the digital world to the physical world, and back again.

The IoT user experience, meanwhile, is about the interaction between the user and the entire product, regardless of whether it’s software or hardware.

Whether you’re designing software, hardware, or marrying the two within an IoT product, UX is concerned with understanding why users are doing something. In the broadest of terms, UX is the conversation that designers and development teams have to find new ways to deliver value to users.

This conversation is ever-evolving as business requirements change, or as new data reveals more optimized routes for users to accomplish their tasks. This conversation matters for IoT-connected solutions specifically because it gives teams the opportunity to optimize data from the software and hardware sides of an IoT product to create more meaningful interactions for users.

Translating UI/UX Between Software and Hardware

Traditionally, UI/UX has been equated to software as a map for users to follow through a digital environment. For hardware, the focus was more on the physical form and industrial design. But because IoT combines software experiences with connectable hardware, it’s crucial for product development teams to think about UI/UX in new ways as a strategy for delivering new types of value to users. You have to ask questions about the IoT product experience, like:

• What is the IoT experience like in isolation of each part of the product-software and hardware?
• How and why do those pieces work together?
• What new interactions can users have that result from the communication of software and hardware?
• How do we add new functionality to a pre-existing physical product without rebuilding it?
• How is all of this ultimately packaged as a single product experience?

For example, say you’ve got a power button on a screen in a mobile app, and you’ve also got a button on the accompanying physical hardware that accomplishes the same task – to toggle the power of the connected hardware on and off, and to alert the user of that change in state.

When the user interacts with the button in the mobile app, the user is going to receive some sort of UI update indicating that the power state has changed. This can be a number of things, but for this example let’s assume a color change paired with a string of text changing from “On” to “Off.”

On the hardware side of things, when the power button is pressed the same sort of pattern should be observed here too. There needs to be some method of feedback to update the user that the power state has changed. Traditionally, we may see an LED light turn itself off to indicate the IoT device power is off.

The feedback is the same, albeit delivered in two unique ways. The important thing here is that the app and the hardware are actively communicating with each other, and updating to the same state as the other signals a change.

If one portion of the IoT product fails, we still need to receive real-time feedback from the other to continue to provide value to the user. Sometimes this feedback is as simple as a message on a screen that reads “Failed to connect. Check that device is plugged in.”

If communication breaks down between software and hardware, at most only half of the IoT product experience can still be had by users. In most cases we want this still functioning half to be the hardware, but if the hardware does fail we’re afforded a new opportunity with accompanying software to help fix things.

A non-communicating product is only useless if it can not be reported on and diagnosed for repair. Luckily, in the IoT space, we can leverage the other half of the conversation (software) to help diagnose the one that has stopped communicating, providing users with valuable data on how to restart communication, and continue on with using their IoT product.

Traditional Hardware Products Haven’t Been Friendly Communicators…

Traditional hardware products haven’t been friendly communicators because they were not designed to be, and were possibly limited by the technologies available when they were produced.

Traditional hardware products have only ever needed to accomplish the tasks they were designed for, which means no communication with other types of products was perfectly acceptable. Nowadays, we have the option of evolving the functionality of hardware as the need arises, thus giving products a longer lifespan. This affords opportunity for users and manufacturers alike.

For users, a longer lifespan means more user engagement, more personalized experiences, and also new ways to incorporate products into one’s life. On the business side of things, longer shelf life can signal a lot of opportunity for engaging users’ resources with new types of product accompaniments and programs.

That is a whole other conversation, but it’s worth noting that it signals for a new type of product strategy to solve for.

The biggest design challenge in helping hardware become a good communicator is defining a pattern for physical feedback (the LED light for example) without ever assuming that the functional requirements of the software will remain exactly the same tomorrow as they are today.

We must design for this type of future-state translation at the same time we design for what is applicable today. This is definitely not an issue for all IoT products, but one we take special care when solving for hardware that needs to show feedback visually.

Why UX Design Should Be Part of Your IoT Product Strategy

All of these considerations for the IoT user experience are best implemented from the beginning of your project, instead of scrambling to make things fit together on your final manufacturing run. The design of your software, the design of your connected device, and the way that they interact should factor hugely into your product strategy and evolve together as you test your product.

If you’re looking for a team with a deep understanding of the IoT experience, Very’s IoT development services are a great fit. Reach out to us today and let’s talk more about your project.