The Hidden UX Problem With Giving Users Too Many AI Models
Summary: sarah wilson discusses the challenges of multi-model AI products, emphasizing the complexity added by offering multiple models to users. They argue that users typically come with a task in mind, not a specific model, which can lead to cognitive overload when faced with numerous options. The author suggests redesigning interfaces to prioritize task-based workflows, providing sensible defaults, and reserving model selection as an advanced feature. They highlight the importance of learning from user behavior to improve routing decisions and enhance user experience, all while maintaining transparency and control for advanced users.
For AI products, adding another model can feel like an obvious upgrade.
A new model becomes available. It handles a certain type of image better, supports a different video workflow, or gives users another creative option. Adding it to the product seems to increase capability without taking anything away.
But there is a cost that is easy to underestimate: every new model creates another decision for the user.
I have been thinking about this while looking at how multi-model creative products are evolving. The technical challenge of supporting multiple models is only part of the problem. The harder product question may be deciding how much of that complexity users should actually see.
Users Usually Arrive With a Task, Not a Model
Most people don't open an AI product thinking:
"I want to use Model X today."
They are more likely to arrive with a practical goal:
"I need a product image."
"I have an image and want to turn it into a short video."
"I need a few concepts for a campaign."
"I want to test whether this visual idea works before spending more time on it."
The model is a means to that outcome.
Yet many AI products reverse this relationship. One of the first things a user sees is a list of model names, versions, modes, and settings.
For people who closely follow model releases, that level of control is useful.
For everyone else, it creates a prerequisite: understand the tools before completing the task.
More Models Can Mean More Friction
Imagine a user who wants to animate an existing product image.
If the interface offers one generation path, the decision is relatively simple.
If it offers six models, the user immediately has more questions.
Which one is better for image-to-video?
Which one is more likely to preserve the reference?
Does the newest model necessarily make sense for this task?
Should I test several?
What happens if the first result is poor?
The platform has technically become more capable, but the user's path to the Generate button has become less obvious.
This is the paradox of multi-model products: adding capability can also add cognitive load.
Model Selection Could Become a Routing Problem
One way to think about this is to separate the user's task from the underlying model.
Instead of designing the workflow as:
Choose Model → Configure → Generate
it could begin with:
Define Task → Identify Requirements → Recommend Route → Generate
Consider this request:
"I have a product image and want a subtle six-second clip without changing the main product."
There is already useful information in that sentence.
The input is an image.
The desired output is video.
Reference preservation matters.
Motion should be restrained.
The user has effectively described requirements that could help the product recommend a starting point.
The model selector doesn't necessarily need to disappear. It simply doesn't have to be the first decision.
Building Around Multiple Models Made This More Visible
I started paying more attention to this issue while working with multi-model creative workflows. A platform such as DoMax AI brings different AI image and video generation options into one environment, which makes the model-selection problem particularly visible.
The interesting product challenge isn't simply putting more models in the same place.
It's deciding what happens next.
If users still need to leave the product, research every available model, compare specifications, return, and then make a selection, the platform has reduced tool switching without necessarily reducing decision friction.
That distinction matters.
Good Defaults May Be More Valuable Than More Options
This suggests that AI products may need stronger defaults.
Suppose a user chooses "Animate an Image."
The product could recommend an appropriate generation route based on the input and task, while still exposing model selection as an advanced option.
A short explanation could make the decision transparent:
"Recommended for image-to-video tasks where reference consistency is important."
The user can accept the recommendation or override it.
This preserves control without requiring everyone to understand the entire model catalog.
Good defaults are not about taking decisions away from users. They are about deciding which choices deserve attention at a particular moment.
Power Users Complicate the Picture
There is an obvious problem with hiding model complexity: experienced users often want it.
A designer who has tested several models may know exactly which one they prefer.
A developer may be evaluating model behavior deliberately.
A creative team may have an established workflow built around a particular model.
For these users, automatically choosing everything would be frustrating.
That makes progressive disclosure interesting.
A beginner might see:
Create an Image
Animate an Image
Create a Video
An advanced user might open another layer and see:
Model
Generation settings
Reference options
Additional controls
The underlying capabilities are the same. What changes is how much complexity the interface exposes by default.
Model Count Is a Weak Product Metric
This also changes how we think about competition between AI products.
"Supports 15 models" sounds stronger than "supports 5 models."
But that number tells us very little about whether the product is easier to use.
A smaller selection with clear routing may create a better experience than a huge catalog where users have to perform their own research before every generation.
The more useful questions might be:
How quickly can a new user reach a reasonable first result?
How often do users switch models after a failed generation?
Do they understand why one model was recommended?
How many generations happen before a usable result is selected?
Do users repeatedly return to the same few models despite having many available?
Those behaviors tell us more than the size of the model list.
Failed Generations Are Product Data
There is another side to this.
If a user repeatedly tries one model, gets an unsatisfactory result, changes the prompt several times, and eventually switches to another model, that sequence contains useful information.
The product could potentially learn from the pattern.
Not by assuming that one model is universally better, but by identifying situations where users repeatedly abandon a particular route.
Over time, model routing could become informed by actual task patterns rather than static descriptions such as "best for video" or "best quality."
That would make the interface more useful as the number of available models grows.
The Model Doesn't Have to Disappear
I don't think the endpoint is a completely invisible model layer.
Generative models are not interchangeable infrastructure. Their differences can materially affect style, motion, consistency, speed, controls, and the kinds of inputs they accept.
Users should be able to understand and control those differences when they matter.
But there is a difference between making model choice available and making model choice mandatory.
That may become an increasingly important distinction.
The Bigger Product Question
The AI industry is moving quickly toward more models, more versions, and more specialized capabilities.
From an engineering perspective, connecting those capabilities is valuable.
From a product perspective, connecting them is only half the job.
Someone still has to decide which option makes sense for the task.
Today, we often push that decision onto the user.
I'm not sure that will remain the dominant interface.
As multi-model products mature, one competitive advantage may be the ability to hide complexity at the right moment and reveal it when it becomes useful.
That leaves me with a question for other founders building AI products:
When users come to your product, do they actually want to choose a model—or do they mainly want to describe what they're trying to accomplish and get a sensible place to start?
.png?_a=BAVMn6E80){kind=small}