Staff Product Designer
Why Ashby
I wanted to share some thinking beyond what a traditional portfolio allows.

The model is broken. You already know this.

The standard EPD structure produces predictable work, not good work. The designer gets a brief, makes wireframes and hands off to engineers. Repeat. I wrote "The Rise of the Forward-Deployed Designer" because I'd seen this cycle fail too many times. Designers have more to offer than production. They should own problems, not receive them.

Ashby already operates this way. That's why I want in.

What I've built

I've spent seven years in federal consulting owning problems end-to-end. Not waiting for scope. Diagnosing what's broken, writing specs, building direction, and shipping.

  • Design systems from zero. 2ndWatch: full design language for an enterprise SaaS suite, built from scratch over eight months. CMS: unified three brand systems into one visual language, then architected the token and component layers beneath it. QPP: token architecture in Figma, Style Dictionary, and JSON enabling React and Angular teams to share foundations across stacks.
  • End-to-end problem ownership. VA Disability Benefits: arrived to recover a flagged engagement. Reset research objectives, shaped design tickets with acceptance criteria, got the team moving. No PM scoped that for me.
  • IA and interaction design for complex workflows. CMS QPP: restructured the authenticated experience so practitioners could navigate 195 quality measures and surface their highest-priority reporting actions. IRS ITIN: 0-to-1 product integrating computer vision with digital intake, cutting two weeks off each application.
  • Writing as core workflow. Federal consulting requires written specs, design rationale, and documented decision-making at every stage. I don't treat documentation as overhead. It's how I think clearly and how teams stay aligned without meetings.

I build things
Not mockups. Things.

  • Figma plugin that flags detached and off-system components in design files. Adopted voluntarily by five designers across four teams.
  • Next.js application that crawls design system documentation and normalizes component data using a local LLM.
  • Twelve AI Workflows for Designers, a published framework for integrating AI into design practice. Not theory. Methods I use daily with Claude, Figma Make, and GitHub Copilot.
I care about tools because tools shape how teams think. A good design system isn't a component library. It's an opinion about quality, encoded into infrastructure that makes the right decision obvious and the wrong one hard to miss.

Why this moment

Ashby's design system needs someone who treats it as a product, not support. Someone who sees a pattern emerging across three features, extracts it, documents it, and ships it before teams start building their own versions. Someone who writes the spec that prevents the next five design decisions from needing a meeting.

That's the work I've done my entire career. I've just been doing it inside organizations that didn't name it. Ashby names it.

That's why I want to be here.