Companies are racing to deploy generative AI. The board wants it, the CEO announced it, IT provisioned it. And somewhere inside the organization, employees are quietly ignoring it.
This isn’t merely a technology problem. It’s a user experience problem — and many organizations aren’t treating it that way.
At AnswerLab, we’ve spent the last few years on both sides of this challenge: partnering with companies to research and strategize AI deployment across both their external products and their internal teams, and working through our own internal AI transformation. What we’ve learned from both aligns with the broader research: the gap between AI availability and AI impact is enormous, and the factors that close it are almost always human-centered ones.
EY’s 2025 Work Reimagined study, which surveyed 15,000 employees and 1,500 employers, found that while 88% of employees report using AI at work, only 28% of organizations have positioned their people to achieve “transformative business impact” from it. A 2024 McKinsey Global Survey found a related gap: while nine in ten employees reported using generative AI for their work, only 13% considered their organization to have formally adopted AI tools at scale.
AI was everywhere, in other words, but rarely working as intended. These aren’t technology gaps. They’re experience gaps, and closing them requires the same discipline any good product team brings to designing for users.
The Bolted-On Problem
When many organizations deploy AI, they do it as a technology initiative. They select a tool, provision licenses, send a rollout email, maybe hold a lunch-and-learn. Then they measure adoption rates and wonder why the numbers are flat.
The problem is structural. AI has been added on top of existing workflows rather than woven into them. It asks employees to leave the tools and habits they’ve built over years, navigate to a separate interface, figure out what to ask, and somehow supply all the context the tool needs to be useful. For someone already managing a packed calendar and a full inbox, that context switch is a significant ask, and one that delivers uncertain returns.
In our internal AI rollout, custom tooling was one part of a broader investment in upskilling and workflow integration, and was initially the least successful. When we built out structured AI-assisted workflows, adoption lagged. When we talked to our teams, the message was consistent: the process felt rigid, the tool felt separate, and it was easier to just complete tasks manually or with more general-purpose AI tools.
The pivot that made the biggest difference wasn’t a better tool. It was a different philosophy. We shifted toward smaller, lower-friction interventions: lightweight automations that operated in the background, surfacing useful outputs directly into Google Drive, the space where our teams already live, rather than asking people to go somewhere new. Adoption followed almost immediately.
Research we’ve conducted with enterprise clients reinforces this pattern. In a study exploring how employees experienced AI-enabled features in a workplace communications platform, the features that resonated most weren’t the most technically impressive. They were the ones that reduced the friction of tasks employees were already trying to do. Features that were integrated into existing workflows outperformed standalone AI modes in both perceived value and reported likelihood of use.
The design principle that emerges from this is simple but easy to overlook: people don’t want a new AI workflow. They want their existing workflow to work better. The job isn’t to introduce AI as a destination. It’s to make AI invisible infrastructure, something that quietly makes the work easier without requiring the user to change their habits around it.
Trust Is a UX Issue
Ask employees why they don’t use AI and you’ll hear a short list of answers: it’s inaccurate, it might expose confidential data, I’m not sure what it knows. These are often framed as attitude problems, resistance, technophobia, change management failures. They aren’t. They are legitimate UX concerns, and they deserve design responses.
Trust in AI tools is built or broken at the interface level. In the enterprise research we’ve conducted, the most consistent driver of employee reluctance wasn’t skepticism about AI in the abstract. Participants were generally enthusiastic about the potential.
The friction was specific: when will this be wrong? What data is it drawing from? What can it see that I don’t want it to see? These were questions users couldn’t answer, and when users can’t answer them, they tend not to trust the system.
Our internal adoption survey data for the past tells a similar story. The single most pervasive friction point we identified across our own teams was trust breakdown caused by hallucinations and inaccurate outputs, particularly in high-stakes moments like client-facing reporting and quote-finding in research transcripts. For a subset of our team, repeated failures could erode trust enough to restrict AI use to the most basic tasks or abandon a workflow entirely. The verification overhead that followed erased the efficiency gains that justified the tool in the first place.
What we’ve seen move the needle on trust, both internally and in client research, tends to involve the same few things. Visible data sourcing matters: people want to know where an AI summary came from and be able to check it. Recency signals matter: timestamps and clear data boundaries reduce anxiety about whether information is current or stale. And explicit privacy framing matters: workers are more willing to engage with AI when they understand concretely what it can and cannot access, rather than having to guess.
Perhaps most importantly, the right kind of education matters. Not a prompt library, but a genuine orientation to how large language models work, why they hallucinate, and what verification looks like in practice. The most effective AI users on our team aren’t the ones who got the most prompting tips. They’re the ones who developed a working mental model of what AI is actually doing, which gave them a better intuition for when to trust it and when to check.
That education investment is harder to measure than an adoption dashboard, but in our experience it is foundational to durable use. Without it, every hallucination is a trust-breaking event. With it, it’s a tool behaving within known parameters.
When AI Design Backfires
There’s a third failure mode that organizations tend to discover later in deployment, usually when early adoption numbers have flattened or sentiment surveys start surfacing concerns. It’s the design misstep that’s easy to make: building AI experiences that were meant to feel helpful but end up undermining the very adoption they were designed to encourage.
The most common version of this in enterprise settings is the anthropomorphized AI assistant: a chatbot persona, an experience designed to feel warm and human in order to ease adoption. The intuition behind it is understandable. But the research we’ve done complicates it.
In research conducted on AI-enabled features across workplace productivity and communications tools, a persistent finding was that participants drew a meaningful distinction between AI that felt like a tool and AI that felt like a person. The tool framing was generally embraced. The “person” framing generated skepticism and, in some cases, active discomfort.
Participants described AI assistants designed with humanlike personas as unprofessional and uncanny, and several raised concerns about representation and bias when AI personas defaulted to gendered or racially-coded appearances. Some participants noted that human-like AI framing could actively work against good usage habits, encouraging users to frame interactions as human conversations rather than the technical processes they actually are.
The over-trust risk is worth naming, too. When AI is designed to feel like a knowledgeable colleague, people may be less inclined to verify its outputs and more exposed when it’s wrong.
The design implication, at least from what we’ve observed, is to be honest about what AI is. People don’t need AI to feel like a friend. They tend to respond better to systems that feel reliable and transparent and that give them control. That means making capabilities and limitations explicit, building in appropriate friction for high-stakes outputs, and resisting the urge to dress up the interface in ways that flatter the technology rather than serve the user.
What the Research-Informed Approach Looks Like in Practice
The organizations that get AI deployment right seem to be doing something that sounds obvious in retrospect: they’re researching their employees the way they’d research any user. They’re asking what work actually looks like, where the friction is, what would make a difference, and what would make things worse. They’re piloting with real workflows and iterating based on what they learn.
At AnswerLab, the interventions that have had the most lasting impact internally have been the ones that came out of listening: the move from structured proprietary tooling to lightweight workflow augmentation, the investment in LLM literacy alongside prompting practice, and the decision to give teams protected enterprise-grade environments where they could experiment without worrying about confidential data being used to train models. None of those were obvious in advance. They came out of paying attention to how our people were actually experiencing AI, and treating that experience as the design problem to solve.
This isn’t just our experience. The Wharton Human-AI Research Center’s longitudinal study of enterprise AI found that organizations seeing the strongest outcomes from generative AI reported significantly higher investment in employee training and greater latitude for employees to innovate, and concluded that human capital factors, not technology factors, are the primary drivers of deployment speed and efficacy.
The productivity case for AI in the enterprise is strong. But realizing it requires treating employees not as change-management challenges but as users with real needs, legitimate concerns, and a finite capacity to absorb new tools. When you design AI deployment around that reality, the numbers take care of themselves.
