I design AI and data-heavy systems for regulated industries

1. Why are we doing this?

What's the business outcome — and what's the cost of getting it wrong? In regulated domains, "because leadership wants it" isn't enough. I need to know whether this reduces legal exposure, speeds up a decision, or prevents a costly error.

2. Who are we doing this for?

Not just "the user" — the specific person under pressure. A federal policy researcher racing a deadline. A dealership warranty admin processing claims between customer calls. A data scientist who needs to trust the AI before acting on it. Designing for "users" is easy; designing for someone whose job is on the line is different.

3. What evidence do we have?

In high-stakes domains, assumptions are expensive. I ask: What do we know from research? What do we know from support tickets, error logs, or compliance audits? What are we guessing — and how will we test it before it ships?

4. How do we measure success?

Business metrics and user metrics, tied together. Reduced decision time. Fewer support calls. Lower error rates. Faster claims processing. If we can't name the number we're moving, we're not ready to design.

5. Are there any significant risks?

This is where regulated domains differ from consumer software. What's the legal exposure if this workflow fails? What happens if the AI is wrong — and who catches it? How does this hold up under Section 508 audit? A bad interface here doesn't just frustrate users; it delays benefits, creates liability, or lets vulnerabilities spread.

6. Are there technical restrictions?

Legacy systems, compliance requirements, data residency, accessibility standards, AI model limitations. At SSA, I designed within the US Web Design System and Section 508. At Optum, I designed around AI guardrails and HITL workflows. Constraints aren't obstacles — they're the design space.

7. Who needs to be involved?

In regulated domains, it's never just product and engineering. Legal, compliance, accessibility, subject-matter experts, federal stakeholders. I've run design workshops in Figma, FigJam, and Miro to align engineers, PMs, and stakeholders on high-stakes projects — and I've learned that the earlier you bring in the people who can say "no," the faster you get to "yes."

how I work

Trade offs

• Subaru of America: chose speed over polish → the team needed a working prototype for a trade show. I prioritized a clear, demo-ready flow over edge-case coverage and visual refinement — a reminder that "done enough to learn from" often beats "perfect but late.

Ambiguity

• Optum's Project Ana: no research, no documentation → created assumptions, tested, iterated.
• SkyAI: unclear goals → aligned on "success" before designing anything. Federal and healthcare projects rarely come with clean briefs — I've learned to create assumptions, test them fast, and iterate before the cost of being wrong compounds.

Systems thinking

• Optum's Project Ana: aligned metrics + edge cases across flows so the experience stayed consistent at scale. In AI and data-heavy systems, edge cases aren't edge cases — they're the main event. I design for the exception, not just the happy path.

How I've changed

• DuPont → Optum's Project Ana: I stopped thinking in terms of the "perfect" step design process and started thinking on business alignment. In enterprise software, the "perfect" design process is the one that ships on time and meets business metrics.
• Most importantly, I've learned to cut out inefficiencies, know where and when to cut processes short, and deliver on company demands.