Designing inside the federal government
Before enterprise real estate and founder products, my practice was shaped by federal work — digital services for the Office of the U.S. Trade Representative, the National Cancer Institute, and Health & Human Services. This page is deliberately sanitized: federal work products aren't mine to publish, so it describes the nature of the work rather than showing internal artifacts.
Government is where design constraints are real
Federal work teaches a specific kind of design discipline. Users are often required to use the software, so every friction is a tax, not a churn risk. Content is policy-dense and can't be simplified by deleting it. Accessibility isn't a nice-to-have — it's law. Stakeholders span career staff, political appointees, and contractors, and shipping means navigating security review, legacy systems, and procurement reality.
Working across USTR, NCI, and HHS engagements meant designing web experiences and internal tools inside those constraints: organizing dense, high-stakes content so specialists could actually use it; aligning stakeholders with very different incentives; and delivering within the technical boundaries of government infrastructure.
The shape of the practice
Without publishing internal artifacts, the work can be described honestly in terms of its recurring problems:
What federal work left in my practice
Everything since carries the imprint: the Bright MLS work treated professional users like the mandatory-use users they are; FlowOS and Canopy model workflows with the rigor of systems that can't fail quietly; and accessibility remains a default, not a feature. For government and enterprise consulting teams, this is the shorthand: I've designed inside your constraints before, and I know the difference between what a deck promises and what security review allows.