Critique of Legacy Design

My strongest initial impression of the onboarding process the first time I went through it was how much friction we were throwing at users - the invasive nature of ID and photo requirements, the overall amount of clock time the flow took, etc.

The two top issues that concerned me (I had no data at this point, just intuition):

• The “quick start guide” presented early in the flow took well over a minute to read, combined value proposition messaging with a mini device-usage tutorial, and was presented right before the first friction point. Given how much more the user was going to have to do, I feared much of this information wouldn’t be retained.

• A high-friction, and long, age verification process. If everything went perfectly, the process usually took around 3 minutes, much of which was “please wait” time while the back-end age verification process completed. I felt that this “please wait” time (which in corner cases could last as long as 5 minutes) was wasted time on the user’s part and we might be able to do something better.

Design Iteration #1: AV First

The first major iteration of the onboarding design I proposed was fairly ambitious and designed primarily to improve the “time to core” metric while hopefully also raising (or at least not lowering) “conversion to core” rate.

I estimated “Time to core” would be reduced from an average of 5:15 down to about 3:00 if the following changes were made:

• Replace “gradual onboarding” with an “AV first” strategy (age verification = AV). You couldn’t really do anything in this app without being age verified, and it took at least a minute or so for the AV process to complete. So why not let the user finish some the other required steps (phone verification, account creation, device pairing, maybe a quick tutorial) while the system was waiting for the API to return AV completion success?

• Replace the old 85-second “quick start guide” with a much shorter 5-screen “welcome slider” that simply gave a high-level value proposition of what features the app had. I felt it was important to get users excited about the app before the friction points began, but did not want the user to feel obligated to remember any key details before completing the other tasks.

To help validate my ideas, I needed to put this flow in front of users. Paige Belt, JUUL’s head user researcher, offered to add evaluation of this flow into an existing research study she was planning to conduct in Vancouver, CA. I joined her for a couple of days and helped her walk users through both our live app and an on-phone figma prototype of my proposed redesign. The readout indicated a significant preference and time savings for the proposed redesign.

Many, but not all, of my proposed changes were added to the app within a few sprints once a few small revisions were made based on UXR feedback. My “AV first” concept made it into the backlog, but a large number of other high priority projects being implemented at that time took precedence.

60 Second Onboarding

In late 2019, I was asked to design an app onboarding scenario for a version of the JUUL device that would not produce vapor until the user had passed through the age verification process. My “AV First” approach was starting to look more inevitable, and it also was becoming clear that simplifying the AV process itself was going to take on more importance.

I worked with Christian Kendall, our product team’s AV specialist, on a more radical proposal for what I called “60 second onboarding.”

A big presumption for this flow was that one of two things would have happen with our backend AV process:

• We could use a two-phase approach with the existing AV vendor in order to reduce the perceived AV wait time down to about 10 seconds.

  • Our AV vendor had a slightly lower-confidence API that only took about 10 seconds to return a result. We could use that result to initially unlock the device for the user.

  • We would then require that the user keep their JUUL near their phone for a few minutes while the second, higher confidence API would run in the background. If the user failed the second attempt (hopefully rarely), or took their JUUL out of bluetooth range before the result was returned, we would re-lock the device.

• If the above approach was perceived as too radical, we had a second AV vendor coming online in the next few months that was promising 30 second wait times at high confidence.

Other innovations in this flow included:

• Removing the account creation requirement (it would be offered as an option once the device was activated)

• Removing the tutorials and welcome screens altogether

• Continuing to use the “AV First” approach

While our radical approach to AV was not implemented, we did actually build a version of the app that used this approach, but only for iOS, and it never saw the light of day as Apple never approved any of the app versions submitted by the JUUL team.

This version of our iOS app was also one of the rare times our design team was allowed to “color outside the lines” a bit in terms of brand.

2020 Onboarding

Due to issues that had nothing to do with the design, JUUL made major changes to the strategy they wanted to make for device activation. However, the product team liked my general “AV first” approach and by early 2020 there was a clearer indication that we would eventually be using a vendor with a much faster AV wait time.

The design that was implemented over the next several months, and which is mostly live in JUUL’s Canada and UK Android apps as of May 2020, took the “AV First” approach and cleaned up / optimized many of the sections of the flow.

A lightly edited video of this flow can be seen at the top of this page. Below are some of the additional improvements we’ve been able to make.

The “Sit Tight” Carousel

v1 of the JUUL app simply gave a generic “please try again” message, which must have been exasperating to a user who had waited 3-5 minutes to get their result. I worked with Jason Yonker on the engineering team to get a better understanding of what we could tell users to do based on what the API was returning.