Smart-home UX Heuristics
DISCLAIMER: Some links on this page might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. However, there is no additional charge to you! Your purchase help me continue to provide you with dope free content!
What does building home automations have in common with building websites?
User Experience
How we interact with digital content and physical ones is largely influenced by the experience they offer. Of course, there are exceptions, but they do not make the rule. A UX designer I worked with recommended a website called the Laws of UX where it explained over 20 different design principles, heuristics, cognitive biases, and gestalt that influence how we as humans interface with the world. Often time when developing new features questions around user interaction come up “Will users know how to find it”, “Do they know that pressing this button affects this element over here”, or “Does this user flow make it easier for them to solve this problem”. Some of the answers can be found in surveys, historical data, and consultation but I find that the principles found on this site provide a clear approach without being too prescriptive. Building a smart home requires a similar line of questions: “Will my family or guest be able to use this automation”, “Do they know that pressing this smart button affects this device over here”, and “Does this automation make it easier to solve this issue”?
Smart Home User Experience
Unfortunately, there’s no consolidated source for smart home user experience principles that could do the same for smart home creators like what the Laws Of UX did for me. This is what prompted me to create the Smart-home UX heuristics. The following principles were created based on observing my family’s interaction with various parts of our smart-home for over a year as well as anecdotes from others who post their own smart-home experience online. These heuristics are not battle-tested tested so this blog will update the principles as more information is presented.
1 - Assistant
An automation should add value without requiring more from you.
Smart-home automation is supposed to make tasks easier for the occupants. A common comment you hear in the smart-home niche is that automation is supposed to be invisible and provide value. This heuristic echoes this sentiment and asserts that users should not have to do anything extra to gain value from automation.
Example:
You want to track whether or not mail was dropped off or collected without having to go check the mailbox. You add a door sensor to the mailbox so you know every time the mail box is opened. Unfortunately you can’t tell whether the mail is dropped off or being checked by your spouse. To solve this you can either:
A - Add an NFC to the mailbox for you and your spouse to scan whenever either of you collect the mail to mark it as complete.
B - Use some other smart-home device like doorbell camera or front-door sensor to get confirmation of whether or not a family member picked up the mail.Resolution A
Though it is straightforward (and pretty cool), because it requires more from the person pick up the mail, it’s not sustainable. Even though the effort of scanning the NFC is really small, it’s still something extra and I find that people just don’t care enough.
Resolution B (Preferred)
This is more complex, but you or your family will never have to think about it or do anything different. You still get alerts when mail is delivered and by using, for instance, a door bell camera, your notification can have a snapshot so you can see who was at the mailbox.
Adding some nuance
I should call out that this heuristic subtly implies that automation should not change a user’s behavior. While this is mostly true, the nuance is that automation that requires a behavior change must be intentional and intrinsic to the automation’s purpose, like, for example, an automation that reminds you to wash the dishes. Where you would most likely forget, this automation is designed to provoke a different behavior. Automations like these are fine but must be used sparingly.
2 - Insider Knowledge
Automations should not require special knowledge, special codes, or aspects that need to be memorized in order to be used.
This does not apply to security-based automation. In general, automation should require very little from the users. Where the assistant principle refers to limiting additional physical requirements, the insider knowledge principle limits the cognitive mental load requirement.
Example:
You want to have a visual indicator letting the members of the house know when laundry is completed. You add sensors to the washer and dryer so you track when each is in use or done.
A) You have an individually addressable RGB strip light in the washroom so you create a color code for each state: Blue means clothes are washing, yellow means clothes are drying, green means complete. The light strip will split the lights in half if the state color differs so both blue and yellow will show at the same time if both devices are running.
B) alternatively you create a single notification that fires when the washing machine or dryer is done. This notification is sent to your phone and is broadcast on the smart speakers throughout the house if people are home and are at an appropriate hour. If no one is home the message is stored lo calling in ”voicemail” and played once the family is home again.Choice A
This automation gives too much information and requires your family to remember the different meanings behind the colored lights.
Choice B (Preferred)
This is preferred as the state of the clothes isn’t really critical and the notifications can be delayed. Please understand that I am not saying that using colored lights for laundry or signaling is bad! This principle simply highlights that you should strive to make your automation as intuitive as possible.
3 - Anti-Ambiguous
Automations should not introduce ambiguity.
If you walked into a house and the lights suddenly turned red, what would you think? Red intrinsically signals that there is something wrong. Though you would be confused you with intuitively know something may not be right. Imagine if the lights turned blue or purple what would you think? You would be more confused than alarmed. Similar to insider knowledge, anti-ambiguous asserts that automations and their triggers should not introduce more questions. More specifically, automations should actively try to provide clarity for the occupants.
Developers can spend weeks to months writing code for a specific feature. They become intimately knowledgeable about each line of code and can fix issues quickly. But there typically comes a point where the code goes untouched for weeks until a new feature comes along and introduces a bug. It’s a running troupe that devs forget what they write and ridicule the code just to later learn this was their code all along.I bring up that story because your smart home will be the same. You’ll create automation that may not receive a lot of traffic, but after a few months when it activates again, you’ll scratch your head wondering “What does this light mean” or “How many times should I press this button to deactivate this notification”? Your automation should provide clarity to make it easy for even guests to react. For example, if you use colored lights to express danger, it would be helpful to include a message clarifying what the light means and possible next steps. If you have a smart button by the door, it should be labeled to clue in the users what the button might do.
4 - Fail-Safe
Manual analogs of an automation should still be available
This is another common principle you’ll hear in the smart-home niche. The example often given is smart-switches vs smart-light bulbs. Smart-light bulbs require constant power so the wall switch must be on at all times. If someone turns off the switch, the smart bulb disconnects from your smart-home. To increase reliability, some smart-home owners disable the switch behind the plate, cover the switch with tape or implement some other way to keep the switch in the on position. This heuristic addresses this concern and other situations like it. Another example is smart-blinds that retro-fit over existing drawstring blinds. These devices prevent users from manually opening the blinds. If a guest is sleeping in the room or power goes out, the blinds are near useless. This principle is usually the first one people learn about as this is a common problem in the smart-home space.
5 - All or nothing
If an automation cannot run by itself 100% of the time without being annoying, then users should be able to easily opt-in or out without violating any of the other rules
Some automations provide value by making assumptions about human behavior. For example, if you walk into a dark room, you will 99% of the time turn on the light. In the 1% where you don’t want to turn it on, it’s usually still ok if the light turns on since you have to see. Of course, there are times when you want to make sure the lights don’t turn on, for instance, not wanting to wake your spouse, but I find that these automations typically take these edge cases into consideration. The Aqara FP2 can not only detect presence but it also senses light. Using this sensor along with a time condition, you can create an automation that turns the lights on only when it is dark, during a certain window of time, and only when presence is detected. The conditions around this automation make it so well-balanced that this automation can safely run 100% of the time without negatively affecting the user experience. However if an automation cannot safely run 100% of the time without negatively affecting the user experience, then a user should have the ability to easily enable or disable it.
Let’s say you have an automation that shuts down the house, sets the alarm, and plays soft music whenever you plug in your phone at bedtime. This automation works the majority of the time but on the nights when your phone’s battery is low and you’re having a late night, then you don’t want this automation to fire. You need a way to quickly disable and enable the automation The subtlety to this is that seamless automations that use innocuous triggers (plugging in a phone, playing/pausing Apple TV) are not the easiest to remember when you should disable. This heuristic requires much care when providing opt-in/opt-out features.
6 - Accessibility
Automations should only present themselves to users who have the ability to use it otherwise it should stay hidden.
This heuristic is best explained using a recent automation I was trying to fix.
I have an Apple TV and created an automation that toggles the lights when playing/pausing videos. When a video plays, the lights turn off, when the video pauses the lights turn up. However, I don’t want this automation to fire every single time. For example, this shouldn’t happen during the middle of the day and there are times at night when I just want the lights to stay off. In an attempt to fix it, I thought to use an NFC tag. To let people know that this automation exists as an option, Home Assistant would announce only once that you can tap your phone on the NFC to toggle the lights. I liked the idea, but it makes a lot of assumptions.
Will the person watching have their phone on them?
What would happen if my kid wanted to watch the TV?
What if I had a guest that wanted to watch the TV?
Additionally, to make this automation work for my wife, I would have to program her phone to trigger a webhook or install a home assistant on her phone to trigger the automation (she has an Android). The accessibility principle focuses on ensuring automation makes itself known to the user only if it is certain the user can take advantage of it. Using an NFC, introduced too many scenarios where the user would be unable to use the automation.
7 - Perfect Timing
Automation should be well-timed and contextual to prevent becoming a “pest”
This heuristic was inspired by channel member @makrini. When creating automation that update based on some dynamic condition, all human interactions with the automation should be well-timed to prevent over-communication or unreliable results.
My smart-home devices go offline often, so I created an automation that sends me messages whenever critical devices go offline. When a tracked device goes offline home assistant will send a message to my phone and leave a message in voicemail. Since the automation polls the state of the devices every hour, I get about 15 messages a day about the same devices. This automation has become a pest and I often ignore it at this point. A better solution would be to send the initial notification the first time the device goes offline and then every subsequent day, I get a single message outlining the issues and the length of time it has gone unresolved.
Final Thoughts
These rules are not battle-tested so some may be deleted, some may change and others could remain the same. The idea was to document these concepts and see if my lessons learned could translate into something valuable for not only people new to the smart-home niche but also provide clarity to concepts that veterans of the space instinctively recognized.