Win a free ticket to the 2020 IoT Innovator Summit in Austin, TX.

Subscribe to our blog to get the latest articles straight to your inbox.

Design is the best strategy for ensuring that your users are fluent in the interactions and communications between software and hardware in an IoT experience. When designing your IoT user experience, there are a few things you should keep in mind.

How is Design Different for an IoT Experience?

Designing for IoT is a process worth investing in because you’re ultimately planning to create a frictionless experience from the app, to the device, and back again. This is most successful when there is a system of shared design principles and behaviors between the software and hardware.

The design process for IoT starts by observing how each side of the product (software and hardware) needs to communicate with the other, as well as how each side functions on its own. These observations are used to inform the methods of user feedback on either side, and to create new types of product features you are incapable of producing when working with just one side (e.g., power consumption data visualized for a user).

You may hear the team at Very talk a lot about the idea of an IoT Product Experience being the sort of intangible feeling of fulfillment a user walks away with by experiencing both sides of IoT in tandem. It is important that each side can stand on its own to provide value to users, and also is an additive for the shared experience when put together. If you aren’t making at least one better through this relationship, then it may be time to rethink your product strategy.

Design Can Extend the Lifespan of Your IoT Product

The easiest way I’ve discovered to explain the additive value of design to connected devices is to talk about the role of communication and the physical hardware.

Traditionally, once a piece of hardware is manufactured, it will no longer be able to grow as users' needs do. However, when a connected device is manufactured with a custom hardware + firmware + software strategy, it is designed to be updated, and you are already affording yourself the opportunity to make adjustments in the future.

You don’t have to know what these opportunities are at the moment of manufacturing, but you should at least have a strategy for discovering them. Things like data collection and analysis for the physical device, and users’ interactions are massive parts in deciding what comes next.

To facilitate the extended product experience that IoT technology makes possible, we have to understand how software and hardware communicate with each other. This happens through two major pathways:

  1. Hardware state displayed as digital feedback in software
  2. Software controlling hardware state

To make effective use of these pathways, we have to find a shared language between digital feedback and physical hardware outputs. You can start to define this language through design systems, establishing behavior norms, and identifying the types of interactions you’re managing.

Design System: A shared set of design principles that work across mediums to communicate the intent of the product. Creates a known entity for users to engage with, regardless of whether they’re on the software or hardware side.

Behavioral Norms: How does the experience feel, and how does it change when an action is carried out? Look for consistent patterns to enforce the behaviors for which you’ve designed features.

Types of Interactions: What utilities need to be carried out via software, what utilities need to be carried out via hardware, and what utilities can be accessed via either?

Hardware Testing is Not Really a Thing

One of the fun things we’re learning at Very is how we can apply the concepts of user testing and iteration to software as well as hardware. Testing hardware is more difficult to do compared with software because hardware has physical costs, like materials, manufacturing costs, and production time. We can update software 10 times in one week if we need to. Hardware presents more challenges.

Say we’re designing a power button. We should probably design it to resemble something we’re familiar with, like a switch or toggle. While viewing the power button in isolation makes sense from an industrial design perspective, there are still a lot of other questions we need to answer to make sure we develop an accessible user experience across hardware and software, like:

  • Where does this switch need to live?
  • How big does it need to be?
  • How quickly does it need to react?
  • How could it possibly break in the environments where it’s going to live?
  • What other outside factors are going to influence a light switch flipping on and off?
  • How can we signal this back to the software?

Sometimes, you’ll encounter a situation where you want to do something with the software, but there’s not a feasible way to translate it into a hardware feature. At that point, you have to shift your paradigm a little bit back to a more traditional UX mindset, which is okay and also the easiest way to test adding new types of value for users.

 As long as the hardware is accomplishing its main task, you can always extend functionality in new and wildly different ways with software. Examples might include analytics reporting or monitoring energy consumption, using the sensors that are already in the connected device.

Make User-Centered Design Part of Your IoT Product Strategy

A big part of creating an effective user experience, especially as hardware relates to connected devices, is having an open and flexible product strategy .

For example, I was the designer on the Koller Smart Tank app. For that project, we started the software design and the hardware design pretty much on the same day.

We had an idea of what we needed to accomplish. We knew we needed a piece of hardware that turned lights on and off. And we needed a smartphone that controlled that hardware. But outside of that, we didn’t really have much definition for features past what we’d defined for the minimum viable product (MVP).

Going into a project with loose definitions around the features worked to our advantage for software and hardware because we were able to develop them in tandem. The software and hardware teams could collectively decide what we wanted the user to be able to achieve, and think about how the hardware and software could work together. 

The best part was that we had room to iterate on both parts because the hardware was running companion firmware. We created the opportunity to add new functionality to the physical IoT product after business requirements were updated, and as we collected some data via analytics and user testing.

Why You Need Design for Your IoT Product 

IoT design has all of the constraints and challenges present in traditional software design, with an added challenge of building an extended product experience outside of a screen. Wherever your IoT project takes you, make sure you’re investing in UX professionals who understand the unique aspects of IoT design to deliver the best customer experience. 

Interested in learning more about IoT development? Download this free guide to get everything you need to know.