Sapling's Updates Page

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.

  • Role: Design Lead
  • Platform: Desktop


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:

    • Managers were having trouble locating their team’s time off requests
    • Sapling Admins needed a quicker way to follow up on open tasks and documents

    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:

    1. Competitive analysis
      - Goal was to better understand how other HR tools expose their data to end-users
      - Our Head of Product and I recorded ourselves interacting with four other tools, and shared our learnings with other stakeholders
    2. A targeted survey to new hires hired within 60 days, who used Sapling to get onboarded. I asked:
      - When you logged into Sapling for the first time, what did you expect?
      - If you were to login to Sapling right now, what would you do first?
      - Is there something that you felt was missing from your onboarding experience?
    3. User interviews (through a video call) with two Sapling power users
      - In a 30 min discussion, I observed how they interact with Sapling, and asked about both most useful and most accessed pages.

    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.

    For example, if there were open tasks (such as completing a survey, or setting up a meeting) they wanted to complete it quickly.

    Our Head of Product and I sat down and brainstormed a bit, prioritizing the sections based on combined research efforts.

    Building an MVP

    What we decided to show in our MVP for the Updates Page:

    • For everyone: 
      - open and overdue tasks
      - open and overdue documents
      - Shortcuts to the Org Chart, which new hires found to be the most helpful tool in the app
    • For managers only: 
      - everything above, plus pending time off requests from their team
    • For Sapling admins only: 
      - everything above, plus a holistic view of their onboarding program, and a shortcut to the pending hires page

    After lots of discussion, we decided to de-scope several other pieces of information:

    • Scheduled emails 
      - The engineering team estimated that this would add an extra 2 weeks to the project, as well as increase page loading time (due to the amount of emails that are scheduled in Sapling)
    • A list of employees who are out of office
      - At the time, our average customer had about 100 employees, so we made an assumption that this would be near empty on most days, especially since our Time Off Product was new at the time (and therefore not heavily adopted). We knew we wanted to come back to it, but were comfortable leaving it out for the MVP
    • A Facebook like status feature to announce company messages
      - We made an assumption that Slack would be used for this use-case for most customers, despite feedback from the Sales team that the market was looking for an HR tool that does this


    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.

    Variation A
    Variation B
    Variation C

    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:

    Admin experience: 

    Employee experience:

    Manager experience:

    Testing With Customers 

    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:

    • Cognitive Overload: we received feedback that the information was a lot to take in at first glance. Was there a way we could rethink the page architecture to appear less overwhelming?
    • Microcopy: One user felt that the terminology wasn’t descriptive enough. The term “Employee experience” meant nothing to her, and she was scared that employees at her organization wouldn’t find it useful either.
    • Missing components: as part of this feature, we removed manager detailsfrom user profiles to keep the page clean, but received feedback that it was actually quite critical to keep visible at all times
    An enhancement we shipped to show someone's manager more visibily on their Sapling profile:

    Launch and Improve

    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:

    • Beta invitation invite
    • A knowledge base article about the feature
    • An email announcement that would be sent when this is live for all customers 
    • A Google form used to capture feedback

    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