Building AI products people use

Most AI features I have seen fail were built because the model could do something impressive, not because anyone needed it. I have made that mistake myself. These are the habits that replaced it.

Start from the workflow

Good AI products start from work people already do by hand and dislike: the same task many times a day, following a process they could write down, without much judgment involved. The model is an implementation detail of automating it.

When you are new to a domain, it is easy to assume you know which parts hurt. Usually you are wrong in ways that matter. So I ask users to walk through what they actually do, step by step, and listen for where the time goes and what they have already tried. The question is never "would you use AI for this?" It is "what takes the most time, and why?"

Design for failure

Traditional software fails loudly. AI fails quietly: the output looks plausible and is wrong. So every action needs a way back.

• Show before acting. Summarize what the system is about to do.
• Make it reversible. Every automated change gets an undo and an audit trail.
• Route by risk. Let the system act alone on low-stakes, high-confidence cases, ask for confirmation in the middle, and hand off to a person otherwise. A model's stated confidence is often poorly calibrated, so set these thresholds from measured accuracy on your own cases, not from the number the model reports.

Speed is part of quality

Users judge an AI feature by how it feels, and waiting feels like failure. A faster answer that is slightly less accurate often wins over a slower, better one, especially when mistakes are easy to undo. Stream partial results, cache common requests, and use plain rules for the easy cases so the model only handles the hard ones.

Close the loop

AI products improve through feedback, not only through code. Capture a signal on every output, review the failures every week, version prompts like code, and test changes on a slice of traffic before shipping them to everyone. Watching real sessions shows problems that metrics miss.

Don't make it a person

Giving the system a name and a personality raises expectations it cannot meet. Plain, specific language works better: say what it can do, do it, and correct mistakes without apologizing like a person would.

Start small

Launch to a handful of users who have the exact problem, talk to them every week, and widen access as it stabilizes. The goal is not the most capable model. It is a workflow that people stop thinking about because it just gets done.