A cloud security console that made automated protection observable.

Glasswall Email Interceptor is a cloud security console. It intercepts email attachments, sanitizes them through Content Disarm & Reconstruction, and delivers a rebuilt file that carries none of the original threat.

The technology already worked. What the product needed was a way for a security administrator to see it working, and to explain it to someone else afterward.

Four things make that possible:

None of that structure came from the technology. It came from what the problem turned out to be.

I led product design from early validation through interaction design and usability testing, working closely with product leadership, engineering, cloud architects, and security subject-matter experts.

Because the product introduced a new way of operationalizing Content Disarm & Reconstruction, much of the work was translation: taking highly technical security concepts and turning them into workflows administrators could understand, trust, and act on.

The challenge extended past designing screens. Administrators would ultimately be accountable for decisions the system made on their behalf, so every workflow had to balance automation against transparency. Success depended on building enough shared understanding across product, engineering, and security that automation could feel observable, explainable, and trustworthy.

Before any interface work, I spent time with the cloud engineers and product leadership working out what the system would actually do. Not as a hand-off or a requirements review, but as design work. In a product where every screen is a report on an automated decision, the behaviour of the system is the interface.

The method was to draw it. I brought diagrams into working sessions rather than documents, because a diagram is something a group can disagree with precisely. Engineers could point at a path and say that isn't how the service behaves; product leadership could point at another and say we're not funding that in v1. Both are answers you want before you've designed a screen around them.

Mapping this way kept surfacing decisions nobody had made yet, and they were rarely purely technical. If a file is held, does the recipient learn it existed at all? When a file is replaced, is a text extract or a screen capture the honest substitute? Who is allowed to request a release, and what does an administrator need to see before approving one? Those look like engineering questions and they are product questions, which is exactly why they needed both groups in the room.

Three things came out of working this way. The interface was designed against what the system could really do, instead of an optimistic version that would have to be walked back. Scope conversations got concrete early, because cutting a path on a diagram is cheaper than cutting a screen. And the team left with one shared vocabulary for these outcomes: held, replaced, released. That became the language the transaction log itself uses.

Instead of treating CDR as a background service, the interface was designed to surface every layer of the process. Each automated action had a visible explanation an administrator could point to.

Four questions the interface has to answer for every single file:

Those four answers are what turns a black box into a record. An administrator who can answer all four can defend the outcome to an auditor, a manager, or the person whose attachment was rebuilt.

Policy changes carry real risk. A single misconfiguration can expose an entire department, and the administrator making the change usually finds out after the fact.

Three decisions moved that discovery earlier: the interface shows a policy's scope before activation rather than after, it mirrors Azure's group structure so the administrator isn't holding two mental models at once, and it replaces command-line workflows with visual confirmation.

Each rule states its own consequence in the column header: sanitise balances usability and security, allow keeps risky active content, disallow stops the file entirely. An administrator tuning a policy can see what they are accepting at the moment they accept it.

Together those let administrators change policy with confidence rather than caution, which in practice is the difference between a policy model that gets tuned and one that gets frozen.

Success wasn't defined by task completion time. It was defined by whether administrators could explain their decisions afterward, and whether they trusted the system enough not to manually reprocess files.

Three things were measured: