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 Lead
November - May 2022 (6 months)
Figma, JIRA, Trello
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.
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.
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.
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.
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”
Knowing what users want to accomplish in the product enables us to target high-value features for all group needs.
Applying personas to project goals scopes down the feature priorities based on the value a group of users might gain.
Personas directly apply to the value Lever users will derive from their level of access and permissions.
Align with design > product > csms > stakeholders to agree on business-level personas to implement and utilize cross-functionally in the org.
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.
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.
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.
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.
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.
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.
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:
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
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.
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.
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.
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.
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
Power Users
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:
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.
Custom roles can fill the gaps.
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.
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.
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.
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:
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:
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 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:
"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.
