HOW I THINK

Most organizations think they have a UX problem when they actually have a trust problem, an incentives problem, or an alignment problem. Adoption is where those collide — you can ship a beautiful flow and still watch people route around it. I look for the leverage point where product, business, and user needs intersect, and design from there. AI just means one operator can now build all the way to that point, not just spec it.

1. Understand the system before touching pixels.

Every hard enterprise problem is a systems problem wearing a UI costume. Before I draw a screen I map the states, transitions, and edge cases the interface will have to survive — because a flow that only handles the happy path is a prototype, not a product. At Deere, the "licensing screen" was really one machine carrying seven simultaneous consent states; nothing got simple until the system underneath did.

2. Find where complexity actually lives.

Complexity is rarely where the ticket says it is. My first job is to locate the real leverage point — the one place where product, business, and user needs actually intersect — and design outward from there, instead of polishing the symptom. Usually it's one rule, one incentive, or one moment of mistrust doing most of the damage; fix that and half the screens stop needing to exist.

3. Simplify rules before simplifying interfaces.

You can't clean up a screen that sits on top of a tangled rule set — the mess just moves into edge cases and support tickets. So I simplify the model first: collapse overlapping states into one lifecycle, reduce how many things can be true at once, then let the interface inherit that clarity. A simple UI on a complex rule set is a promise the product can't keep.

4. Prototype with engineering early.

Design thrown over a wall arrives late and wrong. I prototype in code, sit with engineers while constraints are still cheap to change, and treat feasibility as a design input, not a veto that shows up at the end. Half of good enterprise design is knowing what the system can actually do — and the fastest way to know is to build a little of it yourself.

5. Design for adoption — not approval.

A design that wins the review and loses the user is a failure with good optics. Sign-off is a checkpoint; adoption is the goal. I design for the moment a busy person decides whether to route around the thing I built — and I'd rather ship something that survives that decision than something that photographs well in a deck.

One job underneath all five: make complex systems trustworthy enough to adopt — at scale. The rest is just knowing, on a given problem, which of these to reach for first.