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.

Product Management
User Research
Persona Definitions

Project Details


Design Lead


November - May 2022 (6 months)


Figma, JIRA, Trello


Case Team Image


Sr Product Designer
Case Team Image


Sr Product Designer
Case Team Image


Product Designer
Case Team Image




How can we enable users in our software, without restricting or limiting their job function, in addition to the nuances that go into each orgs idea of compliance and security concerns?
Lever's existing documentation of personas was essentially a list of titles without an understanding of how they used Lever's product or how they could use Lever's product within their recruiting and hiring process.

I strongly believe we cannot solve the right problems for our customers if we do not understand what those problems are, and furthermore cannot use those learnings to inform what potential solutions are. We needed to define our personas, and then understand how to use them to enable customers as well as our internal teams.
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


Define categories that each of the 22 personas fall into in order to create groups that align with their jobs to be done. This allowed us to layer findings into ongoing work with the role based access control restructure. Understanding persona categories and jobs to be done further enables the ability tie those back to key product actions and level of access needed to fully empower them in Lever, removing all existing friction and blockers currently experienced today.

The goal: tie job titles to known jobs to be done within those roles, map them back to product features, and then structure how organization size impacts privacy, data, and permissions concerns.

Solution Image

Project Kickoff

It all started with a confluence document i stumbled upon containing 22 potential personas who "might" need to use Lever or an ATS tool within their recruiting and hiring process. It was just a document of assumed titles that can be involved in an end to end hiring process. This project was not an ask from a team or stakeholders, but was an individually owned and driven initiative on my end with the goal of bringing more in depth awareness and knowledge to our products users.

I put together a framework and presentation to open these discussions with stakeholders, utilizing design storytelling to inform them of the benefits of knowing who are users are, their motivations, goals, drivers, and anti-goals. This created alignment on the recognized gap/need within Lever and enabled me to add this project as a roadmap item alongside permissions.

From there I built out an end to end phased plan on how to implement the learnings into our permissions solution space, and over time layer these personas into future product or feature initiative planning and roadmap sessions for product and go to market teams to utilize moving forward.

Utilizing the RBAC project as an opportunity to grow Lever

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.

After a project kickoff and beginning initial research and discovery, I learned that all 5 available access groups didn't meet the mark for most of our customers. For those who were startups, they didn't mind having users be super admins since their companies were so small and trust was present amongst all members. It was enterprise that was struggling to find a match with how we presented our groups. Each category somehow limited a team member, and due to concerns with sensitive data and information that the ATS stored, enterprise customers were more likely to restrict users rather than allow more leeway.

Early research and discovery learnings combined with what we knew about our current personas standing led this project to being the key factor for Lever's RBAC project to see success.

Inform a path forward

The first step was to list out the "unknowns" that would be priority in shaping a path forward when swimming through 22 different job titles and how those relate back to our ATS.

  • Where does each role have crossover with other roles/titles?
  • What are users within those roles attempting to do within the product?
  • How do their product actions relate back to their role title?
  • What are the tasks they need to complete on a day to day basis within an ATS?
  • Are any permissions needed to complete those tasks "sensitive"?

When trying to answer these questions internally I found there wasn't any existing documentation or an org-wide agreement of who are users were outside of their titles.

Aligning Teams on the Value of Defining Personas

Building a product-led org

Value through relevance

Personas can be utilized to inform high value product investment areas and build roadmap items based on persona relevance, value add, and monetization goals towards enterprise orgs.

Outcome driven initiatives

Outcomes become more accurately anticipated when utilizing personas to inform the risks, hypothesis, assumptions, and success measurements to know how successful a project was or wasn't.


Personas are the driver for Levers new RBAC architecture, allowing us to drive further scalability and success with our customers through permissions based enablement.

Where it leads

Standardize org wide

Cross functionally align with design teams, product managers, CSMs, and other stakeholders to gain buy in on business-level personas to implement and utilize org-wide.

Optimize product planning

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.

Inform 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

Early phases of discovery and research were focused on any existing documentation or previous work that had been done around our personas. This led to internal interviews with go to market, sales, product, design, and engineering teams to better understand how they utilizing personas or any user stories within their process/team.

Understanding the hiring process

The first step was understanding each role within the end to end process and what each roles tasks were made up of on a day to day basis.  I made a visual representing a standard hiring process outlining which roles are involved and in what capacity. Before validating with customers, general research informed key personas with the largest need for ATS tools: recruiters and hiring managers.

From there I needed to further inform our customers product usage needs to see if roles had any differences based on the size of the organization, from SMB to mid market to enterprise. This helped define a default (or standard) set of permissions those users expect within ATS software that are commonalities regardless of company size. From there the structure could be further built upon by layering in areas seen as sensitive or compliance concerns, which would require manual provisions.

Challenge: Lever called personas and access the same thing

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. This added a lot of confusion throughout the organization when our employees thought of who a user was and what they needed. They would approach it from a software usage perspective and not a "needs of a human being" perspective.

  • 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

Challenge: personas were just job titles at this state

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?

Context: access roles 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.

Who are Lever's users?

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.

During this phase I did discovery for other product teams or go to market roles within the organization to better understand how they utilize personas in their projects and roadmap discussions.

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


Case Team Image


Case Team Image


Case Team Image


Case Team Image


Director of Recruiting


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 were similar within departments and only shifted based on the level of the role you held within that department.

The 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.

Identifying critical jobs to be done

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

Persona Groups

Our tool overwhelmed product planning sessions due to the amount of user types and workflows.

I needed to simplify our approach when attempting to enable everyone all the time, or only focusing on enabling a few at a time in order to make our company scale alongside our enterprise customers who had more concerns and questions regarding in product compliance and sensitive data. 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.

Taking the 3 core actions mentioned above I created narratives around them.

  • 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”

The key takeaway

Lever’s product could not account for 22 individual job titles and remain scalable. In doing so we corner ourselves into adding too much for small companies, and not enough for larger orgs. We needed to focus on the core personas who require ATS tools in their flow and then additionally layer in how their org size impacts the scope of flexibility they have with those permissions.

I based group creation on the root of each personas day to day actions: enabling, doing, and assisting.

Solution Image

These new learnings informed previous incomplete research around personas and allowed us to tell a better story with our features and their intended audience.

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 just because they have similar titles.

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).

Recruiters are our core persona or "power users".

Lever's New Approach

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" 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.

Back to top