CASE STUDY → UX ARCHITECTURE FOR CRITICAL INFRASTRUCTURE
UI interface architecture, UX design, complete navigation flows and UX/UI strategy — for a national cybersecurity platform with classified data and zero tolerance for error.
An operational intelligence system at the intersection of UX architecture, backend engineering and national security constraints.
Case study
The full case study will be published very soon. In the meantime you can explore ANA on the official CCN-CERT site.
01 — THE CONTEXT
ANA — Automation and Normalization of Audits — is CCN‑CERT's technical governance solution for managing the cybersecurity exposure surface. It automates continuous vulnerability assessment without human intervention. It integrates with the National Cryptologic Centre's tool ecosystem. It generates early alerts before a threat becomes an incident.
The problem wasn't technical. The platform processed real data from multiple sources with correct logic. The problem was that operators who had to work with it every day couldn't do so with the speed and precision the environment demanded.
The dashboards were built by engineers. The information existed — but without a decision architecture. No hierarchy. No orientation toward the analyst's workflow.
"When the data is correct but the interface doesn't make it operable, the system fails just the same."
ANA operates in high-security environments. Restricted access.
02 — MY ROLE
I joined this project as a backend developer. C#, .NET, MongoDB — I built the data pipelines that fed the platform. The same data I would later have to make visible and operable in the interface.
The company saw potential I hadn't seen in myself yet. They invested in two UX/UI and Product Design master's degrees to enable my transition. I returned to the same system I had built from the inside — this time from the experience layer.
That wasn't an accident. It was the advantage. Understanding the system's architecture before designing how it was displayed completely changed the type of decisions I could make. I wasn't designing on assumptions — I was designing on the real data structure, its relationships and its constraints. There was no handoff between design and engineering. I was the same person on both sides of the table.
Project trajectory Backend → validation wireframes with the technical team → complete interaction layer design → UX architecture leadership for ANA and CLARA — operating as a permanent bridge between engineering decisions and product behaviour.
The structural advantage
The transition was gradual: first wireframes to validate flows with the technical team, then complete interaction layer design, finally UX architecture leadership for ANA and CLARA — operating as a permanent bridge between engineering decisions and product behaviour.
03 — THE CHALLENGE
ANA is not a single-use tool. It's a modular platform with four distinct functional areas, each responding to a different operator profile with different information needs.
The design challenge wasn't each module in isolation. It was creating a system architecture that made the experience coherent across all four — with different roles, different access levels, and workflows that crossed modules without forcing the operator to rebuild context each time.
VULNERABILITIES
Automation and normalisation of the audit process. The operator needs to know in seconds what is critical, what is pending and what has been resolved — without rebuilding that context manually every time they open the platform.
TECHNICAL INSPECTION
Tracking of corrective plans and improvement processes. States, deadlines and temporal evolution. The interface must support that tracking without turning it into administrative overhead.
EXPOSURE SURFACE
The operator assesses an organisation's exposure level considering the operational relevance of each threat — not just its abstract technical severity.
COMPLIANCE PROFILING
Compliance status against official regulations. The operator needs a global reading and the ability to drill into specific entities without losing the overall context.
04 — THE DIAGNOSIS
Before redesigning any screen, I mapped the real workflows. What analysts do when they open the platform. Where they lose time. What information they look for that isn't where they expect it. What decisions they make and with what data.
The pattern was clear.
PROBLEM 1
Navigation was organised by technical modules. An analyst whose workflow crossed vulnerabilities and exposure surface navigated between separate sections, rebuilding context each time. The system was coherent with its own architecture. It wasn't coherent with how a security analyst works under pressure.
PROBLEM 2
No decision architecture. No operational hierarchy. All data with the same visual weight — critical and low competed for attention. The operator mentally constructed the priority the interface should have established for them.
PROBLEM 3
To find the criticality status of an asset group, you had to click in. Blind navigation — click to discover. In an environment where response time matters, every unnecessary click is operational friction.
PROBLEM 4
ANA has multiple profiles — analysts, supervisors, directors. Technical permissions determined access. But the information architecture showed the same to everyone. What an analyst sees and what a director needs are two different things that the platform treated as one.
05 — THE DECISION
The obvious move was to improve each module's UI independently. We had the modules defined, the technical team available and the data working. We chose not to. The problem wasn't visual — it was architectural.
DISCARDED
Would have improved the appearance without changing behaviour. The operator would still be building context manually. Dashboards would still be data inventories without operational direction. Friction would have moved, not disappeared.
DISCARDED
No continuity with the system operators already knew. In high-security environments, resistance to new interfaces is the first adoption blocker. A full redesign without reference to the existing system would have generated a rejection period the team couldn't afford.
COMMITTED TO
A system where the interface establishes context before the operator starts working. Operational information on the surface, not behind it. Structural hierarchy, not just visual. A shared criticality language that works across all modules.
06 — THE SYSTEM · DASHBOARD
The first decision was the main dashboard. The engineering version was technically correct — it displayed the data. It was operationally useless — the analyst mentally built their workflow every time they opened the platform.
The redesign started from a concrete question: what does the operator need to know in the first 30 seconds of their shift?
The answer determined the hierarchy: overall status as the dominant, immediate signal. Total vulnerabilities with visual distribution by criticality. Active audits with progress by system type. Summary view with direct action numbers — assets, resolved findings, pending findings.
Each widget expandable via the + button. The operator decides what information they need visible at each moment without changing screens. They can also reorder cards to match their actual workflow — the dashboard isn't an imposed screen, it's a workspace the operator makes their own.
Learning
The dashboard stopped being a data inventory and became a working surface. Information hierarchy replaced the mental construction of context. The operator arrives, reads, decides.
Prominent overall status, direct action metrics, clear operational hierarchy.
06 — THE SYSTEM · ASSETS
The asset card system was one of the decisions with the highest operational impact in the project.
Before: card with icon and name. To find the criticality status of a group, you had to enter and view the list. Blind navigation in an environment where orientation time matters.
After: each card is an autonomous executive summary. Entity type visible via badge — Group or Asset. Number of assets the group contains. Criticality distribution via numbered colour dots — how many assets are critical, high, medium, low, informational.
The operator scans the view and knows where the problem is without navigating, without clicking, without rebuilding context.
Learning
Operational information on the surface eliminates exploratory navigation in environments where every second counts. The card stopped being access to information and became the information itself.
Each card informs without the need to navigate.
06 — THE SYSTEM · CRITICALITY
The criticality encoding in the previous version was primarily chromatic. The problem with relying solely on colour in a work environment with multiple screens, extended shifts and variable lighting conditions is predictable.
I defined a structural criticality system — not just visual. Five levels with consistent colour encoding across all modules: Critical in purple, High in dark red, Medium in orange, Low in yellow, Info in green. But criticality doesn't live only in colour — it lives in hierarchical position, typographic weight and element size within each view.
A critical finding is structurally different from a medium one. The operator identifies the criticality level even in suboptimal display conditions.
"One system. One language. Zero ambiguity."
Five levels with structural encoding — not just visual.
06 — THE SYSTEM · AGGREGATION
ANA and the CCN ecosystem platforms operate independently. Each lives in its silo. An operator or director who needs the overall security status of their organisation had to open separate systems, navigate each one and mentally construct a unified picture.
I proposed and designed a General Dashboard that aggregates the most relevant information from each ecosystem platform into a single surface. Without replacing them. Without merging them. Each module is an executive summary of its platform — with the same traffic light system, the same information architecture, the same criticality language.
The director sees the overall security status of their organisation in 30 seconds. Without opening three systems. Without building context.
Currently in development. Available to view in conversation.
Learning
Proposing a cross‑platform dashboard in an environment where each tool has its own team and its own data logic requires understanding the systems' architecture from the inside. This wasn't a client request — it was an architecture proposal that came from knowing each platform's backend.
Overall security status in 30 seconds. Without opening three systems.
07 — THE SCALE PROBLEM
The system had to work for analysts with different workflows, in organisations with different structures, under different classification levels. We couldn't validate with everyone. We had to design with enough structural rigour for the system to work in contexts we hadn't seen.
DOCUMENTATION
I generated complete usage documentation for the tool — not as a closing deliverable, but as part of the control system. Every component documented with its inputs, constraints and expected behaviour. A component without documentation in a critical infrastructure environment is a decision without a contract.
COMMUNICATION
I also produced the platform's sales presentations. I understood the product well enough to articulate its value to non-technical clients — translating system architecture into a business proposition. That dual capacity — building the system and communicating it outward — was part of the value I brought to the team.
CONSTRAINTS
In high-security environments, constraints are the working material. The roles and permissions model couldn't be an invisible technical layer — it had to manifest in the experience. The information architecture for each role was designed from the right question: not what each profile can see, but what decisions they make and what they need to make them.
08 — RESULTS
Audit management time
−40%
Reduction in technical inspection management time across security audits.
Reactive speed
×3
Deployment and tracking of corrective measures and remediation plans.
Threat notification time
−60%
Reduction in time to notify new threats impacting the organisation.
Operational context
Analysts took significantly less time to identify priorities at the start of each shift. The workflow-oriented dashboard architecture eliminated the mental construction step they previously performed manually.
Adoption was immediate with no resistance period. In high-security internal platforms, resistance to new interfaces is the primary blocker. Continuous validation with real operators during design generated a friction-free transition.
The role model implemented at the experience layer generated zero unauthorised access incidents. The information architecture met security requirements without additional technical control layers.
The most verifiable result
Classified system
Active production
ANA is deployed and in active use in public and private organisations under CCN‑CERT supervision. A live platform for Spain's national cybersecurity authority. That's the most verifiable result — and the hardest to replicate in a design portfolio.
09 — REFLECTION
Designing for national security analysts teaches something that conventional product design rarely demands: that the interface isn't the product. The product is the decision system the interface supports.
At Vocento, a bad design decision reduced conversion. At ANA, a bad design decision compromised an investigation. That difference in consequences doesn't change the process — it changes the rigour with which you evaluate every architecture decision.
"Systems don't fail because of design quality. They fail because the interface doesn't make the intelligence inside them operable."
What I would do differently
Involve operators earlier in defining constraints, not just in validating solutions. The analysts' operational knowledge emerged in late validation sessions — when some architecture changes were already costly to reverse. In complex systems, constraint research is as important as user research.
