UX-UI · · 6 min read
Designing security products people can actually operate
Security tools fail when the people using them can't understand what they show. Design principles for interfaces where decisions have consequences, from someone who has built them.
I’ve spent around twenty-five years designing digital products, and several of them in cybersecurity: three years as Design Lead at Exein, working on embedded security, and now as co-founder and CTO of Shorium.
The lesson I keep relearning is simple. A security product is only as good as the decisions people can make with it.
Detection, analysis and cryptography can be excellent. If the person in front of the screen can’t tell what matters, why, and what to do next, the product fails at the moment it’s needed.
The two ways security interfaces fail
They show everything. Every alert, every finding, every log line, all with the same visual weight. The interface is technically complete and practically unusable. People learn to ignore it, which is worse than having nothing.
They hide everything. A single score, a green badge, a traffic light. It looks simple and reassuring. But when someone asks “why is this red?” or “are we sure this is green?”, the interface has no answer.
Both come from the same mistake: treating simplicity as the removal of information, rather than as the organisation of it.
Principles I use
1. Start from the decision, not the data. Before designing a screen, write down the decisions the user has to make on it. Patch now or later? Escalate or close? Which product is affected? Every element on the screen should help one of those decisions.
2. Make severity mean something. Severity should combine how bad an issue is with how exposed this specific system is. A critical vulnerability in a component that isn’t reachable is not the same as a medium one on an exposed interface. Show why something is ranked where it is.
3. Always show provenance. Where did this finding come from? Which scan, which rule, which data, when? In security, trust in the tool depends on being able to check it.
4. Show consequences before actions. If a user is about to revoke a certificate, rotate a key or push an update, show what depends on it first. The most expensive mistakes in security are well-intentioned changes with invisible side effects.
5. Design for the incident, not the demo. Demos happen on calm days with clean data. Real use happens at 2 a.m., under pressure, with partial information. Test your interface in those conditions: tired users, incomplete data, many simultaneous alerts.
6. Keep a record of what was decided. Security work is audited, and regulations such as the Cyber Resilience Act require evidence. The interface should make it easy to record who decided what, based on which information.
7. Make it accessible. Security teams include people with different abilities, working on different devices, often under stress. Accessibility here is not a courtesy, it’s operational resilience.
Complexity isn’t the enemy
Security is complex because the systems it protects are complex. The job of design isn’t to make that complexity disappear. It’s to make it navigable: overview first, details on demand, and a clear path from “something is wrong” to “this is what we do”.
That principle shapes how we think about the Trust Twin at Shorium. A model of cryptographic dependencies is only useful if a person can reason with it. I wrote about that in Why I’m building Shorium.
Good security design doesn’t make people feel safe. It helps them be right.