Scopes & Workspaces: From Alert Flood to Focused Triage

Challenge

Approach

—Before any design work, defined what a Scope actually was: a workspace? A fully separate account? Mapped the range of users it needed to serve, from a single independent operator to a super-user with access across many unrelated organizations. Researched direct competitors (Jira, Microsoft) and indirect ones (Gmail, Notion) on how they handle switching between separate content worlds inside one account.

—V1 placed scope creation in a header dropdown, grounded in that competitor research but still invisible; interviews confirmed people had simply never seen it.

—V2 moved it to a persistent, always-visible left sidebar. Page visits picked up, but scope creation itself stayed flat.

—Follow-up interviews surfaced a trust problem, not a navigation one: "What happens if I delete a scope? Do my domains disappear?"

—The V2 update added intentional friction as trust scaffolding: confirmation dialogs, inline explanations, and first-run guidance.

—Confirmation dialogs, inline copy, and the sidebar itself come out of the same system governed in Imminent Threats, rather than being invented fresh for Scopes, part of why the trust scaffolding reads as consistent with the rest of the product instead of a one-off intervention.

Impact

▸Watched one customer build their first scope live, guided, during onboarding: of roughly 400 alerts, about 20 belonged to high-priority assets that actually needed investigation, proof the mechanism works when someone walks through it with you.

1

2

• 1Scope switcher, always visible: The V2 fix: moved out of a header dropdown into a persistent sidebar spot, so the active scope is never a guess.
• 2Scoped view: 79 threats, not the full queue: Splitting off a scope is what let this analyst see a manageable count instead of re-triaging every alert in the account.

▸That guided success hasn't translated into independent use: across 6 months of platform data, only 1 scope was ever created outside a guided session, and that one wasn't a customer acting on their own. 14 customers visited the scope management page 54 times combined; none completed the flow unassisted.

▸A separate customer conversation confirmed awareness without action: they understood the feature and the trust-scaffolding change, but had no active need for a second scope at that moment, a reminder that comprehension isn't the same as a use case pulling someone through.

Validation

Two flatlines, two separate rounds with the same two analysts

Same research relationship as IoPA: 2 embedded power users, not external test subjects, in a SOC analyst base too small (5-10 active users at any point) for a quantitative test to mean much on its own. Here that relationship split into two distinct rounds, one after V1 shipped and flatlined, one after V2 shipped and flatlined again, so I could tell whether the second failure had the same cause as the first before proposing V3.

What I'd do differently

Retrospective

• —V1 was grounded in competitor research (Jira, Microsoft, Gmail, Notion), not a guess, and it still shipped without usability-testing the actual placement on our own users first. V2 shipped without testing its trust hypothesis either. Two flatlines in a row is the cost of that: I'd pull a lightweight test of the actual blocker before either launch, not after. Competitive precedent tells you how other tools solved it, not whether your users will find it in your product.
• —The trust-scaffolding pattern (confirmations, inline explanations, first-run guidance) hasn't been validated on a feature outside Scopes yet, it's a hypothesis about high-stakes security UX in general, not a proven one.
• —Six months of platform data confirm the trust hypothesis was right but incomplete: it removes hesitation once someone is already in the flow, guided. It hasn't yet produced a single unprompted, independent scope creation. Next test: a lighter-weight nudge tied to an actual moment of alert overload, instead of relying on users to find scope management cold.