Case study · IBM Security / Resilient · UX Designer / Researcher
From Discovery to Design: Artifacts & Related Incidents
Redesigning how security analysts work with Artifacts, the data tied to a security incident, inside an incident response platform. A contextual inquiry into one customer’s workflow drove several rounds of ideation, refined against a panel of existing users.
← All case studiesContext
Assigned to redesign the Artifacts functionality inside Resilient, IBM’s incident response, orchestration, and automation platform. Artifacts represent the data, IPs, hashes, domains, and more, tied to a security incident. One customer wanted to use Artifacts to unlock new workflows. I proposed a contextual inquiry into their actual incident-response process, which led to several rounds of ideation refined against a panel of existing users.
Who, What, Wow
Early research synthesized into a “Who / What / Wow” framing, a way of keeping the whole team aligned on outcome rather than feature requests:
- Who: Security analysts
- What: they use Artifacts to identify prior, already-closed incidents with matching indicators, pulling in remediation history and context
- Wow: drastically reducing manual triage by surfacing related incidents and enabling identical remediation across them
Process
- Ran a deep-dive contextual inquiry: an over-the-shoulder session with a SOC lead at a major enterprise customer
- Conducted six additional user interviews at a customer forum
- Took findings through an early low-fidelity concept first, validated against the current product experience, then multiple rounds of refinement toward increasingly complex bulk-action use cases
What we learned
- Artifacts become more valuable the more context is built around them, and that context is discovered piecework, across multiple places in the tool
- Analysts already informally help each other by annotating artifacts, a signal for formalizing that behavior
- When artifacts span multiple incidents, different teams need to coordinate
- Over time, artifacts reveal patterns useful for a more programmatic defense strategy
Key Decisions
Validate against the current UI first
Rather than jumping straight to a new concept, the first move was annotating what was broken in the existing experience and proposing targeted fixes. A deliberate, low-risk way to iterate.
Behavior-driven framing over feature requests
Using Who/What/Wow kept stakeholders aligned on the outcome analysts actually needed, instead of a running list of feature asks.
Outcome
The final direction let incident responders rapidly identify highly related incidents by shared artifacts, and either reuse a prior remediation path or connect directly with the analyst who solved it before, cutting response time on recurring incident patterns. A bulk remediation workflow for related incidents came out of this work as a clear next opportunity.
A good example of iterating in public: validating against what already exists before proposing something new, and using a shared vocabulary to keep a cross-functional team moving in the same direction.