In an earlier post, I wrote about setup wizards with tips on when to use them and how to design them. The guidance I shared in that article is extensible across every type of setup experience, but I’d like to take a moment to show how that guidance relates to a very specific type of setup experience called companion setup. In this post, I’ll introduce companion setup, when it’s useful, and provide tips on how to choreograph the flow within it.
What is companion setup?
Companion setup is when a new device or service is set up with the assistance of a secondary device or service. Some examples include:
- Using a phone, tablet, or desktop computer to set up a different type of device like a camera, smartwatch, or thermostat.
- Using someone’s current phone to set up a newly purchased phone
- Using a different website to streamline account setup for a new service
Sometimes companion setup involves the installation of a companion app on the phone or computer someone is using to set up a new device. A companion app is an app that runs on a separate device and can offer complementary or expanded features.
When companion setup is useful, and when it’s not
Companion setup is best in cases where the new device has a small (or no) screen, or when it otherwise might be tedious or difficult to complete setup steps on the new device alone. For example, if the new device or service requires inputting a lot of information that might already exist on someone’s current devices, companion setup can simplify the task by transferring the information directly. Companion setup can make the setup of new devices more accessible by offering input methods and accessibility options that are available on the companion device but not the new device.
Does this mean companion setup should be required for new device setup? No. Asking a user to coordinate setup between two devices can add its own level of complication such as managing errors, disconnection, and handoff of activities. It can also make it confusing for users to know how to troubleshoot future issues (is this issue because of the companion device I used to set this up, or the product itself?). In my book Better Onboarding, I say that we must avoid taking people out of flow during our onboarding experiences. When we add steps to our setup experiences that require users to complete tasks elsewhere, we open up the experience to confusion, error, or abandonment. Email verification is one of the biggest offenders of this issue.
If setup would otherwise already have simple steps that could all be handed on the new device or service, then runtime setup, which I covered in my previous post on setup wizards, would be better.
A caution on companion apps
We should exercise caution if we want to require the user to install a companion app for setup. Sometimes these apps aren’t really necessary even for setup, but end up laden with features that take up space and use up data on a person’s phone. They also become extra work for teams to maintain.
For example, GoPro cameras do require a companion app to help with setup, but this app is also part of many day-to-day workflows with the camera. Many users opt to use the app to sync their photos, do editing, and transfer them to their phone storage without needing to manage photo editing with SD cards. Therefore, asking a user to install and use a companion experience to support GoPro setup makes sense. And in other cases, a companion app may be necessary if the types of setup options required to use a device or service are just not available via the web or the companion device’s operating system.
However, a companion app makes much less sense for devices that truly can operate perfectly on their own. Consider Bluetooth headphones. Most modern phone and computer operating systems handle pairing Bluetooth and audio streaming by default. Requiring the user to install a companion app would not make sense for these cases.
Instead of jumping to use of a companion app, see if you can achieve your goals through a device’s operating system or a web URL. The ID.me companion setup mentioned earlier, where the user is given the option of taking photos of documents for identity verification with their phone, is managed through a URL and does not require an app.
Choreographing companion setup
When you determine that companion setup is necessary, then you can get into the design of it. The most important part of companion setup is the choreography of states and actions between the two devices so that the user knows which device to focus their attention on at any given time. This will minimize mistakes and confusion. I’ve found it’s best to designate one device as the primary surface and the other as the secondary surface at any given time.
The primary surface is the one that will be used to show instructions and take action. In most cases, the primary surface will be someone’s phone or computer. The secondary surface should only reflect status and give feedback.
If at any time during setup the focus needs to shift from one surface to another, a clear handoff moment needs to be designed. These handoffs often happen at the start and finish of setup, where someone may start on the new device or service, be told that they now need to use a companion device to continue, shift focus to the companion device, and then the companion device redirects them back to the new one to finalize setup.
For example, if someone uses their old iPhone to set up a new iPhone, they will automatically be prompted on their current phone, if it’s nearby, to use it to set up their new one. After confirming their choice by using their old iPhone to scan an authentication code off of their newer one, the person will be shown a handoff state on their old phone, telling them to shift focus to the new iPhone. At this point, the new iPhone is now the primary device driving setup, and they just need to ensure they keep their old phone nearby. At the end of setup, the two devices go their separate ways, with the user able to start using their new iphone.
Switching primary and secondary surfaces multiple times in the middle of setup should be avoided, because every handoff moment is an opportunity for error or distraction.
There is a whole chapter on cross-device interactions in Claire Rowland’s book Designing for the Internet of Things where she digs into role assignment across devices, so I recommend checking that out. Although published in 2015, much of the guidance is evergreen.
Choreography across prompt, work, and follow-up
In my previous post, I mentioned how the 3-pronged structure of onboarding actions I introduced in my book—the prompt, work, and follow-up—can be applied to an entire setup flow as well to each individual step within it.
Even where more than one device is involved, this 3-pronged framework can still be upheld. The Apple iPhone companion setup flow above shows how the two devices can work together to reflect the prompt, work, and follow-up portions of the entire setup flow: The initial prompt to set up using an existing device appears on the new iPhone with the other showing reinforcing information; the work is mainly done on the new iPhone while the old iPhone sits in a pending state; and when setup is completed, both devices show a follow-up confirmation message and next step options.
This choreography across the prompt, work, and follow-up can also be applied at the per step level. For example when I worked on Android Wear 2.0, I designed steps in setup so that the prompt, work, and follow-up of any one step was on the companion app on the user’s phone, but the watch would reinforce the follow-up states of each step by indicating successful step completion.
Reliable connections make or break companion setup
Because companion setup requires handoffs between two devices or services, it’s important that the connection technology used is reliable and that you’ve designed options in case something fails.
First, this means choosing your connection technologies well; there are, for example, challenges when it comes to selecting Bluetooth for device connections. The same applies if you’re relying on existing APIs. If you happen to be in control of the APIs you’re building, then you need to think about API design best practices.
Second, this means getting ahead of potential connection issues. If there could be indeterminate lag while waiting for something to respond, clearly indicate this at least on the primary surface and give people backup options if it seems a process has stalled. And anticipate and design for error states that give users options for restarting a setup step or taking an alternate path without losing their place in setup.
Companion setup experiences can streamline the setup of new devices and services by offering more accessible input and output options, and by expediting setup with the use of information transfer. However, it’s important to choreograph companion setup experiences thoughtfully to prevent confusion and errors. Ensure you designate one device as the primary surface for setup, and one as secondary at any given time, so that the user knows where to focus their attention. Choreograph across both the primary and secondary surfaces to guide the user through the prompt, work, and follow-up of setup steps. And pay extra mind to the frameworks and APIs used to connect the two devices.