Sigalit Mualem
← Back to work

Malanta.ai · 2024-2026

Imminent Threats: Redesigning from Zero to a Wide Product Vision

My role: Lead Product Designer

3
Structured lenses replacing one flat threat list
2 days
Figma screenshots to a 6-page interactive Cursor prototype
37
Color tokens governing the design system this workflow runs on
280
Page views, the most-visited screen in the app

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: The version I inherited only showed analysts a narrow slice of the threat picture, so they had no real path from 'here's a threat' to 'here's what I should do about it.'

  • Replaced a flat list with three structured lenses that keep context and the next action in one place instead of across screens.
  • Gave analysts a clear first-screen orientation in a dense threat queue, validated with analysts late in the process rather than at the start.
  • 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

Product-market fit wasn't settled going in. Marketing and product management ran structured conversations with potential customers through SageTap; I reviewed the recorded sessions and analyzed the insights to understand who we were actually building for, what bottlenecks came up in how they described their day-to-day workflow, and where their current tools fell short of what we were proposing.
Job to be done: an analyst lands on Imminent Threats holding a raw signal and needs a path from 'here's a threat' to 'here's what I should do about it,' connecting assets, infrastructure, and exposure without switching screens.
Before · Inherited narrow list
Home, before
Version 1 was designed before I joined and reflected a short-range product vision with limited workflow depth: one flat list, no way to group or narrow it.
Analysts needed clearer structure to connect threat signals across assets, infrastructure, and exposure scenarios while moving toward action.
The same two power users who later flagged the alert flood behind Scopes said it here first: hundreds of imminent threats in one undifferentiated list, with no way to see them by what actually mattered to them in the moment.

Approach

Reframed Imminent Threats as a complete decision workflow rather than a static list surface.
Organized the experience around three connected lenses, each a way to group the same alert list instead of one fixed order: by Assets (what's mine), by Attack Infrastructure (what's connected), or by Exposure Scenario (what kind of threat). Scopes later solved the same volume problem from a different angle, letting analysts save their own filtered view; this redesign solved it structurally, in the default grouping itself.
After · Three-lens workflow
Home, after
Iterated closely with PM and R&D to preserve feasibility while expanding product scope.
Validated the restructured workflow with analysts through usability sessions, though most of that validation landed after the information architecture was already mostly locked, a sequencing tradeoff worth naming, not smoothing over.
On my own initiative, rebuilt Imminent Threats from Figma screenshots into a 6-page interactive prototype in Cursor in two days, delivering working flows and a usable spec engineering could build from, not just static screens.

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.

37

Color tokens (Figma Color Styles)

14

Text style variables, 2 typefaces

11

Documented component families

2

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 a single flat threat list with three structured lenses so analysts get detection context and the next action in one workflow.
Built with Product Management, Frontend Engineering, and Security stakeholders, so the model shipped as working information architecture.
No instrumented quantitative metric like time-to-decision or click depth, but a real behavioral signal: both power users actually used the group-by switch, and each defaulted to a different lens, Assets for one, Exposure Scenario for the other, matching what mattered to their own workflow. That's evidence the three-lens choice itself was the right call, not proof of impact at scale.
Six months of platform data filled part of that gap: 280 visits made this the most-visited page in the app, with a median 163-second session, evidence analysts stop and read here, not just pass through on the way to IoPA.

What I'd do differently

Retrospective

  • No instrumented success metric, no time-to-decision, no click depth, shipped alongside the redesign. Watching two analysts choose two different default lenses told me the grouping model was right; it didn't tell me whether the workflow made them faster or slower. That's the first thing I'd fix if I ran it again: define the metric before the workflow ships, not after. Six months post-launch, page-level engagement data (session length, most-visited page in the app) closed part of that gap, though click-depth by lens, which of the three lenses analysts actually use, is still unmeasured. That's the next thing I'd instrument, not the workflow itself.
  • Most analyst validation landed after the information architecture was already mostly locked. Next time I'd pull that testing earlier, even at the cost of a slower first draft.