Context defines solution
Understand the user, business, market, operations and technical environment before deciding what to build.
I design products that make complex systems feel simple.
Five years owning product work end to end in small teams — research, definition, UX, UI, design systems, specs, handoff and QA.
Enabling standardization of cases across a company’s claim assessors — without taking away the flexibility a real case needs.
View case study
A data-exchange environment for internal and external users — replacing the PDF-over-email ritual with something the system can actually read.
View case study
A customer, prospect and vendor management system — so a person’s history stops depending on whoever handled their last case.
View case study
Understand the user, business, market, operations and technical environment before deciding what to build.
Define what must become possible for the user and the business before designing functionality.
Strong foundations, shared definitions and documented decisions reduce rework and help teams move faster.
Create systems that can evolve with the product instead of solving only the immediate screen or use case.
Use consistency, predictability and reusable patterns to make complex products understandable.
The full loop, start to finish — not just the middle of it.
Created and maintained the design system across four-plus years of product development, expanding it as the use cases, interface requirements and platform demands evolved.
Participated well beyond design approval — testing every feature, documenting issues, writing release notes and helping the engineering team bring the designed solution into production correctly.
Managed the product design area’s roadmaps, boards, priorities, documentation and project visibility.
I have shaped research questions and designed from the findings, but the interviews themselves have usually been run by someone else. I want to own that end of the loop rather than inherit its output.
I work in English every day in writing, documentation and specs. I have had far fewer chances to present live to a customer in it, and that is the gap I am most actively closing.
I use AI tools throughout my own process. Designing it into the product itself — as something the end user touches, with its failure modes handled — is not something I have shipped yet.
I have used metrics to argue for decisions and to check them afterwards. I have not owned the practice end to end: choosing the instrumentation, building the dashboards, and feeding what they say back into the roadmap.
If you value clear design decisions, someone who builds a system instead of putting out the fire in front of them, who thinks in architecture and how a product scales, and who understands what the product owes the business — then