Building Better User Interfaces (UIs) for IoT Systems

IoT products can be quite complicated and designing them well is tricky. Here are 6 tips to help you create the best possible product for your customers!

974
Power button on a purple geometric background
Illustration: © IoT For All

A mental challenge to get us started: how do you get your customers to pair your shiny new device to their phone?

  • Nope; sorry, no touchscreen.
  • Sorry, it only has one button.
  • Again, no screen. Just a couple of LEDs. Cool?

Ok, maybe that was easy for you. Now, how does the user unpair it? Trigger a function or three? Pair it to your WiFi? Factory reset? Put it into airplane mode? Etc.

With minimal user inputs, this can be a challenging product decision. One that many companies get wrong. Some over-rely on the app, which is fine until a new phone breaks the flow. Others create elaborate press schemes that are nearly impossible to follow.

  • If your product requires me to press it seven times within 3.4 seconds, I will throw it away.

Start With a List

When I first started building products, I did what made sense: code a few options in there, and we can add more later.

Pairing, cool, got that. Un-pairing too? Oh function one, cool added that. Wait you want a second function? Um, maybe I can add a long press to get that. No, two presses.

And it goes downhill from there. In the end, I had to refactor the whole button code, rethink the user experience and start over. Because I didn’t start with a plan.

It doesn’t even have to be a full plan. But start by writing down all the functions the device needs to do. Create a table with a row for each function. Ask your team for more. Look at other products, buy competitor’s products and set them up and learn, ask friends and customers.

As your list grows, you might be surprised how many things are on it. Even for simple devices like smart home sensors, it can have almost a dozen operations. And that’s ok, we can now simplify.

Documentation Isn’t Bad (Usually)

In my more recent products, I added this list to the Product Requirements Document (PRD) to capture and consolidate the button functionality. And nearly every reviewer has complained about how “complex” it is.

To be honest, it makes me giggle a little when I see it. Not because I’m clever or dislike feedback. But, I know that most of the people reviewing it haven’t seen all the functionality of other products in one table.

Take a look at two products I own and use:

GE ZigBee Light Switch

  • Single press top to turn on
  • Single press bottom to turn off
  • Press top button ten times to unpair
  • Press the top button three times then the bottom once to toggle the blue LED when turned off
  • Press and hold either side to adjust brightness on dimmer version

FitBit Charge 2

  • Single press turns on the screen (if it’s off)
  • Single press changes the screen menu (if the screen is on)
  • Long pressing on the main screen turns notifications on/off
  • Long press on other screens starts the timer, activity or other functionality
  • Single press while charging shows the battery level
  • Double press button to turn off the silent alarm

I’m not calling either out in any way here, but is it surprising how “complex” they look all listed out?

  • That’s the point: if it looks overly complicated in your documentation, how will this look to your customers?

As they say, recognizing the problem is the first step to creating an excellent product.

Simplify the Experience

First, a quick disclaimer: I haven’t built your product nor am I disclosing any innovative secrets here. Instead, I hope these thoughts cause you to pause and think about your product. Please make it better; I might be one of your customers, and I like easy to use things.

Simplifying the functionality table can start in a couple of different ways. Pick one to start, iterate with a second and make up a third for your use case. The idea is to simplify and document.

One is to create a column for where the function is triggered, meaning how many can be done from the app or cloud only. But think about this for a moment, if the user doesn’t have their phone, is the function impaired? How many need to be physical buttons only? Things like the Bluetooth pairing or turning it on. Separate out the list and focus on the ones that use human interaction.

A second way is to group them by the functional state such as moving, charging, sleeping or pairing. A button press could mean something different if the security system is armed, perhaps it triggering it, whereas a single press when unarmed merely flashes the LED. But, this example also illustrates what can break too. What if the user didn’t know the system was in an armed state? The functionality for individual states should be apparent and not a cause of added confusion.

Another is to group by what should be harder to do. Things like a factory reset or setting off an alarm need to be intentional. These can be your more complicated interactions since they happen rarely or the customer expects them to be intentional. You could try long presses, maybe over ten seconds, or perhaps four short presses in quick succession. This leaves the more common use cases to simple interactions.

Sometimes you need to add another button or input. Even Apple, famed for their simplicity, has three physical buttons and a switch on the iPhone. If it becomes clear that a single button isn’t enough, add another with care.

  • When your user manual says “press the X button,” is it clear which button it’s referring to?

Adding a label to the device solves some of the confusion, but always think beyond the typical use case. How would a visually impaired person or someone who can’t read your language distinguish the options? Adding buttons can make specific functions simpler, but adds new challenges to overcome.

Try it, Break it, Fix it

One of the best pieces of advice I’ve received is: try it and see what happens. Use an Arduino, PlayDoh and duck tape if needed. But make it simple and make it something you can quickly change. This way you can see if you like it.

  • If you don’t like how it works, then change it!

Yup, that simple. And then have your team try it. Have your mother and brother try it. Have your kids try it. But only explain the minimum they would know if they read a user manual. Maybe even sketch one up with a Sharpie and printer paper.

Sit back and watch. Do they press the buttons quickly or push hard? What do they do if nothing happens? Take notes and learn. Go back to your desk, make changes and try again. Always remember that customers are humans, humans who press buttons and tap widgets much differently than you.

Now, go forth and build better products!