← Back to work Case Study 01 · Security / Data-heavy UI

Signal, not noise.

Client: Security platform — international company, under NDA
Role: UX research + UI/UX design
Scope: Research · Prioritisation model · Data visualisation · UI
Status: Shipped — brand & data masked

1/ Context

The product scans a company's Java fleet — over a hundred JVM instances, JDK 8 through 21 — and flags known vulnerabilities in the components running on them. The engine was strong; the dashboard wasn't. It presented findings as a flat CVE list: technically complete, practically unreadable. Engineers spent their time working out where to look instead of fixing.

My brief was to rethink the dashboard from scratch so engineers find real problems faster — data visualisation first, and a clear prioritisation of the things that actually get vulnerabilities fixed. My part of the project was the research and the UX/UI; the client is an international company, so the brand and the data here are masked.

2/ The work

Research with the people in the trenches. Sessions with security analysts and Java engineers about how they actually triage: what they check first, what they export to spreadsheets, and which questions the old screens couldn't answer.
Reframe the priority. The key insight: severity alone doesn't rank the work. A critical CVE in a library nobody calls matters less than a high one on a live execution path. The redesign leads with reachability and fleet impact, not just CVSS numbers.
Charts that answer triage questions. Every visualisation earns its place: the CVSS distribution shows how bad the backlog is, disclosure-vs-remediation shows whether the team is keeping up, predictive analysis flags which components break next.
The Fleet Matrix. The centrepiece — components × JVM instances as a reachability heatmap. Hue encodes severity, opacity encodes reachability confidence; a filled cell means vulnerable code sits on a live path. One screen replaces a week of cross-referencing.

3/ Screens

Vulnerability detection dashboard: fleet KPIs for affected components, classes and methods, CVSS score distribution, disclosure-vs-remediation trend, predictive analysis and a severity-sorted CVE table — The overview — affected components, classes and methods against fleet totals, and a CVE table sorted by what to fix first, with per-CVE fleet impact.

Fleet Matrix: a heatmap of vulnerable components across JVM instances grouped by service, where colour is CVSS severity and opacity is reachability confidence, with fleet hotspot rankings alongside — The Fleet Matrix — reachability across the fleet. A filled cell means vulnerable code on a live execution path; the hotspots rail names the instances and components that hurt most.

4/ Outcome

The dashboard now answers the only question that matters in the first ten seconds of a session: what do I fix today? Sixteen open CVEs arrive as an ordered, reachability-ranked to-do instead of a wall of red — and the arguing about priorities moved from meetings into the interface.

🔒 Specific numbers are under NDA — the full story, research artefacts included, is available in a call.

Drowning your engineers in data instead of answers?

Book a walkthrough →