Where has critical thinking in UX design gone?

There is something deeply troubling about how many designers operate in product design today.

Designers are busier than ever. They are competent with tools such as Figma, with design methods (looking at you Sprints and Double Diamond) and have a grasp of design patterns and they produce artifacts, lots and lots of painstaking artifacts. And yet they are not thinking critically about the products or tools they are putting into the world. This isn’t a ethics complaint about how we should be the moral fiber of the product team. It’s a concern that we’re abdicating a core part of our craft itself. Discernment, discipline and judgement.

Designers wait for a PM to give them requirements. They wait for a researcher to explain what the user does, what the user feels, what the user says hurts. They nod along, translate those inputs into screens, and move forward.

But they have not not taken ownership of understanding the work itself. They think from the outside, like researchers trying to remain objective. They avoid internalizing a stake in the game. They are building software out of “shallow empathy” not out of a hungry drive guided by subject matter expertise, and a conviction on what would be a better tool or experience. They are production for someone else’s ideas, not the architects of a better future for something they feel personally in their own veins.

That difference matters. A lot.

Many designers understand a user only at a conceptual level. They can describe it. Maybe they can map a flow. They can repeat what someone else told them. But they have not internalized what it means to perform that job day after day, under pressure, with incomplete information, within real constraints. They find satisfaction in a golden path where everything goes right, ignoring the messy realities which mean most users won’t ever experience that.

They have not asked why that work exists in the first place. They have not interrogated what is broken about it. They have not formed a clear, internal picture of what the work is actually for, what the objective is as opposed to how it currently gets done.

So what they end up designing is not a solution to the work. It is a faithful reproduction of a legacy pattern, often one that exists simply because it always has. Maybe they apply new tech, or they update the way it happens based on new product requirements. But this isn’t a fight they feel ownership for.

In a perverse twist many designers treat users as the ultimate authority on what the work should be. That sounds respectful. It sounds user-centered. But it is often wrong.

Most users using a product, or working in a tool are not reflective about the work itself. They are coping. They are executing a prescribed process. They fumble through, following the invisible path prescribed by designers long gone from the product team. They experience the tools or software as painful facts of life, not as things that could be fundamentally rethought. And they are rarely in a position to step back and ask what parts of the effort are essential, what parts are accidental, and what parts exist only because of historical constraints.

Users are experts in their pain. They are not experts in system design.

When designers mistake one for the other, they outsource judgment. They assume that the people inside a broken system are best positioned to describe what a better system should look like. That assumption feels humble, but it is intellectually lazy.

Side note: there are occasionally really insightful and critical thinking users who can absolutely prescribe the exact right product requirements and solutions. They are reflective, they are likely deep experts and have a massive amount of experience and situations on which to draw from. They may be subject matter experts, they may be orchestrators of work themselves. They may be more of a customer who makes purchasing decisions about tools and systems than an end user, and are detailing their own policy and process requirements for the product they seek for their workers. We may listen to them because of these qualifications and arrive at really strong product outcomes, but we need to be clear about where they can speak for all users vs their own expert bias or organizational needs.

The result is predictable. Designers propose solutions that technically meet requirements. They align with PRDs. They reflect what came out of research. Their intentions are good. But they have never adopted a important critical stance.

They are assuming that the reporting from the field is sufficient. That the people doing the work have enough clarity, and enough critical distance, to articulate what would actually make the system better. That assumption lets designers avoid risk.

This is intellectual outsourcing. This is risk outsourcing.

Instead of challenging themselves to overcome their naïveté and develop enough expertise which could tell them if the design is solving the challenge well.

They avoid being accountable for the outcomes, perfectly comfortable positioning themselves as execution arms rather than leaders. They translate inputs. They deliver outputs. And they call that neutrality.

It is not neutrality. It is avoidance.

This failure becomes irresponsible in the age of AI.

For mature products or stable domains, you can sometimes get away with incrementalism. But AI is not incremental. It is a technology that collapses technical constraints that previously justified bad workflows. It creates the possibility of rethinking what work even is.

AI changes what information is needed and when, what decisions matter, and who or what performs different parts of a task. It moves the goalposts for effort and for success. But you can only take advantage of that shift if you are willing to step back and ask uncomfortable questions about the user effort itself.

What is the work actually for? What information is truly required, when? Where are the real judgment calls? Which parts of the workflow exist because of human limitation rather than technical necessity?

If you design AI by preserving old structures simply because users describe them as familiar, you are wasting the opportunity entirely.

User testing often makes this worse.

Too often, designers test static mocks instead of dynamic systems. They avoid representative data. They put users in the role of critics rather than practitioners. The user is asked to evaluate a screen, not to do real work in a living system.

Side note: One form of this is discovery research, performed early in order for users to get a sense for the problem space. But this also happens late in the process. Designers will mock out a flow and do user-acceptance testing. Often this will be sloppy; showing users a set of screens or flows and asking if they like them. Or maybe they ask the user if this is an improvement from an existing workflow or approach. Positive response is taken for evidence that the design solves the problem well. But this is both biasing and outsources system design judgement to something more like a popularity contest. This is not a responsible or objective way to evaluate a design. A design should be striving to solve namable and testable problems; which don’t require a user to give their opinion.

So testing becomes a mechanism for reinforcing the status quo. It validates whether the new thing looks like the old thing, slightly improved. It does not challenge the deeper fundamentals; if the work should be structured this way at all.

Everyone leaves feeling good. Requirements were met. Feedback was positive. The process was followed.

And yet all you have done is pave over cow paths.

There is a quiet self-satisfaction that creeps in here. The design “worked.” The users didn’t object. The team avoided conflict. But no one asked whether this was the right solution, or even the right problem framing.

If that fight does not happen inside the product team, it gets deferred to the users. They pay for it in hours, days, and years of friction. Hundreds of thousands of hours get burned because the team was unwilling to challenge themselves to bring critical thinking to the process and product.

Failure of critical stance

This is not a failure of permission. It is not a failure of artifacts. It is not about being asked the right questions.

The role of a designer is to understand the user, the work, the situation and and design the best possible solution given the technological and business constraints. That requires judgment. It requires saying “this doesn’t make sense” even when everyone else is comfortable. It requires questioning the work, not just the interface.

The role of design is to exercise discernment and judgement on behalf of the user, the customer. It is to internalize the circumstances and work so deeply that the designer could perform the job, or if highly specialized could at least engage in a critical conversation with an expert in the field about the deeper fundamentals and principles of the work to be done. The designer should seek to have things live rent free in their head. Insights and sudden inspiration should show up in the shower, or on a long drive. They should be more critical of their own design work than their PM, Eng or users. If they do test with users they are driven to prove with a scientific method, seeking to disprove why their design works rather than a smile and a nod from an easy grader.

When designers refuse to do that, they are not being neutral. They are abdicating responsibility to the craft of design. Design is nothing if it is not at its core judgement. Judgment requires taking a stance, the possibility of being wrong, of investing time and effort into enough experience to form a critical stance. This means not accepting what is presented, but getting close enough to the details that you’d fight for something specific. Design without judgment is just making rectangles with words in them.