The choreography of companion setup

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.

Illustration of two devices juggling symbols associated with setup, such as toggles, checkboxes, info icons, bluetooth icon, and password lock icon.

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.  

Photo (left) of a GoPro camera asking the user to install the GoPro Quick app on their phone to finish setup. Screenshot (right) of GoPro Quick app asking the user to connect and set up their camera
GoPro cameras use companion setup via a phone companion app. This companion setup experience includes using the phone app to check for and install any new firmware updates that were released after the camera was packaged.
Two screenshots. One is of the website (left side) asking if the user would like to take photos with their phone and requesting their phone number to send a URL to. Second screenshot (right) shows setup URL loaded on the phone with instructions for taking photos.
Companion setup isn’t just for setting up new devices. is a service that provides identity verification for people who want to create online accounts for services like the IRS. During its setup experience, users are given the option to use their mobile phone camera to take photos of their identity documents. handles this with a website URL sent to the user via a text message, and doesn’t require the use of a dedicated companion app.

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.   

Two screenshots of a phone companion app screen and a watch screen during setup.
To streamline setup of a new watch in the release of Android Wear 2.0 (an older version of Wear OS by Google that I worked on), companion setup was used to make it easy for the new watch owner to complete complex tasks, like transferring their account or Wi-Fi credentials to their watch.
2 photos and 1 desktop computer screenshot of Myo setup, showing how the armband device does not have any screens. The desktop screenshot shows an instruction to install updates to the armband via companion setup.
Companion setup also helps with devices that have limited input and output methods. The Myo Gesture Control armband, an older device, could only give feedback via vibration, so required the use of companion setup to get firmware updates and calibrate gestures. The packaging helped provide complementary instructions such as the need to get the desktop companion app. I covered the Myo armband in an older post on

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 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. 

Screenshot of a text message from with a link to a URL where the user can continue with parts of account setup on their phone. uses a web URL sent to the user’s phone number to initiate companion setup for document verification.

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. 

Diagram showing how two devices might choreograph companion setup across primary and secondary surfaces.
Diagram showing an example of how a new device and a companion device can be choreographed so that one gets focus and the other reflects status during 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. 

4 photographs in a 2x2 grid each showing an old iPhone's and new iPhone's screens across 4 different parts of companion setup.
Example of how two devices can be coordinated as primary and secondary surfaces during companion setup, from iPhone setup. Top left and right shows users a prompt and action on their current phone, which is the primary surface for the first two steps of setup. Then, the current iPhone hands off to the new iPhone, becoming the secondary surface simply showing status and confirmation for the rest of setup.

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.

Image showing 3 screenshots of Android Wear 2.0 setup flow on the phone companion app and on the watch screen.
This is an example of companion device choreography across the prompt, work, and follow-up of a single step in the Android Wear 2.0 setup flow. The prompt for copying accounts from phone to watch appears on the phone, while the watch reads “Continue setup on phone.” The Work (here, authenticating to confirm account transfer) is done on the phone. And then when the step is successfully completed, the phone follows up by moving to the next step while the watch shows a temporary “Accounts copied” confirmation message. 

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. 

Screenshot of website on step 1 of setup confirming a setup text has been sent to a phone number the user provided, and is waiting for them to continue setup on their phone. has invested in building responsive APIs as well as various pending states during focus handoff to help users recover in the case of an issue. For example, if the user does not receive the text message containing their mobile setup URL, they have the option to “Send it again.”


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.