How I turn AI complexity into enterprise clarity.
I've spent 18 years designing for enterprise complexity. The last four have been at the intersection where AI capability meets human judgment in high-stakes environments — oil & gas operations, enterprise procurement, national financial intelligence. The design problem is never the model. It's the trust architecture, the decision interface, and the governance system that makes AI usable, defensible, and ultimately adopted.
“In AI products for expert users, trust is the feature. The rest is implementation detail.”
Three non-negotiable beliefs
These aren't UX principles borrowed from a framework. They're positions I arrived at through repeated experience with the same class of failure — and they govern every decision I make from the first brief to the last QA pass.
Trust before utility
In high-stakes enterprise environments — oil & gas operations, financial decisioning, procurement approval chains — users won't adopt a system they cannot explain to their manager. Every AI interface I design establishes a trust architecture before optimising for speed or coverage. Confidence without explainability is a liability, not a feature.
Series B AI Startup · Oil & Gas AI Platform
The beta had technically superior ML models, but two of three pilot customers were leaving. The failure wasn't the model — it was the absence of explainability. I redesigned around confidence intervals, structured evidence trails, and an override workflow that fed directly into model retraining. Both at-risk customers converted. The override dataset was later cited as a proprietary moat in the Series C pitch.
Systems thinking over screen thinking
A single well-designed screen solves one problem. A well-governed design system solves the same problem across six products, three client brands, and four engineering teams — without a single component fork. Feature design is additive. System design is exponential. I operate at architecture level first, and push decisions down to component level only once the architecture is sound.
Enterprise Energy Platform · Multi-Brand Design System
A 4-layer token system — global primitives → semantic roles → component tokens → brand overrides — produced 87 production components, three independently branded client deployments, and a 40% reduction in feature delivery time from a single source of truth. A full brand rebrand required changing 12 token values, not 87 components.
Decisions, not dashboards
Enterprise platforms are drowning in data. The design question is never 'how do I display this?' — it's 'what decision does this need to support, and what is the minimum viable signal to make that decision confidently and quickly?' I work backwards from the decision, not forward from the data schema. This is the difference between a reporting tool and an intelligence layer.
Procurement Intelligence · Gulf Petrochemical Enterprise
A Gulf manufacturer had procurement data across 11 systems and decision visibility across zero. Before touching a design tool, I mapped every decision procurement leaders needed to make — approve, escalate, expedite, defer — and designed the intelligence layer to surface exactly those signals at the exact workflow moment they were needed. Cycle time dropped from 11 to 4 days.
Six stages. Applied to every engagement.
This isn't a waterfall process. The stages are non-linear in practice — I move between them fluidly as new evidence surfaces. But I don't skip any of them. Each stage has a specific job, and skipping one creates a specific class of failure downstream.
Understand the domain before designing the interface
I don't start with wireframes. I start with the work. For oil & gas, that meant learning subsurface interpretation cycles and shadowing geoscientists across three operator sites before sketching a single screen. For procurement, it meant understanding CAPEX approval chains and why a 4-day delay on a $2M purchase order can cascade into an operational shutdown. Research, for me, is strategic intelligence — not empathy theatre.
From practice
12 contextual inquiries, 3 operator sites, 6 weeks of domain immersion before the first design review at the AI startup. The critical insight that changed everything: domain experts didn't distrust AI — they distrusted outputs they couldn't interrogate.
Separate the stated problem from the actual problem
Every brief describes a symptom. My first job is to find the root cause. At an AI startup, the stated problem was 'users aren't using the product.' The actual problem was a trust deficit caused by unexplainable ML outputs. In banking, the brief was 'redesign the app.' The actual problem was five distinct failure modes — navigation debt, discoverability collapse, memory overload, anxiety loops, and loss-of-control moments — each requiring a different design intervention, not a single redesign.
From practice
Identified 5 distinct failure archetypes in a corporate banking app before any design work started. Each archetype required a completely different fix: IA restructure, progressive disclosure, notification layering, freeze-card accessibility, and statement clarity.
Map the ecosystem before designing any single feature
Before I open a design tool, I map the system: data flows, user roles, decision handoffs, AI intervention points, and failure modes. This produces an architecture-level design brief — not a wireframe. It tells me where to optimise for speed, where to optimise for trust, and where a decision in one corner of the product will cascade into consequences three, five, or ten screens away.
From practice
For a national chamber of commerce BI platform — 40+ dashboards, 16 countries, 6 economic domains, one week to deadline — the design challenge wasn't visual. It was IA: how do you build navigation that works for an economist in Morocco and a trade analyst in Riyadh studying different datasets on the same platform?
Define the human-AI collaboration model explicitly
For every AI-integrated product, I design the collaboration contract before touching a screen: when does AI propose, confirm, or act? How is uncertainty surfaced without creating anxiety? What does meaningful human override look like, and critically, how do those overrides improve the model over time? These aren't UX details — they determine whether an AI product earns expert trust or gets quietly abandoned after two sessions.
From practice
At the AI startup: AI proposes confidence ribbons → expert reviews evidence panel → expert overrides via structured taxonomy → overrides re-enter the training pipeline. The UX became a data flywheel. The board cited the override dataset as a defensible proprietary moat in the Series C pitch.
Ship iteratively, within a governed design system
Iteration without governance creates UX debt at scale. Every component I ship maps to a design token. Every pattern maps to a documented principle. Every exception requires a deliberate decision — not an accident. This discipline allows enterprise-scale teams to move fast without fragmenting the experience across products, teams, and client brands. Governance isn't bureaucracy. It's the structural condition that makes speed sustainable.
From practice
87 components, 3 brand themes, 4 engineering teams on the enterprise energy platform — all shipping from one token-based system. Average feature delivery time fell from 12 to 7 days after the architecture was in place.
Close the loop with outcomes, not assumptions
I close every significant design decision with measurement. Not vanity metrics — decision latency, error rates, task completion under realistic working conditions, business impact proxies. This isn't only about proving design value. It's about building institutional knowledge: what actually worked, under what conditions, for which users. Design without measurement is decoration that happens to be interactive.
From practice
Defined the AI platform's measurement framework before the product shipped: interpretation time target (−50%), session depth target (30 min+), pilot conversion rate. Actual results exceeded every target: −72% interpretation time, 47 min average session up from 12 min, 2 of 3 pilot conversions. These numbers anchored the Series C story.
I operate at both levels simultaneously.
Most enterprise UX leaders choose between strategic influence and hands-on delivery. I don't accept that trade-off. The strategic layer informs execution quality. Execution experience gives strategic recommendations credibility. Neither works well without the other.
Reusable design patterns from real projects
These aren't templates I apply wholesale — they're abstracted patterns that emerged from solving the same class of problem multiple times. Each represents a solved design challenge with a validated structure that I adapt to new contexts.
The Trust Architecture
For expert users in high-stakes domains, trust is the product — not a feature you add later.
Surface probability ranges, not certainties. Match visual precision to model precision — never overclaim.
Show every data input behind an AI suggestion. Make the reasoning interrogatable, not opaque.
Human disagreement captures a reason taxonomy. Expert corrections are training data, not noise to be discarded.
Every expert override improves the model. The product compounds in intelligence as it gets used.
The Token Cascade
Brand flexibility at enterprise scale requires architecture, not customisation on top of customisation.
Raw values with no semantic meaning: #6366f1, 16px, 0.5rem. The atomic layer — never referenced directly by components.
color-brand, text-primary, spacing-component. Intent mapped to values. Meaning without implementation specificity.
button-bg, card-border, nav-height. Components reference semantic roles, never raw primitives.
Client A, B, C each remap semantic roles to their brand primitives. One architecture, three distinct visual identities.
The Decision Interface
Enterprise users don't need more data. They need the decisive signal at the moment of judgment.
Identify every decision the user must make: approve, reject, escalate, defer. These are design targets, not dashboard requirements.
Which specific data points are necessary — and sufficient — for each decision? Surface only those. Cut the rest.
Deliver the signal at the exact workflow moment it's needed — not in a separate report opened in another tab.
Every surfaced insight leads directly to a low-friction, visible action. Data presented without an action path is noise with formatting.
What this approach delivers
Design quality is subjective. These numbers aren't. Every metric below is measured from a shipped product — not estimated, not projected.
Want to see this approach in practice?
Seven case studies — enterprise AI, design systems, banking, procurement, and national intelligence — each documented with the full decision-making arc: problem, options, trade-offs, and measured outcomes.