Janine Richartz — DesignerHow to start
Defining the challenges and problems when starting the concept for an IoT onboarding is a good approach to the UX concept. At the beginning, important questions to find an answer for, are
- Who will use your product/application in real life?
- Which technology will be used best for achieving your goal to bring your device onto the internet? (Depends also on the environment where the device will be installed)
- How to explain to the users in an understandable way how to connect that device to the internet?
An option to get these answers would be to do some research. At first define your target group and give your users a face. Let’s imagine you have to concept an onboarding to bring a smart home gateway into the internet which will control an heating.
Define your target group and give your users a face.
Start by imagining which different personas will use that gateway and then try to really understand these people. Know what they need and which problems they have with the current workflow and onboarding. For example: Probably heatings in a house won’t be installed by their owners. In most cases there will be an installer who will install the heating and so the gateway, too, because the gateway has physically to be connected to the heating.
But honestly, do you know how an installer is working and installing heatings right away? So the best method to get to know that is to visit and accompany installers for heatings, who will later use and have to install your smart home gateway in their everyday work life, and see how they usually do their everyday work. That turned out to be a valuable method to really learn what the users need. In case that a gateway will be used by consumers at home (e.g. to control lightning bulbs), try to find someone who already uses smart home products which require gateways or comparable devices and ask them for their experience with onboarding and using the devices. The most important thing is that you are certain about the persona which will later use the product and has to configure it and which problems they might face.
Bluetooth, Wi-Fi, WAC? — Good tool, half work!
After specifying the target group it’s important to quickly make a decision on the technology which will be used to onboard the device onto the internet. At that point the user’s needs should definitely be in the focus. If the onboarding isn’t as easy and understandable as possible for the user there is a high risk that they will be dissatisfied or even quit the process. The challenge is not only with the technology choice, but also with the design of an easy and satisfying user flow.
We know several ways to get a device online. The most common once are Bluetooth and Wi-Fi. In most cases, even both at the same time. A stable connection between things and the internet can be achieved by bringing the device into the user’s home network. This is known, for example, from gateways with which you can control lights or heatings, or from smart home speakers that let you play your favourite songs like Google Home or Amazon Echo. Because in most cases not the product gets into the internet, but a gateway, that is connected to the heater. Important: The app or web application, via which the heating will be controlled, has to be located in the same (home) network in which the gateway is suppose to be.
For many of these devices the way of onboarding is the same or similar. Therefore, we at grandcentrix, an IoT solution provider, have created a blueprint for the different IoT onboardings. The blueprint serves as the basis for our concept work so that it can be passed on to our developers in the form of wireframes, a flowchart or clickable prototypes.
Set up the gateway
Of course, the user’s journey does not just starts at the device’s set up. At first, the gateway must be unpacked, physically installed and then connected to the power. The installer will attach the gateway close to the heater and connect both via a bus system. This bus system is used for data exchange between gateway and heating. In most cases, the gateway also draws electricity from the heater — other gateways are equipped with a main plug and require their own socket. During or after the mechanical installation of the gateway, the user must already have download the related app. The app does not only serve as an instruction manual for the IoT onboarding but also for subsequent heating-control. Generally, the App is public in the respective store. But to help users, the packaging can also include a QR code which, by scanning, guides the users to the correct app download.
Connect the App to the Gateway
Now the important part begins. In order to connect the gateway to the user’s home network, it must somehow receive the password of the Wi-Fi home network. This password is sent to the gateway via a BLE (Bluetooth Low Energy ) connection. Because as soon as the gateway is connected to a power supply, it automatically opens the pairing mode and starts with the advertising. This means that the gateway can now be recognised by the app as a gateway, that has not yet been set up and is ready for pairing. All gateways in pairing mode nearby now appear in the app.
It must be ensured which gateway is to be added to the Wi-Fi network. It is not uncommon that there are more than one gateway within the radio range of the network, so the user must select which gateway should be set up in the app, choosing from a list of all the gateways. Each gateway has a unique name so that the user can recognise it as the desired gateway. For example, part of the serial number can be included in the name of the gateway, wich should also be visible on the gateway or in the operating instructions, to be comparable. After a successfully established BLE connection between the gateway and the app, the gateway can now be brought into the home network.
Connect the gateway to the home network
The initially existing connection via Bluetooth Low Energy (BLE) wouldn’t match for the complete use and setup of the gateway, since BLE is mainly intended to transmit small amounts of data and not to maintain a permanent connection.
BLE is used for applications that do not need to exchange large amounts of data
Therefore, the gateway must now be connected to the user’s home network. For this purpose, the gateway performs a scan of the surrounding Wi-Fi networks, which are displayed in a list. This should be based on the design of the operating system on the user’s smartphone so that he or she can operate the view as intuitively as possible.
There, the user selects the home network with which the gateway should be connected. The password of the Wi-Fi network must then be transferred to the gateway. The user must enter the password in the app. If the installer takes over the setup of the gateway, the subsequent user of the application should enter the Wi-Fi password in the app himself at this step so that the password does not have to be communicated to the installer. The password is sent to the gateway via the BLE connection and the gateway can connect to the home network. In the positive case, the gateway is now connected to the user’s home network, the BLE connection can be disconnected without user interaction and the IoT onboarding is thus completed. Of course, a wide variety of errors can occur at any point, not only when typing in the password wrong. At that point, it’s particularly important to explain clearly what the users can do to solve the error. The gateway cannot always tell the app what exactly caused the error. In most cases, error screens from IoT onboarding therefore contain a list of frequently occurring, generic error cases. This includes, for example, entering an incorrect Wi-Fi password, interrupting the connection or automatically switching off the pairing mode. The user should be briefly and concisely explained what he or she can do in this case and if they don’t get ahead on their own they should be able to call up a help page or contact support.
Alternative option: Pairing button
At the point where the gateway is connected to the app, there’s another option in addition to the automatic pairing mode after plugin the gateway as described earlier. If an automatic pairing mode is not desired (e.g. for security reasons) the user can also trigger the pairing mode manually. To do this, he would press the so-called pairing button. This is a button on the gateway, which only puts the device into pairing mode when this button is pressed. In this case the gateway only then permanently sends a message via Bluetooth Low Energy that it has not yet been set up and is now ready for connection. The interface should simply guide the users through this step by explaining that they have to press the button on the gateway for further setup. Visual support by depicting the pairing button as a photo, animation or graphic helps the user to find it and supports a positive onboarding experience, see the following examples:
Alternative option: Wi-Fi-Hotspot
An alternative to pairing mode via Bluetooth Low Energy is to open a Wi-Fi hotspot. After the mechanical installation of the gateway and physical connection to the heater, the gateway automatically opens a Wi-Fi hotspot. (Alternatively, the hotspot can only be opened by pressing the pairing button.) In order for the app to be able to connect to this hotspot, the users must switch to the Wi-Fi settings of their smartphone and manually join the hotspot network there. As soon as the connection to the hotspot is established, the user can enter the Wi-Fi home network password and this will be sent to the gateway via the hotspot. Since the user left the app to enter the hotspot and switch to the smartphone settings, this way is not as suitable from the user’s point of view as connecting via Bluetooth Low Energy. By switching the apps, the user is torn out of the onboarding flow and the experience is suboptional. The Wi-Fi hotspot is just another way to send the Wi-Fi password to the device and an alternative to BLE mode. Arguments for Wi-Fi hotspot and against BLE could for example be the design of the chip on the gateway’s hardware.
Digression: Send Wi-Fi password on iOS (Apple wireless accessory configuration)
Even the easiest and fastest IoT onboarding faces a challenge for the user. This is entering the Wi-Fi home network password. Probably everyone knows it: the Wi-Fi password is not just long but also predestined to typing errors. Since it usually consists of many numbers and / or letters, it is often annoying to type and enter it or even to find it, until you don’t use it that often.
Therefore there is a special support for this step on iOS devices (only). The so-called Apple wireless accessory configuration (WAC) makes this step easier for the user by reading out the Wi-Fi password from the iPhone if it has ever been connected to the desired network. The gateway automatically opens WAC mode when it is set up for the first time. At the point of onboarding, where the user normally has to enter the Wi-Fi password, the accessory configuration (WAC) opens immediately. This collects information about the surrounding Wi-Fi networks and WAC devices.
In the first step of setting up via WAC, the accessory configuration found surrounding devices (the gateway) and surrounding Wi-Fi networks that had not yet been set up. Since the user is usually already connected to the home network with his or her iPhone, this network will be preselected. The user must select the device which is about to set up and the gateway receives the Wi-Fi password of the selected network via WAC and can connect to it. The user does not have to enter the password, neither he or she has to leave the app because WAC can be opened in a modal dialog within the app. The password is read from the iPhone because the user once has already set up the connection to the home network on this iPhone.
In order to use WAC, however, the gateway must be MFi certified.
Unfortunately there is no comparable procedure from Android itself until now.
From the user’s perspective
The user should not only be guided through the onboarding easily and quickly but also in an understandable manner. Since the technical background overwhelms easily or doesn’t interest the most users, it is important to create a good balance of information and instructions. Especially important are concise headlines, which give the user a quick overview of which step is being carried out. My experience as a UX designer for IoT products, also conducting several user tests, have often shown me that users only skim over texts and even sometimes skip them completely. Long texts and complicated explanations are more of a hurdle for the user and should be kept as short and precise as possible. This applies in particular to the headings of the screens. Short but meaningful headlines such as “Find devices” or “Push pairing button” have proven to be helpful and user-friendly. Supporting graphic elements such as graphics, illustrations or animations also help the users to set up the hardware and make it easier for the them.
Another finding from user testings was that users prefer visual confirmations as soon as a significant part of onboarding has been completed. For example, if the connection between the gateway and the app was successful. In the event of a fault, providing visual feedback is of course all the more important. In addition, it is also helpful for the user if the various states of onboarding are also indicated by an LED on the gateway itself. The establishment of a connection could be signaled, for example, by a flashing LED on the gateway while an existing connection by the permanent lighting up of this. Responding lights should also be included in the concept for the onboarding.
Takeaways
Finally, I would like to summarise the most important findings and helpful tips to create a successful (IoT) onboarding concept:
- Analyze and research the exact target group of the IoT device and get to know the potential users
- IoT onboarding should not be a long, complicated or technically described process
- Short and concise headlines and texts
- Supporting graphics, illustrations, animations
- Visual confirmations, for example after a successful connection
- Provide suggestions for solutions in the event of errors and offer the opportunity for further help (support, hotline, etc.)
- A demo mode, in which the use of the application is simulated and can be tested using sample data, can show users the most important features of the app even without having an associated IoT device