Cybersecurity User Personas

Understanding “Protector” Personas for Enhanced Alignment Around Users

Jump to:

• Background

• Key Insights

• Research Impact

• Methodologies

• Reflections & Learnings

Problem Statement

We aim to gain deeper insights into the needs and motivations of cybersecurity professionals to identify opportunities for enhancing our existing products, thus better serving them and alleviating their pain points.

Hypothesis

Through insights from our Marketing team's Buyer personas and data from our Sales team, the hypothesis is that the Protector personas will break down predictably based on market size.

Research Goals

1. Learn about what most troubles cybersecurity professionals and identify the root causes of these concerns.

2. Examine the distinguishing characteristics among different Protector personas and explore the factors that contribute to their differences.

3. Discover which security tools are the most important to Protectors and why.

Protector Persona: Andy the Authority

• Responsibilities are more technical than operational

• High technical know-how

• High confidence in their security knowledge

• Feelings: Satisfied, Frustrated, Anxious, Overwhelmed, Heroic

• Andy represents a user with a deep understanding of cybersecurity and technology. They have a long history working in information security and stay informed of new trends in the field, including new products and new weak points.

Protector Persona: Drew the Driven

• Mix of technical and operational responsibilities

• High technical know-how

• Medium confidence in their security knowledge

• Feelings: Stressed, Satisfied, Frustrated, Bored, Challenged

• Drew represents a user with a medium level of cybersecurity knowledge and a high level of technology knowledge; they recognize that they still have much to learn when it comes to security. Drew may transform into an Andy later on in their career as they learn and gain more experience in security.

Protector Persona: Gil the Gatekeeper

• Responsibilities are more operational than technical

• Low technical know-how

• Low to medium confidence in their security knowledge

• Feelings: Frustrated, Annoyed, Stressed, Worried, Angry

• Gil represents a user in an executive or managerial role who does not have a strong understanding of cybersecurity as a field, despite making security product decisions. They know the basics but their background is operations-focused. They need help filling in the gaps when it comes to technology and security.

Insights

1. The Protectors did not divide along market size or by industry.

   • Rather, all market sizes were represented within all three Protectors.

   • More important were their feelings, the average number of security tools their company uses, etc.

2. I had to consider the Dunning-Kruger effect when measuring security confidence level.

   • Doesn’t realize how much they know

     • Andy the Authority can fall into this category because they feel there is always more to learn, especially in cybersecurity.

   • Knows what they know

   • Knows what they don’t know

   • Doesn’t know what they don’t know

     • Gil the Gatekeeper can fall into this category. Some of the Gils thought they knew more than they did.

For further information on findings and insights, please contact me.

UX Team

• Offers a clear understanding into the security requirements and expectations of users.

• Researchers and designers can reference these personas over and over in future projects.

Product Team

• Allows product managers to make informed decisions about feature development.

• Guides the creation of security-focused features and functionalities that align with the needs and pain points of Protectors.

Engineering Team

• Provides insight into who engineers are building for and what their security needs are.

• Protectors can be used as shorthand in engineering and technology conversations when referencing this user type.

Customer Success, Customer Support, and Sales Teams

• These teams use the Protectors in training and onboarding new team members.

• Provides guidance on how to recognize the different Protectors and how best to communicate with each of them.

Marketing Team

• Assists in positioning the product as a secure solution and in targeting marketing campaigns more effectively.

• Marketing has used the Protectors when writing blog posts and Voice of the Customer posts.

Some of the key methodologies for this project are listed below, with explanations as to why they were chosen for this project:

Personas Course: Prior to starting the Protector Persona project, I took a one-day Nielsen Norman Group course about personas called Personas: Turn User Data Into User-Centered Design. This course outlined the differences between personas vs. archetypes vs. proto-personas and also demonstrated synthesis methodologies to use.

User Interviews: Due to our hypothesis, I planned to complete at least 30 interviews — 10 enterprise security professionals, 10 mid-market security professionals, and 10 small business security professionals. In the end, I completed 31 user interviews, recruited through UserTesting. Because our targeted audience (security professionals) was niche, we iterated on our screener multiple times in order to find the right people to talk to.

Segmentation Analysis — Attribute Exploration: After concluding the interviews, I applied the segmentation analysis technique I acquired during the NNG class. In this methodology, you create a table with various column headers, each representing different topics or attributes discussed, such as Feelings, Responsibilities, Industry, and more. Subsequently, you populate the table with each row corresponding to an interviewed interviewee.

Segmentation Analysis — Dimension Analysis: Following the completion of attribute exploration, I initiated dimension analysis. In dimension analysis, you establish "dimensions" that can be either categorical or continuum in style. In categorical dimensions, you create categories by drawing a line and dividing it into segments, each representing a different category based on the attribute. For example, for the attribute "Feelings," categories might include "Satisfied," "Angry," "Overwhelmed," and so on. In continuum dimensions, you draw a line where each end signifies a distinct attribute. For instance, in the case of the attribute "Responsibilities," one end of the line would denote "More Operational," while the other end would represent "More Technical." You then plot the interviewees on a dimension for each attribute outlined in the attribute exploration table and begin to see clusters or groupings to differentiate between the different personas.

Persona Skeletons: After I finished synthesis, I began outlining the Personas in FigJam based on the three groupings I saw during Segmentation Analysis. I called these “Persona Skeletons” because they were another level of synthesis. There was no real layout of the information but more just trying to see each persona in its entirety. This also helped me better understand the differences between personas.

Visual Design & Illustration: After finalizing the Persona Skeletons, I designed (and iterated on) how to present the Protector Personas visually to the company. Each persona was represented by two cards: one containing persona details and the other addressing assumptions, which were based on our initial hypothesis and stakeholder interviews. To mitigate bias, I created three different illustrations for each persona, to emphasize that each persona is a category and the illustrations are just examples of who that persona could represent. This approach aimed to enhance empathy for the personas and reduce potential biases.