Stage 02 · User research
Who this is for
Two personas, split by behaviour. A third group is named and deliberately excluded. Every block stands on a source, and where there is no source the line says so instead of guessing.
- Behavioural groups
- 2 a third named, not built for
- Practitioner studies read
- 3 two with interviews
- Verbatim analyst quotes held
- 5 was zero at stage 01
- Critique findings on this file
- 19 all verified, all fixed
Stage 01 gathered evidence about the market and a frame about people. Stage 02 replaced part of that frame with data from studies of practitioners. Statements still resting on our own decisions carry PREMISE; statements with no source carry [?] and a way to close them.
01 · Observations
What the research actually established about people
The twenty screenshots gathered at stage 01 prove what vendors sell to buyers. Three of them show a working console from the inside. The other seventeen are marketing pages addressed to a SOC lead with a budget, or reference from outside security.
None of the twenty shows an analyst at work. So everything stage 01 produced about the market is evidence, and everything it produced about people was a frame that marked itself honestly. Stage 02 went and got the rest.
Premise replaced by measurement
| Line | Was | Now |
|---|
| A 24/7 rotation | PREMISE | 79% of SOCs are operational 24/7 [SANS SOC Survey 2025] |
| Two to six years in operations | PREMISE | Three to five years is the most common tenure. 31% stay three to five years, 4% stay ten or more |
| MDR providers carry other companies’ triage | PREMISE | 183 of 443 respondents outsource alerting, meaning triage and escalation, fully or partially |
| The analyst arrives trusting the agent | never stated | The opposite. AI/ML tools rank at the bottom of the SOC satisfaction list. Two of three AI/ML technologies measured rank at the very bottom, generative language tools score 2 out of 4, and 42% of SOCs run AI/ML out of the box with no customization. EDR/XDR is the only technology above 3 out of 4 |
The last row outranks the rest. The category Rasha is issued arrives with a poor record in her own profession’s rating of it. What is measured is satisfaction with a tool category across SOCs, not this individual’s prior attitude toward a new tool [?]: the direction is evidenced, the leap to her personal starting point is ours. Every trust mechanism in Harrier argues with that rating rather than building on a blank slate.
The five behaviours, after follow-up research
| Behaviour | Status |
|---|
| 1. Pattern-matching before reading | Still [?] as a claim about analysts. It now has a vendor’s design bet behind it: Defender generates incident names so that “this specific naming allows you to quickly understand the scope of the incident”. Evidence about the industry’s belief, not about people |
| 2. Satisficing under volume | Supported, by quotes in both practitioner studies |
| 3. Trust set by the last failure | Still [?] as stated, but the starting level is now known and it is low |
| 4. Tenant switching resets context | Supported in structure, not in cost. Microsoft carries Tenant name as a row column, yet opens real work “in a new tab for that tenant” and refuses to assign across tenants |
| 5. Writing for the future auditor | Corrected. The reader is the next analyst, not an auditor |
02 · Primary persona
The adjudicator
Primary
Rasha Idrissi
Tier-2 analyst at an MDR provider, four years in operations
Facts that change the design
| Fact | What it changes |
|---|
| Four years in operations, inside the most common tenure band of three to five years, at 31% | Analysts with three or more years want the system to augment their speed rather than reiterate fundamentals. Clerk does not explain what she already knows |
| A 24/7 rotation at 79% of SOCs, measured across SOCs generally rather than at providers specifically. One interviewed responder describes 12-hour shifts. Remote at least part of the time, 73% | The handoff is written and asynchronous, which is what the sources carry. That it is therefore the first and last screen of her shift is a design decision, not a finding |
40 or more tenants PREMISE | Every queue row has to carry which client it belongs to |
Where she starts
A shift starts with somebody else’s unfinished work. She did not choose this tool; the provider bought it and entered through a bake-off.
What hurts today
- The explanation is missing or too long: “During triage, I ignore lengthy explanations. What I need most are straightforward next steps”, and “diving into deep algorithm explanations slows me down”
- A confidence percentage with no account of where it came from. An explanation is more meaningful “if I have some context about how that percentage was generated”
- No organisational perspective. A detection platform “doesn’t have the organizational perspective… if that is there then it is like wonders”
- Tools explain one alert while she needs the incident: “we have to find a connection between the critical and the high alerts to determine if it’s an incident”
- The tenant boundary is hard in the tool she uses today: real work opens “in a new tab for that tenant”, and “you can only assign multiple incidents from same tenant”
- The end of the shift corrupts the record: “over-utilised analysts are just gonna be ready to just get out and head home. So they just wanna get it done fast, and rush”
How she actually keeps the record
Two behaviours that constrain how the handoff can be built at all. A screen that asks her to compose a summary at 07:00 is asking for the failure mode above.
- It accumulates through the shift. One responder had already built it that way: “I’ve got it set up so it integrates with Teams, so you can actually write it in Teams as the day’s going on”
- What she passes on is signposting, not a document. Four of six responders described the same division: “we put loads of ticket references in so that way it keeps everything in one location… Handovers are more for signposting”
What earns her trust
Not accuracy. Analysts were “consistently willing to accept XAI outputs, even in cases of lower predictive accuracy, when explanations were perceived as relevant and evidence-backed”. And there is a ceiling: more explanation can reduce trust once it introduces confusion or doubt.
Design consequenceThe first thing Clerk shows must be the cheapest correct thing. Depth is one keystroke away, not on screen.
“During triage, I ignore lengthy explanations. What I need most are straightforward next steps.”SOC analyst, RIT study, 24 in-depth interviews. Verbatim, not synthesised.
Still open, as hypotheses
| Assume | Verify by |
|---|
| She recognises the shape of a case before reading it [?] | A timed first-glance test on a queue row with the detail hidden. Three design decisions rest on this |
40 or more tenants per analyst PREMISE | Asking three MDR providers their analyst-to-client ratio. No public source gives one |
| Tenant switching costs her measurably [?] | Timing verdicts on familiar against unfamiliar tenants |
03 · Secondary persona
The rope-holder
Secondary
Tomas Berg
SOC lead and service delivery manager
They do not consume Clerk’s explanation, they audit it. And they decide where the agent earns more latitude. A different job, not a different job title.
Corrected during critique. The first draft supported the auditing half with the finding that analysts with three or more years find step-by-step guidance irrelevant. That finding describes Rasha, who has four years, so it cannot be what separates Tomas from her. The same evidence was doing two contradictory jobs. The claim that they audit rather than consume has no source [?]. Assume it; verify by asking three SOC leads what they open first in a weekly review.
| Evidence that they are a separate person | Source |
|---|
| Intercom ships a separate manager dashboard reviewing AI use | The closest thing in the whole package to evidence that this role needs a surface of its own rather than a permission level |
| Access level changes what a person can see at all: “Based on their access, the information they can see changes… we want to add all of that into a summarized version” | RIT |
| One responder owns their team’s handover procedure and rebuilt shift cycles to cover the busiest hours; another organisation limits handover writing to senior staff | UCL |
| 69% of SOCs still rely on manual or mostly manual processes to report metrics | SANS. That this person is the one who does it is our inference [?] |
| 62% say their organisation is not doing enough to retain top talent | SANS |
No verbatim line from a SOC lead exists in our sources.Left empty rather than synthesised. That absence is itself a finding.
The risk this persona carries forwardWhether Tomas is a user of this console at all is unresolved [?], and stage 02 made it less likely rather than more. Simbian writes that “L3 analysts keep containment authority for anything outside the pre-approved envelope”, and Dropzone is reported to ship Administrator, Member and Restricted Read Only with no autonomy-approver role among them. The industry treats latitude as configuration under a permission, not as a distinct job.
04 · Named and not built for
Three groups that exist and get no design
Junior, Tier-1
The evidence exists: an explainable dashboard could serve as a learning aid by “talking to them like another colleague”, and new analysts writing handovers “talk about anything and everything that’s happened”.
Not a persona, because Harrier’s premise is the residual queue: what survives auto-resolution is precisely what needs judgment.
Consequence if this call is wrong. If providers staff the residual queue with juniors, the product needs a teaching mode, and Rasha’s pain “do not explain what I already know” inverts into its opposite.
Detection engineer
Consumes rejection reasons. No screen in this MVP. Consequence: the rejection interface has to emit something machine-routable, even though we build no surface for the person who receives it.
Client security contact
Never logs in PREMISE. Their trust is built almost entirely out of the summaries they receive. Consequence: the summary is a product surface even though its reader is not a user.
05 · What primary does
Not what it means. What it does
The rule stages 03a, 04 and 07 readA conflict between decisions is resolved in favour of Rasha. She carries the higher risk and holds fewer levers. Tomas’s scenarios must work, but the interface is not built around them.
Criterion used to choose. Primary is the person whose needs are not met by a design built for the other, and who stands closest to the activation node.
Why Rasha. The activation node is First Verdict, and the case file, the product’s centre of gravity, is hers. A surface built for her serves Tomas; the reverse does not hold. This also settles what the main dashboard is: the queue, with the fleet as the resting state of the detail pane, rather than a fleet view with a queue underneath it.
Why Tomas is secondary rather than absent. He owns the SLA and the decision to widen Clerk’s latitude, which is the differentiator itself. He is secondary because his decisions are periodic and considered, while hers are continuous and under time pressure, and an interface tuned for the second case survives the first better than the reverse.