After years working at the intersection of business, UX, and technology, I have learned to recognize a familiar pattern: organizations adopting AI not to solve real problems, but to be seen solving them. Here is what that looks like from the inside.
There is a meeting I have sat through more times than I can count. Someone presents a product roadmap, and somewhere in the middle of it there is a slide — sometimes called 'AI Strategy', sometimes 'Intelligent Features' — that lists three or four AI-powered capabilities the team plans to ship in the next quarter. The business case is rarely about a specific user problem. The real reason is almost always the same: the competition announced something similar last month.
I am not here to criticize organizations for wanting to keep up. The pressure is real. What concerns me is the design work that gets produced under those conditions — and more specifically, the experience users end up with when AI is added to a product as a response to competitive anxiety rather than as an answer to a genuine need.
After working across B2B SaaS platforms, payment systems, e-commerce, and service design, I have developed a fairly reliable sense for when an AI initiative will succeed and when it will produce a demo that impresses stakeholders and frustrates users. The difference is almost never about the technology. It is always about the intent behind it.
The best AI feature I ever designed was the one we decided not to build. Understanding why it was unnecessary was more valuable than shipping it would have been.
— Roy Villasana
What AI Theatre Actually Looks Like in a Design Process
It usually starts at the brief stage. The ask comes in as a capability ('add a recommendation engine', 'implement a smart assistant', 'make it predictive') rather than as a problem ('users are abandoning the flow at step three', 'support tickets are dominated by this one confusion'). When the capability is the starting point, the design process works backward from the technology to find a user problem that fits it — instead of forward from a real user need to the right solution.
The product design work in these projects often feels fine in isolation. The UI is clean. The interaction patterns are sensible. But at some point in the process — usually during user testing — a quiet question surfaces that nobody wants to answer: Would a simpler, non-AI solution solve this just as well?
In my experience, the honest answer to that question is yes more often than teams are comfortable acknowledging. A well-structured form with smart defaults solves a lot of problems that 'intelligent autofill' gets credited for. A clear information hierarchy reduces cognitive load more reliably than a 'personalized dashboard' that adapts based on usage patterns. The AI version is more impressive. The simpler version is more useful. Choosing the simpler one requires a kind of organizational courage that is genuinely rare.
The Three Questions I Ask at the Start of Every AI Initiative
Over the years I have settled on three questions that consistently separate well-grounded AI work from performative adoption. I ask them early — before wireframes, before technical scoping, before anything.
- What does the user do today without this feature, and how do we know it is a problem? If the answer is a usage metric or a support ticket pattern, we are building on solid ground. If the answer is an assumption or a competitive reference, we are not.
- What does the experience look like when the AI is wrong? Every AI feature fails sometimes. If no one has designed what happens when it fails, it has not been fully designed. I have never seen a theatrical AI feature that had a thoughtful error state.
- Who owns this feature six months after launch? AI features require maintenance, retraining, and iteration based on real performance data. If no one has identified who will own that work, the feature was built to be announced, not to be used.
Why This Is a Design Problem, Not an Engineering Problem
I want to be specific about why I think designers — not engineers, not product managers — are in the best position to interrupt this pattern. Engineers build what they are asked to build. Product managers are often under direct pressure to deliver AI features. Designers are the practitioners most directly accountable to the user experience, which means we are also most exposed when AI theatre fails publicly.
More importantly, we have the tools to reveal the gap between AI activity and AI value before it ships: user research that tests real comprehension, usability sessions that surface confusion with AI outputs, success metrics tied to user outcomes rather than feature interactions. The honest application of these tools is the most powerful intervention available in a theatrical AI initiative.
Use them early and use them loudly. Waiting until testing to surface a fundamental strategic problem is a much harder conversation than having it at the brief stage.
Keywords
AI adoption, AI-driven design, product design strategy, UX strategy, AI product design, performative innovation, design leadership, user experience, AI integration, design process