Continuous threat exposure management, made legible enough to act on

A redesigned reporting flow, an accessible color system, a consolidated information architecture, and a component library migrated onto Tailwind and MUI with the front-end engineer.

I audited the whole experience with fresh eyes before proposing anything. Screenshots marked up with everything that struck me as odd: interactions, missing patterns, inconsistencies, plain questions. Then I presented it to stakeholders as a loose plan of action rather than a finished verdict.

I also scheduled recorded product walkthroughs with people across the company and stayed hands-off, letting each person run it as they saw fit. What someone shows you first, and what they skip, tells you more about the real information architecture than any sitemap. One of those happened over coffee with a front-end engineer who lived nearby. I took handwritten notes to avoid interrupting the flow, with a column for each person's opportunities and challenges.

Four areas the audit surfaced

I also set up a local environment so I could pull builds and see my designs running. That gave me Storybook, where the components actually lived, and the ability to QA in code rather than in a static file.

On my first day the CTO handed me the Export Report screen, a high-touch feature shipped just before I joined. A user generated a report of their current security landscape and hit OK. It asked for too many decisions upfront and pushed the key context below the fold.

This flow was the report card. It was how customers saw whether we were worth the investment, and how they identified problem areas in their own posture. Getting it right early also bought me the credibility to argue for the bigger structural work.

One week, start to delivery

What I could and could not change

The brief I was given was plain: it works well as is, just style it better. Here is what I pushed on and where I landed.

The approach

• Sensible defaults in the export dialog, with progressive disclosure, so the critical context stayed above the fold and the click count dropped.
• Users could expand only the areas relevant to them, drilling into the specifics behind each section.
• Changed the primary button from a download icon plus the word Report to Generate a Report, so the action named itself.

Customers had begun complaining that we did not meet ADA standards. The specific failure was concrete: users with red/green colorblindness could not tell our statuses apart. In a security product, that means the severity of a finding is invisible to some of the people responsible for acting on it.

I established a standardized set of primary, secondary, and accent colors meeting AA and AAA contrast ratios, and simplified the coverage scale so the ranking survived without relying on hue alone.

Menus and icons differed across modules, so users relearned the layout each time they moved between them. I consolidated the information architecture, added proper hover and active states, and removed the brittle dividers that were holding layouts together, so the structure could take new modules without being rebuilt.

A toolkit of reusable components and style guides, so consistency held as the product grew instead of decaying with each new screen. Buttons, input fields, and cards, each with enabled, hover, focused, disabled, and error states defined rather than improvised.

Working with the front-end engineer, we branched the code and migrated from the licensed third-party stack to Tailwind CSS and MUI. We took modal dialogs first, deliberately: they involve the most components, so they proved the value of the migration fastest. Everything was QA'd in Storybook and in live builds.

This is also where the export-flow lesson paid off. Behaviors I could not win by argument arrived for free once the component library brought them by default.

Three continuing threads, each about closing the distance between seeing something and doing something about it.