Malanta.ai · 2024-2026

Imminent Threats: From a Narrow List to a Full Analyst Workflow

My role: Lead Product Designer

3: Ways to group the same list: attack infrastructure, assets, exposure type
2: Main users, and each one picked a different view
2 days: Figma screenshots to a 6-page clickable Cursor prototype
37: Color tokens in the design system this workflow runs on

Tools

CursorFigmaDesign SystemGitHub

Teams

Product DesignProduct ManagementFrontend EngineeringSecurity Stakeholders

Bottom line

My role: Lead Product Designer. I owned the product framing and interaction architecture for the Imminent Threats workflow, from first sketches to final delivery, including the design system it's built on.

The problem: One long list of hundreds of threats. In session recordings users scrolled, clicked at random, and left, and in conversations they told us they couldn't find their way.

Product's first fix, nesting alerts, confused users. Product then moved to my proposal: attack infrastructure first, with a toggle to group by asset or exposure type.
In every view, each row still shows how many attack infrastructures and assets are involved, so product's main signal is never hidden.
Built the three-lens model on a governed design system (37 color tokens, 14 text styles, 11 component families); the same system now runs IoPA, Scopes, and the threat card, not just this screen.

Challenge

Job to be done: an analyst lands on Imminent Threats and needs to find what to check first, and move from 'here's a threat' to 'here's what I should do about it'.

Version 1 was designed before I joined: one long list of hundreds of threats, with no way to group or narrow it.

Imminent Threats before the redesign: one long flat list of exposed subdomains with no grouping — Before · One long list, no way to group or narrow it

We saw the problem from two directions. In session recordings, users scrolled for a long time, clicked at random, closed the panel, kept scrolling, and then left. In conversations they said: "There are hundreds of alerts. We can't find our way." Many rows weren't urgent, and the order wasn't clear.

Product-market fit wasn't settled yet. Marketing and product ran conversations with potential customers, and I reviewed the recordings to understand who we were building for and where their current tools fell short.

Approach

Decision 1, a disagreement. Product wanted the screen to focus only on attack infrastructure (the servers attackers prepare), because that's what made the product different. The product manager sat with me in the user conversations and heard users say they were lost. His first fix nested many alerts inside one, by rules users didn't understand. They couldn't tell why one alert sat outside and the rest sat under it.

After we saw that it didn't work, the product manager moved to my proposal. Attack infrastructure stays the main view, biggest first, because that's the first thing worth investigating. A toggle groups the same list by asset or by exposure type, in A to Z order. Inside each group, alerts are sorted by time. Our cyber researchers' data showed we had what we needed to group this way. What I gave up: attack infrastructure is no longer the only focus of the screen.

Imminent Threats after the redesign, grouped by attack infrastructure, biggest group first — After · Main view: grouped by attack infrastructure, biggest first

Decision 2: every view still shows the attack infrastructure at a glance. The risk of switching views was missing the most important signal. So in every view, each row shows how many attack infrastructures and how many assets are involved. Users can decide what to handle first in any view, and product's main signal is never hidden.

The same list grouped by asset, each row showing its attack infrastructure count — Toggle · Grouped by asset, attack infrastructure still on every row

The same list grouped by exposure scenario, each row showing asset and attack infrastructure counts — Toggle · Grouped by exposure scenario

So engineering could see every view, I rebuilt the screen from Figma screenshots into a 6-page clickable prototype in Cursor, in two days, on my own initiative.

Design system, in service of four workflows

Built as delivery infrastructure, not decoration

The three-lens model only holds together if every card, badge, and panel across Assets, Attack Infrastructure, and Exposure Scenario reads as one product. That meant governing a Figma library, a component Gallery, and the shipped code as one distributed source of truth, with a named rule for which layer leads when two disagree.

This is the same system that runs IoPA, Scopes, and the threat card: one set of tokens and components, not a separate visual language per screen. Documented here because Imminent Threats is where the governance model (the Gallery contract, the light/dark parity check, the code-reveal loop) took shape first.

I treated the Gallery as the contract surface: every variant had to be visible in light and dark mode before it counted as done, and I verified the Figma MCP integration end to end (auth, file key, metadata reads) before trusting it in a design review, the same way I'd verify a junior's claim that something works.

That self-initiated build fed into the design system's move to Storybook: once engineering shipped the components there, I could update them directly alongside Cursor instead of routing every tweak through a handoff.

Color tokens (Figma Color Styles)

Text style variables, 2 typefaces

Documented component families

Modes: light + dark, parity-checked

Blue scale

100

#F0FDFF

200

#D9F8FE

300

#8CC7DC

400

#06B6D4

500

#028FC2

600

#0E7490

700

#155E75

800

#164E63

900

#012F69

Foundation

Canvas

#FAF9F5

Light 100

#FFFFFF

Light 300

#F2F2F2

Light 400

#D1D1D1

Dark 600

#0F3443

Dark 700

#0D2C38

Dark 800

#0A212A

Dark 900

#010B0D

Ascent

200

#F6E2D0

300

#FFB37F

400

#BCCCEC

500

#7E78C1

600

#AD009F

700

#1447E6

Status & category backgrounds

Low

#DCFCE7

Critical

#FFE2E2

High

#FCEBD4

Medium

#FFF1C8

New

#E1F7FF

Manual

#DBEAFE

Auto

#F3E8FF

Reputation

#FFE1FD

Wrote visual consistency as policy with documented exceptions, not tokens alone: for example, a uniform 1px icon stroke everywhere except the page-level help icon, which stays thicker on purpose so it doesn't get lost.
Gave every Gallery variant a code-reveal control so an engineer could copy exact JSX instead of eyeballing a screenshot, closing the parity loop deliberately instead of hoping it held.

Impact

Replaced one flat list with three ways to group it, so analysts can start from what matters to them: attack infrastructure, their own assets, or the type of exposure.

Both main users used the toggle, and each chose a different view: assets for one, exposure type for the other. There was no single right view for everyone. That's a strong signal the choice was right, not proof of impact at scale.

The lesson: group the way users think, not the way the data is built. The first try grouped by rules users didn't understand. Clear groups with a clear order worked.

Mixpanel showed only a few uses of the toggle, so I don't present usage numbers as proof. Imminent Threats is the screen that opens first when you enter the product, so its visit count doesn't show whether the design worked.

What I'd do differently

Retrospective

We didn't measure the grouping properly: no dedicated tracking was set up for the toggle. Today I don't ship a feature without deciding first how we'll measure it: which view people use, and how fast they decide.
Most validation with users came after the structure was already mostly set. Next time I'd test earlier, before the structure is final, even if the first draft takes longer.