how i work
Driven by work that requires understanding something complex before designing anything. I spend real time with actual users and stakeholders, clarifying what needs solving, and staying with the project until it ships. Usually guiding the engineering team through the build.
The habits below run through most projects, always adapted to what each challenge allows.
.habits

User Shadowing
Sitting down with users to see exactly where they get stuck in their daily workflows. Refined over 14 years of entering cockpits and control rooms to shadow specialists in high-stress environments.
Systemic Design
Mapping out connections and building clean Figma libraries so the product scales without breaking.

Stakeholder Alignment
Bringing decision makers and end users into the same room. Years of running customer advisory boards to keep business goals and the real workflow pointed the same way.

Developer Alignment
Working closely with engineers to ensure designs are ready to build. Experienced in aligning with rigid technical constraints, APIs, and safety-critical frameworks.

Early Prototyping
Making quick, interactive prototypes to break things and fix them before code is written.

Balanced Guardrails
Keeping tight business targets in view without letting the user experience get ruined along the way.
.research


Open questions over the ones with obvious answers
Clients don't always know how to express the solution they need. understanding the problem and its context is the designer's responsibility, so the solution doesn't quietly create new problems.
Build rapport before asking the hard questions
Flight schools and ops teams have been promised better tools before. the first conversation is rarely the useful one. by the third or fourth, when people stop performing and start telling you what's actually broken, the real research starts.
Meet customers in their environment when possible
An instructor's classroom, a planner's screen layout, an operator's wall of printed checklists shows in five minutes what a survey wouldn't surface in five weeks.
.method

Match the technique to what the project allows
Some projects allow long customer engagements, full CAB cycles, and continuous research. Others have weeks, a fixed launch window, and a small group of named customers. Others inherit a legacy product with no measurement layer at all. Each setup calls for a different way of working, and learning to read those differences has been part of the work.
.on new things
Most of the projects I've led started outside what I knew. The way through has been to listen carefully, learn from the people who do know, and bring everyone's knowledge into a shape the product can use.
.working with customers

CDP 2025 (Boeing)
3 onboarding sessions for Anaysis Workspace at Boeing's customer development program, the annual gathering of crew planning customers. Live demos, polling, and feedback that fed into the 2025 roadmap.
Customer Advisory Boards (CAB)
4 rounds with 6+ airlines. Co-designed the CAB format later adopted across other Jeppesen product lines.
User Conference 2025 (Vancouver)
Live demo from a standing station at the annual user conference. Informal interviews with crew planners between sessions, testing parameter workflows on their own data. Findings merged into the broader research programme.
