Sapling’s Updates page serves as the homepage for all users when they login to the platform. Our team built it to provide a better first-touch experience for new and returning users, after realizing that the previous homepage wasn’t useful, and that we were missing an opportunity to surface up key data.
There were two things we were seeking to solve by building a new homepage
1. Feature Discoverability
As Sapling’s app grew in complexity, we noticed that all types of users (people managers, HR Admins and employees using Sapling) had trouble finding information relevant to their role. The information was there, on some pages in our app, but there was friction, especially for newer Sapling users, or those (like Managers) who login less frequently. A few examples:
When we confirmed that these types of questions made up 19% of our total customer support volume, we knew we needed to prioritize a solution.
2. Usage
As a team, most of our time and energy was spent developing features targeted towards Sapling power users, who are typically People OPS or HR leaders with admin access to the product. We received feedback that employees loved using Sapling to complete their onboarding, but didn’t have a reason to come back. By providing them a contextual, helpful home page, we hypothesized that overall usage would increase.
Before jumping to conclusions, we wanted to get a better grasp of what type of data is for our users to see first when they login.
For extra context, it’s important to understand that there are four user types (personas) we build for at Sapling:
Prior to the Updates Page, when you logged into Sapling, all users were taken to their profile page, where they could complete or change HR related information (such as a home address, or food allergies).
Existing home page:
To better understand how we should prioritize what is shown on the page, I kicked off three different research initiatives:
A pivotal user journey is the onboarding process, where admins can import hires from their Applicant Tracking System (ATS) and manage their employee data. We learned that for HR and People Ops folks, knowing a quick forecast of upcoming new hires was the most important thing, so that they can plan an organized, efficient on-boarding process alongside other stakeholders. It was clear that we wanted to surface this first on our future updates page.
Journey map that illustrates the admin onboarding process:
After some further exploration and analysis of our survey, we learned that employees were feeling overwhelmed during their first 30 days, so it was helpful to give them quick access to anything they needed to do during this time.
Our Head of Product and I sat down and brainstormed a bit, prioritizing the sections based on combined research efforts.
What we decided to show in our MVP for the Updates Page:
After lots of discussion, we decided to de-scope several other pieces of information:
Before opening up Figma to develop visual designs for this feature , I found it helpful to define and finalize the content taxonomy. Using an old-fashioned spreadsheet, I wrote down each use case for the page and organized it by persona. It was helpful to use this as an opportunity to flesh out the microcopy as well. We shared this early on with the engineering team, who helped us better understand how the chosen numbers would be calculated.
The end result was something like this:
By organizing the data into panels, I was able to begin to visualize how these would be displayed.
Next, I put together a rough wireframe of this page using Balsamiq. I quickly put together 8 versions, and shortlisted three of them to review with our Head of Product.
We printed the wireframes below, and tested the designs against our research and product requirements.
We chose version B, as it allowed us to use an existing Material Design component, expansion panel. The engineers suggested this path, as it would allow us to launch an MVP quicker to excited customers. Using expansion panels also allowed us to surface high level stats to users, but still allow them to drill down if they felt like it.
Over the next few days, I polished the designs using Sketch, and put together a few prototypes using Invision. The three prototypes were created to illustrate how the data would change depending on the user’s role within Sapling:
We scheduled some time to review our polished prototypes with a few Sapling power users. The full research notes can be found here, and were shared with other project stakeholders for review. We noticed a few patterns between the conversations, and decided to tackle the following:
A few weeks later, development was complete! Sapling’s QA team and each spent time testing every scenario extensively, and I supported them through visual design polish.
Because this was Sapling’s new home page, we thought it would be helpful to organize a two-week beta program where customers would agree to help us test and improve the page before we rolled it out more broadly. At the time, we had a pretty small team, so I took the lead on organizing a full go-to-market plan, alongside our Customer Success Lead, Head of Product and our Content Marketer. I identified a few deliverables that would be necessary as we rolled this out:
The three of us collaborated on the above, and successfully launched the feature with our customers engaged along the way.
As usage grew on the Updates Page , we used Fullstory to observe how users were interacting with the page. We noticed that the majority of the time, if a user was not a Saplnig admin, they spent less than 5 seconds on the page. We assumed this was because the information wasn’t providing value, and perhaps it was being overlooked.
As I mentioned earlier, two of the features we de-scoped initially, were the Out Of Office, and Milestones panels. These served as a way to inform employees if there was a coworker out of town, or if there was a birthday in the office. Initially we thought these weren’t valuable enough, but after observing the interactions and talking to a few other Sapling coworkers, we decided to design and build these in our next product release. It turns out that new hires and existing employees using Sapling loved our calendar feature, because it made them feel part of a larger team. Providing a shortcut to this information made sense, and aligned with our mission.
The next (and current) iteration of the Updates Page looked like this:
Read next case study ≫
