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 professionals who make cybersecurity decisions for their company 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, technical know-how, 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

  • Drew the Driven often felt they still had a lot to learn and therefore fell into this category.

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

Business Team

• Increased sales conversion rates by enabling the sales team to quickly identify prospect security mindsets and tailor pitches to address specific concerns

• Reduced customer support resolution times following the implementation of persona-based training materials for customer success/service staff

• Enhanced cross-functional collaboration with security personas serving as a shared language across previously siloed departments

  • Leveraged persona insights to guide a foundational research initiative (0→1) assessing the viability of implementing attribute-based access control (ABAC) in commercial sectors — traditionally limited to federal contexts — directly informing the company's 2024 strategic roadmap

UX Team

• Provides clear, actionable insights into security requirements and expectations of different user types

• Creates a reusable research foundation that designers can reference across projects, saving time and ensuring consistency

Product Team

• Enables data-driven prioritization of security features based on validated user needs

• Provides a framework for evaluating feature ideas against actual user jobs, reducing development of unnecessary functionality

Engineering Team

• Offers engineers concrete understanding of end users' security requirements and expectations

• Improves technical decision-making when engineers face architecture or implementation choices by considering the security knowledge and behaviors of different Protector types

Customer Success, Support, and Sales Teams

• Streamlines training and onboarding with persona-based educational materials

• Equips customer-facing staff with tools to quickly identify security mindsets and adapt communication accordingly

Marketing Team

• Strengthens security-focused product positioning with authentic user insights

• Enriches content marketing through targeted blog posts and 15+ Voice of Customer (VOC) materials that resonate with specific Protector types

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

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

Jobs-to-be-Done (JTBD): After completing the persona analysis, I collaborated with our product team to identify the specific Jobs-to-be-Done for each Protector persona. This revealed the functional, emotional, and social objectives these users strive to accomplish when managing their company's cybersecurity. Mapping these jobs to each persona provided actionable insights that directly informed feature prioritization and product development.

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.