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.
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 included:
- Teaching teams new to Evernote Business how to use the product with the intent to increase post-free trial conversions
- 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.
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
I had previously worked on onboarding for Evernote Business during a technical initiative to divorce our consumer and business products and experiences. Because of this, I had helped conduct user research to better understand who our users were and why they were using our Business product. These were a few of the key insights we were able to leverage:
- Teams join Evernote Business to have a centralized information repository where members can access and contribute necessary 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 business 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 more diverse with regards to how much they invested into the product. Some used the product regularly, while many failed to adopt it. Naturally, the amount of value that teams found determined their likelihood to continue their subscription.
In addition to these learnings, I had access to what I had designed during that particular initiative, as well as the designs from before my time. Though I didn’t initially utilize these iterations for inspiration, they eventually helped us craft onboarding principles by understanding how we needed to evolve from where we were.
Observing User Feedback from our Beta
In addition to the work 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 or poorly existing teams were learning the new features, especially in conjunction with a redesigned Evernote web client (which was a part of this new release.)
From this, we gained two primary learnings. Firstly, teams had difficult 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 any disruptions in their workflow.
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
Before we could dive into the details of user flows, 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 objectives into success metrics and began to define what an activated team might look like on Evernote Business, as we wanted to establish data-driven foundations that would help us understand the correlations between team behaviors and conversions. To that extent, our data tracking had historically been inconsistent and failed to capture a clear 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:
- 5 or more notes in shared spaces
- 3 or more team members had signed up from 10 team invitations
- 3 or more team members had logged 3 or more sessions
- 3 or more team members had contributed shared content
- 80% of the signed up team had downloaded Evernote on a 2nd client
Establishing Priorities for Teams
With objectives set, our next step was to map our expectations along the actual product experience. So, we took to the whiteboards to walk through an admin’s and user’s journey into Evernote Business, and prioritized what was important to introduce during onboarding. 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, as we walked through their potential experiences, we recognized that it was most important to have them understand 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.
For users, we wanted to ensure that we reduced the burden for admins to onboard them by having them truly understand the product. 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 getting into the design details of 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. As I had referenced past iterations of Evernote Business onboarding, I realized that much of our education was too passive and non-contextual. With these modules, we were being direct about what we thought was important for teams to know while still providing flexibility to explore the product on their own. Additionally, these modules were contextual. If team members followed our signals, they would experience onboarding organically. If they decided to explore on their own, they would still receive the education that was pertinent to where they were in their journey.
- 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. Accordingly, we wanted to ensure that teams were only going through the onboarding modules 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 had experienced.
- Finally, they were applicable across the different scenarios we were trying to build for new/existing teams and admins/users. When we had initially began this project, we didn’t quite have a clear picture of how much developer time we would have available. Once we learned that it wasn’t much, modularizing our onboarding proved to be the best way for us to work with our constraints and implement all of the scenarios across all of our clients.
Iterating on the Modules
Naturally, we discussed each module in great length and iterated on them quite a bit. However, there were a few specific areas within the experience that we prioritized.
For example, we heavily debated the concept of creating example content — which is now part of the Space Directory FLE — for Business teams. Given how constrained we were with developer and design resources, we were unsure of the value in this investment. As such, we turned to research to understand what gaps in knowledge existed with our thinking around onboarding and to see how impactful seeing examples would be for users to pick up the concept of spaces (and 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 also worked on establishing a multitude of entry points for the examples and worked to design experiments around the degree to which we highlighted them.
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 the options at hand.
Finalizing Onboarding for New Teams
With the completion of each module, we were ready to push the new Business team onboarding experience out to the world. To that extent, we were only halfway done at this point. Our next objective was to solve for existing Business teams.
Designing for Existing Teams
Though we knew there would be obstacles for us to fully acclimate existing teams to newly added spaces, we were determined to help them grasp the concept of and embrace the improved experience.
Having conducted research through the Spaces Beta, we had a strong footing around what we needed to think about with regards to existing teams. 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 conception around notes and notebooks.
Making Tweaks to our Modules
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 ensure that existing teams could choose to enter the new experience or revert back to the previous one. In addition, should they choose to continue into the new product, we wanted to assure them that their content had not been tampered with and that their workflows were left undisrupted.
With these additions and the ability to leverage our existing modules, we had actually completed designing the flow for existing teams. These flows were not without their own in-depth levels of iteration, however.
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, we were severely constrained with regards to how much we could build. But since we had not planned on optimizing for existing teams, this was not a major detriment to the project. As such, we set out to build basic experiences with popovers in each of the clients to help facilitate both existing and new teams towards the new feature. This ultimately meant that the experiences for users across the various clients were more informational than actionable.
Our Impact & Next Steps
Since our product launch, we’ve learned that 40% of new teams have become activated, which means that they’re creating 5 or more notes in shared spaces in their first week (along with other milestones.) Given this data, we felt really accomplished with the results of our work, especially since we endured so many constraints along the way.
To that extent, there are some pretty immediate next steps for the team to take on. Specifically, we have access to team behaviors that seem to positively correlate with example spaces and second client downloads. If we can surface those two areas of the product more effectively, we may be able to activate more teams as they come through Evernote Business. With that, there is plenty of room for improvement. We’ve set a great base, and I’m excited to see what’s next for Business onboarding.