Focusing on the Right Persona

November 10, 2022

By Jim Beno - Director of User Experience, Skyhigh Security

As a security company, the users of our product typically work in the Information Security (InfoSec) organization. But more and more, we’re finding that our Security Service Edge (SSE) features are targeting users outside the security team: mostly in Information Technology (IT), but also Engineering / Operations. These are the people developing and deploying applications in the cloud, controlling access to them, and ensuring the performance of the network.

There are at least four major SSE workflows or features targeting roles outside the security organization:

• Granting Access to Applications – As companies shift more of their infrastructure to the public cloud, they need to control access to the applications hosted there. Our Zero Trust Network Access (ZTNA) solution provides this capability. Managing these access policies, and responding to employee requests for access, is not the job of the Security Operations Center (SOC). This is a responsibility owned by IT and the IT Help Desk.
• Managing Firewall Policy – With all this infrastructure in the public cloud, for security, companies need to control access not just by specifying “who” is able to use these applications – but also the “how” – the details of which protocols, ports, devices, locations, etc.
• Digital Experience Monitoring – With office locations across the globe and many people working from home, it’s inevitable that some employees will have problems accessing an application or service. Identifying the scope and source of these problems can be a nightmare. When the IT Help Desk calls come in, the security team is not going to be picking up the phone.
• Fixing Misconfigurations & Vulnerabilities – Within IT and Engineering, various teams may be building applications on Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. Our job is to help companies secure these applications, whether it’s the IT Architect responsible for their cloud infrastructure, the account owners that develop and configure the applications, or the DevOps / DevSecOps personnel that deploy them. If we detect a vulnerability or a misconfiguration, the security team does not have “the keys to the castle” to fix it – we have to get the issue in front of the IT or Engineering owner that can make the change.

Creating Personas

At Skyhigh Security, we have dedicated user researchers whose job is to understand customers and generate insights that inform product requirements and design. For each new product capability, we need to ensure we’re targeting the right user, and learn everything we can about them: What motivates them? What tasks do they perform? What applications or systems do they use? How do they collaborate with others? What are their top pain points?

We start by asking these questions to internal team members in product management and sales. We’ll often hold a work session and capture our collective knowledge on a virtual whiteboard. Once we know what job roles to target, we’ll then interview customers and observe how they work. After a few of these sessions, some common themes will start to emerge. We then synthesize all the insights by creating a fictional character – a “persona” – that becomes the focal point for writing use cases and design.

Introducing Fred and Kawika

Lately, our researchers have been investigating two new personas responsible for digital experience monitoring and firewall policy: “Fred” who works in the IT Help Desk, and “Kawika,” the Network Admin. Here are some of the insights we’ve learned from this dynamic duo:

• Kawika is responsible for the performance of the network. When everything’s working, life is good. But when things go wrong, he must drop everything and spring into action. To avoid this, he wants to proactively monitor critical applications on the network – he can’t wait for a bunch of trouble tickets to come in.
• Similar to the SOC, IT has different tiers to handle support issues. When an employee encounters a problem accessing an application, they’ll open a ticket that’s handled by the IT help desk. This means Fred will be first in line to investigate the problem. He has a playbook to guide him through troubleshooting. If it looks like a network issue, then he will escalate it to the Network team. Now it’s Kawika’s turn.
• Diagnosing a network problem is not easy. The network architecture is complex. When accessing a cloud service, traffic from the employee’s device travels across many different networks. There are many variables that can affect performance, and conditions can change over time. To investigate these issues, Kawika must use many tools and consoles to get the information he needs.

Avoiding Ambiguity

All these insights are summarized on single-page datasheets that we’ve created for Fred, Kawika, and their colleagues. We also hold training sessions to introduce the personas to the cross-functional teams. When we hear product managers and engineers reference a persona by name, we know we’ve done our job!

Every UX design flow in Figma starts with an artboard showing the target persona and use case. This way everyone’s on the same page and we avoid ambiguous references to “the admin” or “the security architect.” If we’re reviewing the design and someone questions the target persona, that’s great! We welcome that discussion. In fact, that’s exactly how Fred and Kawika came into existence.

There’s nothing worse than designing and building a new feature, only to find out after it’s released that your assumptions about the target user were wrong. It could have significant implications on the workflow and require a complete overhaul. It’s far better to invest in a little user research up front to validate your assumptions, and make sure you’re on target.