H
Howardism
Plate IIProduct & OrgHOWARDISM

Task-Level Speedup, System-Level Cost

NN/g's 2026 survey of 521 UX practitioners (convenience sample, `empirical` self-report): AI shortened every one of 15 tasks, yet sentiment averaged only 3.57/5 and 69% of open-ended comments were at least partly negative, because saved time did not stay with the person who saved it. It was absorbed by inflated expectations or spent fixing other people's AI output, so a prototype made in minutes that costs a designer days is a net loss; the unit of analysis for AI productivity should be the total effort, across everyone, to ship work of acceptable quality

Article metadata
Publication details
Published:October 26, 2026
Filed:Concept
Domain:Product & Org
Tags:AdoptionProductivity MeasurementUXOrganizationSurvey
Reading:12 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Illustration for Task-Level Speedup, System-Level Cost

Sources#

Summary#

Most organizations judge AI at the task level: how many people use it, and how much faster one deliverable gets produced. Rosala & Banawa (Nielsen Norman Group, 2026-10-23) surveyed 521 UX practitioners and found the task-level number almost uniformly good and the people reporting it unconvinced. Every task they asked about got faster. The mean feeling about using AI at work was 3.57 on a 1–5 scale: above neutral (p < 0.05), but not by much. Their explanation is a unit-of-analysis error:

"Respondents reported that AI shortened every task they used it for. Yet the time saved rarely stayed with them: it was absorbed by expectations to produce more or was spent cleaning up other people's AI-generated work. A task made faster for one person can create work for another."

The proposed unit is the system: "the total time and effort, across everyone involved, needed to ship work of acceptable quality." By that measure, "a prototype generated in minutes that costs a designer days to make usable is a net loss."

This is the same mismatch Acceleration Whiplash measures in software delivery (throughput up, downstream quality and review load up). It shows up here in a population that mostly does not write code, through a different mechanism. In the SDLC the cost lands on a stage, such as review, CI or incidents. Here it lands on a person in another role.

Evidence note. empirical, but self-reported, cross-sectional and a convenience sample: NN/g's own panel, newsletter, invite-only Slack communities and LinkedIn. Of 2,814 responses, 521 were kept, and only 21 of them were PMs. The open-ended evidence comes from the 43% (226) who chose to comment, and the authors warn that people with strong views are likelier to do so. The system-level claim is the authors' interpretation of comments, not a measured time balance. Nobody in the survey measured anyone's hours.

The task half: faster everywhere, least where users are#

Among respondents who did each task and used AI for it at least sometimes, all 15 tasks averaged below the "about the same" midpoint on a 1 (much shorter) to 5 (much longer) duration scale, and no confidence interval overlaps it (chart viewed). Writing or editing code improved most (1.28), then debugging or testing code (1.40) and desk research (1.47). Evaluating or reviewing designs (2.10), interviewing users (2.12) and testing designs with users (2.21) improved least.

Frequency of use follows the same order. Code (3.99 on a 1 never to 5 always scale), desk research (3.83) and analysing one's own research data (3.81) come first. Evaluating designs (2.59), testing with users (1.97) and interviewing users (1.82) come last. Most respondents never used AI for interviewing users (61%) or testing with users (51%). Only 11% used AI interviewers, and the same share used synthetic users. The authors' reason is that sessions with users still take the time they take: AI drafts the guide but does not shorten the hour. Critique depends on human goals and context that are hard to hand to a model.

So the task-level gains are concentrated in desk work on artifacts and data. The work that touches users, which is the reason UX exists as a function, is where AI is used least and saves least. The Three Loops of AI-Native Building's external feedback loop shows the same pattern at the product level.

The system half: where the saved time went#

The authors coded 149 of the 155 negative comments into 12 reasons (chart viewed; most comments carried more than one):

ReasonComments
Unreliable output and verification burden40
Cognitive offloading or skill atrophy26
Ethical or environmental concern25
Mandated or pressured adoption24
Devaluation of UX expertise and practice20
Increased expectations and workload18
Job and career insecurity18
Burden from others' AI use17
Learning curve and lack of support15
Work less meaningful10
Work more cognitively draining6
Cost of AI tokens or tools1

Three channels turn a faster task into a slower system:

  1. Verification stays with the user. The top reason is the output itself. "AI is incredible because it can make 80000 mistakes in the time that it takes for someone to correct 5 of them." This is Verification as the New Bottleneck in a design and research workflow, and it matches the barrier question: output quality was the top barrier to adoption (54%), ahead of data security (50%).
  2. Expectations absorb the saving. "Leadership expects faster work and designers to be able to do more, but AI output quality does not support that yet." The saving is booked before it is realized. Psychological Costs of AI Adoption's P12 describes the same thing from the inside: "Because now you can do more, so you feel like you need to do more."
  3. Someone else's AI use becomes your work. "I now sometimes find myself trying to quickly fix completely unusable prototypes made by a product manager. And I'm expected to come up with a solution just as quickly as AI does." The authors tie this to mandates: organizations that require and track AI use get performative use, which means more AI output that someone else then has to check and fix. That is the mechanism AI Usage Mandates and Quota Gaming measured as 31% filler in one firm's query logs, seen here from the receiving end.

Benefits and costs come from the same people. Of 61 comments saying AI made them faster, 26 were also negative. The cleanest positive group was practitioners who control their own use. Of 7 who mentioned working solo or on a very small team, 5 left purely positive comments. With no one downstream to receive their output, the system is the task, and the task-level gain is the whole gain. Respondents whose quality rose said they put the saved time back into the work ("sunk costs (design hours) doesn't affect the decision to keep improving"), which the authors call "what system-level productivity looks like."

Who pays: the same output, a different ledger#

The cross-role channel is the part this page adds to the corpus, and the code-side evidence places it more precisely:

  • In merged agent PRs, Follow-Up Fixes on Agent PRs finds that 69.6% of follow-up fixes come from the same agent. The cost of bad output there stays mostly with its producer, and the review queue is the shared cost. NN/g's cross-role case is the opposite: the PM's prototype is fixed by a designer, who did not produce it and was not consulted.
  • Open Source Under Agent Contributions is the cross-organization version. Contribution supply goes unbounded, and the maintainer's attention pays for it.
  • Prototype Fidelity After Cheap Polish and Polish No Longer Signals Readiness supply the reason the prototype case is especially expensive. A polished artifact looks finished, so the receiving designer is "expected to come up with a solution just as quickly as AI does": the fidelity sets the deadline, not the maturity.

The common rule: a productivity measure taken at the producer misses whatever the output costs everyone else. Per-user AI usage counts and per-deliverable cycle time are both producer-side. The authors' prescription follows from this: measure "whether work reaches users faster and better", not whether each individual uses AI; decide which tasks merit AI, since tasks involving users benefit least; and treat AI output as a draft, because "time saved doesn't have to become more output."

Limits#

  • No time balance was measured. The net-loss prototype is an illustration built from comments, not a tally. The survey measures perceived task duration per person and never follows an artifact from one person to the next.
  • The perceived speedups are self-reports from people who chose to use AI for that task, so they are conditional on use. The corpus's warning that perception lags telemetry applies to the task half as well as the system half.
  • The sentiment coding was done by LLMs. Claude Opus 5.5 and ChatGPT-6 Astra worked from the same written rules. A researcher hand-rated a random 50 and reviewed every comment where the models disagreed. No agreement statistic is reported.
  • The population is UX practitioners reached through NN/g channels. Engineering (n = 7) and PM (n = 21) cells are too small to compare, and the sample is weighted toward enterprises (almost half). Startups are only 4%, although they report the highest agentic use (85%).

Connections#

  • Acceleration Whiplash — the same task-versus-system mismatch measured with SDLC telemetry. There the cost lands on a delivery stage (review time, incidents). Here it lands on a person in another role, reported by the people receiving it
  • AI Usage Mandates and Quota Gaming — the producer side of "burden from others' AI use": a mandate that counts use gets performative use, and this survey hears from the people who fix its output
  • Psychological Costs of AI Adoption — the expectation channel stated by a practitioner ("now you can do more, so you feel like you need to do more"), and the verification tax as the cost that keeps the saving from reaching the system
  • Prototype Fidelity After Cheap Polish — why the cross-role prototype is the expensive case: it costs minutes to make and days to make usable, and its polish sets the receiving designer's deadline
  • Polish No Longer Signals Readiness — the failure mode in a survey respondent's words: a PM's polished prototype read as nearly done, then handed to a designer to finish at AI speed
  • Follow-Up Fixes on Agent PRs — the code-side ledger, where most fix work returns to the producing agent. It is the contrast that shows cross-role transfer is a property of the workflow, not of AI output as such
  • Open Source Under Agent Contributions — the same cost transfer across organizations, from contributors to maintainers
  • Verification as the New Bottleneck — the top coded reason for negative sentiment (40 of 149) is this hub's bottleneck outside software
  • The Three Loops of AI-Native Building — the tasks AI barely touches are the user-facing ones, which is that page's external loop
  • Role Averaging, Not Role Elimination — the specialists' side of averaging: researchers and designers expect their roles to shrink more often and feel less secure than PMs and generalists, and they are the ones who receive the averaged role's output
  • Engineer PM Convergence — the convergence's cost to the role being converged into: designers report fixing PM-made prototypes, while PMs report the highest job security in the sample
  • Human Attention as the Agent-Output Bottleneck — where the cost lands when the producer and the receiver are the same person: Anthropic's interactive agents produce more output than their own users could read in a work week, and the saved time goes into meta-work that filters it
  • Generative AI and Collaboration Networks — a possible instance of the saving booked elsewhere: Copilot adopters convene ~1.4 more collaboration hours a month, which land on colleagues' calendars. Whether those hours catch errors or certify them is unmeasured

Open Questions#

  • Is the system-level net actually negative for cross-role AI output, or is "minutes to make, days to fix" a vivid minority case? Settler: a time-use or artifact-tracing study that follows AI-generated deliverables (prototypes, specs, research summaries) from producer to the person who finishes them and sums hours on both sides against a pre-AI baseline.

Sources#

  • AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings — Maria Rosala & Rachel Banawa, AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings, Nielsen Norman Group, 2026-10-23, empirical (self-report survey). Fielded 2026-08-24 to 09-11; 2,814 responses, 521 kept after removing incomplete, bot (all from LinkedIn) and not-currently-working responses (246 designers, 145 researchers, 21 PMs, 109 others). Statistics in Stata; open-ended responses coded in Dovetail; sentiment by two LLMs with a human check. Cited for the task frequency and duration charts, the 12-reason negative-comment coding, the solo/small-team and speed-plus-negative counts, the barriers chart and the conclusion's system-level argument. Charts viewed: task frequency, task duration, negative reasons, barriers, comment sentiment. Source-side inconsistency: the task-duration caption says "larger numbers represent better time savings", but the chart's axis runs 1 = much shorter to 5 = much longer, and its values are low numbers for big savings. The prose's "4.2 out of 5, where … 5 means much shorter" uses the reversed scale. The values here follow the chart. COI: NN/g sells UX training and consulting, and the conclusion's prescriptions (protect UX expertise, consult designers) align with its market. That does not touch the descriptive numbers.
  • How employment is changing at Anthropic — Wilmers, Catipon, Massenkoff & McCrory (Anthropic Institute), How employment is changing at Anthropic, 2026-10-16, empirical, first-party. Cited in Connections only (reading load and meta-work)
§ end
Cited by 14
Related articles