Designing AI Products for the Person Who Will Actually Use Them
Most AI product failures are not technical failures. They are failures to ask who this is actually for before building it
The technical capability to build an AI product has become widely accessible. Tools, frameworks, and pre-trained models that once required a specialised research team can now be assembled by a small team in weeks. This has produced an explosion of AI products, and it has also exposed a problem that has nothing to do with technical capability: a great many of these products were built around what the technology could do rather than around what the person using it actually needs.
The Design Question That Gets Skipped
Product teams building with AI tend to start with a capability: this model can summarise text, this system can generate an image, this tool can answer a question. The product design then works backward from the capability toward a use case, which sounds reasonable and often produces something nobody quite needed.
The more durable approach starts from the opposite direction: what does this specific person, in this specific situation, actually need, and does an AI capability genuinely serve that need better than a simpler tool would. This sounds obvious stated plainly, and it is routinely skipped, because starting from the capability is more exciting and moves faster in the short term than starting from a genuine unmet need.
The Anthropological Theoalgorithm, developed within this publication’s own reflection on ethical technology, poses the discipline as a single non-negotiable question asked before any other design decision: who is the human person this technology is meant to serve. Products built without seriously answering this question tend to serve the roadmap rather than the person, and users notice, even when they cannot articulate exactly what feels wrong.
What Good AI Product Design Actually Requires
Genuine user research with the people who will actually use the product, not only the people purchasing it on their behalf, since these are frequently different populations with different needs, particularly in enterprise and institutional software where the buyer and the user are rarely the same person.
Honest testing of failure modes before launch, not only of the product’s best-case performance. A product that works beautifully in a demo and fails unpredictably in ordinary use has been tested against the wrong standard. The relevant question is not “can this work” but “what happens to the user when it does not.”
Design that makes the system’s limitations visible rather than hidden, so a user can calibrate their trust appropriately rather than either over-trusting a confident-sounding output or dismissing a genuinely useful tool because they cannot tell when to rely on it.
And a willingness to conclude, sometimes, that AI is not the right approach to a given problem at all. A team that has invested months building an AI capability faces real pressure to find a use for it regardless of whether a simpler solution would serve users better. The discipline to abandon that investment when the evidence points elsewhere is rare, and it is precisely the discipline that distinguishes products built for people from products built to justify their own existence.