We Don't Have a UX Problem. We Have a Problem Understanding What UX Is.

There is a kind of meeting most product designers will recognize. The roadmap has been set. The scope has been negotiated. Engineering has an estimate, and someone in leadership has already promised a date to someone else. Then a designer is invited in and asked to make it intuitive.

Nothing about that meeting is malicious. Nobody is trying to sideline anyone. It is just what happens in an organization that believes design is the stage where decisions get their appearance. And it is, by a wide margin, the complaint I hear most from the designers I mentor, work alongside, and interview: they are brought in after the important questions have been answered and asked to make the answers look good.

Nielsen Norman Group's State of UX 2026 report, published in January, describes a field coming out of a long stretch of layoffs and hiring freezes and now being asked to show clear, measurable contributions to business goals. It warns against "design theater," the production of polished artifacts that generate activity without results, and argues that the value of UX is migrating away from the visible interface and toward the system underneath it: the content, the functionality, the logic.

I agree with almost all of it. But I think the way our industry talks about this moment hides something uncomfortable. We keep describing it as a UX problem. We need more influence, better metrics, a bigger seat, sharper storytelling. I don't think that is quite right. We don't have a UX problem. We have a problem understanding what UX is, and a meaningful share of that confusion is ours.

The interface is the residue of a decision

User experience is not the interface. The interface is where the experience becomes visible, but the experience itself is the sum of a long chain of decisions, most of them made far upstream of any screen. What problem we chose to solve, and for whom. What we decided not to build. What the pricing model rewards. What the support policy allows. How the data is structured, which quietly determines what the product can ever know about the person using it. What gets measured, which determines what gets optimized.

By the time a designer opens a design file, most of the experience has already been decided. The screen is the residue of those choices. You can make the residue clean and legible, and that work genuinely matters, but you cannot design your way out of a decision you were never part of. A beautifully crafted onboarding flow for a product that solves the wrong problem is still a product that solves the wrong problem. It just does it with better spacing.

This is the distinction I think gets lost. Designing an interface and influencing the decisions behind it are two different jobs. Both are legitimately UX. Only one of them reliably changes outcomes.

Decorating decisions

When design enters late, its purpose quietly changes. It stops being a way of figuring out what to do and becomes a way of presenting what has already been decided. I have started calling this decorating decisions, and once you notice it you see it everywhere.

The tell is in the questions designers are allowed to ask. In a healthy process, a designer can ask whether a feature should exist and get a real answer. In a decorating process, the only acceptable questions are about how. How should this screen be laid out. How should this flow be sequenced. How should this error be worded. Those are good questions. They are also the questions with the least leverage, because they operate inside a decision space someone else has already narrowed.

The cost is not just wasted effort. It is that the organization gives up its cheapest moment to be wrong. Learning that users don't want something during a two-day prototype test costs almost nothing. Learning it after the feature ships costs a quarter, sometimes more. Design that arrives late is design applied at the most expensive point in the timeline, and then it gets blamed for not producing a return.

How the deliverable became the job

It is tempting to put all of this on organizations, and some of it belongs there. But I think our own field built a good part of the trap.

Over the last decade, product design professionalized around artifacts. Portfolios became galleries of high-fidelity screens. Hiring loops evaluated designers through take-home exercises that started from a brief someone else had written. Job descriptions listed tools. Teams measured design throughput in tickets closed and files handed off. Even our process diagrams, the tidy double diamonds on every agency website, implied that the work could be packaged into a sequence of deliverables: personas, journey maps, wireframes, prototypes, specs.

None of those artifacts are bad. The problem is that an artifact is legible and an outcome is not. A stakeholder can see a Figma file. They cannot see the feature you talked them out of building, the support tickets that never got filed, or the churn that never happened. When the only visible output of design is the deliverable, the organization learns to value design as the deliverable, and eventually so do designers. NN/g makes a version of this point when it notes that employers are starting to favor breadth and judgment over portfolio artifacts. That is a correction, and an overdue one.

I have watched the downstream effect on teams I've worked with. Designers who are genuinely strong strategic thinkers spend most of their week producing variants for review, because variants are what get reviewed. The strategic work happens in the margins, if it happens at all, and it does not show up anywhere anyone is looking.

Consistency is not the same thing as a good experience

A related confusion has grown up around design systems. I have written before that most products don't need one nearly as early as they think they do. But there is a subtler issue than premature systematization. Somewhere along the way, a lot of teams started treating visual consistency as a proxy for experience quality.

Consistency is valuable. It lowers the cost of learning a product and makes it feel trustworthy. But it is a property of the surface. A product can be perfectly consistent and still be confusing, slow to deliver value, hostile to edge cases, or built around a workflow nobody actually has. Every button can match the spec and the user can still have no idea what to do next.

The danger is that consistency is easy to audit. You can measure component adoption, token coverage, and drift. Those numbers trend up and to the right, and they feel like progress. Meanwhile the harder questions go unasked because they don't fit on the dashboard. Did people understand the product? Did they succeed at what they came to do? Did they come back? When NN/g observes that standardized design systems and AI have made interface work cheaper, I read that as a warning. The part of the job that is easiest to systematize is also the part that is easiest to commoditize.

Why we are still asking for a seat

The seat-at-the-table conversation is older than many of the designers having it. When NN/g surveyed UX professionals about their biggest challenges back in 2017, the answers clustered around the same themes we are discussing now: UX lacking a strong and sustainable position in the organization, missing support from the business, weak influence and low visibility. Nearly a decade later the vocabulary has changed and the complaint has not.

Part of the reason, I think, is that the request is framed wrong. A seat at the table is not something you are granted because your discipline is important. It is something you hold because the people at the table find your presence useful for the decisions they are accountable for. Leaders don't make room for perspectives. They make room for leverage.

My time in naval aviation shaped how I think about this more than any design book has. In a ready room, nobody earns a voice in the plan by insisting that their specialty matters. You earn it by bringing information that changes the plan, delivered in the terms the plan is built from: fuel, time, risk, the mission. The weather brief that gets listened to is the one that says what the weather means for the decision, not the one that explains why the weather is interesting.

Design has often shown up to the table with interesting weather. Research findings without implications. Usability issues without a cost attached. Principles without trade-offs. When we speak only in the language of craft, we should not be surprised when we are only invited to craft conversations.

What strategic design actually looks like

Be more strategic is advice so vague it is close to useless, so I want to be specific. In my experience, the designers who consistently influence decisions do a handful of things differently.

They frame the problem before they solve it. Before any screens exist, they write down what problem is being solved, for whom, how we will know it worked, and what we are assuming along the way. Usually it fits on a single page. It is the most underrated design artifact there is, because it moves the conversation upstream to where the leverage lives, and because it is very hard for a team to fight about pixels once it has agreed on the problem.

They talk in consequences. Not that users found something confusing, but that a third of test participants could not finish setup, and setup completion is the strongest predictor of retention the team has. The finding is identical. The second version is a business argument.

They make the cheap moment to be wrong available. Rough prototypes, quick tests, a sketch that lets a room disagree early. The point is not a polished concept. It is giving the organization a chance to change its mind while changing its mind is still inexpensive.

They name trade-offs out loud. Every decision has a cost somewhere in the experience. Designers who state that cost plainly, without moralizing about it, become the people leaders want in the room, because they reduce the odds of being surprised later.

And they stay through the outcome. Shipping is not the end of the design work. The designers with real influence are the ones who come back three weeks later with what actually happened, good or bad. Nothing builds credibility faster than being the person who closes the loop.

None of this abandons craft. Craft is what makes all of it credible. A designer who can frame a problem and also deliver a beautifully resolved solution is far more persuasive than one who can do only one of those things. The point is that craft is the foundation of the job, not the boundary of it.

The part organizations own

None of this lets organizations off the hook. If design is consistently brought in at the end, that is a process choice, and leaders can make a different one. Put a designer in discovery and roadmap planning, not just delivery. Evaluate design by outcomes rather than throughput. Ask for design's point of view on whether to build something, not only on how. And when a designer raises a concern about the problem itself, treat it as information rather than resistance.

Organizations that work this way are not being generous to their designers. They are buying cheap insurance against building the wrong thing, which remains one of the most expensive mistakes a product team can make.

Wrapping Up

The identity crisis in UX is real, but I don't think it is a crisis about our value. It is a crisis about our definition. If UX means the interface, then it really is getting cheaper, more standardized, and easier to automate, and the anxiety running through the field is justified. If UX means the quality of the decisions that shape what people experience, then the work has never been more necessary, and very little of it can be generated from a prompt.

The interface still matters. It is where everything we decided finally meets the person we decided it for. But it was never the whole job. The sooner we, and the organizations we work in, stop confusing the visible part of design with the point of it, the sooner the question of a seat at the table stops being a question.