Generating Security Personas

Context

When I started as a UX Researcher at Illumio, the product team was working without user personas. Most of the product managers had used them in the past and thought that referencing personas would help more people think concretely about the users and have better conversations. The need was there, but no one had experience with building formal personas. After I’d been oriented and trained on the product, the CTO approached me and asked how we could get started.

Goals

The aim was to create concrete user models so product managers, engineers, and designers could talk about the same people—and so those models would guide design decisions. Personas needed to be vivid enough to convey useful detail, compact enough to stay usable, and grounded enough that teams would trust them in planning conversations.

Solutions

The first collection centered on two design-facing personas, plus a proto-persona for a role we would not design for:

• Mark — Network Security Administrator (primary design target)
• Melinda — Software Engineer, in-house
• Mathila — Software Engineer, outsourced (proto-persona; not a design target)

Process

I proposed a project that would take 2–4 weeks, depending on the availability of collaborators and subjects. I described the first four steps and got approval for that, including a budget for travel if that became necessary. Here are all the steps:

1. Defining internal expectations and priorities
2. Data collection in the field
3. Synthesizing results
4. Producing the personas
5. Socializing the personas
6. Updating personas
7. Expanding the collection

Defining internal expectations and priorities

I scheduled meetings with PMs, engineers, designers, and support staff to find out

• what they assumed about the users (e.g. “Users think of server attributes in a certain order: where it is located, then what application it serves, then what environment it belongs to.”)
• what questions they had (e.g. “Is it easy for users to understand how to use a node-link diagram?”)
• which workflows were most relevant (e.g. authoring network security policy drafts, turning those drafts into active policy)
• what kind of data would make them skeptical (e.g. "don’t just show me someone from company x, because there’s only a couple of companies like that”)

Interviewing users in the field (security administrator profile)

Topic areas:

• Typical day, Typical week
• Objectives and how success is evaluated
  • how is time allocated between responsibilities
  • what are the success criteria
• Common tasks and workflows
  • what tasks do you do most often? can you show me?
  • what tools do you use for that?
• Organizational context
  • who do you collaborate with?
  • who relies on your work?
  • who can block your work?
• Frustrations

Visiting customers required more elaborate communication and scheduling. This was sometimes expensive and more time-consuming, but the benefits outweighed the cost. The data was so much richer, the picture of the customer and context was much fuller, and the rapport that formed facilitated future research. I usually had a designer with me, and we took turns taking notes and asking questions. We watched customers do tasks and used whiteboards a lot to capture and validate what they were describing.

Here are some whiteboard shots from a trip to two different customers in Illinois.

Analyzing the data

I started by moving the data into a loose matrix that organized interview observations by topic area. Above you can see what it looked like as it started to fill in. Within each topic, there were patterns that started to reveal themes. Here are a couple of examples.

• Within the topic of goals, the job of creating a labeling schema became a theme. Specifically, there were common anecdotes about how first versions of a schema didn’t work and needed to be scrapped. This theme became one of the frustration items in Mark’s persona.
• Within the topics of skills and responsibilities, the ability to specialize became a theme. Some were given ample time to learn segmentation-specific skills, while others were not. This became a key dimension for comparison: “specialized team to manage segmentation.” Comparing users on this dimension served as a powerful predictor of success with the product.

Producing the personas

This was a matter of choosing relevant details that make the persona vivid and convey information that will guide design decisions. The persona should be compact, so of course some findings are left out.

Were the personas effective and clear? I chose a few representatives from engineering and design to get feedback on the first drafts. They had great suggestions.

Impact

Socializing the personas

To aid adoption, the personas needed an introduction. I did a tour with all of the stakeholders from step one and their teams, getting their feedback on the first version of Melinda and Mark. I did a presentation at a company all-hands as well.

Before the introduction, I used teasers to try generating some buzz. I added “Who’s Mark?” to my email signature and had confederates ask their coworkers if they’d been hearing about someone named Mark. I’m not sure how well it worked. I did quickly learn that most people thought the names were very plain.

Updating personas

Since personas are really a snapshot, over time the details can become less representative. New details may become relevant. Here’s an example. As the customer base grew, we began seeing more organizations that were outsourcing some of the software development work. I updated the Network Security Administrator to describe the situation where

• external developers did not know what network traffic was required for their applications
• it was not possible to grant access to external developers so that they could investigate the traffic on their own

Expanding the collection

I also created a proto-persona to represent the external developer. This persona was someone we would not design for, since they won’t be expected to have access to the product. Because of the limited applicability, I didn’t spend time interviewing people in that role. I used second-hand information: descriptions from customers interacting with people in that role. It was useful to reference this persona when talking about the increasingly common situation where network information was hard to acquire.