Threat
Visibility
One legible view of the attacks hitting a customer’s entire ecosystem — and the shortest path from seeing to acting.
The platform continuously discovers, tests, and protects the APIs, mobile apps, web, and cloud services in a company’s stack. This project lived inside the API-protection product: specifically, how to show the attacks hitting a customer’s APIs.
A modern application-security platform.
It continuously discovers, tests, and protects the APIs, mobile apps, web, and cloud services that make up a company’s application stack. This project lived inside the platform’s API-protection product — specifically, how to show the attacks hitting a customer’s APIs.
Surfaces
APIs · mobile · web · cloud
Approach
Discover · test · protect
This work
API attack visibility
My role
Product / UX & data viz
Teams don’t lack data. They drown in it.
A platform watches a customer’s whole ecosystem — mobile, APIs, cloud, web — and every surface streams security signal: attempted exploits, suspicious traffic, schema mismatches. The raw material is all there. What’s missing is a way to stand back and read it.
“What’s hitting us right now, where’s it coming from — and what do I deal with before lunch?”
Readable in seconds. Actionable in one move.
I designed toward five questions a security lead asks on sight. Every chart had to answer one — and encode severity so attention lands in the right place first.
What attacks are most common?
By request volume.
Where do they come from?
Source location.
How severe are they?
Severity encoding.
What's my attack surface?
Affected endpoints.
What are the trends?
Change over time.
Technical, time-poor, always mid-triage.
One primary persona shaped every call: the security lead responsible for threats across a whole portfolio of apps and services — who opens this dashboard between a dozen other tabs and needs the situation in seconds, not a morning of reading logs.
“Tell me what’s being hit and how bad it is. I’ll decide what to do — I just can’t read logs all morning.”
- The important thing is the visible thing.
- One consistent visual language — no hunting.
- Every screen has an obvious “so what.”
Goals
Situation in seconds · triage by severity · act without leaving the view.
Frustrations
The log wall · alert noise · context switching across a dozen tabs.
Grounded in the personas artifact from the project record.
Everyone showed a piece. No one showed the shape.
Three benchmarks — each useful, each partial. The opening was a view that reads the whole landscape at a glance.
A feed of attacks
Useful OWASP-type breakdowns — strong on events, weak on shape.
Organized by attacker
Most-attempted endpoints and types — a different lens, not the first question.
A blocked-request log
Precise, but a wall of rows to read line by line — precision without the vantage point.
Three forks that shaped the frame.
Each was a live option, not a strawman. The design is the sum of choosing the right side of all three.
A live feed
Individual attacks — the market’s default.
Aggregate by type & origin
The shape reads in seconds.
Everything on the front page
Every stakeholder’s signal.
Only the five questions
Earn the glanceable layer.
A static overview
A poster to look at.
A working surface
Scan, filter, drill in, act.
One visual grammar. Five views.
Lead with type & origin. Rank by volume. Encode severity by color. Learn the grammar once on the ecosystem view, and every other screen — endpoints, trends, a single attack, an anomaly — reads the same way, with nothing new to learn.
Ecosystem dashboard
Lead with type & origin, ranked by volume — the shape of what’s hitting the whole stack, readable in seconds.
Attack surface
The same grammar turned on endpoints: which of my APIs is taking the most heat, ranked and severity-encoded.
Historical view
Spot the spike, jump to the window. Volume as a trend answers the fifth question — what are the trends?
From seeing to acting
A working surface, not a poster. A selected attack opens a detail drawer — reusing the platform’s policy-violation pattern — carrying the payload, the path, and the one clear next action.
Anomaly detail
Not every signal is an attack. Anomalies reuse the same drawer — what tripped, the rate against the threshold, the facts — so there’s nothing new to learn.
A chart that’s interesting but ambiguous is worse than none. A critical attack can never read as safe.
Decide what earns the glanceable layer — and what gets demoted.
Promote
Volume, severity, attack surface — the glanceable layer.
Demote
Payloads, request internals — on-demand, in the drawer.
Encode
Severity by color; a critical attack can’t read as safe.
Restrain
A few chart types, used consistently — no novelty for its own sake.
Attacks up front — the glanceable layer.
Anomalies folded in on demand — same drawer, nothing new to learn.
The plan — and an honest line about the record.
Step 1
Test with real users — is it legible, is the remediation flow usable?
Step 2
Refine the encoding and the drawer before build.
Step 3
Partner with engineering on integration and rollout.
The surviving record documents the plan, not a committed KPI or measured outcome. Every figure shown is placeholder sample data — this case study makes no claim it can’t stand behind.
In a data-dense, high-stakes domain, editing is the design.
The hard part isn’t drawing the charts — it’s deciding what earns a place in the glanceable layer, how to encode severity so attention lands correctly, and how to keep the path from “I see a problem” to “I’m doing something about it” short and unbroken. Anyone can add another widget; the value is in what you leave off, and why.
The visualization is the front door. The value is the handoff.
Lead with type and origin. Encode severity so the important thing is the visible thing. Then get out of the way — scan, drill in, act, without ever leaving the view.