Case Study Banner

Project Summary

Lever has access roles that exist within the platform which each contain a set of permissions that restrict or enable employees based on the access role they have. They fall into 5 buckets, and users can layer in custom sensitive information privileges on a case-by-case basis.

When talking about personas in a project context, we are referring to our “access role” persona.

Design
Product Management
User Research
Persona Definitions
ATS

Project Details

Role :

Design Lead

Duration :

November - May 2022 (6 months)

Website :

Lever.co

Tools :

Figma, JIRA, Trello

Teammates

Case Team Image

Meghan

Sr Product Designer
Case Team Image

Josh

Sr Product Designer
Case Team Image

Sam

Product Designer
Case Team Image

Nate

CEO/Stakehodler

Problem

Problem Icon
How can we build a better product without knowing who we are building for?
Lever's documentation listed 22 hypothesized personas involved in the hiring process whether they touched Lever directly or not. A large gap existed in the understanding of how any find value within Lever.

There was also a misunderstanding amongst the org on what a persona was. Lever's approach was to use job titles users held and apply that to the appropriate access groups which then defined personas.
Problem Tab Image
With the restrictions on our current model, users have to rely heavily on their colleagues to get their work done.
Currently, users within Lever have to find workarounds for the blockers put up by our limited RBAC model. This has created a great deal of friction for our customers across all segments, as users need to ping other colleagues with a different set of permissions to give them information or go through a lengthy internally approvals process for an access change.
Problem Tab Image

Solution

Problem Icon

Through research and user interviews I documented the roles (job titles) most commonly involved in the hiring process and segmented them by hiring phases and job requirements. Taking this information I further expanded on it by researching how org size/levels impact that persona and the amount of information they have access to.

22+ job titles can take place within the hiring process so it made sense to create groups of personas based on the root of their function: enabling, doing, and assisting.

Solution Image

Project Kickoff

I was given a confluence document with 22 listed personas of who might be using Lever and the assumed jobs they might own. There were no breakdowns of how org size impacted this (if at all). My first step was to communicate the value of understanding org-wide personas. From there I formulated a plan on how to implement the learnings into product planning sessions moving forward.

The Project Was Born From Another Project

One of my projects was focused on further expanding on 2 of 5 access groups: the "sadmin" (Super Admin) and "Admin". The original ask was to refine the sadmin & Admin user types into personas.

First, meet with 5 sadmin and 5 Admin users internally to identify their needs, wants, and goals to translate those into workable personas. Later, present learnings to design + product regarding our sadmin + admin personas.

Recognizing Gaps to Fill

With 0 context to start, I made a list of questions based on the gaps I recognized with the little context I started with. These questions created a clearer path to discovery.

  • Which roles typically fall into each user type?
  • What are users within those roles attempting to do within the product?
  • What are the jobs they are trying to do?
  • What are the tasks they need to complete on a day to day basis?
  • What permissions do they need to do each task or job?

After thinking through the task itself and the open questions, I began to question the other "personas" as well and found that there was no documentation or org-wide understanding of who are users were outside of their roles. The idea that propelled my thinking was “how can I enable the personas within Lever, without restricting or limiting their job function, as well as considering the nuances that go into each orgs idea of compliance and security concerns”

Create a vision

Personas Scale Business

Research Image

Value in Relevance

Knowing what users want to accomplish in the product enables us to target high-value features for all group needs.

Research Image

Clearer Goals

Applying personas to project goals scopes down the feature priorities based on the value a group of users might gain.

Research Image

RBAC

Personas directly apply to the value Lever users will derive from their level of access and permissions.

Desired Outcomes

Research Image

Standardize Personas

Align with design > product > csms > stakeholders to agree on business-level personas to implement and utilize cross-functionally in the org.

Research Image

Prioritize the Right Way

Applying personas to feature prioritization optimizes success in outcomes by building what users get the most value from instead of vague requirements that aim to please all.

Research Image

Build for the Future

Understanding where we're at now helps us build a better product for the future of ATS software. Applying the knowledge of personas to the future of their job roles allows us to think ahead.

Research and Discovery

Kicking off the project to understand which personas exist and the extent of previous research. I also wanted to uncover how product and other cross-functional areas of the organization utilize personas in their projects and roadmap discussions.

Lever has access roles that exist within the platform which each contain a set of permissions that restrict or enable employees based on the access role they have. They fall into 5 buckets, and users can layer in custom sensitive information privileges on a case-by-case basis. When talking about personas in a project context, there are considerations of how "access roles" tie to those personas.

My Early Approach

I needed to understand what each role was involved in the hiring process, and what tasks were typically performed in the process. I made a breakdown of a standard hiring process, outlining which roles are involved, and in what capacity. Before validating through research, the highest touch points came from Recruiters and Hiring Managers.

From there, I needed to understand if any functions of those persona's jobs changed from SMB to MM1, MM2, and Enterprise. This would help me define a default set of permissions that are commonalities regardless of company size, and weed out the areas that are seen as compliance concerns that should be manually provisioned.

Issue 1: Lever Conflated Personas + Access Roles

Access Roles identify groups of permissions that apply to a user within an org. This is usually based on their title and job function. Admins manually enter their employee details and then choose an access role to assign based on the associated permissions.

The Product Org would utilize the word "access role" and "persona" in the same context which caused initial confusion for me. Originally, "personas" were approached from the level of access they had to the product.

  • Interviewer: Can complete feedback and refer candidates
  • Limited Team Member: Can see candidates they’ve been granted access to and associated job postings
  • Team Member: Can see all candidates and job posting reports, and be granted partial or no sensitive information privileges
  • Admin: Can see all candidates and reports (except offer reports), administer most settings, and be granted full, partial, or no sensitive information privileges
  • Sadmin: Can see all candidates and reports, administer all settings and jobs, and has full sensitive information privileges

The images below are from initial research I conducted to understand which access roles existed and how they tied into a persona. This identified key differences between each access role. I used this to create connections between a user profile and how Lever might have defined a profile based on those roles.

Story Image

Issue 2: Personas Didn't Have Depth

Lever's approach was to apply job titles to access groups which then defined personas. The list of 22 personas within documentation recognized personas as the job title. Those were:

  • Employee/team member
  • Interviewer
  • Hiring Manager
  • Recruiter
  • Sourcer
  • Recruiting Coordinator
  • Recruiting Manager
  • Recruiting Operations
  • VP of talent (Head of Talent Acquisition)
  • Recruiting Operations Manager
  • Analyst/Business Analyst
  • Director of IT
  • Candidate Experience Manager
  • Talent Marketing Specialist
  • Marketing Comms
  • CHRO
  • CEO
  • CFO

The problem with this was although generalized personas were created, there was no further investigation on how they tie into Lever outside the assumption/hypothesizing done by the previous project owners. There were more unknowns than knowns such as

  • Which of those personas actively use Lever?
  • Who are the power users?
  • Who needs hiring tools versus platform management tools?
  • Which persona owns the implementation process?
  • Which persona our product should aim to empower and prioritize?

Access Role vs Permissions

Permissions are the individual items users within their access role can access or grant access to. Permissions were too rigid due to the inability to customize.

For example: if one employee met the criteria for an access role, but one permission was missing required for them to get their job done, the only way to grant that permission is to assign the access role one tier higher. This would provide that employee access to additional areas of the tool that might be confidential, thus compromising security.

To understand the limitations and capabilities of each access role, I created a test account in Lever and went through multiple flows within each view to annotate the differences between them. I was looking for indicators of differences in view, navigation items, limitations, and product access.

Personas vs Access Roles

One of the challenges within the research was that Lever used “personas” and “access roles” interchangeably. This caused confusion initially with product owners as they thought company personas just meant new access groups. Part of the project encompassed an additional angle for uncovering a detailed understanding of Lever’s personas and how the implementations team thought jobs to be done tied that back to an access role recommendation.

I utilized this opportunity to educate the product org on the differences between an identified persona, and an access role. This was done through a 2 part product presentation at product all hands over the course of 2 weeks.

In this stage, we agreed that access roles should tell a better story around persona and jobs to be done in order to more accurately scale alongside our customers' needs.

It still didn't answer the question

Who Are Lever's Users?

Problem Icon

If we don’t know who we are building for, how can we say who will benefit from these features? Who needs access to what, and why? We understand the pieces of WHAT, but how do we make it something tangible? How do we create and inspire empathy in this process without having a user to keep in mind?

Due to the number of personas that could touch the hiring process, focusing too much on individual persona might skew how we think of building features and scaling them and tying that into the value that comes with that. I hypothesized that we can’t build a product that improves work for many if we focus on the few.

Solution Image

User Research

Internal + external research sessions to validate hypotheses and assumptions within the hiring process. I also utilized this time to understand how org size affects job function and security concerns with access. These were important to include as considerations to ensure the persona profiles outlined did not restrict our users from completing primary tasks or inaccurately represent Lever customers.

User Research Sessions

  • Create internal research plan outlining goals, learnings, targeted personas based on our assumptions in jobs to be done <> relevance to title, and lastly create a script.
  • Conduct 12 interviews across Lever within recruitment, customer success, and implementations
  • Synthesize into key findings

Participants

Case Team Image

Rachel

CSMs
Case Team Image

Regi

Implementations
Case Team Image

Chealy

Recruiters
Case Team Image

Nate

Director of Recruiting

Takeaways

After synthesizing all 12 calls, I compiled a list of patterns amongst the groups of users we had formed assumptions on that were validated through these research calls.

Jobs To Be Done

  • Jobs to be done were similar within departments and only shifted based on the level of the role you held within that department.

Power Users

  • Regardless of 22 or 100 people involved in a hiring process it was clear that the our power user within Lever was the Recruiter.

Personas and Core Actions

Since jobs to do can vary depending on role, seniority, department, and individual org requirements (size, security, or dedicated teams) I synthesized the jobs to be done amongst org departments and roles within those departments to reveal the bigger picture within actions they need to achieve in the product. Those were as follows:

  • Someone who manages all things related to product or platform and its users
  • Someone who manages talent and hiring process tasks
  • Someone who only participates in interviews and providing candidate feedback when requested

Grouping Personas

Our tool enables different people and different workflows dependent upon different factors. This is how I tackled the impossible. I framed the migration to groups rather than individual personas to encompass the long list of tasks a user might want to do without sacrificing their job functions. Personas can be grouped based on how they impact their own, or others' job functions.

Digging deeper into the three core actions mentioned above, I broke them down further to tell a story.

  • Those who enable/need to enable others to get their job done (managing the platform, adding/managing users, adding/managing tools, etc). Example: “I enable users to do their jobs, by managing and maintaining the tool”
  • Those who rely on Lever to get their job or functions within their job done. That can be users who need Lever to do their day-to-day tasks or users who need to use Lever frequently enough to be impacted by limitations and restrictions. Example: “I use Lever to carry out my hiring tasks and cannot complete my job functions without utilizing Lever”
  • Those who use Lever on an as-needed basis and are not limited or impacted by Lever tools. Example: “I only use Lever as needed and can carry out my job function without Lever”

Custom roles can fill the gaps.

What it Means

Problem Icon

Lever’s personas are not every person involved in hiring a candidate! They are the personas that use Lever day to day to perform their job functions

There are 20+ job titles that can take place within the hiring process so it made sense to create groups of personas based on the root of their function. Enabling, doing, and assisting.

Solution Image

Important Learnings

After identifying new learnings through the research process, I was able to realize a lot of the gaps we had in our previous research.

Lever originally took the idea of a hiring team and applied that to our product, which enables and optimizes the workflow of hiring teams. In hindsight, it makes sense. Taking a step back, it’s not the reality of our day-to-day users within Lever.

Only 2-3 of the original persona groups identified utilize Lever on a day-to-day basis, and most of those fit within the same permission sets depending on seniority (for example a Recruiter versus a Director of Recruitment). Lever's core personas should be the power users. Who benefits from the product updates? Who benefits from new features and product improvements?

We can't assume users have the same goals.

The persona that may implement the product and interact with CSMs is not usually (depending on company size) the persona that utilizes Lever every day. I wanted to take into consideration the rest of the hiring team and how they touch our product, but so many of the personas we listed in our original research hardly have any touch points with Lever.

When inquiring on the most common persona CSMs and implementations encounter as the day-to-day user, it remained consistent regardless of company size. The consideration is how the job function changes from segment to segment (SMB to MM1 to MM2 to Strat/Enterprise).

It didn't take a crystal ball to tell us a recruiter is our core persona, but it did take a lot of conversations and research to understand how they were our core persona.

Persona Groups are born

Kicking off the project to understand which personas exist and the extent of previous research. I also wanted to uncover how product and other cross-functional areas of the organization utilize personas in their projects and roadmap discussions.

Lever has access roles that exist within the platform which each contain a set of permissions that restrict or enable employees based on the access role they have. They fall into 5 buckets, and users can layer in custom sensitive information privileges on a case-by-case basis. When talking about personas in a project context, there are considerations of how "access roles" tie to those personas.

Lever's Power User: Recruiters

The recruiter is Lever's power user. No matter the sizing of the company, the recruiter remains the most active user in Lever, utilizing our product each and every day to complete their workflow. Job functions may change from org to org depending on sizing and company compliances. In order for recruiters to be operating at their maximum potential in Lever, they need the flexibility to access parts of the product many orgs view as sensitive information. Recruiters run the engine in the hiring train.

The key goals of our power user:

  • Carry out day to day tasks in Lever to complete my job function
  • Ensure our talent pool is engaged + nurtured through the process
  • Be empowered and autonomous in my workflow without any reliance on others
  • Communicate with candidates in a timely manner
  • Create, post, and manage jobs
  • Manage and share candidate profiles

Platform Admins - The Enabler

Platform admins are those who do not actively participate in the hiring process. They might participate in interviewing panels from time to time, but otherwise are largely uninvolved. Platform admins are typically the users who interact with CSMs and implementations when getting lever set up, as well as ongoing Lever <> org touch points.

They manage the Lever platform for their users. This includes actions such as implementing Lever, managing permissions, and managing org settings. This persona consists of IT teams, IT stakeholders, implementations teams, engineering managers or IC engineers, platform specialists, and org-wide stakeholders such as the CEO, Chief of Security, and CFO. Company sizing impacts which exact “title” manages the platform, but all access and permissions remain consistent for someone acting as a platform admin.

The key goals of platform admins:

  • Own implementation of Lever within our org. I am in charge of getting Lever up and running. I am in charge of connecting Lever with our existing integrations
  • Enable teammates with the right permissions/access. I own the management of all user permissions
  • Enable and optimize team workflows through available integrations. Manage existing integrations and enable new ones
  • Own more technical facing facets of Lever to reduce human error. Technical facets of the platform should be handled by a dedicated source

The images below are from initial research I conducted to understand which access roles existed and how they tied into a persona. This identified key differences between each access role. I used this to create connections between a user profile and how Lever might have defined a profile based on those roles.

Hiring Pioneers - The Doers

Hiring pioneers are those within Lever that are key players in the hiring process. This persona covers hiring managers, sourcers, coordinators, recruiters, directors/managers of talent or recruiting, and recruiting and talent operations.

Permissions vary on their job function, but most of our hiring pioneers will be using Lever to do the majority, if not all, of their hiring-related tasks.  Think of this persona as someone who provides a key piece of the puzzle in hiring, and together they complete a puzzle. Individually, they do not drive all aspects of hiring and talent management. They also do not touch or contribute to platform management.

Key goals of hiring pioneers:

  • Carry out day to day tasks in Lever to complete my job function
  • Ensure we keep our talent pool engaged and nurtured through the process
  • Be empowered and autonomous in my workflow without any reliance on others
  • Create, post, and manage jobs Manage and share candidate profiles
  • Communicate with candidates in a timely manner

Helpers

"Helpers" are the personas that do not touch anything behind the scenes within Lever. They are individual contributors who can be pulled in to interview candidates either 1:1 or on panels as needed. Their main use case for Lever is to assess talent, gain context on candidates before interviewing, and record feedback for recruiters or candidate owners to review before moving them forward.