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