I Think the Traditional UX Process Is Dying. And I'm a UX Leader.
The discipline still matters deeply. What is losing its usefulness is the artifact-heavy assembly line we built around it.
I spent years working inside a process that most experience designers would recognize immediately: discovery, wireframes, design, handoff.
We interviewed stakeholders. We mapped journeys. We organized requirements, built presentations, debated wireframes, and refined screens. Eventually, we handed everything to developers and hoped the experience we had imagined would survive the journey into production.
There was real value in that work. I learned how to ask better questions, understand complicated organizations, and lead teams through ambiguity. I still use those skills every day.
But I have started questioning how much of the process actually helped us learn, and how much existed because building something real was expensive, slow, or outside the design team’s reach.
That distinction matters now.
I think the traditional UX process is dying. And I’m a UX leader.
The discipline still matters deeply. What I believe is losing its usefulness is the artifact-heavy assembly line we built around it: a sequence where documents and screens become the evidence of progress, while actual experience arrives much later.
I want us to move toward a different rhythm: question, working prototype, user feedback, production. Research and design belong throughout that rhythm. They should shape what we build and help us understand what happens when people use it.
We built a process around the cost of being wrong
The traditional workflow had a practical logic. When development required a substantial commitment, teams tried to resolve uncertainty before writing code. A wireframe was cheaper to change than a finished application. A design review could catch a problem before it became an engineering problem.
I understand that logic because I have worked within it. Leading enterprise experiences means navigating stakeholders, content, technology, and business constraints that cannot be wished away.
The problem starts when the sequence becomes sacred.
Discovery becomes a phase we finish. Wireframes become a milestone we approve. Design becomes a package we deliver. Development becomes someone else’s responsibility. Each group completes its part, but nobody gets a complete view of the experience until the pieces come together.
At that point, changing direction can feel like admitting failure.
A team might spend weeks approving a flow that nobody has actually used. Everyone agrees that the screens look reasonable. Then someone tries the real thing and hesitates at the first decision.
The process produced agreement. It did not necessarily produce understanding.
A screen can hide the most important questions
Static design is useful, but it leaves plenty unresolved. What happens after someone submits the form? What if the information is incomplete? How does the experience behave when a request fails? Can someone return tomorrow and continue where they stopped?
Those questions often appear as annotations, additional screens, or assumptions waiting for a developer to interpret them. The more complicated the experience, the more space exists between what the design communicates and what the product must do.
A working prototype can make that space visible earlier.
Imagine a business trying to improve customer onboarding. Instead of beginning with a large collection of screens, we start with a question: where do people lose confidence about what happens next?
We build a small flow that lets someone provide information, receive a response, and understand their next step. Then we watch people try it. We learn whether the language makes sense, whether the sequence feels reasonable, and whether the confirmation actually provides reassurance.
We still need to understand the broader journey. But we now have something concrete to examine while that understanding develops.
The prototype becomes an instrument for asking better questions.
Earlier feedback changes the conversation
When people review a presentation, they tend to respond to what they can see. A headline. A color. A layout. Those reactions can be useful, but they can also pull a team toward preference debates before it understands whether the experience works.
When people use a prototype, the conversation can become more specific. They cannot find the next step. They misunderstand a label. They enter information in an unexpected order. They want an option we never considered.
That gives us something we can investigate.
It also changes how stakeholders participate. Instead of imagining what a future product might feel like, they can try a limited version and explain where it conflicts with their operational reality.
An employee might reveal that the proposed approval process skips a required review. A customer might show us that our categories reflect the company’s structure rather than the way people think about their needs.
These are discoveries, even if they happen after we have built something.
Discovery does not stop when the prototype starts. The prototype creates another way to discover.
AI changes what we can attempt
In my own work with AI-assisted building, I am exploring a closer relationship between design decisions and functioning experiences. The appeal is being able to try an idea, inspect its behavior, and adjust it while the question is still fresh.
That does not make every generated interface good, or every generated application trustworthy. A convincing front end can disguise missing functionality. Code can look complete while relying on invented data, fragile assumptions, or behavior that nobody has checked.
The designer’s responsibility grows in that environment.
We need to understand what the prototype actually demonstrates. Are we testing comprehension, or a complete workflow? Is the data real? Which interactions are simulated? What might a participant assume from the way we present it?
We also need enough technical understanding to collaborate intelligently with the people responsible for making the system dependable.
AI can help us produce something to examine. It cannot decide whether we are examining the right thing, or whether the result deserves to become a product.
That is where experienced judgment matters.
Working does not mean ready for production
I want to be careful about the phrase “working prototype.” Clicking through an experience is a meaningful step, but it does not establish production readiness.
A prototype may use sample data, simplified permissions, or services that will not survive real demand. It may demonstrate the happy path while leaving recovery, accessibility, privacy, and maintenance unresolved.
Moving from prototype to production requires deliberate decisions about those gaps.
Sometimes the prototype can evolve into the product. Sometimes we should keep what we learned and rebuild the implementation. The value of the prototype is the learning it creates; preserving its code is a separate decision.
For a public information site, that transition might be relatively straightforward. For a system handling sensitive information or consequential decisions, the validation and engineering work can be substantial.
The loop should fit the consequences of getting something wrong.
Speed helps when it gets us to useful evidence sooner. It becomes a liability when it encourages us to mistake an impressive demonstration for a dependable service.
Research still has work that prototypes cannot do
A prototype can help us investigate an interaction. It cannot automatically tell us whether we chose the right problem, reached the right people, or understood their circumstances.
People arrive with habits, limitations, pressures, and workarounds that may never appear in a usability session. Some of the most valuable research happens before there is anything to put on a screen.
Observation, interviews, existing data, and conversations with frontline staff can reveal why a problem exists. They can also reveal that a new interface would do very little to solve it.
I would rather learn that early than build a polished answer to the wrong question.
Even after a prototype exists, we need to interpret feedback carefully. A participant’s request is a clue. Their behavior needs context. A handful of successful sessions does not establish that an experience will work for everyone.
The process I am arguing for gives research more opportunities to influence the product. It brings evidence into decisions repeatedly, instead of treating the discovery report as the moment when understanding was completed.
Design leadership needs a different definition of progress
This shift has implications for how we lead teams.
If progress is measured by completed deliverables, we will build a culture that optimizes for deliverables. Designers will become very good at producing the documents and screens that move a project through its approval system.
I want to ask different questions in a review. What uncertainty did we reduce? What did we observe? Which decision changed because of it? What remains unresolved before we can responsibly move forward?
Those questions require more from a leader than checking whether the design phase is on schedule.
They require judgment about where to spend attention, when to seek more evidence, and when the team knows enough to act. They also require us to make room for findings that challenge an approved direction.
A team should be able to say, “We tested this, and our assumption was wrong,” without feeling that it wasted the sprint.
That can be the most valuable result of the sprint. Learning only helps if the organization is willing to change something because of it.
Systems thinking becomes part of everyday design
When a prototype behaves like a product, design decisions begin to expose their connections to the larger system. A simple status label might depend on several business rules. A helpful notification might require reliable data, clear ownership, and a policy about when to contact someone.
The interface is where those relationships become visible to the user.
This is why I think systems thinking belongs at the center of design leadership. We need to understand how the experience connects to operations, content, permissions, and the people maintaining it after launch.
Design systems help when they capture useful patterns and behavior that teams can reuse. Their value extends beyond visual consistency. A well-understood pattern can carry decisions about interaction, accessibility, and content into the next feature.
But a component library cannot resolve a confused business process. Nor can a prototype repair unclear ownership by itself.
Sometimes the most important design contribution is showing that the organization must make a decision before the interface can make sense. Leaders need to recognize that moment and help the right people work through it.
Keep the artifacts that earn their place
I still believe in journey maps, wireframes, specifications, and carefully written documentation. A complex service may need all of them. Distributed teams need shared context. Future maintainers need to understand why a system behaves as it does.
The question is what each artifact helps us accomplish.
If a journey map reveals a neglected part of the experience, it is doing useful work. If a wireframe helps us compare approaches cheaply, it earns its place. If documentation helps another team safely change the product, it creates lasting value.
But if we are producing an artifact because the process expects it, we should be willing to reconsider it.
At Artifact Digital, that is the approach I want our work to reflect: begin with a meaningful question, choose the smallest useful way to investigate it, and bring people into the experience early enough that their feedback can change the outcome.
Production then becomes another place to learn. Real usage can reveal problems our earlier work missed and help us decide what deserves attention next.
For a client, the practical question becomes whether customers complete the task more easily, whether staff spend less time resolving confusion, or whether the business can deliver its service more reliably. We should agree on those outcomes early and revisit them after launch, using evidence rather than presentation quality.
I am excited about that future because it brings design closer to the people it is supposed to serve. It asks us to carry our thinking further, into behavior, consequences, and the systems behind the screen.
The traditional sequence gave many of us a foundation. We can respect that foundation while changing the way we work.
UX still has a vital job to do. Its future should be measured by the quality of the experiences we help create.