The post-launch success of an Internet-of-Things (IoT) product depends on attaining high levels of mental understanding (cognitive trust) and emotional connection (affective trust) from your users. Cognitive and affective trust in the IoT product is essential for end users to deem a product dependable, reliable, and worthwhile. Achieving a high level of trust will result in high perceived quality and usefulness leading to reviews, recommendations, and continued success.
The primary method of interaction with an IoT product is generally via a web or mobile interface on a smartphone or tablet. Being the primary interaction interface, the mobile experience often defines the overall IoT product experience and is essential for building both affective and cognitive trust.
Building a functional mobile interface that controls the product and then simply adding intelligence or notifications is not sufficient to build trust. The methods in which information, controls, abstraction, automation, and design are presented to the user are of utmost importance in developing trust. In the following sections we will take a brief look at these areas and point out how improvements can be made to take your IoT project to the next level.
Many IoT products fail immediately after the user's initial period of excitement. This failure is often attributed to the user interface being too complicated, time consuming to use, or the product being untrustworthy. Users have a very low tolerance for managing IoT product and expect them to "just work." For this reason, minor technical issues or interface imperfections result in the discontinued use of IoT products, ultimately damaging user and public trust. For a user, spending even a couple minutes fixing an issue may be too high friction for the user to overcome. Mobile UX and its lasting effect on product trust cannot be overstated.
Often when creating physical IoT-enabled products, companies spend the majority of their budget and time on the physical feature set and industrial design. Mobile control of the product is usually regarded as a secondary design process for monitoring or controlling the device. In many cases, this can lead to a short-lived life of the product and decreased satisfaction by the device owner. After the initial novelty of owning a connected product wears off, a user has less tolerance for product complexity and time-intensive methods of controlling it via a mobile device. In these cases, users revert to the immediacy of the physical control instead - removing the main advantage of creating an IoT enabled product. By being aware of the following UX considerations, you can ensure users retain perceived value in your IoT offering and remain satisfied with the product experience.
Information about the IoT device is viewed by a user at two different times: first, when they want to affect the system and second, when they want to understand what affected the system.
In the first case, the information most often needed is the real-time state of the device. Once the state of the device can be assessed, the user can decide how to affect the system to achieve their desired outcome. Because the user is trying to perform an action, the information presented should be brief and contextualized. This will allow the user to digest the minimal information required to make their action plan quickly before executing.
The second case is one of trust. A user may want to view the current and past state of the device to confirm everything is operating as expected or to understand what happened when their expectations have been violated. The latter situation means the user has already lost some trust in the system and is trying to regain trust by gaining additional insight into how the system works. If a user is willing to spend this much time in diagnosing the system, they may be receptive to additional information about how the system works, and this may be a good time to provide additional insight.
Many IoT devices are unable to resolve control changes immediately. For example, it may take several hours for the fluid level in an IoT pump control system to change in response to a command. Providing a simple control to set the desired level of the tank is functional, but doesn't provide any status information to the user. Without being able to see the current status, a user may have their trust violated when they walk to the tank and it isn't yet at the set level.
Displaying text of the tank's current level near the tank level's control is both functional and informative. A user can now watch as the values slowly converge. The user can then make an estimation on how long it will take to reach the set point.
A side effect of providing users with this information is that they tend to try to over-adjust the system in an effort to achieve convergence more quickly. For example, they may try setting the level higher than the actual desired level hoping the pump will work faster. One one of preventing this is providing additional information on how long it will take the system to resolve the discrepancy between the user's set point and its actual value. This can be done textually with a time estimate or visually through the distance between two elements. Another method to minimize a user over-adjusting the system is by including the convergence discrepancy into the design of the control. For example, a user may be forced to drag a set point physically further away from the live value on screen, reinforcing the temporal distance change needed for the two values to converge.
Abstraction in user experience is key to helping users understand and control IoT products.
When it comes to controlling an IoT system, there is a fine balance between providing users with a lot of information and the bare minimum. On one hand, providing only the raw data to the user will often overwhelm them, forcing them to invest large amounts of time to understand how to control the product. On the other hand, oversimplifying the data doesn't provide the user with enough information to determine how modifying the controls will affect the system.
A proper level of data abstraction can often be obtained by explaining abstract concepts (such as "hot", "cold", or "presets") with iconography while providing only the most pertinent low-level data (such as current temperature in degrees).
If large amounts of low-level data need to be presented to the user, it is recommended to use a Focus-Plus-Context (FPC) interface. A FPC interface provides a detailed view of a specific portion of the data (what is relevant to the current user's location, the current time, past behaviours in similar situations, etc.), while keeping the remaining data abstracted.
Much care must also be taken in presenting information and controls for a group of multiple devices. The user must have a clear mental model about what each group data point means for each single device, as well as how changing a group control affects an individual device. This can become very complex when an interface also provides scheduling and scenes for multiple devices. In these cases, it can be useful to provide the group data at a high level of abstraction and provide a convenient way to view the low-level details of the status of each product in the group. If schedules are needed, it can often be clearer to provide schedules as a per-device control where scenes are able to change the settings of multiple devices at once, rather than the concept of grouping the devices themselves.
Although an IoT product may have great information presentation, controls, and abstraction, it is hard to achieve affective trust without clean user interface design. A good initial design will set the tone for overall trust with the product, while a bad initial design can degrade the perceived quality of the hardware and its dependability. Although design tastes will change depending on product application, the general design should work towards preventing over-cluttering by use of whitespace and professional, meaningful graphics.
A tradeoff also needs to be established between replicating the physical interface in virtual form and creating a completely abstracted, new interface. Dials and knobs may make sense for physical controls, but they do not always translate well to virtual controls.
Generally, retaining simple items which are similar in both the physical and virtual interface (such as terminology, colouring, and control grouping) provides enough similarity that the two interfaces will feel connected and fluent.
Automating control of a system can provide much convenience to end users but it must NEVER be done at the expense of user understanding. If a user cannot understand why a physical device is performing the way it is, they won't consider it to be smart - they will consider it to be untrustworthy and overly complex. Often too complex to use.
When a device or automated system is about to make an adjustment based on an automated process, it should first explain to the user what the adjustment is, why it wants to make an adjustment, and obtain consent to do so. If the system is able to do these three things, the user will gain additional understanding, and a certain level of trust will be formed.