Behind the Design: Optimizely’s Mobile Onboarding
A lesson in managing corporate communication and hidden stakeholders
In November 2014, Optimizely officially launched A/B testing for iOS apps. Our product had been in beta for months, but the team didn’t feel that it was ready for a general release. To get over the finish line, we focused on building an MVPP — a Minimum Viable Product we’re Proud of — which we wrote about previously. A key piece of the MVPP was designing a new-user onboarding that made a complex and technical process feel smooth and easy for a variety of users.
A user’s onboarding experience sets the tone for the rest of your product. It’s your first opportunity to impress or disappoint, to create excitement or trepidation. The usual advice for designing user onboarding—show the value of your product as soon as possible — is solid, but it’s also hard to follow when your onboarding hinges on something as technical and time-consuming as installing a software development kit (SDK).
Among other things, the Optimizely SDK determines which version of your A/B test a user sees, so you can’t use our product without installing it. The installation itself isn’t particularly complicated, just embed some code and a unique, account-specific identifier into your application and you’re good to go. What’s hard about SDK installation is that the people doing it are often on a different team or in a different part of a company from the people actually using Optimizely. Cross-team communication can be hard, and delays will leave new users with a product they can’t use right away.
In designing the onboarding for Optimizely for Mobile, I couldn’t get rid of SDK installation, but I could help mitigate the pain by designing the onboarding flow to accommodate multiple entry points for the various stakeholders, working to make SDK installation as easy as possible, and providing visibility for all users at each stage of the onboarding process.
Multiple paths, same destination
One of the first questions I faced was whether to divorce the SDK-installation instructions from the main onboarding flow. While some portion of our users would install the SDK themselves, we suspected that our target user — a mobile product manager — would likely be passing the work off to a development team. This created a fork in the onboarding flow: the PM needed an account, but not necessarily the SDK instructions, while the developers needed the SDK instructions, plus the unique identifier assigned to the end user’s account. Finally, everyone involved in the process needed to know that SDK installation was a critical step to actually using the product, something our current dashboard wasn’t doing a good job of conveying.
To better understand how the SDK-installation process happens in the real world, I worked with our user-research team to interview several people who approximated our target audience: app developers or marketers who hadn’t used our product, but who were interested in A/B testing mobile apps.
We discovered something interesting: while the person signing up for an account may not be the one to install the SDK, he or she may still want to evaluate the installation process. A long or complicated installation meant that potential customers had to justify their decision to use Optimizely more strongly. The developers installing the SDK were not our end users, but they were stakeholders in product adoption nonetheless.
Ultimately, I gave users a choice between viewing the SDK instructions or emailing them to someone else, and made it easy to move between the two options. Sending users through SDK installation by default accommodated what our research suggested was the most common path through the onboarding flow, and also reinforced that SDK installation is a critical step in the onboarding process.
Designing for indirect stakeholders
Many product interfaces are carefully designed for end users, but often fail to consider the developers whose work makes that use possible. Thanks to user research, we knew that developers were influential in successful product adoption, so I worked with our mobile product manager to redesign the SDK installation process until we felt that we had the simplest, least painful process we could feasibly design. We removed and condensed steps and ran people of different technical abilities through the instructions until we could confidently call the process “easy.”
To reduce friction even more, we embedded the unique, account-specific identifier directly into the instructions that end users emailed to their developers. This way, developers could access all the information they needed without having to sign up for yet another service.
Providing visibility
Despite our efforts to smooth the process, SDK installation can still take weeks. Giving end users visibility into the status of an installation is another way we support the multiple stakeholders involved in the installation process.
The first time you build your app with the Optimizely SDK installed, we ping our server to confirm that we’re seeing your application, which indicates that you’ve installed the SDK correctly. That confirmation shows up in a status bar at the bottom of the SDK-installation instructions, as well as in the end-user interface.
This feature has several benefits. For the person installing the SDK, it’s an easy way to be sure everything is working properly. For the end user, it’s a way to see whether the SDK has been installed just by pulling up Optimizely. For the Optimizely team, it’s a great way to track how many people creating accounts are making it past SDK installation during the onboarding process.
Detecting SDK status also allows us to tailor the content on the overview page to help move the users to their next step. A project with no SDK detected offer users access to installation instructions and help docs, as well as articles with advice about developing testing strategies (somthing the user can work on while they wait). A project with an SDK detected prompts users to create their first experiment, and also offers an article with easy test ideas to get customers started.
When you can’t get around a lengthy and complicated step in the onboarding process, it becomes critically important to get every other aspect right. By accommodating multiple entry points into the onboarding flow, working hard to make SDK installation clear and easy, and providing visibility into each stage of the onboarding process, we were setting up new customers to succeed. We continue to improve on our onboarding as we hear from customers, but I take it as a good sign every time another company goes live with our SDK without our help!
