Case Study — Government Data Platform

Koverse.
Designing for decisions
you can't take back.

When data engineers configure access control on classified records, they make permanent decisions. Most of them don't fully understand that — until it's too late. My job was to make sure they did.

Role
Lead Product Designer
Team
SAIC Innovation Factory
Stack
React · Figma
Timeline
2021 – 2025
Status
Deployed across DoD naval and classified government programs
Koverse Aether main dashboard

The Problem

One wrong decision.
Permanent consequences.

Koverse is a data platform for ingesting, managing, and analyzing large datasets in secure government environments. Its most technically significant feature is ABAC — Attribute-Based Access Control — a security mechanism that determines who can see what data based on matching attributes between records and users.

Configuring ABAC correctly at the moment of ingest is critical. Getting it wrong doesn't just cause access issues — it can result in classified data being exposed to users who shouldn't see it, or locked away from analysts who need it. And once the data is imported, the ABAC labels can never be changed.

"The design question wasn't how to make ABAC easier to use. It was how to make a permanently consequential decision feel appropriately weighty — without making the product feel hostile."

Koverse also has an edge extension — a platform for managing data across distributed, geographically dispersed deployments. Think: a network of military field sites, each running local data infrastructure, all feeding back to a central node. Two different products, one shared design philosophy: the interface is responsible for making the consequences of decisions visible, especially when those consequences are severe and irreversible.

Part One — ABAC Configuration

Key Screen — Access Control Config

The ABAC flow.
Three decisions that define the design.

ABAC configuration screen
Decision 01
Irreversibility as a first-class signal
The warning — "Edits to ABAC labels cannot be made after import" — could have lived in a tooltip or footnote. I put it on the face of the screen, in a styled warning component that breaks from the surrounding UI, before the user has made any selection at all. A warning that appears after the user has committed to a direction is already partially ignored. This one gets processed as part of the decision.
Decision 02
Progressive disclosure as a commitment device
The configuration interface is hidden entirely until the user selects "Yes." The complexity reveals itself only after the decision to proceed — not as a surprise, but as the logical consequence of the choice just made. The step counter ("1. Configure Attributes") immediately frames what follows as a structured process with a known end, not an unknown depth of configuration.
Decision 03
Branching flows by data type
The ABAC flow branches at the first question based on data type — structured records vs. unstructured documents. Rather than one flow with conditional visibility, I designed two separate flows. This surfaces a real product truth: the kind of data you're ingesting determines the kind of access control you need. Hiding that would have produced a confusing flow that randomly showed or hid options.

The Data Layer

Structured + unstructured.
In the same view.

Mixed structured and unstructured dataset view

Koverse handles both structured tabular records and unstructured documents — images, PDFs, raw files — within the same dataset container. The mixed dataset view had to present both data types coherently, without forcing users into a mode-switched interface that felt like two separate products.

Each record renders its file thumbnail alongside its raw metadata — body text, document ID, record type, file storage flags. The SQL/Lucene search bar and the JSON view toggle give power users the control they need without cluttering the default view for analysts who just need to see what's there.

Part Two — Edge Data Management

Key Screen — Most Operationally Specific

The map that tells you
what it can't show you.

Aether geospatial site map
Decision 01
The hidden site pattern
In a classified deployment, some sites can't appear on a map — a Trident submarine doesn't broadcast its position. But a map that shows 30 pins and says nothing about the 12 sites not shown is dishonest — and in a security context, dangerous. The subtitle "[X] number of sites have their location hidden" gives operators accurate situational awareness — they know exactly how many sites they can't see — without revealing which ones or where. The count is information. The location is protected. No published design pattern handles this. I reasoned from first principles.
Decision 02
Dark map as operational language
The dark-themed map isn't aesthetic — it's operational. Light maps in military monitoring contexts create visual noise that competes with status indicators. A dark base layer makes pin density, clustering, and anomalous absences immediately readable. The blue pins against a near-black terrain render site distribution as a scannable pattern rather than a labeled list — which is exactly how an operator needs to process geographic data at a glance.

The Site Manager

Status states, not
data structures.

Aether site manager dashboard

At the site level, the design problem shifts from geographic overview to operational monitoring. The operator needs to know: is this site healthy? Is data flowing correctly? I organized the site manager around status states rather than data structures.

Published, Connected, Available — these states map to operator actions, not technical conditions. An operator who sees "Available" when they expect "Published" knows exactly what to investigate without understanding the underlying data architecture. The throughput metrics (80 GB/s, 307.8 upload speed) are displayed in real time because in an edge environment, a site showing 0 GB/s when it should be showing 80 is a site that may be offline, disconnected, or under active disruption.

Takeaways

What building this
taught me.

The most important moment is the one before the irreversible action
ABAC configuration, classified location handling, operational datastream management — these are contexts where the consequences of a wrong decision outlast the interaction. You have to think about what information the user needs, in what order, at what cognitive load, to make the decision well — not just to complete the form.
Operational constraints are design requirements
The hidden-site pattern wasn't a compromise — it was a design problem with a real solution. Treating security and classification requirements as constraints to work around produces interfaces that leak information or confuse operators. Treating them as first-class design requirements produces interfaces that accurately represent the world the operator is working in.
The gap between capability and accomplishment is always a design gap
Koverse's ABAC system was technically sound. Aether's geospatial infrastructure was sophisticated. In both cases, the design work wasn't adding capability — it was translating capability into clarity. Users couldn't navigate ABAC confidently. Operators couldn't trust what the map was telling them. Both are design failures, not engineering ones.
No pattern library has a solution for every problem
The hidden-site acknowledgment didn't exist as a UI pattern anywhere. Neither did the ABAC irreversibility warning in the context of a government ingest flow. Designing for classified, high-stakes, operationally constrained environments means reasoning from first principles — not applying what's already been solved.
← Previous Tenjin Next → DHS