Process

Design that
holds up under
scrutiny.

My work focuses on systems thinking, tradeoffs, and risk mitigation — not just shipping screens, but shaping how products evolve responsibly. I’m often brought into ambiguous or high-stakes areas where clarity, judgment, and collaboration matter most.

Context

Where I do my best work

I tend to be most effective on products that have genuine complexity, cross-functional stakes, and users who need to trust what they’re looking at. The common thread is responsibility — the work needs to be right.

The problems are complex and consequential
Design is treated as a strategic partner, not a production service
Collaboration across product, engineering, and domain experts is essential
Decisions need to hold up under scrutiny, not just ship quickly
The outcome matters more than the deliverable

My Process

Every project is different, but my process follows a consistent rhythm. I start with understanding — the system, the user, the constraints — before I produce a single frame.

01 / Discover
Understand the system
Map the technical constraints, user context, and business stakes before shaping anything. Ask the questions no one else is asking.
02 / Define
Clarify the problem
Identify mental models, surface assumptions, and align the team around what we’re actually solving — not just what was requested.
03 / Explore
Map tradeoffs
Generate options that reflect real constraints. Weigh them. Pressure-test them. Don’t fall in love with the first elegant solution.
04 / Deliver
Design for real use
Build for the edge cases, the power user, the tired analyst at 2am. Not the ideal state. The messy, real-world one.
05 / Evolve
Document decisions
Document what was decided, why, and what was ruled out. So the team can build on it — and revisit it intelligently when things change.

How I Show Up

I think of myself as a design strategist embedded in a product team — not a service bureau. I push back when I see the wrong problem being solved. I raise concerns about usability risk before they become launch problems. I write documentation so the team doesn’t lose design decisions between sprints.

I’ve been the only designer in a 30-person company. I’ve partnered with engineers daily and presented design rationale in executive reviews. I know how to calibrate my communication to the room, and when to fight for the right decision versus when to make the tradeoff.

CollaborationDaily pairing with engineers, embedded in sprints, present for engineering reviews
CommunicationDecision documentation, design rationale in tickets, async-first with sync when it matters
FeedbackDirect, specific, actionable. I give it and I want it.
SpeedFast enough to keep the team moving, slow enough to catch what causes rework at launch
ResearchUser interviews, usability testing, heuristic analysis, and domain expert partnerships

AI-Assisted Design

I use AI as a thinking partner, not a shortcut

I actively incorporate Claude, ChatGPT, Cursor, and Midjourney into my design practice — for prototyping, ideation, content scaffolding, and pressure-testing assumptions. I don’t treat AI-generated output as finished work. I treat it as a fast path to the right conversation.

Claude

Content architecture, decision documentation, critique partner

ChatGPT

Workflow automation, research synthesis, prompt scaffolding

Cursor

HTML/CSS prototyping, rapid interactive mockups

Midjourney

Visual direction exploration, moodboarding, concept validation