Personas are a fantastic tool for designers. They can guide important user experience decisions throughout the design process.

Many teams take an over-simplified approach, crafting personas that don’t offer any meaningful details to help with the design process. The documents they create look nice. They make good posters. Then everybody ignores them. These personas aren’t valuable.

After this experience, many teams give up on the idea of personas. That could be because they’re trying to make one set of personas for everything they do. We have a different approach that proves to make personas much more valuable.

When personas are valuable, they guide the team’s critical design decisions. These personas serve as a catalyst to having important design discussions. Because they’re based on scenarios, they ensure the team catches critical user paths through the design. Scenario-based personas offer more depth for user stories, so our developers build out better quality functionality.

We find personas based on roles are too vague.

For the last few months, our team has been working on a job board application, where companies can post their job openings and people can apply for the open positions. It would have been easy for us to fall into the common trap of defining our personas into user roles. The job board has two obvious roles: job posters and job seekers.

While ‘seeking a new job’ and ‘posting an open position’ are distinct activities in the application, they aren’t dictated by user roles. The same person could do both over time. Someone who has been posting jobs may also seek a change in their own career. At that point, they’d also become a job seeker.

Personas don’t help us when we define them on roles. Roles are too imprecise and ill-defined to make useful.

It’s clear we need functionality for someone when they’re posting a job and different functionality when someone is seeking a job. Beyond that, having personas of a job poster or a job seeker wouldn’t help us make any decisions. That’s where scenario-based personas come in.

We start with researched scenarios.

Before we started our research with the people who wanted to advertise their open positions, we hypothesized there were basically two overarching scenarios:

Scenario #1: Job poster with existing job description.
Job poster has a description they’ve posted in several other places (including their own company’s career page). They would like exposure to the audience of our job board. They’d like our job board to promote the description they already have.

Scenario #2: Job poster has brand new position with no existing description.
Job poster just received approval to hire a new team member. They haven’t posted the job anywhere yet and therefore haven’t written it up. They’d like to get applicants right away. They believe our job board firmly targets exactly the type of people that would make great candidates. They’d like to post the first job description on our site right away.

We were right in that both scenarios exist. However, our research showed the second scenario happened infrequently. As a result, our team changed up our delivery plans, deciding to focus on the first scenario: posters with existing descriptions.

We look for variations on how people approach our scenario.

Often, we can get by using only scenarios. Scenarios give us all the detail we need to build out the functionality. In these instances, every user who finds themselves in the scenario would approach it basically the same way.

However, in some projects, in-depth research shows us variations in how different people tackle the same scenario. That was certainly the case with job board posters.

We found multiple approaches to posting a job depending on who the job poster was. Here are some variations we found:

Hiring manager with only one position and not working with HR: This hiring manager has only the one position to advertise. They also have control of the hiring process, with no involvement from their HR recruitment department.

Hiring manager with multiple positions: This hiring manager is building out their team with multiple simultaneous openings. Some of the openings may be very similar positions (and may share the same job title), but will describe slightly different job objectives and requirements.

Hiring manager working with HR recruiter: This hiring manager is working with a recruiter from HR, who will screen applicants and answer the applicant’s preliminary questions about the position.

HR recruiter posting the position: This is a recruiter who is simultaneously recruiting multiple open positions within the organization. This recruiter posts the open position instead of the hiring manager, possibly on the hiring manager’s recommendation.

Each scenario-based persona will approach the design differently.

It was from our research that we learned how each persona was different from the others. We saw many people who were like our first persona: the one-position hiring manager who wasn’t working with HR. This was our simplest persona. They just need a way to copy and paste the description text into the job posting form.

The first hiring manager we met who had multiple positions to post was different from our first personas. They wanted to move between drafts of the job postings. They needed to make sure each position had the right information. We need to help them efficiently enter their posts without duplicating their efforts each time.

We also learned hiring managers who work with an HR recruiter need a way to share the job posting draft. They’d like the recruiter to give them feedback. This persona had different needs than our previous two personas.

Finally, the recruiters we met were very different from all the hiring managers. The recruiters worked with dozens of boards and were very interested in capabilities to track which boards produce the best applicants. They also needed to understand why they should choose this board and which types of positions. None of our hiring manager personas showed any interest in these capabilities.

By identifying each persona and noting their different needs, we can make sure we’re not missing any key functionality. We’re more likely to anticipate all of our users’ needs this way.

Our scenario-based personas emerged from our research.

To identify our personas, we paid attention to what we were learning from our research. We started the research by interviewing hiring managers, asking them to walk us through their hiring process.

We learned about their autonomy and their relationship with HR. We learned about the order that things happened in the hiring process. We learned who usually crafts the job description. We learned about their frustrations with attracting the best applicants.

It was in these interviews that we caught our first glimpses of the different personas. We learned more about them by using interview-based tasks as we conducted usability tests on our prototypes.

After each research session, we’d flesh out the persona descriptions a bit more. The more people we researched, the richer our understanding of each persona became.

These weren’t personas we created to figure out who to research. They were personas that emerged from the variations we saw once we started our research. We’ve found this to be a much easier way to get to more accurate and nuanced personas.

These personas are most useful for specific scenarios.

These four personas turned out to only be useful to our team for that particular scenario. For a different scenario (paying for the posting), we needed different personas (people who wanted invoices versus paying with a credit card). And we didn’t need any personas for the scenarios of turning off the job posting (because the position is no longer open) or extending the posting (because it hasn’t been filled before the post’s expiration date).

In the course of building something like our job board application, we could have a dozen or more scenarios. Personas would only matter to us for approximately half of our scenarios.

The personas for one scenario will unlikely influence the functionality of the other scenarios. We’ve found personas are most valuable when they’re specific to a single scenario. This makes describing the personas substantially easier. We only describe a persona’s specific attributes that will influence the functionality differently from other personas.

Bridging a gap between scenarios and user stories.

Many teams use user stories that look like As a [user], I need to [action] so [an outcome occurs]. With our scenarios and the personas from those scenarios, we can easily fill in all the pieces.

For example, using one of the personas I listed above, we can craft the user story of As a hiring manager working with HR, I need to share a draft of my job posting so my HR recruiter can add in details I’ve left out. Having both the personas and the scenarios to use as background information, creating rich user stories like these become simpler. They also give the developers more insight on where to take the functionality to make it work for the user.

We’ve found these scenario-based personas work very well with other UX techniques, such as Jeff Patton’s Story Mapping, Indi Young’s Mental Models, and Jeff Gothelf’s Lean UX. Scenario-based personas become a lightweight tool to ensure we’re covering all our bases and building the right design.

from Stories by Jared M. Spool on Medium https://medium.com/@jmspool/making-personas-truly-valuable-by-making-them-scenario-based-87522715cba3?source=rss-b90ef6212176——2