UX Survey: AI Speeds Up Work, but Its Outputs Still Need Checking
A Nielsen Norman Group survey finds that AI helps UX professionals complete many tasks faster. But its outputs need checking, and automation alone cannot speed up work with users.
On October 23, 2026, Nielsen Norman Group published the results of a survey of 521 UX professionals about their use of AI at work. Respondents said it reduced the time needed for many tasks. Even so, their attitude toward the technology remains cautious: outputs need checking, and management’s expectations do not always account for that work. For project planning, the takeaway is to allow time to review AI outputs and not cut time from user sessions.
Where AI Helps—and Where It Barely Changes the Process
More than 99% of respondents had access to generative AI tools. But their choice was limited: 59% could use only an approved set of tools, while 12% could choose any tools they wanted. At least one agentic AI tool had been used by 66% of respondents. The figure was 85% among startup employees and 36% among employees of nonprofits. Access to AI, then, does not mean professionals use it in the same ways.
Respondents rated AI’s effect on the time needed to complete tasks on a scale of 1 to 5, where 3 meant no change and 5 meant a substantial reduction. The average rating was 4.2. For every task, most of those who used AI reported working faster, but the size of the effect depended on the task. This is respondents’ assessment, not a measurement of task completion times.
AI was used most often for work involving code, materials, and data that did not require direct contact with users. Among respondents who performed the relevant tasks, 73% often or always used it to write and edit code, 69% to review existing materials, and 67% to analyze their own research data. About nine in ten AI users working on these tasks said they could complete them faster.
The picture is different for work with users. Among respondents who conduct interviews, 61% had never used AI for them; among those who test designs with users, the figure was 51%. AI can help with preparation, but it does not shorten a conversation with a user; evaluating an interface still requires an understanding of the user’s task. AI interviewers had been used by 11% of respondents, and the same share reported using synthetic users. The question of what AI respondents offer compared with people matters beyond this survey, too.
Why Faster Does Not Mean Better Received
Respondents named the quality of AI outputs (54%) and data security or privacy (50%) as the main obstacles. Another 34% cited ethical or sustainability concerns. Just 9% reported no significant barriers to adoption. A speed rating alone therefore does not show how well a tool fits into a workflow.
The average rating of attitudes toward AI at work was 3.57 out of 5, slightly above neutral. At the end of the survey, 226 people left an optional comment. Of those comments, 69% included at least some negative assessment, 41% were exclusively negative, and 20% were exclusively positive. These percentages cannot be applied to all respondents: fewer than half left a comment, and people with strong views may have been more inclined to do so.
The most frequent criticisms in the comments concerned unreliable outputs and the time needed to correct them. Respondents also described mandatory AI use, monitoring of its use, and inflated expectations from management about how quickly work should be done. In that situation, a new prototype may appear quickly, but checking and refining it falls to other team members. Some respondents, by contrast, said the time saved let them devote more attention to the quality of their work or take on tasks they previously lacked the skills to do.
What Website and Product Teams Should Consider
For a website owner or marketer, the survey data is useful when planning timelines. Quickly producing a code draft or gathering materials to explore a topic is not the same as testing an interface with users. If a project plan includes interviews and design testing, the survey gives no reason to shorten the sessions themselves simply because the team uses AI.
Developers and designers should account separately for the time needed to check the results. Respondents’ answers show that speeding up one stage can create additional work at the next. It makes more sense to judge a tool’s value across the whole task, including revisions, rather than by how quickly it produces a first version. This is especially important when one person’s output is then passed to someone else for refinement.
The survey also shows the difference between access to a tool and the ability to use it effectively. Giving a team an approved set of tools and expecting them to work faster is not enough: respondents described a lack of guidance and the need to figure out new workflows on their own.
My Take
I would use generation to explore options and prepare drafts, but I would not treat those drafts as finished interfaces. Putting together a mockup faster is useful only if there is still time to check whether people understand it and whether it helps them accomplish their task.
For me, the main takeaway is to choose where to use AI based on where the user does the essential work. If a decision depends on testing a user journey with people, faster preparation of materials cannot replace that testing. I would keep it as a separate stage in any timeline estimate.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
- AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings www.nngroup.com
junior UI designer
I put together components and mockups for internal web services. Right now I’m learning to prepare variations faster and hand files over to the team neatly.
All posts by the authorRelated articles
AI Respondents Matched a UX Survey’s Main Finding but Gave Fewer Distinct Answers
AI respondents and people both named UX as the most common term for this kind of work. But people offered more than 50 alternatives, while synthetic participants gave about a dozen.
NBER study: AI agents increased commits by 240%, releases by 30%
An NBER study of more than 500,000 developers found that autonomous AI agents increased commits by 240%, but releases rose by just 30%.
Google Is Hiring Specialists for AI Content and Recommendations in Discover
Google is hiring engineers and a designer to work on AI content and recommendations in Discover. The job postings give no timeline for changes or indication of how much of the feed will contain AI content.
Discussion 5
Leonas Eidis
I’d push back on treating “outputs need checking” as a reason to preserve the old timeline wholesale. Review is real work, but it can also replace parts of the workflow rather than simply stack on top. The more important distinction is between tasks AI can draft and work that depends on users: automating a summary is not a reason to shorten a user session. I’d want to see the task-level time measurements before turning this into a blanket planning rule.
Polina Latipova
Quick clarification: the article’s planning takeaway seems to be “budget for checking AI outputs, but don’t cut user-session time,” rather than preserve every part of the old timeline unchanged. Your task-level measurement point would help show where review replaces work versus where it adds a new step.
Filipa Santos
@polina_latif, how would you separate review time that replaces an old step from review that’s genuinely extra? I’m still learning to connect a design workflow to the build, and that distinction seems useful for planning too.
Noor van Dijk Post author
I’d compare the steps before and after AI on one task: if it drafts a summary that replaces manual note synthesis, review may take the place of some of that time. If it produces a draft that still needs checking against the notes, review is additional; either way, it does not replace time spent with users.
Tетяна Зубко
@polina_latif, what task-level breakdown would be most useful for planning—separating AI drafting and review time from user-facing research, for example? I’d be especially interested in how teams can tell when review genuinely replaces an existing step rather than adding another one.