You have probably sat in the meeting where someone says, “Let’s just try it and see.” No research, no problem definition, just a backlog and a sprint. Over the past decade, agile, low‑code, and now AI have made it so easy to build that the hard part of UX, figuring out the right problem and whether it is worth solving, quietly drops off the agenda.

Teams run personas sessions, map journeys, cover walls in sticky notes, and still ship services that have never met a real user. UX becomes performance instead of practice: the rituals are visible, the outcomes are not. It is textbook UX Theatre.

Agile often rewards teams for output and iteration, not for the invisible work of UX research and problem framing, so UX ends up bolted onto delivery rather than treated as a critical step. Low‑code and no‑code made it easier for anyone to build quickly, which only reinforces the idea that “doing” means solutioning, and that research and design are optional overhead rather than core work.

AI is just the newest way to act on that same instinct. It gives teams two cheap routes around UX:

Skip UX entirely. Teams move straight from idea to backlog; they build and ship code, maybe do a bit of QA or usability testing, but never invest in discovery, research, or design. UX becomes “whatever the team can squeeze in” instead of a defined part of the process.

Use AI fakery. Teams use AI to generate personas and “insights” as a proxy for research, which lets them claim they did user centered design without talking to a single person

Neither route treats UX as a discipline; both treat it as something you can skip or synthesize. In organizations that already underfunded UCD and produced the first examples of UX Theatre, it is not surprising to see UX roles cut, UX research folded into generic “product discovery,” and the idea of UX as a critical step erode even further. AI just accelerates habits that were already there.

I am not anti‑AI. I use it, and I expect it to take on more substantial roles in workshops and UX over time. My concern is how easily it can be used to get around the human judgment, responsibility, and context that UX and facilitation actually depend on. When AI is treated as a shortcut to “research” and “insights,” it quietly replaces the work of designing research, talking to people, and defining problems with synthetic stand‑ins and fake data.

This is where workshops matter right now: as deliberate pauses where the team has to do three things the current tool stack encourages them to skip:

1. Name the right problem. Use workshops to walk through what you already know: service performance, support data, operational pain points, and team experience. Agree on what problem you are actually solving instead of chasing the first idea someone brought to the table.
2. Ground the work in real research. Treat workshops as places to share and interrogate findings from actual research, not to invent personas or stories from opinion. Consider what users have really said and done before anyone proposes a solution.
3. Align solutioning to evidence. When people start throwing ideas around, tie them back to user needs and constraints. That is very different from prompting an AI to “design a dashboard for X” and accepting whatever it returns as your starting point.

None of this works if the workshop itself is theatre. If you walk in with no data, no research, and fill the time with opinions or AI‑generated personas, you have only shifted the performance and given it a new name. Workshops can slip into replacing real user input when they are used as stand‑ins for research itself.

Instead, workshops should be where research and data are brought into the open and made unavoidable.

When everyone is inclined to jump straight to solutions, you can use workshops to help your team start with the problem and the data: look at what you already know, decide what you still need to learn, and only then talk about what to build.

Next time your team starts solutioning, offer to run a session to determine:

1. What problem are we actually trying to define, and what data are we bringing in to do it?
2. Which parts of this work still need real user input, not synthetic personas or “vibe” research?
3. How will we keep the ideas in the session tied to what we know about users, not just to whatever the fastest tool can generate?