Product design is an art of negotiation. Friction rarely disappears. The real question is who pays for it.
In 1999, I joined The Tennessean and spent the next several years working on Tennessean.com and related digital products. Newspaper websites were still figuring out how print economics translated to the web.
Readers came for the journalism. They did not come for the ads. Advertisers, naturally, had a different opinion.
The newspaper needed advertising revenue. Editorial wanted the stories to remain readable and credible. Marketing needed inventory it could sell. Developers had to make all of it work inside the technology we had at the time, preferably without bringing the page to its knees.
Every ad became a small argument: How big? Where does it go? How often? Can it interrupt an article? Does it move? How much advertising can you wrap around a piece of journalism before the journalism starts feeling like the thing getting in the way?
The pure user-centered answer was easy: remove the ads.
Beautiful experience.
There was only one small problem. Eventually you might remove the newspaper with them.
I didn't have the language for it then, but much of what I was doing wasn't really about designing pages.
It was negotiation.
Friction doesn't disappear
Today, YouTube is solving essentially the same problem, only at a ridiculous scale.
The viewer wants to watch without interruption. The creator wants to get paid. The advertiser wants attention. YouTube needs all three of them to come back tomorrow.
There is no interface that gives everybody everything they want, so the product negotiates. YouTube's mid-roll system favors natural pauses and transitions over more disruptive moments because those breakpoints tend to preserve viewer retention while balancing creator earnings, viewer experience, and advertiser value. In 2025, YouTube explicitly connected that approach to better long-term monetization. (YouTube Help)
That distinction matters.
The problem isn't simply that ads are bad UX and revenue is good business. Push monetization hard enough, and eventually you damage the audience producing the monetization.
We often describe good UX as if our job is to remove friction: fewer clicks, less waiting, less interruption, less thinking. Sometimes that's exactly the job. But friction doesn't disappear because a designer dislikes it. It moves.
Remove advertising, and perhaps the user pays a subscription. Remove every security step and somebody eventually pays for that convenience. Make something cheaper to build, and Support may spend the next three years dealing with the consequences.
Good design isn't about removing all friction. It's about deciding which friction is necessary, where it belongs, and who pays for it.
The cost might be money, time, attention, privacy, cognitive effort, engineering complexity, operational overhead, or risk.
The interesting part is rarely whether a cost exists.
It's where we put it.
There is rarely one user
Designers are often told that we are the voice of the user.
Fine. Which user?
Enterprise software makes the problem obvious. The executive buying the platform may want controls, reporting, auditability, and risk reduction. The administrator wants configuration and permissions. The manager wants visibility. The employee using the thing all day wants to finish a task without opening a manual.
All of them are users of the same system, but their interests are not identical.
Add another approval step and perhaps the compliance team sleeps better while every employee pays for that decision every day. Remove it, and the daily experience gets faster, but risk moves somewhere else.
Marketplaces expose the same problem from another angle: both sides can be end users, and improving one side's experience can simply transfer inconvenience, risk, or cost to the other.
That is why “advocating for the user” has always felt incomplete to me. There isn't always one clean set of user needs sitting on one side of a whiteboard and an evil business sitting on the other.
There is a system of interests.
The designer's job isn't automatically choosing one side. It's understanding what happens to the rest of the system when a choice is made.
Not every requirement is a requirement
Organizations love the word requirement.
Business requirement. Marketing requirement. Technical requirement. User requirement.
Eventually everything in the meeting becomes a requirement, which is convenient because requirements sound like things we're no longer allowed to question.
They aren't all the same.
“We need more qualified leads” is a goal.
“I need to understand what I'm agreeing to before I pay” is a user need.
“This has to operate on our existing architecture” may be a constraint.
“The VP wants the button above the fold” is a preference.
“We need a popup” is usually a proposed solution wearing a fake mustache and pretending to be a requirement.
That last one isn't merely sloppy vocabulary. It's a decision made before discovery.
If Marketing says, “We need a popup,” there isn't much left to negotiate except the popup. If Marketing says, “We need 20 percent more qualified leads from this page,” we have a design problem again.
Maybe a popup is the answer. Maybe the offer is wrong. Maybe the form asks for too much. Maybe the page attracts the wrong audience. Maybe nobody understands what we're selling.
The same applies to technical constraints.
“We can't do that.”
Maybe.
Can't? Or expensive? Risky? Not this quarter? Incompatible with the current architecture? Simply annoying?
Those aren't the same thing.
Senior designers don't just work within constraints. They learn which constraints are real.
A false constraint creates a false compromise. Once you separate the real problem from the solution somebody attached to it, another option can appear.
Good negotiation changes the equation
Security gives us a clean example.
Users don't want authentication friction. Security teams want stronger authentication. The lazy compromise is somewhere in the middle: make users suffer, but not too much.
GitHub faced a version of this when it began requiring two-factor authentication for large groups of code contributors.
Instead of simply adding another gate and telling developers to live with it, GitHub invested in enrollment, recovery, authentication options, support workflows, and passkeys.
The numbers matter. Among contributors who received the 2FA requirement in 2023, GitHub reported nearly 95 percent enrollment. At the same time, 2FA-related support tickets dropped by one-third, and recovery tickets requiring substantial human intervention fell by 54 percent. GitHub credited its up-front research and UX work as part of that result. (GitHub)
More security. Less support burden.
GitHub didn't find the midpoint between security and usability. It changed part of the equation.
Sometimes good negotiation isn't finding the middle. It's finding a third option.
That's the difference between compromise and design.
Some floors are not negotiable
There is a trap in all this.
If business wants one thing and users want another, it is tempting to imagine product design as finding a comfortable spot halfway between them.
That's not always acceptable.
You don't negotiate your way to 60 percent safe. You don't meet informed consent halfway. Accessibility doesn't mean one group wants zero and another wants 100, so everybody shakes hands at 50.
Some things establish the floor.
Accessibility is useful here because it exposes the distinction between the standard and the path.
Where accessibility is legally, contractually, or organizationally required, the minimum outcome isn't the bargaining chip. What remains negotiable is how you get there: architecture, sequencing, tooling, remediation priorities, testing, ownership, and how accessibility becomes part of delivery instead of a cleanup exercise at the end.
The standard is the floor. The path is negotiable.
The harder case is an organization operating somewhere accessibility isn't strongly regulated.
Nobody is forcing the decision.
That's when you discover whether you can actually make the case.
Accessibility still needs a business language
The easiest accessibility argument is moral: disabled people should be able to use the product.
True.
It may also get you exactly zero budget.
The other popular argument is business theater: take a global disability statistic, multiply it by your market, and announce a giant accessibility ROI.
That's not analysis. That's arithmetic cosplay.
The real conversation is more specific.
With Product, I want to know whether people with disabilities can complete the important tasks.
With Engineering, I want to know how many accessibility barriers we're introducing every release, how long they take to fix, and whether the same defects keep coming back.
With Sales, I want to know whether accessibility questions are slowing procurement or excluding us from deals.
With Support, I want to know how often somebody needs a human being because the supposedly self-service path doesn't actually serve them.
With leadership, I want to know which customers and markets we intend to pursue next, and how expensive the retrofit becomes if we wait.
Same accessibility problem. Different negotiation.
Don't sell accessibility as charity. Don't sell it as magical ROI either. Connect it to the outcomes the organization already claims to care about.
You're negotiating the path to accessibility. You're not negotiating whether disabled people count as users.
A KPI is a vote
Business says the idea will increase revenue. Design says users will hate it. Engineering says it will take six months. Marketing says users won't care.
Everybody sounds confident.
Without evidence, the person with the highest title, loudest voice, or best PowerPoint has a suspicious advantage.
This is where measurement becomes part of negotiation.
Microsoft's experimentation teams use the term guardrail metrics for things they may not be trying to improve but explicitly don't want to degrade—page-load time, crash rate, abandonment, and similar measures. (Microsoft Research)
In plain English: measure what you're trying to gain, then measure what you might be breaking to get it.
More ad revenue? Measure revenue, but watch retention.
More paid subscriptions? Measure conversion, but watch the health of the free-user population.
Faster delivery? Measure cycle time, but watch escaped defects.
Stronger security? Measure adoption, but watch failed authentication and support demand.
Better accessibility? Don't just count issues closed. Count the new barriers introduced by the next release.
A KPI is a vote.
If you measure only conversion, every optimization problem eventually becomes a conversion problem. If you measure only delivery speed, speed wins. If revenue is the only thing you measure, the business wins the negotiation before the meeting even starts.
A mature product doesn't only measure what it wants more of. It also measures what it refuses to destroy while getting there.
Time changes the negotiation
Some decisions look completely different depending on whether you're optimizing this click, this quarter, or the next five years.
At the end of 2025, Duolingo made that tension unusually visible. It announced that its 2026 strategy would prioritize user growth and better teaching, including improvements to the free experience, even though management expected the choice to moderate near-term financial growth. (Duolingo)
By Q2 2026, daily active users were growing 23 percent year over year to 58.7 million, up from 21 percent growth in Q1. Revenue and adjusted core profit both beat Wall Street expectations. Some of that acceleration came from a one-time Streak Revival campaign that brought millions of inactive learners back, so declaring the strategy “proved” would be premature.
And the market still wasn't impressed.
Duolingo shares fell more than 10 percent in after-hours trading as investors focused on slower bookings growth and softer Q3 revenue guidance, even as the company raised its full-year profitability outlook. (Reuters)
That's more interesting than a clean success story.
The user-growth metric management said mattered was moving in the right direction. Revenue and profit beat expectations. The market still wanted something else.
Quarter versus decade.
The negotiation isn't always user versus business. Sometimes it's one definition of business success versus another.
AI can hide the cost
AI doesn't make this problem disappear. It can make the cost harder to see.
Imagine an AI assistant drafting an email to a customer.
If the draft is wrong, I read it, fix it, and send it. The failure costs me thirty seconds.
Now let the agent send the email automatically.
Same model. Same probability of being wrong. Completely different product decision.
If it sends the wrong information, the user spends time repairing the relationship. Support may get involved. The business may lose trust. A manager may have to explain what happened.
The model made the mistake.
Humans deal with the consequence.
This is why I use Bounded Autonomy in my Eight Heuristics for Generative and Agentic AI Products: small, reversible actions can happen quietly when there is an obvious undo; actions capable of meaningful damage need stronger previews, approval, intervention, or recovery.
The negotiation isn't simply speed versus accuracy. It's convenience versus liability. Automation versus control.
When the system decides for me, who pays when it's wrong?
That is a product design question before it is an AI question.
Negotiation requires a legible deal
YouTube telling me that I can watch something for free in exchange for advertising is a deal.
I may dislike it, but I can see it.
Making a subscription effortless to start and deliberately difficult to cancel is something else. So is hiding the option the company doesn't want me to choose, disguising consent, or repeatedly asking after I've already said no.
Negotiation requires a legible deal. Manipulation hides the deal.
A business has interests. Of course it does. Design is allowed to serve them.
But if the business can only win when the interface prevents the user from understanding the transaction, we're no longer negotiating.
We've simply made the cost harder to see.
Governance gives “no” somewhere to go
This is the part that gets conveniently left out of a lot of design ethics conversations.
What happens when somebody walks into the meeting and explicitly asks for the manipulative version because conversion needs to move this quarter?
Saying, “That's a dark pattern,” may be correct. It may also end the conversation without changing the product.
Go back to the actual goal.
What are we trying to improve? What does the proposed solution cost the user? How would we know if we've pushed too far? What guardrail belongs beside the success metric? Can we reach the same business outcome without hiding the deal?
Then make the decision visible.
If leadership still chooses the harmful version, document the risk and the decision owner. If it crosses a genuine floor: safety, consent, accessibility, deliberate deception, escalate it through whatever governance exists.
And if there is nowhere to escalate it, that is a governance problem in itself.
Governance is what happens when “I don't think we should do this” has somewhere to go.
Without that, ethics depends on whoever happens to be the most stubborn person in the room.
Make the trade visible
Product Designers aren’t the user's lawyer, the business's decorator, engineering's ticket factory, or marketing's button department.
Much of the job is sitting in an uncomfortable place between different versions of reality. The user needs something. The business needs something. Technology allows something. Operations can support something. Regulation creates boundaries. Evidence tells us something—usually imperfectly.
None of it arrives neatly packaged.
Before accepting a trade-off as inevitable, I want a team to answer five questions:
- What does each side actually need, and which “requirements” are really proposed solutions?
- Which constraints are real, and which are simply expensive, inconvenient, or inherited?
- What cannot be traded away?
- What are we trying to improve, and what are we unwilling to damage while doing it?
- Can we change the equation instead of splitting the difference?
And then one more:
If this works exactly as designed, who pays?
Sometimes the answer is perfectly acceptable.
The attacker trying to enter an account gets blocked. A business accepts more engineering cost today to avoid much larger remediation later. An advertiser pays for attention. A user accepts a few seconds of friction because the alternative carries a much larger risk.
There is no rule saying every product decision must benefit everybody equally.
But sometimes that question exposes something we'd rather not see.
Back at The Tennessean, we weren't trying to invent advertising readers would love. Nobody finished an article and thought, Wonderful journalism. Shame there wasn't another banner in the middle.
We were trying to find an arrangement where readers could still read, advertisers could still reach them, the publication could still make money, and we didn't slowly destroy the reason people came to us in the first place.
The systems are more complicated now. We have subscriptions, enterprise platforms, marketplaces, algorithms, AI, personalization, accessibility, privacy, security, regulation, and dashboards full of numbers telling slightly different versions of the truth.
But the work hasn't changed as much as we like to pretend.
The job isn't to make everybody happy. It's to understand what everybody actually needs, know what shouldn't be traded away, find room where everyone else sees a binary choice, and make the trade visible before someone quietly gets stuck with the cost.
That's not compromise.
That's negotiation.
“We should never allow ourselves to be bullied by an either-or.”
— Mary Parker Follett