Designing AI and data-heavy systems for federal agencies

How I approach federal design

Compliance is a design requirement, not a checklist.

Section 508 and US Web Design System adherence were built into the interaction model from the first wireframe, not added at the end. At SSA, that meant designing within federal standards while still shipping a field office manager tool that cut administrative overhead. At Optum, it meant designing an AI platform that passed audit without sacrificing usability.

Make the AI's reasoning auditable.

In federal contexts, trust is not a feeling. It is a requirement. Confidence scores, adapter-level attribution, citation panels, and HITL flagging systems are how you earn it. Users need to see where the answer came from, how confident the system is, and how to override it when it is wrong.

Design for interrupted workflows.

Federal employees work on multiple cases at once. They shift between them. They need to pick up where they left off. The history tables, document libraries, and "pick up where you left off" interactions are not nice-to-haves. They are the baseline for how federal users actually work.

Validate with the people doing the work.

Stakeholder proxies are useful for alignment. They cannot replace watching real federal users work. At SSA, I interviewed field office managers and technicians directly. At Optum, I partnered with the Senior Director of Architecture and the Senior Technical Project Manager to define what success looked like before designing anything.

This is the same problem I solve across federal, analytics, and enterprise software: AI and data-heavy systems where users need to trust the output, trace the reasoning, and act on high-stakes data without sacrificing accuracy.