How I work
I reformulate the task before I design it. Most of the briefs I’ve worked from described a solution someone had already chosen — the useful work started when we went back to what the actual problem was.
Most of my work happens inside limits I did not set: a system of record the business runs on, a pricing model that lives in contracts rather than in the product, an agreement between departments that predates the brief. I start by finding out what the limit is holding up, because a constraint that has survived that long is usually load-bearing. On the partner portal the legacy system could not be touched, so the question changed from what the new portal should look like to what the new surface could own that the old one did not. The answer — the specification line and where it came from — came out of the constraint.
What I can stand behind
Every case I write has a section about what did not work, and it is not there for modesty. The order in which a project is run is a design decision, and the places where I got that order wrong are hard to fake. On DSSL I finished six screens before checking their structure against comparable products. A structural finding costs a paragraph before the screen exists and a rebuild afterwards. Two defects found later were also diagnosed incorrectly the first time; fixing either diagnosis would have fixed nothing.
Most of what I have shipped is under NDA, and some of it has no baseline to measure against: its metrics were a plan for measurement, not a claim of results. I do not publish numbers I cannot stand behind or let a plan pass for an outcome. I publish the compromise instead — what the design achieved, what it cost, who now does more work, and what would have to change to remove that cost. A named trade-off can be checked in conversation; a number without a baseline cannot.
Where AI sits in how I work
I use AI at every stage of a project rather than at one step of it — from the first interview and the brief, through research, personas and scenarios, the PRD, the information architecture and the design system, into code, testing and deploy. Several models and tools, picked per step, not one assistant for everything.
In my process, it earns its place through volume and first drafts: reading more comparable products than I can cover by hand, restating a requirement until the weak version becomes visible, walking a finished flow and reporting where it breaks. That last pass has repeatedly found defects on screens I had already called done.
The boundary is judgment and evidence. AI can surface options and failure points; it does not choose the object the system is built around, decide which constraint to accept, or turn an assumption into a user finding. Those decisions — and the trade-off I publish — remain mine.
Let's talk
If this is the kind of thinking you want on your team — or if the answer above still leaves a question.