AI Product and Experience Design
Designing products around systems that are sometimes wrong. Six engagements covering what to build, whether it works, how it should feel, and how it stays profitable at scale.
The model is not the product.
An AI feature succeeds or fails on two questions that have nothing to do with the model: what the user does when it is wrong, and what a heavy user costs. Neither appears in a demo, both appear in month nine, and features that skipped them get quietly removed after a year of being described as promising.
So the design work here starts from the real error rate rather than an ideal one, pairs the interaction pattern to it, designs the failure path in the same iteration as the success path, and models cost per user before pricing is announced. Prototypes carry a kill criterion agreed in writing, and a fair share of them conclude that the thing should not be built.
What we build
Each is a standalone engagement with its own scope, price and output. Most clients use two or three in sequence.
AI Product Strategy
What to build and what it is worth, priced per user and designed around the errors the model will make.
Read more →AI MVP and Rapid Prototyping
A prototype built to answer one question, with a kill criterion agreed before it starts.
Read more →UX Design for AI Interfaces
Designing for probabilistic output — uncertainty shown usefully, failure paths designed, correction made easy.
Read more →Conversational and Agent Interface Design
Discoverable capability, visible agent progress, designed approval points and a stop that always works.
Read more →Human-in-the-Loop Workflow Design
Routing by confidence and consequence, interfaces built for review speed, and automation bias measured.
Read more →AI-Native SaaS Development
Multi-tenant AI done properly — data isolation, per-tenant cost, evaluation gating releases, pricing that holds.
Read more →How they fit together
You do not need all twelve. Most programmes follow one of these paths depending on where the uncertainty sits.
Decide what to build
AI product strategy with feasibility measured on your own data and unit economics modelled, then an MVP or prototype built to answer one question with a kill criterion agreed upfront.
Design how it feels
UX design for AI interfaces — uncertainty shown usefully, correction made cheap, failure designed rather than discovered — and conversational and agent interface design where the user cannot see the options.
Design the oversight
Human-in-the-loop workflow design, so the review step catches errors rather than rubber-stamping them — routed by consequence and measured for automation bias.
Build the product
AI-native SaaS development with tenant isolation that holds inside retrieval, cost attributed per customer, and pricing that survives your most enthusiastic user.
FAQ
Marked up with FAQPage schema so these answers can surface in search results and inside AI assistant responses.
Why do AI features get built and then not used?
Usually for design reasons rather than model reasons: correcting the output costs more than doing the task manually, users tried something outside its capability early and concluded it was useless, or there is no visible reason to trust what it produced. All three are fixable without touching the model — see UX design for AI interfaces.
What is different about designing for AI?
Conventional design assumes the system is right. AI is probabilistic, so the interface has to communicate what it can do, express uncertainty in terms someone can act on, make correction cheap, and treat being wrong as a designed state rather than an edge case. Products that did this feel more trustworthy than products with identical accuracy that did not.
How much does an AI feature cost to run?
Enough to change your pricing, which is why it is modelled before anything is announced. AI features break the assumption that marginal cost per user is near zero — a heavy user of a generative feature can cost more than they pay. See AI product strategy.
Should we prototype first?
Almost always, and with a kill criterion agreed in writing before the build. The cheapest possible outcome is discovering in six weeks that something does not work rather than in eighteen months, and a meaningful share of these engagements end with a recommendation not to proceed.
Do you build the AI itself as well?
Yes — the underlying capability comes from the relevant pillar: generative AI and LLM engineering, AI agents, machine learning or conversational AI. This pillar decides what should exist, how it should behave, and how the product around it holds together commercially.
Start with a conversation.
Thirty minutes, no charge, no deck. Tell us what you are trying to build with language models and we will tell you which of these engagements fits, or whether none of them do.