Tidal Cyber · Systems Design · Case Study

Enterprise Coverage Foundations —
building the platform others would extend.

Before Coverage Insight could be redesigned, Tidal Cyber needed a coherent underlying model for what coverage even meant. This project established that model — the definitions, the rules, the IA — that every future coverage feature was built on. Including the framework-aware gating rules that later governed CIS-18, CSF 2.0, and D3FEND visualizations.

Company
Tidal Cyber
My role
Lead UX Designer · Sole designer
Scope
Strategy · IA · Patterns · Docs
Timeline
2023 – Present
5-surface audit diagram
The five surfaces referencing coverage data: primary map, executive dashboard, rollup view, reporting export, and comparison. Before this project, each used different language and scoring logic for the same underlying concept.
4+
Subsequent platform features built on these foundations
Executive visibility into coverage posture
0
Incorrect visualizations reached customers post-gating rules
The problem

Every new feature was inheriting the same broken assumptions.

Coverage data appeared across the product in multiple places with no shared model underneath. Each surface used different language, different scoring logic, and different visual treatments for the same underlying concepts. Every new coverage feature had to make its own decisions about things that should have been decided once.

The result was a product that felt inconsistent, and a codebase where divergence compounded with every new feature. This wasn't a visual design problem. It was an architectural one.

Why this came before Coverage Insight
Redesigning the coverage surface without a coherent underlying model would have been cosmetic. The foundations work happened in parallel with — and in some cases ahead of — the Coverage Insight redesign, because the redesign depended on having stable definitions to design around.
How I approached it

Audit everything. Define the model. Document it as a system.

I started with a full audit of every place coverage data appeared in the product — not just the primary surface, but exports, rollups, dashboards, and in-progress features. The goal was to find every inconsistency and trace it back to a missing or conflicting definition.

Audit diagram
Cross-surface audit — inconsistencies mapped and traced to missing definitions
Each coverage-related surface audited side by side. Inconsistencies traced to the definition that was missing or ambiguous.

From there I worked with PM and engineering to define the core model: what a coverage score means at each level, how scores roll up, how gaps and confidence are represented, and what rules govern what should be shown when data is incomplete. This work established the framework-aware gating rules that later governed the CIS-18, CSF 2.0, and D3FEND visualization work.

System documentation
Coverage model documentation — score definitions, rollup hierarchy, gating rules, and framework-aware logic
The model documentation that became the source of truth for all subsequent feature work.
Key decisions
Defined gating rules before designing any visualization
One of the most important outputs of this project wasn't a screen — it was a set of rules for when a visualization should not be shown. Deciding in advance what the system won't show prevents a class of problems that would otherwise be caught individually, too late, by different people.
Designed rollup logic to accommodate reporting before it was scoped
Executive reporting was on the roadmap but not yet designed. Rather than building rollups in a way that would require rework when reporting arrived, I structured them to feed that workflow from the start — buying future capability without expanding current scope.
Extended the gating rules to cover framework-specific edge cases
CIS-18, CSF 2.0, and D3FEND each have structural differences — parent/sub-control logic, non-linear scoring, categorical rather than numerical coverage — that a single visualization model couldn't handle honestly. The gating rules I established here governed those cases when framework visualization work arrived later.
Delivered patterns, not just screens
The output included a documented pattern system — coverage components, usage rules, definitions — that future designers and engineers could reference directly. A set of mockups would have diverged from the product. A pattern system becomes the source of truth.
What I took from this
Platform work is slower and more valuable than feature work. Getting the model right once saves every future team from making the same decisions independently — and from inheriting each other's inconsistencies.
Deciding what not to show is a design decision. Gating rules are as important as the visualizations they govern — and much easier to define proactively than to retrofit after edge cases surface in production.
Documentation is a design deliverable. A pattern that can't be understood and extended by someone else isn't done yet.