Designing the Opus Onboarding Experience

Getting Users Up and Running ASAP

Onboarding new users can be a make or break moment for your products user retention. Get it right and you are well on your way to creating a habit forming hook for new users. Fall short, and they may never touch your product again.

For the Opus platform, onboarding was a hot button topic that went through a myriad of iterations during the prototype and beta phases of the product.

Disclaimer:

**Due to a non-disclosure agreement, some content and unique identifiers have been excluded or obfuscated. All information in this case study is my own and does not reflect the views of the company**

My Role:

For this project, I led the initial customer and market research, experience design, visual design, user testing and organized QA testing efforts. Additionally, I worked alongside a lead front end developer and members of our business development team who assisted with user testing.

Challenge:

The team’s goal for our Onboarding experience was to get our new users active on the platform as quickly and efficiently as possible.

Initial Insights:

After doing some initial market/competitor research, referring back to our existing user personas and conducting phone interviews with a handful of our early adopters the team identified a few insights that would help us get started:

The completeness of a profile was the first way a venue vetted the quality of a musician.

Many of our competitor’s utilized a complex, time consuming onboarding process.

Users did not have some of our initial content requirements like audio and video clips readily available, especially on their mobile device.

After some internal discussion, the team decided the greatest value we can provide to a new user was a complete profile that would better attract venues. However, we would need to ensure that our profile building process was as lightweight as possible and only required content users were likely to have at their disposal no matter their device.

Kicking Things Off:

With our high level goal and our profile hypothesis in hand, the team began to sketch a rough user flow and the corresponding sketches for our onboarding process. This sketches were then reviewed with some of our early adopters to ensure we had included the most relevant content in our profile pages.

After tweaking the page content and screen order based on feedback from our users, we created a more formal wireframe that was shared with members of our initial user group to ensure this new iteration alleviated the pain points our initial review had brought to light. This second session was conducted remotely using a clickable prototype created in Invision.

Our second remote testing session uncovered additional new insights and pain points on both our profile pages and onboarding flow we would need to resolve before the launch of our beta. This included:

Location information for artists was deemed unnecessary time and time again. Venues didn’t care where an artist was located as long as they showed up for gigs on time and in a professional manner and musicians believed that displaying their location to venues may prevent them from getting hired for some gigs.

Users preferred to initially communicate via email or messaging. Once a gig was booked or musicians began negotiating rates with a venue they were comfortable with phone calls, but they preferred to provide that information on their own terms.

Similar to providing their location, musicians felt that providing a musical genre would limit the type of performances venues would be willing to consider them for.

We were also able to uncover some screens, states and interactions that were missing or were sending mixed signals we knew needed to be added and approved upon when we began the visual design of our onboarding.

An Initial Coat of Paint:

Feeling confident with the onboarding process we had laid the groundwork for, the team moved on to the visual design of our first iteration. With our goal of efficiency in mind, we strove for a minimal, straightforward layout and concise copy. We also took the opportunity to further tweak the content we were including in our profile pages based on the observations gathered from our remote testing.

Some of our edits included removing some of the required information from our account info page, adding notification of our terms and privacy policy to the onboarding process, reordering the account info and account type pages so users inputted their account info before selecting an account type and informing users about why our push notifications were helpful and asking if they would allow Opus to send them.

Happy with the way the visual design of our onboarding had progressed, we moved forward with it’s initial development and implementation into our beta in order to begin collecting data from a live environment.

visual design for our initial new user onboarding flow.
Onboarding tool tip sample.

Falling Flat:

The team was excited to get our onboarding out into the wild and felt confident that we would see a rise in user growth and engagement as a result. The results ended up being quite the opposite and had a ripple effect across our other product segments.

After implementing the onboarding flow, the data uncovered the following red flags that had appeared since the implementation:

We experienced a significant increase in the number of empty state or incomplete user profiles.

Incomplete profile information was driving down the engagement on our job board. Venues and musicians posting job opportunities were seeing less engagement on their posts from other musicians.

Empty state profiles were littering the discover section of the application and users had no way to logically sort or filter them.

**To comply with a non disclosure agreement, actual figures have been omitted.** stud

Back to the Drawing Board:

With a list of new issues to solve, the team began thinking through the potential causes of our new negative user behavior and how our onboarding was influencing it. We came to the following conclusions:

The root of our problem was the increased number of empty state or incomplete profile pages. Despite our initial efforts to expedite the process, fully completing your profile was still too time consuming.

A lack of basic profile profile info we displayed on all job posts was making the accounts seem less trustworthy and decreasing musician engagement on those opportunities.

Having empty state or incomplete profiles peppering our discover tab was negatively impacting the credibility and perceived professionalism of our application.

Addressing the Issues:

The first time around we were too shortsighted when creating the onboarding flow. For this next iteration, the team was focused on being much more cognizant of the downstream effects this initial interaction had on the remainder of our product segments and developed a few hypotheses to address the issue:

Giving the Power to the People:

Building the perfect profile page was not something most users would be able to accomplish the first time using the platform. In most cases, they would either not have or be willing to spend the time it takes to build out their profile or they did not have the appropriate content needed to do so.

To alleviate this issue, once we had acquired the bare minimum information we needed we allowed users to select how their onboarding proceeded based on the highest priority jobs they would be looking to complete.

When I’m looking to discover new gig opportunities, I want to make sure my digital press kit is perfect before making an introduction so I can have the best odds of getting the job.

When I need to fill a substitute or have a gig opportunity, I want to be able to search potential talent before making an introduction so I am not interrupted by unfit candidates.

When I need to book a musician last minute, I want to be able to post the opening as quickly as possible so I can start speaking to candidates as soon as possible.

When I sign up for a new service or download a new app, I want to be able to explore independently so I can evaluate if the platform is useful before sinking more time into it.

If they had the time to spend, users could continue to their profile page. If they just wanted to connect with users or contact someone with about an opportunity, users could head directly to the discover segment. If a user just wanted to poke around, they would be taken to the job board and not interrupted with any tutorials or recommendations until they sought out help or returned to the application again.

Requiring Less Information Upfront:

By allowing users to choose from one of three paths during onboarding, there was potential for users to not even hit their profile page before interacting with the application, keeping the door open for empty state and incomplete profiles to still exist.

We solved this issue by re-evaluating the information we required a new user to input before allowing them to choose a path. Beforehand, they were required to enter three main sections of content:

Account Information

  • First Name
  • Last Name
  • Email Address
  • Password

Account Type

  • Musician
  • Venue

Profile Content

  • Stage Name/Venue Name
  • Address (if venue)
  • Instrument (if musician)
  • Picture
  • Bio

In our second iteration, we decided to only collect the information we needed to establish and secure an account for a user, identify the type of account they were registering and ensure that their account would be listed properly in all segments of the application before allowing them to choose their own way forward.

Opus Onboarding v2.0
Bitnami