Four practice areas. One through-line.

Most digital products have significant backstage complexity — operational work, multi-actor dynamics, touchpoints that span channels and contexts — that shapes the user experience but never appears in a screen design. Service blueprints, journey maps, and experience principles make that complexity legible and designable.

The question I'm always asking in service design work is: who else is in this picture? Who produces the service the user receives? What does the system look like from their perspective? Where does the friction live, and is it visible to the people who could fix it?

For Starchart, that meant surfacing the two-sided actor structure of an internal tool — practitioner and client — and making explicit that the tool's entire value proposition lives backstage, in the production work the client never sees. For Delta, it meant a dual-brand customer journey map that aligned two agencies across an ocean around a shared model of what customers actually experience.

The deliverables I reach for most often: service blueprints, current-state journey maps, experience principles developed collaboratively with teams, and HMW reframes that translate research findings into design invitations.

Agency-side at scale (Delta's Fresh Air, two travel brands, multiple platforms), startup-side under constraint (Calendly, no dedicated PM, high turnover), and solo as both designer and engineer (Zen Editor for Starchart). The technical work — tokens, components, documentation — is the visible part. The work I find most interesting is the organizational layer.

Governance, co-ownership, documentation as culture-building — and the moment a system stops being one person's obsession and becomes something a whole team trusts. That transition is the hardest part, and the most worth designing deliberately.

I've led a studio-wide tooling migration from Sketch to Figma. I've embedded WCAG 2.1 AA at the token level so accessibility scales automatically rather than requiring a retrofit. I've built a system that survived two years of hyper-growth and high turnover by being designed to be embedded, not isolated.

The principle I keep returning to: a design system with a sense of humor earns higher adoption. We called the transitional period on delta.com "Stale Air." People remembered it. They talked about it. The language of the system became part of the culture of the team.

I work from discovery through delivery — research, wireflows, hi-fi, prototypes, testing — and I'm most effective on complex, multi-surface problems where the design decisions compound across touchpoints. I've worked in agencies, startups, and solo, which means I've adapted the process to fit the resources rather than the other way around.

At Delta, that meant being the primary liaison between a design agency and a Fortune 500 client's internal engineering and usability teams — translating research findings for C-suite presentations, writing and facilitating usability test scripts, and shipping responsive web across a site handling millions of bookings. At Calendly, it meant doing foundational IA work while the org was doubling around me. At Starchart, it meant being the only person in the room for every decision from data model to interaction pattern.

The through-line across all three contexts: the quality of the work comes from the quality of the questions asked before a wireframe is drawn. What problem are we actually solving? Who else is affected by this decision? What's the simplest thing that works, and what happens after that?

Making astrological data readable inside a writing environment. Making planetary geography usable in a practitioner's report workflow. Making a travel brand's digital ecosystem legible in a service blueprint. Making a holiday campaign feel like a place worth visiting.

I'm less interested in visualization as spectacle and more interested in it as a tool for decision-making. What's the signal? What's the noise? What does the person reading this actually need to understand? Those questions come before any aesthetic choices.

The most deliberate data visualization decision in Starchart is what it doesn't show: a full astrocartography map displays every planetary line simultaneously, across the entire globe. It's comprehensive and overwhelming. The map module in Starchart shows one line, one region, captioned in the practitioner's voice. Static by default; interactive on demand. The reduction is the design.

The Chick-fil-A Evergreen map is the opposite end of the register: an expressive, illustrated, warm microsite where geography is emotional storytelling rather than navigation. Both are data visualization. The difference is what the person on the other end needs to feel.

The same skills that make a good UX process — understanding what the user actually needs, sequencing complexity appropriately, creating artifacts that outlast the engagement — apply directly to designing a workshop or curriculum. The difference is that the "interface" is a room of people, and the "product" is a changed way of working.

The Harvard Business School engagement is the clearest expression of this. The brief wasn't a workshop — it was a practice. A durable way of working that would keep inclusive design alive after the engagement ended, when no outside facilitator was in the room. That's a different design problem than delivering knowledge. The output isn't slides. It's a team that knows how to do something they didn't know how to do before.

I've also facilitated design principles development sessions inside product organizations — at Calendly with UX designers and content strategists — where the goal is to extract the principles already embedded in a team's best instincts and make them explicit enough to teach and to use.

The design principle I apply to facilitation: never design an exercise that produces an output the room won't own. If it comes from outside, it doesn't stick. If it comes from them, it does.