Why your product decisions need design expertise.
The hidden costs of letting business leaders design user experiences.
This week’s Product Party is brought to you by Chameleon.
Launching features at AI speed, but adoption crawls behind? Turn feature walkthroughs into adoption engines with Chameleon.
Record yourself explaining any feature → AI creates interactive demos, in-app announcements, help docs, and launch assets. Better yet: see which demo viewers become actual feature users.
Finally prove your launches drive real usage on repeat.
Click this link to see how it works.
I once inherited a product where mortgage customers used a major company's portal to manage their loans. The business leaders insisted on amortization graphs, detailed payment breakdowns, and financial tools that made perfect sense to industry experts.
The customers hated it.
We could see exactly what was happening through user session recordings and feedback. People were abandoning basic workflows and complaining about confusing interfaces. Business leaders continued to add features they understood from running their own businesses, rather than considering what might actually help someone manage their mortgage payment.
This is the fundamental mistake most companies make: assuming business expertise translates to design expertise.
Why business leaders think they can design.
This pattern repeats across companies. Business leaders feel confident making UI/UX decisions because they're domain experts who've likely never worked alongside someone dedicated to user experience design. They assume understanding the business means understanding how users should interact with it.
When business leaders design interfaces, they often prioritize completeness over usability. They want users to see everything the product can do and have access to all the data that feels important from a business perspective.
The result is cluttered interfaces that overwhelm users and bury the actions people actually need to take.
Documentation becomes the band-aid.
When products are designed based on business logic rather than user needs, companies often compensate by providing extensive documentation, training programs, and support resources to address these shortcomings. If users can't figure out how to use your product intuitively, you write help articles. If workflows are confusing, you create video tutorials.
This creates a vicious cycle. The more documentation you need, the more complex your product feels. You're essentially taxing users for your design decisions, making them work harder to get value from something they're paying you to provide.
I've seen companies spend more on support documentation and customer success teams than they would have invested in proper UI/UX design in the first place.
What proper investment looks like.
The contrast becomes clear when you see deliberate design investment in action. In my current work, we've A/B tested landing page experiences before and after making flow and UI adjustments. One simple change - reducing the number of fields on a form - resulted in a 5% increase in conversion from page visit to lead.
That might sound modest, but a 5% improvement in conversion typically pays for months of design work within weeks. More importantly, it represents hundreds of people who had a better experience and were more likely to see value in what you're offering.
With the mortgage portal, the closest we got to proper UI/UX investment was rebuilding the login and password recovery experience. That single change had a huge impact on complaints about system access. Users could actually focus on managing their mortgages instead of fighting with the interface.
These aren't dramatic transformations. They're surgical improvements that remove friction from user workflows. However, they require an understanding of how people actually interact with digital products, not just what information they theoretically need.
Building design credibility.
Getting business leaders to trust design decisions requires demonstrating that good design serves business objectives better than business-driven design. When users complete tasks efficiently, they engage more consistently. When interfaces feel intuitive, adoption increases and support costs decrease.
Here's how I approach these conversations:
Start with user evidence: Use session recordings and support tickets to show where current design decisions cause problems. Business leaders understand data.
Connect design problems to business costs: Calculate what poor usability costs in support resources and lost conversions. Make the economic case using metrics that matter.
Propose testable changes: Suggest specific improvements that can be measured quickly. A/B tests provide concrete evidence that design changes impact business results.
Measure and communicate results: When design improvements work, make sure business leaders understand the connection between design decisions and outcomes.
The key is proving that design decisions generate measurable business value, not just prettier interfaces.
When you consistently connect design improvements to metrics that business leaders care about - conversion rates, support tickets, user engagement - you gradually shift from being seen as someone who makes things look nice to someone who makes business problems disappear.
This builds the credibility you need to have input on bigger decisions before they become expensive mistakes.
Making smarter decisions.
Your users aren't struggling with your product because they don't understand your business. They're struggling because your product doesn't cater to their needs.
The most successful companies recognize that business expertise and design expertise solve different problems, and they need both.
The next time someone suggests a product change because "users need to see this information," ask a different question: how will this change make it easier for users to accomplish what they're actually trying to do?
That shift in perspective might save you months of documentation work while creating experiences users actually want to engage with.
What design decision in your product is currently being driven by business logic rather than user needs?
Until next week,
Mike @ Product Party
Want to connect? Send me a message LinkedIn or Bluesky.
