Creating Role-Based Personas for the Enterprise
In my last article (a two-part series), I outlined special considerations around journey mapping for the enterprise. In this article, I expand on why, for the enterprise, characterizing users in terms of roles is more useful than traditional personas. Further, I’ll explain how to characterize roles so that they have a most meaningful impact on design.
Roles vs. Personas: What’s the Difference?
A role describes a group of individuals who perform the same function. Roles often, though not always, conform to job titles in an organization. An individual’s knowledge, skills, and behavior are bounded (at least at a high level) by requirements of a role. I think of roles as a top-down construct: you can easily create a set of provisional roles by understanding how an organization allocates employee responsibilities. These allocations are typically consistent across companies within an industry, which of course makes sense as it allows for fluidity in the industry’s labor market.
Traditional personas are more of a bottom-up construct based on attitudes, preferences, and behavioral characteristics. These are customarily defined as an outcome of research and may be marketed-oriented or design-oriented. They are ideally suited to characterizing consumers (or B-to-B purchasers) with the goal of meeting their needs and wants.
In distinguishing these two approaches, there is the tricky business of vocabulary. As a de-facto standard in the UX field, any characterization of users is typically called a persona — whether it is role-based or behavioral-based. The term I’ll use for depicting enterprise users, therefore, is a role-based persona, though the artifact itself leans more heavily to understanding the goals, demands, and challenges of a given role.
Behavioral-based personas typically represent a set of fictionalized, archetypal users. Organizations will sometimes use the name of the theoretical user as shorthand for the persona, as in “what would Tiffany want here?”
I’ve also seen fictionalized users created for the enterprise, but this adds an unnecessary layer. In other words, rather than designing for Ron, who happens to be an Escrow Officer, you want to design for the role of Escrow Officer. This approach doesn’t mean you can’t include information about the people that tend to occupy the role — as long as it’s relevant to design. For example, on a recent project for a power utility, one role was particularly attractive to people with a military background, underscoring the highly disciplined demands of the role.
Why Even Do Personas?
At their core, personas should meaningfully inform design decisions, but they can have broader utility in an organization for understanding customers and the challenges they face. Indeed, some of the initial motivations for creating personas were to inject user empathy into the design process, particularly for organizations that tended to be engineering-driven. Product management, customer service, sales, new employee orientation — these are all contexts where personas can be useful. The key is to construct them in a way so that they are clear, simple, and compelling.
In the next sections, we’ll at look four steps to creating role-based personas:
- Identifying the Likely Roles
- Gathering Information about the Roles
- Constructing the Personas
- Putting the Roles in the Larger Work Context
Identifying the Likely Roles
An ideal way to understand roles and prepare for observational research is to interview stakeholders who have regular contact with users: customer service, sales engineers, and sales representatives can all bring this perspective. Based on these interviews, you should get a sense of the likely roles (which may be refined as a research outcome) and be in a good position to plan your research and recruit participants.
Throughout the process of developing role-based personas, it’s essential to think of roles as hats people wear. In smaller organizations, people might perform more than one role, but even in larger organizations individuals may move in and out of roles as part of their daily work experience.
Gathering Information About the Roles
For role-based personas to be effective, they should focus on factors that impact work behavior and performance. Demographic details and other personalizing information typical of behavioral-based personas are unnecessary and could lead to inaccurate stereotyping of individuals in the role.
Over the years, I’ve developed a starting “superset” of characteristics suited to describing enterprise users. It’s helpful to review these characteristics in planning the observational research — to think through the information that is important and appropriate to gather. Not all the factors listed below may be meaningful to the roles you observe, and you may discover other important factors in the course of the research.
In presenting the list below, I provide some examples of the information that might be captured, using the role of Escrow Officer.
Descriptive Elements for Enterprise Roles
A) A mission-type statement that summarizes the role’s main “job to be done.” I prefer the phrasing of a mission statement over a goals statement as the mission can have the added nuance of what motivates people in their role. Example for an Escrow Officer: “I lead individuals through complex and financially significant transactions; for most individuals, it is the largest financial transaction they will ever make.”
B) Whether the role requires general or highly specialized skills/knowledge. Designing for expert-level knowledge can have special considerations, including using domain-specific vocabulary and organizing tasks according to accepted practice. Escrow Officers have specialized knowledge around the legal and process requirements of closing real estate transactions.
C) Typical educational/training for the role. Education and training provide additional information about individuals that typically occupy the role. Escrow Officers often enter the field after high school, starting as an Escrow Assistant. They learn the necessary knowledge for the role on-the-job under the wing of the more senior Escrow Officer (rather than through formal education, though certifications are available).
D)Work activities. This section summarizes the main tasks users perform. For the persona, this should be a high-level list consisting of three to six items (you may have a more detailed accounting of tasks in other artifacts such as a journey map). If applicable, it can be helpful to highlight primary vs. secondary activities. Activities for the Escrow Officer include closing transaction (primary), opening new transactions, and building business relationships with mortgage lenders and real estate agents (building their “book of business).”
E) Work intensity (constant intensity → variable intensity). An Escrow Officer works at variable intensity. The work is deadline-driven, and the intensity depends upon the number of transactions closing in a given day. The last week of the month is always high intensity because lenders are driving to meet their monthly quotas.
F) Stress level (calm → high stress). Escrow is a high-stress occupation, deadline-driven, with many dependencies outside the Officer’s control. To close transactions, they must get required information from outside parties, including mortgage lenders and real estate agents.
G) Focus level (focused → interrupt-driven). The Escrow Officer’s day is interrupt-driven. Unexpected, urgent issues often arise when closing transactions if all required information isn’t available.
H) Level of collaboration (no collaboration → highly collaborative. The Escrow Officer’s work is highly collaborative; they work closely with lenders, real estate agents, and escrow assistants.
I) Internal collaborators includes the roles that work directly together. Escrow Officers collaborate heavily with an assigned Escrow Assistant, and more lightly with the office Branch Manager and Receptionist.
J) External collaborators. A role may or may not have external collaborators — people outside the organization who are part of the workflow (and can represent workflow dependencies). External collaborators for the Escrow Officer include mortgage lenders and real estate agents.
K) Mobility (0% mobile → 100% mobile). Escrow Officers are mobile about 25% of the time, meeting individuals to close transactions.
L) Tools and communication. Tools people rely on in the role can represent design opportunities, but also reflect design conventions that are likely to be familiar. It’s also important to note computer form factors in use (phone, tablet, desktop) and any specialized hardware setups, such as the use of multiple monitors. Escrow Officers use a standard PC desktop; while mobile, they use their phone to stay in touch. Overall, email is central to their workday and getting work accomplished.
O) Work environment. In some work environments, there are special characteristics that impact how work gets done. These include:
- Work Location (100% inside → 100% outside)
- Safety (physically safe → dangerous)
- Noise Level (quiet → noisy)
- Lighting Conditions (low light → full light)
M) Performance measurement and compensation. In the enterprise, it’s essential to understand how people’s performance is measured and how they are compensated. These factors can significantly drive workplace behavior. Escrow Agents’ performance is measured on the volume and dollar value of the transactions they close; they are compensated on a combination of salary and commission.
N) Impacting trends. Industry, technology, or regulatory trends can have near-term and longer-term impacts on a role. Escrow Officers are impacted by changes in loan regulations; tightened regulations create additional burdens when working with mortgage lenders.
P) A picture is worth a thousand words. If at all possible, get permission to take a picture of each person included in your research in their actual working context. You can use these photos to create a photo montage for the role and select a representative photo to include in the role-based persona.
Of course, aside from the facts above, the research should give you a broader understanding of users’ work life, particularly the challenges they face. Escrow Officers must manage a myriad of details for a transaction to successfully close on-time. External collaborators (lenders, real estate agents) sometimes don’t come through with information required to meet deadlines. The workload is unpredictable: closings tend to “clump” at the end of the month, as lenders try to meet quotas. Urgent issues can drive out other important activities, such as building business relationships with lenders and agents.
Crafting a Set of Design Imperatives
All descriptive elements discussed thus far for personas — the work activities and context — these ultimately drive to a set of design imperatives. Design imperatives provide a crucial bridge to design, bringing forward users’ needs in an actionable way.
The example design imperatives for the Escrow Officer (EO) are:
- Proactively surface what needs to be done.
- Make it easy for EOs to pick up where they left off.
- Provide the “big picture” of the workload ahead.
- Automate routine communication, such as following up for information.
- Help EOs nurture and grow their “book of business.”
Constructing the Personas
Now, let’s take all the information gathered during research and put it into an at-a-glance presentation. Keep in mind personas summarize a role — personas should be a quick and easy read. You can always include a more expanded description of the role in a different artifact (such as a research report).
Showing Roles into the Larger Work Context
Showing roles in the broader work context is another crucial bridge to design. As enterprise designers, we ultimately design for task performance and so that perspective is the natural orientation. A journey map is an ideal artifact for depicting the work context because it includes the tasks each role performs, the touchpoints between different roles, and the overall flow of the work. Alternatively, you can create a task matrix, where tasks are represented as rows in a table, with roles in the columns.
Conclusions
Role-based personas are grounded in the realities of getting work done in the enterprise. They describe the demands, challenges, and context of a role — not a fictionalized user archetype. They are most useful when they include a set of associated design imperatives and are put in the context of the overall workflow (such as a journey map).
Like all types of personas, they also need to be present in the organization — easily accessible and actively evangelized. Personas can take all manner of forms, both digital and analog (posters, cards, and tear sheets). The most successful efforts are used not only to inform design but to give all in the organization a broader understanding of the users they serve.
