Most design processes optimize for ideal conditions.
Mine doesn’t.

I design for systems as they actually exist:
messy constraints, competing priorities, users who resist change.

Every project begins by understanding how the system actually works, not how it was designed to work.

My job is to find where that theory breaks, before the design does.

From there, the work becomes framing the outcomes that matter, before decisions turn into outputs.
‍
Only then can the critical path to adoption emerge:
the shortest sequence of decisions that reduces friction, perceived risk, and cognitive load.
‍
Validation doesn’t happen in controlled environments.
‍
It happens in real contexts, shaped by workarounds,
organizational dynamics, and imperfect behaviors that determine what gets adopted.

Each stage informs the next,
but the loop doesn’t close with delivery.

It closes when behavior changes:
when the workaround disappears,
when adoption holds under real conditions, when the system works without the designer in the room.

That’s the only outcome worth designing for.

Selected systems designed under real constraints.
‍
Each case represents a different type of adoption challenge.