AI should solve a product problem—not become the product strategy.
AI is rapidly becoming a default item on product roadmaps.
Add a copilot.
Add recommendations.
Add an AI assistant.
Add a chatbot.
Add an agent.
But there is a more fundamental question product teams should ask before any of these:
Does this problem actually need AI?
The availability of powerful AI models does not automatically make AI the right solution. In some products, AI can create experiences that would otherwise be impossible. In others, it introduces uncertainty, complexity, cost, and new failure modes without creating meaningful value for users.
Google’s People + AI Guidebook makes this distinction explicitly: before building an AI feature, teams should determine whether AI creates value that a simpler solution cannot. It also notes that rule-based or manual solutions may be preferable when predictability or complete transparency is important.
For product designers, this changes the starting point.
The question is no longer:
Where can we add AI?
It becomes:
What user problem are we solving—and does AI give us a meaningfully better way to solve it?
Start With the Problem, Not the Model
Imagine a job-search platform.
A user wants to see jobs posted in Muscat during the last seven days.
Do we need AI?
Probably not.
A database query and a few filters can solve the problem faster, cheaper, and more predictably.
Now imagine the same user asks:
Which of these jobs best matches my experience, skills, career goals, and previous projects—and why?
The problem has changed.
The system now needs to interpret unstructured information, understand relationships between the candidate’s experience and job requirements, rank alternatives, and potentially explain those recommendations.
This is where AI may create substantial value.
The difference is important:
AI isn’t valuable because the technology is sophisticated. It’s valuable when the problem requires capabilities that simpler systems cannot provide well.
A Practical AI Decision Framework
Before adding AI to a product, I would ask six questions.
1. Does the problem involve ambiguity?
Traditional software works particularly well when rules are explicit.
If:
A → B
every time, a deterministic system may be exactly what we need.
But many human problems don’t look like this.
Consider:
Is this customer complaint urgent?
Which candidate is most relevant for this role?
What is the main theme across 200 user interviews?
What does the user probably want to do next?
There may not be a single rule capable of answering these questions.
AI becomes particularly useful when products need to work with patterns, probabilities, language, context, or ambiguity.
Google PAIR, for example, identifies recommendations, prediction, natural-language understanding and image recognition as areas where AI can be well suited.
2. Does AI create something meaningfully better?
This may be the most important question.
AI should not merely make a feature look more advanced.
Consider a fitness application.
If users simply need to select:
Running / Cycling / Swimming
adding an AI assistant that asks:
“What kind of activity would you like to do today?”
may actually make the experience slower.
Three buttons were enough.
But suppose the product could understand:
training history + sleep + goals + injuries + schedule + previous performance
and recommend an appropriate training plan.
Now AI is potentially creating something a static interface couldn’t easily provide.
This gives us a useful principle:
Use AI when it expands the product’s capability—not merely its interface.
3. Is uncertainty acceptable?
This is where designing AI products becomes fundamentally different from designing traditional software.
AI can be wrong.
Not just because of a software bug, but because uncertainty can be inherent in the system.
A recommendation may be reasonable but not ideal.
A generated answer may sound convincing while containing an error.
A classification may have high confidence and still be incorrect.
Microsoft’s Human-AI Interaction Guidelines therefore recommend making clear both what an AI system can do and how well it can do it, and providing mechanisms for users to dismiss, correct or recover from incorrect AI behavior.
So before introducing AI, I would ask:
What happens when the AI is wrong?
If the answer is:
“Nothing serious. The user can correct it.”
AI may be appropriate.
If the answer is:
“Someone could make an irreversible, high-stakes decision.”
the design threshold should be dramatically higher.
The question isn’t whether the model makes mistakes.
The product question is whether we can design a safe and useful experience around those mistakes.
4. Does the user need AI—or automation?
These are not the same thing.
Suppose an employee repeatedly copies information from one system into another.
We could build an AI agent.
But perhaps a conventional automation rule solves the entire problem:
When X happens → copy Y → send Z.
No reasoning is required.
No interpretation is required.
No generation is required.
AI introduces probabilistic behavior where deterministic automation would have been sufficient.
This distinction becomes especially important as AI agents become more popular.
Before designing an agent, ask:
Does the system actually need to interpret and decide—or does it simply need to execute?
If execution is enough, automation may be the better product decision.
5. Do users have enough control?
An AI system can technically perform a task while still producing a poor human experience.
Imagine an AI system generating responses to customer complaints.
There are several possible designs.
A
AI automatically responds.
B
AI generates a response and the human approves it.
C
AI generates a response, explains its recommendation, and allows the human to edit, reject, regenerate or approve it.
These aren’t simply different interfaces.
They represent different relationships between human judgment and machine capability.
Microsoft’s HAI guidance specifically emphasizes efficient correction, explanations of AI behavior, feedback mechanisms and global controls.
This leads to another question:
What should AI decide, and what should remain under human control?
Sometimes the best AI product isn’t one that automates the most.
It is one that creates the right division of responsibility between human and AI.
6. Can we evaluate whether AI is actually helping?
An AI feature isn’t successful simply because users interact with it.
Imagine we introduce AI recommendations into a recruitment platform.
We could measure:
AI feature usage: 72%
That sounds impressive.
But it doesn’t tell us whether the feature is useful.
Better questions might be:
Did users discover more relevant opportunities?
Did time-to-relevant-job decrease?
Did users understand why jobs were recommended?
Did inappropriate recommendations decrease?
Did users become over-reliant on the recommendations?
Could users identify when the AI was wrong?
Google’s People + AI guidance connects AI product development directly to defining user needs, evaluation, mental models, explainability, feedback, control, and graceful failure.
AI therefore changes not only what we design.
It changes what we need to measure.
A Simple Decision Test
Before putting an AI feature on the roadmap, I would run this test:
| Question | If YES | If NO |
|---|---|---|
| Does the problem involve ambiguity, prediction or interpretation? | AI may help | Consider rules |
| Does personalization create meaningful value? | Explore AI | Static experience may work |
| Is natural language or unstructured data central? | Explore AI | Conventional UI may work |
| Can the experience tolerate occasional errors? | AI may be viable | Be cautious |
| Can users understand/correct AI behavior? | Good candidate | Redesign interaction |
| Can we measure whether AI improves the outcome? | Prototype & test | Define success first |
This isn’t a formula for deciding whether to use AI.
It is a way of forcing the team to justify AI through user value rather than technological excitement.
The Designer’s Role Is Changing
This is perhaps the part I find most interesting.
In traditional product design, we often design:
User → Interface → System
With AI products, the relationship increasingly becomes:
Human ↔ AI ↔ System
The AI interprets.
It recommends.
It generates.
Sometimes it acts.
And the human develops expectations about what the AI knows, how much it can be trusted, when it should be corrected, and how much responsibility should be delegated to it.
That means product designers need to think beyond screens and flows.
We increasingly need to design:
Capabilities
What should the AI be able to do?
Boundaries
What should it not do?
Mental models
What does the user believe the AI can do?
Uncertainty
How should the system behave when it isn’t sure?
Explainability
When does the user need to understand why?
Control
When can the human intervene?
Recovery
What happens when AI fails?
Trust
How do we help users develop appropriate—not maximum—trust?
Research in Human-AI Interaction has been addressing precisely these challenges. Microsoft’s 18 HAI guidelines, for example, were synthesized from more than two decades of prior work and validated with design practitioners across existing AI-infused products.
AI Is a Product Decision, Not a Feature
Perhaps the biggest mistake teams can make today is beginning with:
“We need an AI feature.”
A better starting point is:
“We have a user problem.”
Then:
Can conventional software solve it?
If yes, use it.
If not:
Could automation solve it?
If yes, automate it.
If not:
Does the problem require prediction, interpretation, generation, recommendation, or reasoning under uncertainty?
Now AI becomes interesting.
And even then, one final question remains:
Can we design the human-AI relationship well enough that the benefits outweigh the uncertainty we introduce?
That’s where AI stops being a technology decision and becomes a product design problem.
References & Further Reading
Microsoft Guidelines for Human-AI Interaction — CHI 2019