AI UX design consulting is advisory work on the user experience of products that have artificial intelligence inside them. It answers two questions a general UX engagement rarely reaches: where in a flow a model actually belongs, and what the interface has to do on the occasions the model is wrong. Vivaldi has designed brand, product and experience work since 1999, and this is the part of that practice that deals with probabilistic systems rather than deterministic ones.
- Since 1999brand, product and experience design work
- 200+published case studies
- 10 officeson four continents
- 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
Most AI features do not fail because the model is bad. They fail because the product was designed as though the model would always be right, and then met a user who could not tell whether it was. This page covers where AI UX work goes wrong, what our AI UX design consulting involves, how to evaluate any firm doing it, and which of our other services your question may actually belong to.
Two notes on scope, so you do not spend time on the wrong page. If your question is about the user experience of a conventional product, that is user experience (UX) design. If it is about whether and how your organization should adopt AI at all, that is AI strategy and new tech. This page is the narrow middle: the design of the thing itself, once you have decided to build it.
When companies bring us in
The pattern is consistent. The model performs well in evaluation and badly in the hands of a user.
- An AI feature shipped, usage spiked for two weeks, and then settled near zero with no clear reason in the analytics
- The model is accurate most of the time, and nobody has designed what the product does during the rest of the time
- Users do not trust an output they cannot interrogate, so they redo the work manually and the feature becomes a second cost rather than a saving
- A conversational layer was added to a product whose underlying tasks were never structured, and it now answers questions the product cannot act on
- Legal, risk or compliance has asked who is accountable for a recommendation, and the interface has no answer because the question was never a design question
Why bolting AI onto an existing flow does not work
The reasonable version of the standard argument is that AI is a capability like any other: build it, expose it in the product, iterate on usage. That works for deterministic features. It breaks here for a specific reason.
Every interface built before this one rested on an assumption so basic that nobody wrote it down: the system knows what it is doing. Buttons do what they say. A search returns what matched. The user’s job is to express intent, and the product’s job is to execute it correctly. A probabilistic system breaks that contract, and almost every design convention inherited from the deterministic era quietly assumes it still holds.
So the failures cluster in predictable places:
- Confidence is invisible, so a guess and a certainty are presented identically and the user learns to distrust both
- There is no route back. The user can accept the output or discard it, with nothing in between, which is the one thing they usually want
- The error state was designed for failures, not for plausible wrongness, which is the failure mode that actually matters and the hardest one to notice
- Correction is a dead end: the user fixes the output and the product learns nothing, so the same error returns tomorrow
- The feature was placed where it was easy to build rather than where the user carries the most load
None of that is solved by a better model. It is solved by deciding what the interface owes the user when the model is uncertain, and designing that path with the same care as the path where everything works.
The second failure is sequencing. AI features are typically tested for model quality and not for task completion. Those are different measurements, and the gap between them is where a technically successful feature goes unused.
What our AI UX design consulting services include
Four bodies of work, roughly in this order. Which you need depends on how settled the underlying product decision already is.
1. Deciding where the model belongs
Before any interface is drawn, the case for putting a model in this flow has to survive scrutiny.
- Which step in the task is genuinely expensive for the user, stated as something they would recognize rather than as a capability the team wants to use
- Whether the step tolerates being approximately right, because a great many do not and that answer settles the design
- What the honest fallback is, including the option that this feature should not exist and the work belongs in the structure of the product instead
2. Designing for uncertainty
This is the part with no established convention, and it is where most of the value in an AI UX engagement is created.
- How confidence is expressed in the interface, in terms a user can act on rather than a number they cannot calibrate
- What the product shows its reasoning for, and what it does not, because explaining everything is its own kind of noise
- The route between accept and reject: editing, narrowing, asking again, or handing the task back to a person with context attached
3. Designing the failure path
An AI product is defined by what it does when it is wrong, and that path is usually designed last or not at all.
- Plausible wrongness treated as the primary error state, with the interface designed to make a wrong answer visible rather than merely polite
- Correction designed as a first-class action, so fixing an output costs the user less than doing the task manually would have
- Escalation and accountability made explicit, so there is a named human path when the stakes exceed what a model should decide alone
- Accessibility and clear semantics treated as structural, so assistive technology and automated agents can interpret the same states a sighted user infers from layout
4. Testing against the task, not the model
- Prototypes tested with real users on the actual task, including deliberately seeded wrong outputs, because a demo of the happy path tells you nothing about trust
- A measure agreed in advance, such as task completion or time to a usable result, rather than model accuracy standing in for product success
- Instrumentation for correction and abandonment, so the next iteration starts from evidence about where users stopped believing the output
Our work here is usually commissioned by a Chief Product Officer, a Head of Digital or a product leader whose AI feature has shipped and stalled. A defined flow typically runs six to twelve weeks, longer where the underlying product decision is still open.
Shipped an AI feature that nobody uses?
Start with a working session on one flow. We will establish what the model is supposed to take off the user, and what the interface currently does on the occasions it is wrong.
How an AI UX design engagement works
- Frame. Interviews with the people who own the product, the people who support it and the people whose work the model is supposed to reduce. A review of usage, correction and abandonment data where it exists. The output is a short list of steps worth putting a model into, and the ones where it will cost more than it saves.
- Structure. The flow itself: where the model acts, what the user sees before acting on it, how confidence is expressed, and what the route back looks like. The output is a decision about what the product does when it is unsure, written down before anyone draws a screen.
- Test. Prototypes put in front of real users with wrong outputs deliberately included, because trust is only measurable when the system is allowed to be wrong in front of someone. The measure of success is agreed before the session.
- Hand over. Specifications a build team can work from, the patterns that govern the next AI surface nobody has designed yet, and a named owner for the escalation cases that will follow.
Why companies choose Vivaldi for AI UX design work
We are a strategy firm that designs, which cuts both ways and is worth being clear about. If you need a large interface production capability or a team to build and tune the model, there are better options than us. If the hard part is that nobody has decided what the model is supposed to take off the user, that is the work we do first, and it is the reason the design holds afterwards.
Three practical consequences. The product decision and the interface decision are made in the same room, so the question of what happens when the model is wrong is not deferred to a ticket. The failure path is treated as a deliverable rather than as an edge case. And we will tell you when the answer is to fix the structure of the task rather than to add a model to it, which is a recommendation that a firm selling AI implementation has no incentive to make.
How to evaluate an AI UX design consultant
Including us. These are the questions worth putting to every firm on your shortlist.
- Ask them to describe the wrong-answer path. If the answer is an error message, they have designed for failure rather than for plausible wrongness, and plausible wrongness is the one that costs you.
- Ask what they will refuse to put a model into. A firm with no examples is selling implementation. The useful answer names a step where approximation is unacceptable, and says why.
- Ask how they test. If testing means a demo of the working case, it is a sales exercise. Trust is only measurable when the system is allowed to be wrong in front of a real user.
- Ask what they measure. Model accuracy is not product success. The useful answer names a task-level measure agreed before the build.
- Ask who owns the escalation. When a recommendation is contested, there has to be a named human path, and it has to exist in the interface rather than in a policy document.
AI UX design consultancy vs AI implementation partner vs in-house product team?
| Criterion | AI UX design consultancy | AI implementation partner | In-house product team |
|---|---|---|---|
| What it decides | Where a model belongs in the task, how uncertainty is expressed, and what the product does when it is wrong | Which model, how it is built, trained, evaluated and deployed | What ships next quarter, within the product structure that already exists |
| Typical deliverables | Task definition, flow and confidence design, failure and correction paths, tested prototypes, build-ready specifications | Pipelines, model evaluation, integration, monitoring | Backlog, releases, incremental optimization |
| Who signs it off | Product and commercial leadership together, because the trade is between accuracy, speed and trust | Engineering and data leadership | Product leadership |
| Blind spot | Limited production and model engineering throughput once the design is settled | Will ship a well-built model into a flow that gives users no reason to believe it | Cannot easily question a feature it is measured on delivering |
| Best when | An AI feature has shipped and stalled, or the case for building it is still open | The design is settled and the work is building it properly | The pattern is proven and the work is continuous improvement |
Related work
This is a narrow service, and a good share of the questions that arrive here belong somewhere else. Four honest redirections.
- Customer experience (CX) design if the question spans touchpoints and channels rather than the inside of one product. This page sits underneath that one.
- User experience (UX) design if the product has no model in it, or the model is not the difficult part.
- AI strategy and new tech if the open question is where AI belongs in the business rather than in a flow, and AI innovation capability consulting if it is whether your teams can build these things repeatably.
- User interface (UI) design and prototyping and testing if the flow is settled and what you need is the surface or the evidence.
Our point of view on how this is changing is set out in How AI changes UX and CX design in 2026. The work sits inside our Experience Strategy practice, part of the argument our Brand, Innovation and Experience pillar makes: an experience is where brand meaning either survives contact with reality or does not. It is delivered at Vivaldi.
AI UX design consulting in the US and worldwide
Our experience design work runs out of ten offices on four continents, with the US team in New York and a substantial practice in Germany, where most of the demand reaching this page originates. AI products make the multi-market problem sharper rather than softer: a model’s confidence has to be expressed in a language and a regulatory context, disclosure requirements differ by market, and the human escalation path a European regulator expects is not always the one a US product team designed. We treat those as structural design decisions rather than as a localization pass at the end.
Start with the moment the model is wrong
A working session on one AI flow: what the model is supposed to take off the user, how the interface signals that it is unsure, and what the user can do about it. You leave with the shape of the problem and where to start.
