window.addEventListener('load',function(){['ktd-logo-sub','ktd-flogo-sub'].forEach(function(c){var el=document.querySelector('.'+c);if(el&&el.textContent.indexOf('Senior')>=0)el.textContent='Lead UX Designer';});});
Enterprise Coverage Foundations — Kamala Espig
Systems Design · Platform 4+ Features Built On This 2023 – Present

Tidal Cyber  ·  End-to-end UX lead · Sole designer

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.

Five-surface coverage data audit
The five surfaces · Pre-project audit
Before this project, each of the five surfaces referencing coverage data used different language and scoring logic for the same underlying concept.
Foundation work 2023 – Present
Context This work predates the 2026 Coverage Map redesign and the unified landing experience. The rollup surface described here has since been absorbed into the landing page. The coverage model and framework gating rules established here still govern the current implementation.
4+subsequent platform features built on these foundations
executive visibility into coverage posture across the platform
0incorrect visualizations reached customers post gating rules

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.

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.

Cross-surface audit
Inconsistencies mapped across all coverage surfaces

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.

Coverage model documentation
Score definitions, rollup hierarchy, and framework-aware gating rules

The model documentation that became the source of truth for all subsequent feature work — score definitions, rollup hierarchy, gating rules, and framework-aware logic.

The most important outputs weren't screens.

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 established here governed those cases when framework visualization work arrived.