We're not designing AI products wrong. We're designing them for the wrong user.

Updated 4 October 2026.

Consider a hypothetical failure mode.

An AI agent applies a promotional pricing rule to a product catalogue. The rule was specified in natural language — conversational, the way many consumer AI interfaces accept input. The AI interprets it correctly in the general case and incorrectly for some bundle-pricing conditions. If the change executes across an integrated inventory system before an operator reviews it, mispriced products could go live across connected stores. Correcting the mistake could require an audit of the affected SKUs.

Design only for the interaction that works, and this is the kind of failure you risk leaving invisible — until it misfires at scale.

This is what happens when you take a design playbook built for consumer AI and apply it to enterprise operations. It doesn't produce bad UX. It produces systems where the failure modes are invisible until they're catastrophic.

The consumer AI UX playbook

Consumer AI UX has a coherent, well-developed design philosophy. It emerged from products like ChatGPT, Midjourney, and Claude — tools where the primary design challenge is reducing the barrier between a user's intent and a useful AI output.

The principles are internally consistent. Make input conversational — natural language lowers the cognitive cost of engagement. Make output exploratory — show variations, encourage iteration, treat the first response as a starting point. Make failure graceful — if the AI gets it wrong, it's easy to try again with a different prompt. Design for the average user's first interaction, not for the power user's hundredth.

These principles produce genuinely good design for consumer contexts. They are actively dangerous in enterprise ones.

The consumer AI design philosophy is optimised for delight on the path that works. Enterprise AI has to be designed for survival on the path that doesn't.

Why consumer AI principles fail in enterprise

The failure is structural, not executional. It's not that consumer AI design patterns are applied badly in enterprise contexts. It's that they were built for a fundamentally different risk environment.

In low-stakes consumer generation, the blast radius of a wrong output can be bounded. A poem misses the tone, an image misses the brief. The user tries again. Recovery may be as simple as reprompting because the output has not yet changed an operational system. That is the distinction that matters here: generating an output versus executing a consequential action.

In enterprise AI, the blast radius scales with the system's integration surface. An AI that generates incorrect copy for a product listing affects one page. An AI that executes an incorrect inventory reallocation affects fulfilment across every warehouse the system is integrated with. An AI that misapplies a pricing rule doesn't produce a wrong answer — it produces a wrong state that the system then acts on, downstream, automatically, before anyone has reviewed it.

The design implications are completely different. Consumer AI can be conversational because conversation is reversible — you can clarify, correct, redirect. Enterprise AI cannot be conversational in the same way because the conversation ends in an execution, and executions in integrated operational systems are not easily reversed.

Role-based permissions make the enterprise action surface more complex. A writing tool's prompt-and-output interaction is not a sufficient model for a system where actions depend on organisational authority. In enterprise AI, the action surface is a function of organisational authority. A warehouse manager can approve inventory reallocation. They cannot approve pricing changes. A category manager can update product attributes. They cannot trigger fulfilment logic. The AI's proposal set — what it even surfaces as options — must be scoped to what the logged-in user is authorised to approve.

This is an access-control problem and a design problem. An AI that surfaces proposals the user cannot approve creates confusion about what the system can do. An AI that only surfaces proposals within the user's authority creates a qualified, trustworthy proposal set. The design decision — what the AI shows, not just what it executes — is load-bearing in a way that consumer AI design never has to consider.

The enterprise AI design principles that actually work

At Fynd, I designed the merchant-facing Sidekick experience, powered by a separate copilot, around supervised actions. Engineering owned the model and backend execution.

The shipped interaction boundary was Propose → Preview → Approve → Execute. An operator could reject the proposed change before commitment. Approval committed it; the implementation did not provide a general post-approval undo. The design premise was visibility before execution — an operator could review the proposed change before authorising it. Beyond that shipped boundary, there is more I would design for.

Preview before execution is not a UX nicety. It's the mechanism by which trust accumulates.

The specific design of the preview matters as much as its existence. For higher-risk changes, I would extend the preview beyond a natural language summary to a before-and-after comparison of the affected records. The summary explains the proposed action. The comparison lets the operator inspect its consequences. I would test that comparison against the simpler preview before treating it as an improvement.

The audit trail is a design requirement, not a compliance afterthought. When something goes wrong in an enterprise system — not if — the operator needs to reconstruct three things: what the AI proposed, what the human approved, and what the system executed. These are three potentially different things. The design of the audit system has to capture all three, at the moment they occurred, with enough context to make the reconstruction meaningful. This requires designing the logging architecture as a user experience — one whose primary user is the operator trying to recover from an incident, not the compliance team generating a report.

Blast radius as a design input. For each AI action surface, start with a question: what is the maximum damage this action can cause if it misfires? Not the average case — the maximum case. The answer should determine how much friction the approval flow needs. A lower-risk, single-record update may need a concise preview. A bulk operation, pricing change or fulfilment action may need more explicit review of affected records and the operator's authority. The friction should be deliberate. Calibrated to the consequences, not added by habit.

What the industry needs to do differently

The enterprise AI design discourse needs to separate from the consumer AI design discourse. Not because they don't inform each other — they do — but because conflating them produces a set of best practices that is correct for one context and actively harmful in the other.

Evaluation criteria need to separate. Consumer AI UX is evaluated on time-to-first-useful-output, engagement, and the quality of the average interaction. Enterprise AI UX should be evaluated on recovery time from a misfire, audit completeness, approval accuracy under time pressure, and the rate of silent errors — AI actions that executed correctly in the technical sense but incorrectly in the operational sense. These measures deserve explicit weight in enterprise evaluation. The criteria should reflect the consequences of the actions a product can execute.

Design patterns need to be documented separately. The conversational input model, the exploratory output model, the graceful failure model — these are consumer AI patterns with consumer AI assumptions baked in. Enterprise AI needs its own pattern library: the diff-first approval model, the blast-radius-calibrated friction model, the role-scoped proposal model, the audit-first logging model. Enterprise product teams should share more of these patterns — and the implementation limits and evidence behind them.

Close

The enterprise AI design failures of the next three years are already being designed right now.

They're being designed by teams who have read the right articles about AI UX, applied the right consumer AI principles with genuine craft and care, and built products that will work beautifully in demos and fail consequentially in production.

Not because they designed badly. Because they designed for the wrong user — for the curious first-time experimenter rather than the operations manager whose business runs on the system being correct.

A low-stakes generated output may be easy to discard. An incorrect operational action can leave the operator with consequences to repair.

That difference is the entire design problem. And until the industry treats it as such — with separate principles, separate patterns, and separate evaluation criteria — we will keep producing enterprise AI that looks like consumer AI and fails like a system that was never designed for what it's actually being asked to do.