There is a strange moment in almost every website or app project.
The designer presents a user flow. The developer explains why something works a certain way. Everyone seems aligned.
Then the client says:
“Can we move this button here?”
“Why don't we put everything on the first screen?”
“I think this looks better.”
“Can we make this bigger?”
“Why do users need three steps? Just put everything on one page.”
And suddenly, a carefully planned user experience starts changing one small decision at a time.
None of these suggestions are necessarily wrong. In fact, clients often have valuable insights that designers and developers don't have. They know their customers, their business, their industry and what they are trying to achieve.
The problem starts when personal preference begins replacing UX expertise.
A client knows their business. A UX designer knows how users interact with products.
Those are two different areas of expertise.
Clients Know the Business. Designers Know the Experience.
This distinction is often missed during product development.
A business owner might know exactly what customers are asking for. They might have spent years talking to those customers and understand their frustrations better than anyone else.
That's valuable.
But knowing what customers want doesn't necessarily mean knowing how to structure a screen, design a navigation system, create a conversion flow or reduce cognitive load.
Think about it this way.
You don't tell an architect where every supporting wall should go just because you live in the house.
You explain how you want to use the house.
The architect figures out how to make that happen safely and efficiently.
UX works in much the same way.
The client should explain the problem. The designer should figure out the experience.
The "Make It Simple" Problem
One of the most common examples is the request to "make it simpler."
It sounds reasonable.
But simplicity doesn't mean putting everything in one place.
Imagine an event marketplace where users can search for vendors, event crew, categories, locations, dates, budgets and services.
A client might look at the interface and say:
"Why do we have separate sections? Put everything together. Users should be able to see everything immediately."
From a business perspective, this may seem convenient.
From a UX perspective, it could create a completely different problem.
Users now have too many choices competing for their attention.
The interface becomes crowded. The hierarchy disappears. Important actions become harder to find.
The product technically has more information, but the experience becomes less useful.
Good UX isn't about showing users everything.
It's about showing them the right thing at the right time.
The Problem With Designing Based on Personal Preference
Another common problem is:
"I don't like this design."
That's perfectly valid as an opinion.
But it isn't necessarily a UX problem.
A designer shouldn't be asking only:
"Does the client like this?"
They should also be asking:
"Does this help the user accomplish what they came here to do?"
Those questions can produce completely different answers.
A client may prefer a page with more information because they want customers to see everything their company offers.
A designer may intentionally remove some information from the first screen because research and usability principles suggest that users need a clearer starting point.
Neither person is necessarily trying to make a bad decision.
They are simply looking at the product from different perspectives.
The client is looking at the business.
The designer is looking at the user.
A good product needs both perspectives, but they shouldn't be confused with each other.
Every "Small Change" Has a Cost
One of the biggest misconceptions in product development is that individual UI changes are harmless.
"Just move this."
"Just add another button."
"Just add one more filter."
"Just show this information here too."
"Just change the flow."
The word "just" can become very expensive.
A single change might affect:
- The page layout
- Responsive behaviour
- Navigation
- User flow
- Backend logic
- API requirements
- Mobile screens
- Validation
- Analytics
- Accessibility
- Future scalability
And sometimes the biggest cost isn't development time.
It's inconsistency.
If the same interaction behaves differently across different parts of the product because individual requests were made over time, users have to learn the interface repeatedly.
That's when a product starts feeling confusing.
When Too Much Feedback Creates Bad UX
Feedback is essential.
Without client feedback, designers can easily make assumptions about the business that turn out to be wrong.
The problem isn't feedback.
The problem is unstructured feedback.
Imagine a designer receives feedback from the founder, marketing manager, sales team, operations team and several other stakeholders.
Everyone has a different opinion.
One person wants more information.
Another wants less.
Someone wants a button at the top.
Someone else wants it at the bottom.
Someone wants five steps.
Someone else wants everything on one page.
Eventually, the product isn't being designed anymore.
It's being negotiated.
And when design becomes a negotiation between personal preferences, the user often becomes the person nobody is representing.
"But Our Customers Want It This Way"
This is where things become more interesting.
Sometimes the client is absolutely right.
If ten customers are repeatedly asking for a particular feature, that feedback should not be ignored.
But there's an important distinction between:
"Customers are asking for this."
and:
"Customers are asking for this, therefore this is how the interface should work."
The first is valuable product feedback.
The second is a design decision.
Suppose customers want faster access to a particular feature.
That's useful information.
A UX designer can then determine whether that feature should be moved to the home screen, added to navigation, surfaced through a shortcut, or incorporated into an existing flow.
The customer tells you what problem they're experiencing.
The designer helps determine how the product should solve it.
Designers Don't Always Get It Right Either
It's important not to turn this into a "clients are wrong, designers are right" argument.
That's not true.
Designers make mistakes too.
A designer can misunderstand the business model.
They can make assumptions about users.
They can overcomplicate something.
They can follow a design trend that doesn't actually work for the product.
They can become too attached to their own solution.
Good UX requires collaboration.
The difference is that disagreement should be resolved through reasoning, user feedback, testing and evidence rather than whoever has the strongest opinion in the meeting.
What Clients Should Actually Control
Clients should have a strong voice in product development.
They should define things such as:
- Business objectives
- Target customers
- Brand identity
- Business rules
- Pricing
- Product requirements
- Important workflows
- Legal or operational requirements
- Content and messaging
- Business priorities
These are areas where the client's expertise is critical.
But when it comes to questions like:
"Where should this action appear?"
"How many steps should this flow have?"
"Should this information be visible immediately?"
"How should navigation work?"
"Should this interaction be a modal, page or drawer?"
Those decisions should involve UX expertise.
The answer shouldn't simply be:
"Because I like it there."
There should be a reason behind it.
The Designer's Job Isn't to Make the Client Happy
This is uncomfortable but important.
A designer's job isn't simply to produce something the client likes looking at.
Their job is to create an experience that works for the people using the product.
Sometimes that means telling the client:
"I don't recommend doing this."
And that's not being difficult.
That's part of the job.
A good designer should be able to explain why.
For example:
"Moving this button to the top will make it more visible, but it will compete with the primary action users need at this stage."
That's a much better conversation than:
"I don't think that looks good."
The first is a UX argument.
The second is a personal preference.
The Best Clients Don't Stop Giving Feedback
Interestingly, the best clients aren't necessarily the ones who give the least feedback.
They're the ones who give the right kind of feedback.
Instead of saying:
"Make this button blue."
They might say:
"Our users aren't noticing this action."
That's useful.
Instead of:
"Put the form on the homepage."
They might say:
"We're losing users before they submit the enquiry."
That's useful.
Instead of:
"I don't like this layout."
They might say:
"I feel the most important information isn't obvious enough."
That's useful.
The difference is simple, good feedback explains the problem, and bad feedback often prescribes the solution.
Once the problem is clear, let the designer work on the solution.
A Better Way to Work With Designers and Developers
The healthiest development process usually looks something like this:
The client explains the business problem.
The team asks questions and understands the users.
The designer proposes the user experience.
The developer evaluates technical feasibility.
The client reviews the proposed solution.
Everyone discusses concerns.
The solution is refined.
Then the team builds it.
This doesn't mean clients should blindly accept everything.
It means disagreements should happen at the level of problems, goals and evidence rather than personal design preferences.
Build for the User, Not the Person Sitting in the Meeting
This is probably the most important principle.
The person approving the product is usually not the person using it.
The founder may be approving the app.
The marketing manager may be reviewing the website.
The product manager may be defining requirements.
But the actual user doesn't care who approved the design.
They only care whether the product makes sense.
They want to know:
"Where do I go?"
"What do I click?"
"What happens next?"
"Can I finish what I came here to do?"
If the answer isn't obvious, the product has a UX problem regardless of how good it looks in a meeting.
Final Thoughts
Client involvement isn't the enemy of good UX.
In fact, good products need strong collaboration between clients, designers and developers.
The problem begins when every stakeholder starts making decisions outside their area of expertise based primarily on personal preference.
A client shouldn't disappear from the design process.
They should be deeply involved in defining the problem.
A designer shouldn't blindly follow every request.
They should challenge decisions that could negatively affect usability. A developer shouldn't simply build whatever is handed over.
They should raise technical and implementation concerns when necessary. And everyone should remember who the product is ultimately being built for.
The user.
Because the best website or app isn't the one that looks perfect to the client in a design review. It's the one that feels obvious, intuitive and effortless to the person using it.