Onboarding Teams in Evernote Business
--
In February of 2018, we released a new feature called Spaces for Evernote Business, a team and collaboration-centered offering of our consumer product. With the introduction of Spaces, Evernote Business added a new level of organizational hierarchy for teams to arrange notebooks and notes. Spaces also provided a simpler solution to share content with team members and surfaced new views for teams to keep track of updates and relevant information.
Ultimately, we were addressing the problems that many of our users vocalized, as well as strategically positioning ourselves to create a more robust, multi-player product.
Goals
Pairing up with a product manager from the Business team, I was tasked with leading the efforts to design the first time experience for Evernote Business users. More specifically, this entailed:
- Teaching teams new to Evernote Business how to use the product, with the ultimate goal of converting teams after their initial free trial
- Introducing existing teams to Spaces and helping them integrate the new feature into their workflows
- Translating the onboarding experience across all 5 of our platforms (Web, Mac, Windows, iOS, and Android)
The entirety of the design process spanned from October to December of 2018, during which I worked cross-functionally with product and engineering to define scope. I also conducted user research sessions, designed flows end-to-end, and worked with developers to ship across all of our clients by our February launch date.
Getting Started
Though the task at hand was, to say the least, overwhelming, there were a few obvious starting points for us to look into.
Leveraging Past Learnings for New Teams
I had previously worked on onboarding for Evernote Business during another initiative. Because of this, I had helped conduct user research to better understand who our users were and why they started using our business product. These were a few of the key insights we leveraged:
- Teams join Evernote Business to have a centralized information repository where members can access and contribute content.
- Within teams, we have two types of users that are delineated by our product system: admins and users. Admins often create and have additional management privileges to their business account, while users are invited as members to the account.
- In addition to the roles set by the system, admins were likely to be existing Evernote users that brought our business product to their teams. As such, they put painstaking amounts of effort to onboard their team members and create a working system within Evernote Business.
- Users, on the other hand, were far more diverse with regards to how much they invested into the product. Some used it regularly, while many failed to adopt it. Relatedly, the amount of value that teams found in the product determined their likelihood to continue their subscription.
Ultimately, we knew how important it would be to communicate the value of our product in a way that met the expectations of new teams. We also wanted to ensure that we were addressing our admins’ pain points by creating a robust onboarding experience for their team members.
Observing Existing Team Feedback from our Beta
In addition to the learnings above, I had designed a simple onboarding flow for our private Spaces Beta and observed users go through the onboarding and core experiences. The goal was to better understand how well existing teams were learning the new features, especially in conjunction with a redesigned Evernote web client (which was also a part of this release.)
From this, we gained two primary learnings. Firstly, teams had difficulty grasping how spaces fit into the overall Evernote ecosystem. They didn’t understand its relation to notebooks and notes, which also meant they couldn’t easily identify the power of Spaces. Secondly, the changes created a lot of anxiety for existing teams. Because they had put in so much work to create a system that fit into their processes, they feared disruptions.
Altogether, we recognized how important it would be to ensure existing teams understood how spaces fit into the product and within their own workflows.
Designing for New Teams
With the knowledge we had accumulated, we were well positioned to start solving how to educate teams about and help them find value in our product. Since we had more groundwork to lay for new teams, we began there.
Setting Goals to Measure Success
We started by identifying goals for new Business teams. Specifically, we wanted new teams to understand three things about Evernote Business:
- It’s a tool for creating and importing content into a single place.
- It’s well-equipped to help teams organize their content, get on the same page, and collaborate.
- All content is available across desktop, mobile, and tablet devices.
We then translated these three goals into success metrics that then defined what an activated team might look like on Evernote Business. In doing so, we hoped to better establish data-driven foundations that would help us understand the correlations between team behaviors and conversion. To that extent, our data tracking had historically been inconsistent and failed to capture an accurate state of the Business product, so we leveraged what data was available and made the following assumptions about what an activated team would look like within their first week of using the product:
- They have 5 or more notes in shared spaces
- 30% of the members join the team on Evernote Business
- 3 or more team members log three or more time-based sessions
- 3 or more team members contribute shared content
- 80% of the team downloads Evernote on a 2nd client
Establishing Priorities for Teams
With goals and metrics set, our next step was to map our expectations along the actual product experience. As such, we walked through admin and user journeys into Evernote Business and prioritized what was important to introduce. Our decisions hinged on what would help teams quickly acclimate to the system while properly establishing Evernote Business as a team productivity tool. We also had to account for the differing priorities and experiences required by admins and users.
For admins specifically, we recognized that it was most important they understood the value of Spaces. We hoped we could do that as they maneuvered through the product organically. In addition, it was critical that admins understood how they could add team members to their business account and then invite them to shared spaces.
With regards to the users, we wanted to reduce the burden that admins took on to onboard them. As such, we felt it critical to introduce them to Spaces and how they could contribute content to their team’s workspace. To that extent, because we stressed the importance of teaching teams about our new organizational construct, we decided it was critical to frame onboarding around Spaces — as opposed to other important features like note-taking and notebook organization.
Designing Admin and User Flows
When we started diving into the onboarding flow for admins, we realized we could easily partition the experiences into modules. That is, after the registration flow, admins would be directed to Evernote for web. There, they would experience a specific first launch experience that would ease them into the product and direct them towards spaces. If they created a space, they would land on an empty state that further propelled them into another first launch experience when they added content. Otherwise, they had the opportunity to view example spaces.
Similarly for users, we were able to partition their experiences into specific modules. Unlike admins, however, we had to consider scenarios in which users were invited to their team’s Evernote Business account with or without spaces.
Thinking about onboarding as a set of modules was great for a number of reasons.
- Firstly, they helped enforce onboarding principles. With these modules, we moved away from passive, non-contextual education, and moved towards direct action that communicated what was important. Additionally, if team members followed our signals, they would experience onboarding organically. They could also explore on their own and still receive education that was pertinent to where they were in the product.
- Secondly, they worked well with our implementation architecture and aligned with how we made calls to our database. More specifically, we were building this experience across all of our clients, so we wanted to ensure that teams only experienced each onboarding module once. While we couldn’t easily track every behavior, we could access whether or not a team member was an admin or user, whether or not they had been invited to or joined a space, etc. This helped us create accurate heuristics regarding which modules team members needed to see across clients.
- Finally, they enabled us to cover the most important cases while accounting for engineering scope, as we had learned pretty early into the project that we would only have two to four weeks from each of the client teams.
Iterating on the Modules
Naturally, we iterated on our work each step of the way, leveraging both stakeholders and user research. One area we spent a sizable amount of effort on included copy. Typically, I worked with my PM to reach an agreement around high-level messaging, and then I’d draft the words. After, I’d hold design reviews with my manager, my product manager, and with product marketing. We’d work together to think through every flow to ensure we were building a cohesive narrative for teams.
The empty state for spaces also proved to be an important area for onboarding, as we wanted to show the power of spaces and help facilitate more engagement when admins and users created them. When we initially started designing this empty state, we had to solve for a dynamic UI and simultaneously show all the different things that team members could add to a space. As we were exploring iterations, we later learned that we would not have the developer resources to build out a powerful tool. As such, we resorted to creating an empty state that showed the most important actions while ensuring that we did not restrict users from other key behaviors.
Finally, we heavily debated the concept of creating example content— which is now part of the Space Directory first launch experience — for teams. Given how constrained we were with developer and design resources, we were initially unsure of the value in this investment. As such, we turned to research to understand what problems existed with our thinking around onboarding and to see how impactful examples could be with regards to spaces (and their relation to notes and notebooks). Once we felt confident in their value, I set out to design four example spaces. With the help of the copywriting team at Evernote, I was able to produce and incorporate around thirty example notes into the experience, as well as iterate on them.
Designing for Existing Teams
With the completion of onboarding for new teams, we were ready to shift our attention towards existing teams. Though we knew there would be obstacles to fully acclimate these teams to newly added spaces, we were determined to help them grasp the concept of and embrace the improved experience.
Having Empathy
Having conducted research through the Spaces Beta, we had a strong footing around what we needed to think about. Specifically, we knew we had to:
- Be sensitive to the fact that change is difficult. Because existing admins and users had existing workflows and processes that took time and effort to fully realize, pushing them into new experiences when they were unprepared created anxiety and frustration.
- Be clear about the hierarchy of Spaces in relation to notes and notebooks. That is, existing teams needed to understand how Spaces fits into their existing conceptions.
Reusing Modules for Existing Teams
We were fortunate to be able to leverage what we had already designed for new Business teams. However, given what we had discovered during our Beta, we knew we had to make a few adjustments.
Specifically, we felt it would be important to provide existing teams with the opportunity to revert back to the old web client if they didn’t feel ready to dive into the new version of it. If they continued to explore the new version, they would see these mechanisms that would assure them that their content had not been touched and was still accessible in the same way.
In addition to this, we had incorporated example spaces into the experience, which we believed helped new and existing teams alike, specifically with regards to understanding how their conception of notes and notebooks could fit into brand new spaces. To that extent, these flows were not without their own in-depth levels of iteration.
Translating the Onboarding Experience Across Clients
We had designed the new and existing team onboarding experiences on what was to be our new web client. However, we had to ensure that there was education present across our iOS, Android, Mac, and Windows applications.
Unfortunately, as mentioned before, we were severely constrained with regards to how much we could build. Accordingly, we decided to move forward with only designing the existing team experience across our other clients, as we knew that new teams would be funneled into the new web client. To that extent, we had to make additional cuts and were only able to build popovers within the clients, which meant that the experience would be more informational than actionable.
The Impact & Next Steps
A few months after we released spaces, we saw about 40% of teams hitting the initial metrics we had set. Though we need to further gauge whether these metrics are rigorous enough, we were happy to see these them.
In addition, we took a look at some more meticulous data around example spaces. What we noticed was that only 1.52% of users who attempt to start a free trial ever get to the the Space Directory. However, of those users that do, 44% of them eventually create a space. As such, we hypothesize that continuing to iterate on example spaces and how we surface them could help lead to increased team conversion and retention.
