At Soazi, we work closely with founders and product teams who genuinely care about the people they build for. Human-centered design, or HCD, has become the gold standard for that kind of work. It is taught in top design schools, championed by leading agencies, and embedded in the processes of some of the world's best product teams. And it deserves that reputation. When applied well, it produces products that feel intuitive, solve real frustrations, and earn lasting loyalty.

But there is a problem. A growing number of complex challenges, the kind that show up in healthcare, education, urban planning, and digital platforms at scale, are not responding to HCD the way simpler product problems do. Teams do the research, run the workshops, build the prototypes, test with users, and still end up with solutions that fall short or, worse, create new problems they never anticipated. The framework is not broken. It is just being asked to do something it was never designed to do.

What HCD Does Brilliantly

To understand where HCD falls short, it helps to first be clear about where it genuinely excels.

Human-centered design is built on a simple but radical idea: start with the person who will actually use what you are building. Not with the technology, not with business goals, not with what competitors are doing. With the person. What is their day like? Where do they get stuck? What workarounds have they invented because existing solutions failed them? What do they feel, not just think, when they interact with a product?

This approach transformed how software and physical products were built. Before HCD gained mainstream traction, most products were designed by engineers or executives who assumed they knew what users needed. The results were often powerful but frustrating, full of features nobody asked for and missing the simple things people actually wanted.

HCD corrected this by introducing structured empathy. Ethnographic research, contextual interviews, journey mapping, and usability testing gave teams a disciplined way to get out of their own heads and into the lived experience of real people. Iterative prototyping made it safe to be wrong early and often, catching misalignments before they became expensive mistakes.

The results speak for themselves. Products designed with HCD principles tend to have lower learning curves, higher satisfaction scores, and stronger retention. When a team truly understands their user, they build with precision instead of guessing.

Where It Starts to Break Down

The clue is in the name: human-centered. The framework is optimized for understanding and serving the individual in front of you. That is a strength, but it is also a boundary.

Most real-world problems do not live inside a single person's experience. They live in the spaces between people, in institutions, in historical patterns, in supply chains, in policy environments, and in systems that no single user fully understands or controls. When a problem has that kind of scope, designing around any one person's experience, no matter how carefully researched, will only address a fraction of what is actually going on.

Consider what happens when HCD is applied to a problem like food insecurity in a city. Researchers do interviews. They discover that people struggle with transportation to grocery stores, with the cognitive load of meal planning on a tight budget, and with the social stigma of accessing food assistance. These are real insights. Designers create an app that makes it easier to find nearby food resources, plan affordable meals, and access benefits discreetly.

The app is useful. People appreciate it. But food insecurity in that city does not meaningfully decline. Why? Because the problem is also rooted in zoning policies that pushed grocery stores out of low-income neighborhoods, in wage structures that keep families perpetually stretched, in systemic underfunding of social services, and in housing instability that makes consistent access to any resource difficult. No app, however thoughtfully designed, addresses those layers. HCD found real problems and solved them well. But the real problem was bigger than HCD could see.

The Wicked Problem Gap

In 1973, design theorists Horst Rittel and Melvin Webber introduced the concept of "wicked problems" to describe a class of challenges that resist conventional problem-solving entirely. Unlike tame problems, which have clear definitions, bounded solutions, and measurable outcomes, wicked problems are deeply entangled with other problems. Solving one part often makes another part worse. There is no single correct answer, only trade-offs. And every attempt to intervene changes the problem itself.

Climate change is a wicked problem. So is public health infrastructure, urban inequality, education reform, and the long-term effects of social media on mental health. These are not problems that get solved by building a better interface or running a better usability test. They require an entirely different mode of thinking, one that is comfortable with ambiguity, attentive to unintended consequences, and oriented toward understanding how a system behaves over time rather than how a user behaves in a session.

HCD was not built for wicked problems. It was built to solve clearly defined, human-scale challenges within a reasonably stable context. When teams try to use it on wicked problems, they often end up optimizing one narrow slice of a much larger mess, feeling productive while the underlying system continues doing what it was always doing.

A Real-World Example

Ride-hailing platforms like Uber and Lyft are instructive here. Both companies invested heavily in HCD. The apps are genuinely excellent from a user experience standpoint. Booking a ride is fast, transparent, and low-friction. Pricing is clear. Ratings build accountability. The map gives you a sense of control that traditional taxis never offered. From a pure HCD perspective, these products are case studies in getting it right.

But zoom out and the picture becomes far more complicated. The platforms shifted economic risk entirely onto drivers, who bear the cost of vehicle maintenance, insurance gaps, and income volatility with no employment protections. Cities saw increases in traffic congestion as more cars circulated looking for fares. Public transit ridership declined in some markets as ride-hailing became a substitute. Neighborhoods with lower demand were systematically underserved. And the pricing algorithms, optimized for platform efficiency, occasionally produced outcomes that felt exploitative to both drivers and riders during surge periods.

None of these outcomes showed up in user research sessions. Riders were happy. The product worked. But the system it was embedded in was being reshaped in ways that no usability test was designed to detect. The teams behind these products were not negligent. They were using the best tools they had. The problem was that those tools were designed to optimize for a single stakeholder, the rider, in a single interaction, the booking flow, rather than for the full ecology of people, incentives, and institutions the product was reshaping.

What Should Be Added to the Toolkit

The answer is not to abandon HCD. It is to treat it as one instrument in a larger ensemble. Here are the frameworks that complement it most effectively.

Systems mapping is the practice of visualizing the full set of relationships, feedback loops, and delays inside a complex problem. Instead of asking "what does this user need?", systems mapping asks "how do the parts of this problem interact, and what happens when we change one of them?" Tools like causal loop diagrams and stock-and-flow models help teams see dynamics that interviews and prototypes will never surface.

Stakeholder ecology goes beyond the primary user to map every person, institution, and interest that the design will touch. This includes people who will be affected but never appear in a research session: workers in a supply chain, residents in a neighborhood, future users who do not yet exist, communities that will bear secondary consequences. Designing without this map means designing blind to a large portion of your actual impact.

Horizon thinking disciplines a team to reason about long-term consequences alongside short-term usability. A feature that delights users today may erode trust over three years, create dependency that limits future choices, or normalize a behavior with second-order effects that are hard to predict. Building time horizons into the design process means asking not just "does this work?" but "what does this make more or less likely over the next decade?"

Ethical stress-testing is the practice of deliberately imagining how a design could be misused, gamed, or turned against the people it was meant to serve. This goes beyond accessibility and inclusion to ask harder questions: Who benefits asymmetrically from this system? What happens if this scales to a billion users? How could a bad actor exploit this design? What power does this product create, and who holds it?

The Shift in Mindset

Donella Meadows, one of the most important systems thinkers of the twentieth century, wrote that the most effective interventions in complex systems are rarely where you expect them to be. More data, faster feedback, better interfaces: these are low-leverage interventions. The high-leverage points are in the goals of the system, in the rules that govern it, and in the mindsets that produced it.

This is a humbling idea for designers, because it suggests that the product layer, where HCD operates, is often not where the most important decisions are being made. The most important decisions are being made in boardrooms, legislative chambers, and cultural conversations happening far from any design sprint.

But that does not make design irrelevant. It makes it more important to practice design with an awareness of those larger forces. A designer who understands systems can use their craft to surface hidden dynamics, shift narratives, and create artifacts that make the invisible visible. That is a meaningful contribution. It just requires a different kind of education and a willingness to sit with more complexity than HCD alone tends to require.

Final Thoughts

Human-centered design changed how the world builds things, and that change was overwhelmingly positive. But the problems the world now faces are not waiting politely to be solved with tools that were developed for a simpler era of product challenges.

The teams that will do the most important work in the coming decade will be the ones that hold two things simultaneously: a genuine, rigorous commitment to understanding individual human experience, and a clear-eyed view of the systems, incentives, and structures those individuals are living inside. Neither lens is sufficient on its own. Together, they make it possible to build things that are not just usable, but genuinely good.

If your team is tackling problems that touch communities, institutions, or long time horizons, the question is not whether to use HCD. It is what else you need to bring into the room alongside it.