How I turn AI complexity into enterprise clarity.
Eighteen years designing for enterprise complexity - the last four where AI capability meets human judgment in oil & gas, procurement, and financial intelligence. The design problem is never the model; it is the trust architecture, the decision interface, and the governance that make AI adopted.
Trust before utility
In high-stakes enterprise AI, adoption doesn't start with speed or automation. It starts with trust. Before users rely on a recommendation, they want to know why the system made it, what evidence sits behind it, where the data came from, and whether they can defend the output to their boss, their operations team, or a regulator asking pointed questions.
So I design for trust early, not as a polish layer at the end. AI outputs need to be explainable, traceable, and challengeable, with confidence levels users can actually interpret. The shift I'm after is from “the system suggested this” to “I understand this recommendation well enough to put my name on it.”
Systems thinking over screen thinking
A good interface can fix one workflow. A governed design system fixes the same workflow across products, brands, and teams without anyone redoing the work. Most inconsistency in enterprise platforms comes from solving screens in isolation: a different token here, a different component there, a different brand interpretation in the third app, and six months later the platform feels like four separate products glued together.
I work at the system layer first. Shared tokens, reusable components, semantic patterns, brand-aware theming, accessibility baked into the primitives, and governance that someone actually owns. That's what lets multiple apps scale without visual drift or duplicated effort, and without one-off design calls that quietly break the wider experience.
Decisions, not dashboards
Enterprise dashboards usually fail by showing whatever data is available. Procurement teams don't need another chart. They need to know what to prioritize today, where savings are leaking, which supplier is becoming a risk, and which contract action is overdue.
I work backwards from the decision. What question is the user trying to answer? What is the minimum data, comparison, and confidence signal needed to answer it well? The output is a decision-support experience, not a reporting surface. Insight is cheap. Knowing what to do next is the part that matters.