UX designing and CX designing

How Designing for Users Means Understanding Everyone Who Isn't One

User-Centered Design didn't arrive as a theory and then get adopted. It arrived as a correction — a reaction to years of building things that technically worked but were quietly hostile to the people using them.

Through the late 1990s and into the early 2000s, web applications were designed primarily around two constraints: what the available technology could do, and what the client wanted to see. The user — the person who would actually navigate the interface, complete the tasks, and either succeed or abandon the attempt — was, at best, an afterthought. At worst, they were invisible entirely. The result was a generation of applications that served their creators' vision but not their audience's reality. Dense pages overloaded with information because the client wanted everything visible at once. Navigation structures that mirrored the company's internal org chart rather than the user's mental model. Registration flows that collected every data point the marketing team could imagine, regardless of whether the user was willing to provide them. Checkout processes designed around the database schema rather than the purchase decision.

Designers and developers lived with these applications too. They were users of other people's products, and they experienced the same frustrations — the unintuitive navigation, the buried functionality, the forms that felt like interrogations. Whether User-Centered Design emerged from that self-critical awareness or simply from the natural maturation of a young discipline is hard to say. Probably both. But the shift, when it came, was decisive. The focus moved from "what does the client want to show?" to "what does the user need to accomplish?" And that single reorientation changed everything.

What the Shift Actually Changed

The immediate effects of UCD were tangible and measurable. Usability improved because someone was finally testing whether real humans could actually complete tasks with the interface. Accessibility improved because thinking about diverse users meant thinking about diverse abilities. Conversion rates improved because reducing friction in task flows meant more people reached the end of the process. Bounce rates dropped because landing pages started answering the question the user arrived with rather than the question the company wished they'd asked.

But the deeper change was cultural. UCD gave designers and developers a framework for advocacy — a principled basis for pushing back on decisions that would harm the user's experience. Before UCD, a designer who objected to a client's request was expressing a personal preference. After UCD, the same objection could be grounded in research, testing, and established methodology. The designer wasn't saying "I don't think that's a good idea." They were saying "our research indicates that users struggle with this pattern, and here's the data."

This was also the moment when investing in web applications started to make real business sense. Products designed around user needs performed better by every metric that mattered — engagement, retention, satisfaction, revenue. The investment in research and testing paid for itself because the resulting product actually worked for the people it was meant to serve. UCD didn't just make products better for users; it made the case that good design was good business.

And it was precisely this success that created the discipline's most persistent challenge.

The Tension That Never Resolves

The moment User-Centered Design proved its value, it entered into permanent tension with the other set of needs that every project must serve: the client's.

This tension is not a failure of methodology. It's structural. The client and the user want different things, not because either party is wrong but because they occupy fundamentally different positions relative to the product.

The client is investing. They're spending money, allocating resources, committing organizational attention. Their needs are expressed in the language of outcomes: return on investment, conversion rates, lead generation, brand visibility, market share, cost efficiency. They want the maximum output from the minimum input. They want the product to perform — not in the user-experience sense of performing well, but in the business sense of producing measurable results.

The user is consuming. They arrive at the product with a task in mind — find information, complete a purchase, submit an application, solve a problem — and their ideal experience is one where the task is accomplished quickly, easily, and without unnecessary friction. In many cases, the user's definition of success is leaving the application as soon as possible. They got what they came for. They're done. They want to move on.

These two orientations don't always conflict. But they conflict often enough that managing the tension is a permanent part of the designer's job, not an occasional complication.

When the Lists Align

There are projects where user needs and client needs point in the same direction, and these projects are, predictably, the easiest to design well.

Consider a government information portal. The client's primary need is to deliver public information effectively — health guidelines, tax procedures, benefit eligibility criteria. The user's primary need is to find and understand that information. The goals are aligned: both sides want the content to be accessible, clear, well-organized, and easy to navigate. The design challenge, while still substantial, is primarily architectural. How do you structure thousands of pages of content so that a user with a specific question can find the answer without getting lost? How do you accommodate the enormous range of literacy levels, language abilities, and device types in the audience?

This is the domain of information architecture, and when the project's success hinges on it, the work is relatively clean. "Relatively" is doing some work in that sentence — information architecture for large-scale content systems is deeply complex — but the alignment of goals means the designer isn't fighting the client to do the right thing. The right thing for the user and the right thing for the client are, in this case, the same thing. The key to success is getting the structure right: the taxonomy, the navigation hierarchy, the search functionality, the content relationships. Get the architecture of information right, and the product serves everyone.

When the Lists Diverge

Then there are the other projects.

An e-commerce platform. The client's need is to maximize average order value, increase time on site, encourage browsing across product categories, capture email addresses for remarketing, and reduce return rates. The user's need is to find the specific product they want, confirm it meets their requirements, purchase it, and leave.

A SaaS onboarding flow. The client's need is to demonstrate the product's full capability during the trial period, collect usage data for the sales team, guide the user toward the paid tier, and reduce churn. The user's need is to determine whether the tool solves their specific problem, accomplish enough to justify continuing, and make a decision without being pressured.

A news publication. The client's need is to maximize page views (which drive advertising revenue), increase newsletter subscriptions, promote premium content, and keep users on the site as long as possible. The user's need is to read the article they came for, possibly explore one or two related pieces, and return to whatever they were doing.

In each of these cases, the client wants the user to do more — more browsing, more clicking, more engaging, more subscribing, more staying. The user wants to do less — less searching, less friction, less distraction, fewer steps between arrival and accomplishment. The client's ideal user is one who lingers. The user's ideal experience is one that doesn't require lingering.

This divergence is where design becomes genuinely difficult, and where the methodology of UCD, on its own, doesn't provide a complete answer. UCD tells you to design for the user. The project's viability depends on satisfying the client. Designing exclusively for one at the expense of the other produces either a product that users love but that doesn't sustain itself commercially, or a product that meets business metrics but bleeds users through attrition and frustration.

The way through this is not to choose a side. It's to understand both sides with enough precision that you can find the overlaps, negotiate the conflicts, and make deliberate trade-offs where compromise is unavoidable.

The Two-List Method

The practical approach begins with something deceptively simple: two lists.

The first list catalogs the user's needs. Not what the team assumes about users, not what the client believes users want, but what research — interviews, surveys, usability testing, analytics, behavioral observation — reveals about what users are actually trying to accomplish, what frustrates them, what they value, and where they abandon the process.

The second list catalogs the client's needs. Not the vague aspiration of "more conversions" but the specific, measurable outcomes the business requires: what data needs to be collected, what actions need to be encouraged, what metrics define success, what constraints (budget, timeline, regulatory, brand) limit the solution space.

Placed side by side, these two lists reveal a landscape that is usually more nuanced than either the design team or the stakeholders expected.

Some needs will be shared. Both the user and the client want the checkout process to be smooth — the user because friction wastes their time, the client because friction kills conversions. Both want the search function to return relevant results — the user because irrelevant results are useless, the client because irrelevant results mean lost sales. These shared needs are the foundation of the product. They're where the design effort has the highest return and the lowest political cost.

Some needs will be complementary. The user wants to feel confident in their purchase decision; the client wants to reduce return rates. These aren't identical needs, but they point toward the same design solutions — better product photography, clearer specifications, honest reviews, accurate sizing guides. Complementary needs are opportunities to satisfy both parties with a single design decision.

And some needs will be genuinely in conflict. The client wants to collect the user's phone number at registration; the user wants to provide as little personal information as possible. The client wants to display promotional banners across the interface; the user wants an uncluttered task environment. The client wants to gate premium content behind a subscription wall; the user wants unrestricted access to the content they found through search.

The conflicts are where the designer earns their keep. Not by siding with the user (which UCD orthodoxy might suggest) or siding with the client (which project politics might demand), but by understanding the underlying motivation behind each need and finding solutions that address the motivation even when they can't satisfy the stated requirement.

The client wants the phone number not because they love collecting data, but because the sales team needs a direct contact channel. Can that channel be established differently — through in-app messaging, through email, through a callback request that the user initiates? The client wants promotional banners not because they enjoy cluttered interfaces, but because new product lines need visibility. Can that visibility be achieved through contextual recommendations within the user's natural task flow rather than through interruptive banners? The client wants a subscription wall not because they want to frustrate readers, but because content production costs money and ad revenue alone doesn't cover it. Can the paywall be implemented in a way that feels like value rather than restriction — a metered model, a premium experience with tangible benefits, a free tier that's generous enough to demonstrate quality?

Each of these reframings preserves the client's underlying objective while reducing or eliminating the user's friction. This is the design work that matters most, and it's entirely invisible in the final product. The user never sees the conflict that was resolved. The client never sees the alternative that was avoided. They both see a product that works.

From Strategy to Scope: The Garrett Milestone

Jesse James Garrett, in The Elements of User Experience, articulated a principle that captures this entire process in a single formulation: strategy becomes scope when user needs and product objectives are translated into specific requirements for content and functionality.

This transition — from abstract needs to concrete scope — is where the two lists stop being an analytical exercise and start becoming a product. It's the moment when "users need to find products quickly" and "the client needs to increase average order value" are reconciled into specific features: a search function with intelligent filtering, a recommendation engine that surfaces genuinely relevant products, a comparison tool that helps users evaluate options without leaving the site. Each feature satisfies a user need and a business objective simultaneously, not because the needs were identical but because the designer understood both well enough to find the intersection.

The Garrett framework matters because it makes this reconciliation explicit and methodical rather than intuitive and ad hoc. It forces the team to document the strategy — the full inventory of needs from both sides — before defining the scope. This sequencing prevents the common failure mode where features are specified before needs are understood, resulting in a product that includes everything the client asked for and nothing the user actually wants.

Empathy as Method, Not Sentiment

The word "empathy" appears frequently in design literature, and it's often treated as a soft virtue — a personality trait that makes designers more sensitive to user needs. That framing undersells what empathy actually is in a professional design context. It's not a feeling. It's a method. It's the disciplined practice of understanding another person's perspective well enough to anticipate their behavior, predict their frustrations, and design for their reality rather than your assumptions.

Applied to users, empathy is the foundation of UCD. You research, you observe, you test, you iterate — all in service of understanding how someone else experiences the product you're building.

But here's the insight that separates competent designers from exceptional ones: empathy for the client is just as important as empathy for the user.

Understanding the client — really understanding them, not just tolerating their requirements — means understanding the pressures they face. The marketing director who insists on the newsletter popup isn't irrational; they're accountable for a growth target that their job depends on. The product manager who wants twelve fields on the registration form isn't hostile to users; they're trying to give the sales team the data they need to close deals that keep the company funded. The CEO who wants the homepage to showcase every product line isn't ignorant of design principles; they're responding to board pressure to demonstrate the breadth of the company's offerings.

When designers understand these pressures — when they empathize with the client's position as deeply as they empathize with the user's — two things happen. First, their proposed solutions become better, because they're solving the actual problem rather than the surface-level request. Second, their relationship with the client improves, because the client feels understood rather than managed. Trust builds. And trust, as we've discussed, is the infrastructure that makes good decisions possible.

The framing that works, the one that consistently produces better outcomes and healthier working relationships, is this: the designer and the client are on the same team, pursuing the same objectives. The designer isn't an advocate for the user against the client. They're an advocate for the product, which succeeds only when both the user's experience and the client's objectives are served.

Play on the same team. Share the same goals. Use your expertise to find the path that serves everyone. That's not a compromise of UCD principles — it's the fullest expression of them. Because a product that delights users but fails commercially never reaches enough users to matter. And a product that meets business metrics but alienates users will, eventually, fail commercially too.

The discipline of UCD, practiced with genuine empathy for everyone the product touches — users, clients, stakeholders, the team itself — is what turns a set of competing requirements into a product that justifies the investment, serves the audience, and gives the team something worth building.

That's not a soft skill. That's the whole skill.