Most AI features start in the wrong place.
A team feels the pressure to ‘have AI’, so they wire a chat box into the corner of the product, point it at a model, and ship it. It demos well. Then you watch the analytics and almost nobody touches it, or the people who do ask it one question and never come back. AI on its own doesn’t solve a problem. It is very good at looking like progress while solving nothing, and customers can tell; most products now carry the remnants of AI that got bolted on for its own sake.
I think about this as a hierarchy of needs, the Maslow kind. Five levels, and each one depends on the level beneath it. The mistake is starting at the top, with the part that shows. It only works from the bottom up:
- Design for a problem
- The product is the manual
- Be transparent, and show what the AI decided
- Respect how people already work
- Make advanced technology feel human
Skip the bottom and everything above it is decoration.
Start with the problem, not the AI
AI doesn’t inherently solve anything. It is a way to solve a problem someone already has, or to reframe that problem into one worth solving. So the first question is never ‘where can we add AI’. It is ‘what is the actual problem, and what is the underlying need (often an emotional one) that nobody has met yet’.
I had this play out directly. Someone asked my team to build a switch that turned off all human escalation. The request had arrived conflated from a handful of customers, with no call recordings behind it to say what they actually meant. I tracked down the customer driving it and pulled their real calls. They didn’t want a switch. Their calls got worse when our AI handed a caller off to a human, because the human had less context than the AI did. The real problem was timing. I shipped a small internal setting and a ‘wait longer before escalating’ option, and the feature nobody had thought to question turned out not to need building at all. Designing for the problem usually means building less than you were asked for, not more.
The product should be the manual
The chat box is the laziest version of AI in a product. It makes the person do the work of describing what they want, into an empty text field, with no idea what the thing can actually do. Gradually this is changing but to the other extreme, where people think they can do anything. We need to find balance.
Embedding the intelligence in the system is harder and far better: surface the right suggestion, decision, or action in context, at the moment it is useful, so the product teaches itself as it is used.
The clearest example I have is the onboarding for an AI receptionist I designed. The people setting it up are non-technical small business owners, not specialists. Instead of a setup wizard or a chat box, I ensured that signing up with the minimum required information still created a fully functioning product and that the first thing a new customer does is call their own number and hear the AI handle the call as their business. The test call is the manual. There is nothing to read first and nothing to learn; the product explains itself by doing the job. The best AI interaction is often no conversation at all.
If you can’t see what the AI decided, you can’t trust it
Trust is the whole game for an AI product, and trust comes from being able to see what the system did and why. When the AI is a black box, a single bad moment reads as a broken product. At Smith.ai, one poor early call was the biggest predictor of cancellation; they had no way to tell a one-off from a systemic failure, so they assumed the worst and left. Sometimes even before turning it on for their business which would have proved that it was a low-frequency event.
The fix wasn’t making all calls perfect. Even humans are incapable of that. It was making the AI’s decisions visible. I led the design of a quality system where the score you could see was only the surface.
Behind it, the system exposed what the AI had actually done: a plain-language account of what it decided on a given call and why, a per-customer view of how it had got smarter, and a way to correct it when it got something wrong that fed straight back in.
A six-week tiger team I set up prototyped the whole loop: a call comes in, the AI’s handling is evaluated, a recommendation is surfaced, the customer applies it, and the proof that it improved is shown back to them. Instead of asking a customer to trust a black box, it let them look inside it. Great AI design builds trust by showing in inner workings. The design challenge here is trust. When a bad call does happen, it’s not relative. A single bad review on a product doesn’t stop you from buying it if the overall rating is 4.9/5.
AI doesn’t need a new way to “talk” to people
Every new AI feature seems to arrive at the same place - ask people to type out what they want. It doesn’t need one. Power users, who operating complex workflows day in and day out, need to have shortcuts and automations to execute as such a high level. Asking an AI to do something via text is like messaging with a family member; you don’t know what the response is going to be (see product is the manual).
Natural language ≠ chat
The trick is to meet people inside the workflow they already have, and put the surprise in the outcome rather than the interface. Natural language can be used to describe a workflow and it can be created but then run by pressing a button. When building a workflow manually, dynamically suggest the next step(s) with a simple button to apply. Notice repeated work and offer proactively to automate it.
I built a ‘bugbot’ prototype that lives where everyone already reports and discusses bugs: Slack. Describe the bug in plain language, an agent reproduces it, diagnoses it, fixes it, and opens a pull request with a human in the loop. Nobody had to learn a tool. Nobody needs access to engineering environments. Nobody even needs to know the ‘right’ way to describe a bug. The only new thing is that a fix shows up.
It is the same principle behind the conversational design on the voice product: natural, intent-driven dialogue rather than a ‘press 1 for sales’ menu that forces the caller to learn our internal structure. We can delight people with what the AI does without inventing a new way for them to ask for it.
The more futuristic the tech, the softer it needs to feel
This is the top of the hierarchy, and it only counts once everything under it holds. The more advanced and unfamiliar the technology, the more human the wrapper has to be, because the job at this point is to make something this new feel approachable enough that people stop thinking about the ‘AI’ part at all.
Anthropic is the example I keep coming back to: serif type, muted colours, the hand-drawn touches. It reads as inviting rather than intimidating, and that is a deliberate counterweight to how powerful the underlying technology is. The same logic shaped the tone of voice work on the receptionist; a warm, natural voice does more for a nervous first-time customer than any feature on the roadmap. Here, soft styling is what lets a person trust a machine.
The work that matters is the foundation
The reason most AI integration fails is that the visible top of this hierarchy is the easy part, and the load-bearing bottom is the hard part. A chat box and a futuristic gradient take an afternoon. Finding the real problem, making the system trustworthy, and fitting it to how someone already works takes the actual design.
So if you are a designer right now, the most valuable place to spend your time is the bottom of the hierarchy, not the top. None of it demos as well as a chat widget, and all of it is what decides whether the AI holds up once a real customer uses it. That is the work I want to keep doing, and the part of this job I think is only getting bigger.