Before You Build: Why AI Products Must Start With People

There is tension at the heart of AI product design right now. Some emerging patterns like intent-driven shortcuts, rich in-chat elements, and co-pilot artifacts. These patters are usually not celebrated.

I wonder why everyone is trying to turn everything into a conversational UI with AI? Decision trees, forms, toggles, and other well-established UX patterns already handle many of the use cases being shoehorned into chat interfaces. Do conversational UI really outperform a traditional GUI? Do conversational interfaces mean surrendering control over the user experience? The obvious follow-up is, why would a designer ever want to do that without overwhelming evidence of user benefit?

This exchange illustrates something important. What it often lacks is the discipline to start from user needs rather than technological capabilities. This pattern often commits to the question, "what can we build?" and ignores the "what should we build, and for whom?" question.

The Problem With Starting From the Technology

It is easy to forget that AI is a means, not an end. When teams begin a project by asking "what can we build with machine learning?" rather than "what problem are people trying to solve?", they risk producing technically impressive products that nobody wants to use — or worse, products that actively degrade the experience they were meant to improve. The Reddit discussion is full of practitioners who have watched this happen: chat interfaces layered onto workflows that were already well served by conventional UI, AI features launched without any user research validating that people wanted them in the first place.

The PAIR Guidebook addresses this head-on by encouraging teams to first articulate clear, human-centered user needs, and only then evaluate whether AI is the right tool to meet them.

The guidebook illustrates this with a deceptively simple example: a running app called RUN. The user needs it identifies are not technical specifications — they are emotional and practical realities. A runner wants variety so they do not get bored and quit. Another wants to track progress toward a 10k race six months away. A third wants to find other runners at their skill level to stay motivated. These are human desires, rooted in psychology and habit, not in data pipelines. The insight is that AI should serve these needs, not define them.

This seems obvious, but it is routinely ignored — and the Reddit discussion makes clear that practitioners on the ground know it. As one commenter put it, most interactions online boil down to data reviewing or data creation, and the majority of the web is still forms. When someone says "I'm looking for a gift," do they really need a conversational AI experience, or would a good search bar with smart filtering do the job better? The guidebook's first lesson is a kind of diagnostic that the industry desperately needs: before you build, confirm that AI would genuinely make the experience better than a simpler alternative would.

Defining Success on Human Terms

Perhaps the most thought-provoking concept in the chapter is the "reward function" — the mechanism by which an AI system determines what counts as success and what counts as failure. In machine learning, the reward function is a technical construct. But the guidebook reframes it as a design decision with profound human consequences.

Consider a social platform that optimizes for engagement. In the short term, this might mean surfacing content that provokes strong reactions — outrage, anxiety, envy — because these emotions drive clicks and shares. The metrics look excellent. But over weeks and months, users begin to feel worse. The experience becomes noisy, exhausting, even harmful. The AI is succeeding on its own terms while failing the people it was built to serve.

The guidebook asks teams to imagine their product not on day one, but on day one hundred or day one thousand. What does a good experience look like after sustained use? Which behaviors should you be optimizing for over the long run? This is a fundamentally different question than "what drives the most immediate engagement?" and it leads to fundamentally different design choices.

The chapter goes further by introducing the concept of second-order effects — the consequences of consequences. These are notoriously difficult to predict, but the guidebook argues they are still worth considering. If your recommendation engine drives users toward increasingly narrow content, what happens to their sense of discovery? If your productivity tool automates decisions that people used to make themselves, what happens to their sense of agency? These are not hypothetical concerns. They are playing out across the industry right now, and the teams that anticipated them are the ones building products that endure.

The Imperative of Diverse Perspectives

Woven throughout the chapter is an emphasis on inclusion that goes beyond corporate responsibility language. The guidebook makes a practical argument: if you only hear from a narrow set of users during development, you will miss major market opportunities and create designs that unintentionally exclude entire groups. This is not just an ethical concern — it is a strategic one.

AI systems learn from data, and data reflects the world that produced it, including its biases and blind spots. When product teams lack diverse perspectives, they are less likely to notice when their training data skews in harmful directions, when their reward functions penalize certain user groups, or when their interface assumptions do not hold across cultures and contexts. The guidebook positions diverse input not as a checkbox to complete but as a design resource — one that makes the final product more robust, more useful, and more trustworthy.

Specification Alignment: Bridging Intent and Behavior

The chapter also introduces a concept it calls specification alignment — the process of ensuring that an AI system's behaviors match its intended purpose. This involves defining the primary goal the product will solve for users, then mapping out the sub-goals people need to address along the way. It is, in essence, the work of translating human intent into system design.

This matters because AI systems are literal in ways that humans are not. A system told to maximize time spent in an app will find ways to maximize time spent in an app, even if those ways are manipulative or counterproductive. A system told to minimize user complaints might learn to avoid challenging users rather than helping them grow. The gap between what designers intend and what systems optimize for is where many AI products fail, and specification alignment is the practice of closing that gap deliberately.

Building Responsibly as a Design Practice

The chapter does not treat responsible AI as a separate workstream or an afterthought. Instead, it positions ethical consideration as integral to the design process from the very beginning. The guidebook points to Google's AI Principles and Responsible AI Practices not as compliance documents but as practical resources that inform better product decisions.

This framing matters. When responsibility is treated as a constraint imposed from outside — something legal or policy teams worry about — it tends to get minimized or worked around. When it is treated as a core design practice, it shapes the product in ways that benefit everyone. A reward function designed with long-term user wellbeing in mind does not just avoid harm; it produces a better product. A development process that includes diverse perspectives does not just prevent exclusion; it uncovers opportunities.

Conclusion

The "User Needs + Defining Success" chapter of the PAIR Guidebook is, at its core, an argument for humility — the same humility that the r/UXDesign community was demanding in its response to eighteen months of conversational AI experimentation. The most striking thing about that Reddit thread was not the original post's enthusiasm for emerging design patterns; it was the chorus of experienced practitioners asking: but does it actually help the user? Show me the data. Show me the outcomes.

The guidebook provides the framework for answering those questions honestly. It asks AI product teams to slow down, to listen before building, to define success in human terms rather than technical ones, and to think carefully about the long-term consequences of their design choices. In an industry often characterized by speed and technological ambition, this is a radical proposition — and an essential one. The products that will matter most are not the ones that showcase the most sophisticated AI, but the ones that make people's lives genuinely better. That starts with understanding what people need, and having the discipline to design for it.