Human-Centered Design is not customer service

This article is meant to instill the principles of human-centered design further, but does not serve as a comprehensive guide on ‘how to do it’. I plan to publish articles related to real-life examples of HCD in practice, and I will update this article as they become available.

f you’re working in a relatively small company with low UX maturity, you might often feel as though the majority of non-designers think of human-centered design as simply being responsive and attentive to our clients and partners.

While being an organization that practices human-centered design certainly helps improve customer support, it cannot and should not be reduced to just that.

What HCD Actually Is

Human-centered design (HCD) is a framework for problem-solving that puts real people — not assumptions — at the center of the design process. It involves deep user research, empathy-building, iterative testing, and constant validation. It’s not a one-time phase or a checkbox. It’s a mindset and method baked into how we define problems, explore ideas, and build solutions.

It’s not just about asking the client what they want and then building that. It’s about understanding what users need, which isn’t always the same thing as what they want.

Why a “Client-First” Mindset Isn’t Enough

A client-first mindset is a good start. However, it can lead to prioritizing short-term satisfaction over long-term usability, scalability, and user outcomes. We can have happy clients who approve our deliverables, but still launch tools that frustrate users or create inefficiencies down the line.

True human-centered design challenges us to go deeper. It asks:

• Have we talked to real users, not just stakeholders?
• Have we tested our ideas before scaling them?
• Are we designing with accessibility, flexibility, and future needs in mind?

If we’re not embedding these questions in our process, we’re doing client-first work only, not human-centered design.

What Happens When We Do Design This Way

When HCD starts to truly embed itself as part of the full product development lifecycle — from discovery to delivery — we build better software. Period. It’s more intuitive. More resilient. More likely to succeed with real users. And ironically, it also results in happier clients, because the things we build just work better.

Some benefits we’ve already seen when we apply this approach:

• We catch issues early, before they become costly fixes.
• We align faster across teams, thanks to clearer user goals.
• We build credibility — not just by responding to feedback, but by anticipating needs before they’re even voiced.

How Your Company Can Do Better

You already have the talent. What you need is more support — organizationally and culturally — for making HCD a shared responsibility, not a design team specialty.

Some starting points:

• Get rid of the mindset that design = making things pretty. UX design is not visual design. Visual design, while still incredibly important, is just one small part of what it means to perform User Experience Design.
• Include UX designers at the start of any new project, and create space for deep user research. Don’t ask for high-fidelity prototypes immediately. You won’t get what you want, and neither will your users.
• Create space for iteration. Rushing to ship means rushing to re-work.
• Encourage cross-functional learning. Developers, PMs, and marketers all benefit from a deeper understanding of user needs, and participation in the process of designing an entire product.

Collaboration is Key

Too often, design gets treated like a delivery service. The designer is handed a list of vague requirements and expected to turn around perfect screens that anticipate every edge case, logic flow, and user scenario, without having been part of the foundational conversations that matter most.

But human-centered design requires human-centered teams. So this is not just ineffective— it’s unsustainable.

HCD is most powerful when it’s collaborative. Tools like journey mapping and service blueprinting aren’t just design exercises — they’re alignment tools. They give everyone on the team a shared understanding of:

• What users are trying to accomplish
• Where our process supports or fails them
• What data and systems come into play behind the scenes
• And most importantly, why it matters

When only one person on the team holds this context, it creates a bottleneck. It reinforces silos. It fosters the kind of ticket-taking, “just tell me what to build” mentality that undermines innovation and accountability.

But when developers, product managers, and other stakeholders are part of this process, everyone becomes more invested in building the right solution, not just a solution. Decisions are made faster. Tradeoffs are smarter. And the work becomes more meaningful.

A Real Moment That Sparked Change

This is a story from my own personal experience.

The need for deeper collaboration became painfully clear during a recent fire-drill with one of our product’s clients. I was brought into a high-stakes client meeting with very little context or notice, and it quickly became obvious: the client’s concerns were rooted in usability issues that had never been reviewed from a design or UX perspective. The feedback had gone from support → devs → solutioning. Design was pulled in late, only to validate potential solution ideas or provide input on UI changes.

That meeting was a wake-up call.

Our current process for handling feedback tends to look like this:

Customer support → bug ticket for devs to scope → dev dictates solutions → design pulled in if visuals are needed

This setup leaves little room for strategy, research, or cross-functional problem-solving. It’s reactive. It’s disconnected. And it puts enormous pressure on developers to be the final word on UX decisions — something that’s not fair to them or to our users.

So I created a shared space in our knowledge base called “Voice of the User.” The goal is to bring customer support, sales/marketing, product management, and design into tighter alignment by making user insights more visible, more structured, and more actionable.

Here’s a process that we should be aiming for, which helps to embed HCD into our product operations:

Customer Support → UX review & Triage → Check against existing designs → UX+PM plan improvements → Devs execute based on shared understanding

This is how we ensure that the feedback we receive doesn’t get lost in translation or turn into band-aid fixes, but instead becomes part of a long-term product strategy. It reinforces that UX isn’t just about visuals — it’s about asking the right questions, identifying patterns, and guiding how we solve real problems.

The Path Forward

Human-centered design is not a service, it’s a strategy. It’s not about being nice to clients, or even about responding quickly when they reach out. It’s not customer service with a new name.

It’s a practical, powerful framework for building better products — when it’s allowed to live at the core of how we work together.

When HCD is siloed or treated as a last-minute visual touch, we miss the opportunity to design with intention. We rush. We guess. We build things twice. And we ask designers and developers to clean up problems we could have prevented together.

But when we treat HCD as a shared responsibility — through practices like collaborative journey mapping, service blueprinting, and cross-functional triage of user feedback — we build smarter, faster, and more meaningfully. We stop reacting and start designing.

I must call out that the “Voice of the User” folder and the collaborative journey mapping are just small steps toward that goal. They are steps in the right direction — toward a process where everyone, not just designers, contribute to delivering thoughtful, user-informed solutions.