Evan Verdoia

Case StudyThreatPoint

Showing enterprises what breaks first in a quantum-safe migration.

ThreatPoint is an enterprise security product that helps organizations prepare for post-quantum cryptography. I joined as its first designer and shaped it from the first concept.

Role

Senior Product Designer · First Designer

Company

Point Wild

Stage

0 → 1 product

Early ThreatPoint concept for key strength. A chart shows 890 of 8,290 RSA and ECDSA keys below the 112-bit policy floor, a table lists weak and aging keys by severity, and a detail panel for the RSA-1024 key payments-jwt-rsa explains the risk and recommends rotating it.
An early concept for the key strength view: which keys fall below policy, which to fix first, and what to do about each one.

The story

From a generic scanner to what breaks first.

The problem

Enterprises have to move to quantum-safe encryption, but most can't see where their cryptography lives or which systems would break first when it changes.

The turn

I led 14 customer research sessions that moved the product from a generic crypto-scanning tool to blast-radius analysis: showing what a change will break before you make it.

The result

As the sole designer, I took ThreatPoint from its first concept to a live demo at Black Hat 2026.

How I worked

Scaling one designer with AI

Agents inside guardrails

I was the only designer, so I built a system to multiply myself. I ran three to four Claude Code agents in parallel, connected to Figma through MCP. They worked inside guardrails I set up: our design tokens, a CLAUDE.md file that held the project's rules and context, and an explicit rule against creating one-off components.

The agents handled the smaller work: UI updates, visual refinements from internal feedback, and first-pass explorations of blast-radius visualizations. I reviewed every output, mostly for visual quality, and redirected about half of them. One run created a set of new components and changed several established ones, so I reverted it. Another proposed a flow twice as long as the one I'd designed, and I kept mine. Over time I built a skill that asks me follow-up questions before an agent starts, which made the first outputs much better.

Nothing went straight into the product. I reviewed changes in Figma first, and then my front-end developer and I reviewed the implementation in Storybook. The work went to his branch, and we reviewed each pull request together before it was merged into the component system.

Handing off the small work freed me for the hard problems: the data model, the blast-radius graph, and keeping the experience cohesive. The demo we shipped would normally have taken a team of three designers.

Handing off a prototype, not a mockup

We never wrote conventional PRDs. The vision lived in one 24-page thesis from our CTO and founder. Everything else started as a one-page note, and then we went straight to prototyping. Over my last year on ThreatPoint, I moved most of my design work out of Figma and into Claude Code. The usual handoff between designer and developer compressed. Designing, prototyping, and aligning on a feature went from about two weeks to about two days.

I usually ran Claude Code in the terminal with git worktrees, so several sessions could work in parallel without overwriting each other. A prototype skill I built started each session with a subagent that read our design system and existing components. The sessions then built variants on top of that. I compared the results, picked a direction, and refined the UI and interaction details myself.

Instead of a static mockup, I handed off a coded prototype. It had real fidelity, and the edge cases were already handled. Our developers reviewed it and changed what they needed to meet their quality standards. I owned the intent, and they owned the code. The product evolved much faster because of it.

The speed had a cost: keeping everyone current when changes landed every day. We kept a dedicated Slack channel, met daily, and shared quick screen recordings. I also wrote PR descriptions that explained the reason for each change. With no PRDs, those descriptions became our design record.

Full case study · Password protected

The full story is under NDA.

The detailed work sits behind a password. Request access and I'll send it over, or I'm happy to walk through it in an interview.