Context
RedCarbon builds SaaS products for cyber security, using AI to support the work of security analysts. By the time I joined, the platform was already well established and in active use. What it lacked was a settled set of design patterns: years of incremental change had left the same problem solved several different ways in different parts of the product.
The team also needed something it had not had for a while — a designer who could stay with the product continuously rather than in bursts. A designer had held the role before me and could no longer follow it.
- CadenceSeveral features per quarter
- Target usersSecurity analysts & customer orgs
- EngagementFreelance, external collaboration
Challenge
The platform had accumulated design decisions faster than it had consolidated them. There was no shared vocabulary of components and behaviours that development could reach for, so each new feature quietly invented its own.
Delivery pressure was constant: several new features every quarter, on top of continuous repair of what already existed. Design was not keeping pace with development, and the gap was widening the inconsistency it was meant to close.
The approach
I treated consistency as something to be earned incrementally, not declared. Rather than stopping the roadmap to rebuild the interface, I worked inside it: every feature request became an opportunity to define one more pattern properly, get it approved, and put it into circulation. The system was assembled in public, one component at a time, while the product kept shipping.
One intent, one container
I unified the behavioural patterns of the platform: the same kind of action now always opens the same kind of surface.
Identical intents were being served by different containers. Some actions opened a modal, others a side sheet, with no rule behind the split — the choice had been made feature by feature, over years. For the user this meant learning the same interaction twice. There was no genuine alternative here: a platform where the same action behaves differently in two places is simply wrong, and nobody argued otherwise. The real work was not persuasion; it was cost.
A visible convention for AI
I defined a dedicated colour and iconography convention that marks every AI-generated or AI-assisted element in the interface, aligned with the requirements of the EU AI Act.
The EU AI Act requires that users be able to recognise, without ambiguity, every piece of data that AI has processed, entered or transformed — and the requirement bites hardest in sensitive sectors like this one. It also happens to be sound design. In a security product, the line between what the system inferred and what is established fact changes how an analyst weighs the information in front of them. Again there was no competing option: once the requirement is understood, the only question is how far the convention has to reach.
Rebuild the surface, not the foundations
I ran the global UI update as a stepped process, with each new component approved individually, instead of a single large-scale intervention.
The product needed better scalability, clearer data legibility, and accessibility that met WCAG AA as a minimum — by then a legal requirement, not a quality target. The obvious route was a deep rework of the interface layer in one pass. The alternative I chose was slower and less satisfying to look at mid-flight, but it did not require the team to touch large amounts of old code at once, which on a live security platform under quarterly delivery pressure was the difference between a plan that could run and one that would stall.
Deliverables
50+ components
With variants and usage rules.
100+ screens
New screens and the patterns derived from them.
20+ flows
Alert triage, source configuration, the analysis surface and customer-side configuration.
3 flows by case type
Split by analyst activity, with every individual action inside the platform traced as a flow.
Navigable prototypes
Scrollable prototypes built around the way the team actually worked.
Product nomenclature
Defined and revised the terms used across the interface.
Infosecurity London
Speech presentations and the accompanying booth for the company’s conference appearance.
Constraints
- Sole designer on a platform with a multi-feature quarterly cadence.
- External collaborator, without the ambient exposure to users and internal discussion an in-house designer accumulates by default.
- Live product with history: every pattern change had to land on code and behaviour that already existed and could not be paused.
- Limited direct access to end users: analyst interviews happened once, around a specific feature.
- Regulatory frame: AI-facing interface decisions had to satisfy the EU AI Act, not only usability.
- Accessibility as a floor, not a goal: WCAG AA compliance at minimum, constraining colour, contrast and data density across every component.
Research inputs
For one feature I worked directly with security analysts, through interviews and a feedback exchange. It was the only structured contact of that kind across the engagement, and it noticeably improved the outcome for that feature — which is part of why I would build the rhythm differently now. Beyond that, I ran my own research into the sector to ground design decisions in how SOC work is actually performed.
Handoff
I designed inside the team’s Agile cycle rather than alongside it. Each change or new feature started as design, then went through a couple of passes with the development leads to check technical feasibility and prepare the handoff. Feasibility was treated as an input to the design, not a verdict on it, which is what made the incremental strategy in Decision 03 possible.
NDA
No product screens, client data or interface material can be shown for this engagement. What appears here is the reasoning, abstracted: rules, conventions and sequencing rather than the surfaces they were applied to.
What I’d do differently
I would organise my work as an external collaborator differently, so that I could anticipate user needs rather than respond to them. Working feature-first meant I was usually solving the problem in front of me. With a better rhythm of contact with real analyst work, I would have seen some of those problems coming a quarter earlier.
