top of page

UX Roundup: Bogus Deskilling Research | Jargon Alienates | AI Exposure Improves AI Attitudes | Interruptions | Prioritizing > Everything | Paper Prototyping | Unsupportive Support | Resizable Panes

Writer: Jakob Nielsen
Jakob Nielsen
1 minute ago
14 min read
Summary: Most deskilling research studies the wrong condition | Speak the user’s language | Using AI increases people’s preference for AI | Interruptions cause stress | Experienced UXers give the most important findings the most attention | Keep paper prototyping for team building | Support scripts often leave users stranded | Allow users to resize screen areas

UX Roundup for September 28, 2026 (GPT Image 2.5)


AI Deskilling Studies Measure the Wrong Skill: Nobody Confiscates the Carpenter’s Hammer

A new logic-puzzle experiment finds that people who used AI performed worse once the AI was yanked away. True, and irrelevant to the work they’ll do with the tool. In the new normal, the tool stays. Research should measure what AI use does to the higher-level skills people need with AI at their side.


Solo Reasoning Predicted Skill Gains; AI Requests Didn’t

Shang Wu and colleagues from the University of California, Irvine, had 124 participants solve logic puzzles in three phases: no AI, optional AI, and no AI again (HCOMP 2026 paper). Cheaper help got used more: people charged 0.1 points per request made 6.7 requests, versus 3.3 requests at 0.18 points each (the difference was only marginally significant, at p < 0.10). Everybody improved with practice, but AI users improved less, and their assisted scores overestimated their later unassisted scores.


The paper’s more useful finding is that skill gains tracked how much time participants spent reasoning on their own before asking for help. The frequency of their requests had no such relationship with skill gains. (The “AI” was a simulated oracle that revealed the correct position of one puzzle piece per request: an answer key sold by the slice.)


Solid work in pursuit of the wrong question.


The confiscation study: hand people a tool, snatch it back, and publish the decline as a finding about the tool. (GPT Image 2)


The Tool Stays: Hammers, Saws, and AI

This study design has hardened into a genre, the confiscation study: hand people a tool (these days usually AI), let them use it, take it away, measure the decline, and conclude that the tool erodes skill. The measurement is valid, but it rests on a false premise: outside the research lab, nobody confiscates the tool.


We don’t evaluate carpenters by confiscating their hammers and saws at the end of their apprenticeships and timing how long they take to drive a nail with a rock, even though that’s how their remote ancestors worked. The carpenter keeps the hammer. The knowledge worker keeps the AI.


At the end of the apprenticeship, let’s confiscate the saw and hammer and see how well the newly minted journeyman carpenter can build a chair without his tools. Bah! (GPT Image 2)


Remember the Calculator Panic

When I was a teenager, the same hand-wringing concerned pocket calculators. Should students be allowed to use them, or would that ruin their math skills? (Danish teachers fretted exactly like American ones. My parents gave me a Texas Instruments calculator when I started high school, and I still got the highest math grades of anybody in that school.)

Fast-forward 50 years, and every business calculation runs on a computer, mostly in a spreadsheet; the pocket calculator itself is now a museum piece.


The calculator panic of the 1970s. Mrs. Larsen didn’t foresee that smartphones would put a calculator in everybody’s pocket whenever he or she left the house. (GPT Image 2)


No job depends on adding four 6-digit numbers by hand. Jobs depend on whether you can read a budget, spot the line that’s wrong, and produce a better one. Numeracy matters more than ever, even as elementary arithmetic loses its value as a workplace skill. The calculator moved the valuable math skills up a level.


Steering Skills Are the Ones Worth Measuring

The same shift is coming with AI. I predict that every business professional will soon have AI assistance for every task. The question that matters is how well people understand the business implications of logic and other fundamentals, and how well they direct and correct AI agents. A confiscation study can never measure those steering skills, because it removes the very tool people must learn to steer.


Performance without AI is a condition that will never exist again. Studying it tells you about the past. (GPT Image 2)


So I call on researchers to study what happens to users’ higher-level skills after AI takes over the lower-level ones. Assume everybody has AI. Never measure performance without it; that condition won’t exist. And distinguish among the ways people use AI, because their effects on learning are far from equal.


My UX Roundup has reported this pattern repeatedly in education: when AI does the exercises for students, learning drops, but when AI works as an individual tutor, learning accelerates. A Nigerian study involving 800 students found gains equivalent to 2 years of schooling in 6 weeks. Some ways of using AI in education and training will make people better at steering AI. Find those. That’s the finding worth having.


AI that does the exercise removes the learning; AI that tutors students through the exercise multiplies it. (GPT Image 2)


Measure Users With Their Tools in Hand

Wu and colleagues have plenty of company: most deskilling studies share the flaw, and no Bayesian model, however elegant, rescues a study that measures the wrong outcome. Give people the hammer, leave it in their hands, and measure what they can now build.


Give people the tool, leave it in their hands, and judge what they can now build. (GPT Image 2)


Speak the User’s Language

The oldest advice in the writing business is still violated daily in UX copywriting. Interfaces greet customers with the vocabulary of the org chart and the codebase: “provisioning,” “sync conflict resolution,” “leverage your core paradigm.” Users didn’t attend your sprint-planning meeting. Words they don’t know sound like words meant for somebody else, so they leave.


Label features with the words users use for their tasks. Engineering’s internal module names belong behind the scenes. Your database can keep its private jargon; your UI must speak to customers. When in doubt, say the label aloud to a customer and watch his or her face.


If your interface needs a glossary, it needs a rewrite. (GPT Image 2)


Exposure Therapy for AI Stigma: Using AI Makes People Prefer AI


Treat AI stigma like a phobia: repeated exposure to good AI experiences changed the minds of even some people who initially wanted nothing to do with it. (GPT Image 2)

People rating AI as more empathetic than humans is a dog-bites-man finding by now. Sarah Gibbons and I debated artificial empathy back in 2023, and my newsletter has reported the same result repeatedly since, from AI beating physicians on rated empathy to AI outdoing human clinicians. The latest study finds the same yet again, but this time the details tell a new story.


People have long judged AI as exhibiting more empathy than humans, even though its feedback often sounds regurgitated. A new study confirmed this finding: AI earns high empathy ratings from the people who receive its emotional support. (GPT Image 2)


A new paper by Yaoxi Shi and co-authors from Imperial College London, Harvard, MIT, and Ben-Gurion University (arXiv preprint) advances the story with 3 experiments involving 1,951 participants and a 28-day field study conducted with OpenAI involving 981 participants. The researchers studied people seeking emotional support.


AI out-empathizing humans is a breakfast staple of the research literature by now: repeatedly replicated and no longer news. I’m reporting on the new study because it also tracks how people’s preferences drift with continued use. (GPT Image 2)


First, a caveat to the AI-superiority chorus: AI was rated more empathetic than human listeners only among people who had chosen AI. An LLM judge found virtually no difference in the empathy of AI responses between those who had chosen AI and those who had wanted a human. That suggests users’ beliefs shaped how they experienced the support. Beliefs shape experience. (Also notable: 63–76% preferred sharing their emotional issues with AI over a human stranger to begin with, with avoiding judgment a major attraction.)


By a wide margin, users preferred to discuss their emotional issues with an AI, mostly because they considered it less judgmental. People also believed AI was more likely to keep what they shared confidential. (GPT Image 2)


The more interesting finding is preference drift. After a single 5-minute chat, 70% of participants assigned to AI chose AI for future emotional sharing, vs. 46% of those assigned to a human. (The human alternative was a stranger, not a best friend, so hold off on humanity’s obituary.)

 

Over 28 days of daily conversations, preference for discussing personal matters with AI rose from 25% to 32%, while preference for humans fell from 82% to 77%. Only personal conversations shifted preferences; a month of factual chitchat changed nothing.


A month of daily 5-minute chats measurably warmed people toward sharing personal matters with a machine and cooled them toward sharing with humans. Their preferences drifted with experience.


Validating feelings, expressing affection, and empathizing on cue can shift preferences toward AI. Machines do all three tirelessly.


This suggests a strategy for reducing AI stigma: give skeptics good experiences with AI. Deliver something useful or enjoyable, and attitudes can follow, even among people who didn’t want AI in the first place.


The entertaining episodic AI short videos now devouring screen time in China could win converts in AI-resistant markets like the United States. My prediction is that they will. If you’re deploying AI in your organization, make people’s first encounters rewarding, with a task they can complete or a result they can use. The first taste does the selling.


Short episodic AI dramas are currently taking China by storm. I predict they’ll be ubiquitous in the West within a few months, as more creators gain experience with Seedance. They may be just the ticket for giving skeptics repeated, enjoyable exposure to AI, which seems to reduce AI stigma. (GPT Image 2)


Interrupt at a Breakpoint or Not at All

Everyone quotes the 23 minutes it supposedly takes to recover from an interruption. The number is real but misfiled. It comes from Gloria Mark’s field observations at UC Irvine, where interrupted tasks resumed on the same day were taken up again after an average of 23 minutes and 15 seconds, usually with two other tasks squeezed in between.


Her 2008 experiment (PDF) with Daniela Gudith and Ulrich Klocke found something more damning: interrupted people completed their work faster (excluding time spent on the interruptions) but reported greater workload, stress, time pressure, effort, and frustration. Error rates didn’t differ significantly, and the study didn’t measure abandonment. The demonstrated cost of a popup extends beyond the seconds it occupies: it levies a rush tax on the rest of the task, paid in stress and effort.


Timing changes the price. Shamsi Iqbal and Brian Bailey at Illinois showed that deferring notifications to natural breakpoints, the pauses between subtasks, reduced frustration and reaction time compared with delivering them immediately.


So, for any message the user didn’t request, wait until the current step ends. Never interrupt typing, make the message dismissible with one action, and reserve a true modal for decisions the system can’t proceed without. An interruption is a withdrawal from the user’s attention, and the balance is smaller than you think.


The popup’s cost extends beyond the 5 seconds it occupies. Users pay a rush tax in stress and effort throughout the rest of the task. (GPT Image 2)


Reporting Everything Is the Junior Move

Anybody can report everything. Junior researchers often do, delivering 60-slide decks in which every observation gets equal billing and stakeholders drown politely. Synthesis is the senior skill: shaking the sieve until patterns, pain points, and opportunities remain while one-off remarks and vanity noise fall through.


Yes, discarding data hurts (you worked for it), but an insight nobody can absorb is as useless as no insight at all. So winnow hard: 3 findings that change a decision beat 30 findings that decorate an appendix. Coverage supplies the raw material; your judgment turns it into something stakeholders can use. Sieve first, then present the findings that deserve their attention.


Gold stays in the sieve. Likes, hearts, and hashtags fall through. (GPT Image 2)


Keep Paper Prototyping in the UX Design Toolkit

AI design tools now generate fully functional, high-fidelity UI prototypes in minutes, gorgeous visuals included. Wonderful. But don’t toss the sticky notes yet. Building a paper prototype together strengthens the team and wins stakeholder buy-in: people support what they helped sketch.


And keeping design ideas deliberately low fidelity fuels divergent thinking, because nobody debates font choices on an index card. Discussion stays on the workflow instead of the surface gloss. So let AI take the lion’s share of prototyping work while paper keeps a small but valuable niche in your design toolkit.


Paper prototyping is no paper tiger: the old cat still has claws. (GPT Image 2)


Start With Users’ Problems Before Adding More Features

AI has dropped the cost of building features to pocket change, which means teams can now optimize the wrong thing at 100 times the speed. The mousetrap stands baited with the sweet cheese of shipping velocity: more features. Snap. Meanwhile, the real user problem sits untouched beside the trap, because discovering it requires the slow work of watching actual users struggle.


Choosing the right problem determines whether all that feature output has any value. Velocity is worthless when the destination is wrong. Before the next sprint, spend 2 hours observing users. The backlog can wait. It always does.


The cheese is free; the spring collects payment. (GPT Image 2)


Support Scripts Often Strand Users

A support bot that ignores the customer’s circumstances can turn a solvable problem into a trap. The castaway has already supplied the essential context: he’s stranded. Advising him to leave merely repackages his goal as an instruction.


The support bot has identified the solution: stop having the problem. (GPT Image 2)


This is support’s doom loop. A customer explains that the account is inaccessible; the bot directs him to settings inside that account. Repeating the advice more politely adds words while leaving the obstacle untouched. The conversation ends exactly where it began.


In Error Message Usability, I argue that recovery requires precise diagnosis and an action users can actually take. Applying that principle to conversational support means preserving what customers have already explained, recognizing failed attempts, and offering another route when the current one is blocked.


Review 5 unresolved support conversations and ask whether each suggested action was possible in the customer’s stated situation. Give the bot a working escalation path that carries the conversation forward with its context intact. Support succeeds when the customer can proceed. Counting a stranded customer as “contained by automation” deserves a special place in the shipwreck museum.


Resizable Panes Let Users Overrule the Designer’s Layout Guess

Splitting a window into panes shows related information side by side, and a draggable splitter lets each user correct the designer’s guess about proportions to suit the task at hand. The pattern fails when dividers become hairlines, panes silently vanish, and layouts forget the user’s adjustments. Generous grab zones, minimum sizes, and remembered positions fix most of these problems.


Definition: Resizable panes divide a single window into 2 or more regions separated by draggable dividers, called splitters. Dragging a splitter reallocates space between adjacent regions without moving or resizing the window itself.

Two rooms, one movable wall. Dragging a splitter is the only interior renovation that takes half a second and can be undone by dragging back. Software should make it exactly this effortless, minus the marble. (GPT Image 2)


One Window, Several Panes of Glass

The vocabulary comes straight from architecture: a physical window holds several panes of glass, and the graphical user interface (GUI) borrowed both words wholesale. The layout idea is nearly as old as the GUI itself.


The Smalltalk-80 class browser (1980) split its window into 5 panes so a programmer could drill down from class category to class to method without opening a single extra window. Norton Commander (1986) placed 2 directory listings side by side and made the twin-pane file manager a small religion that survives to this day.


Email clients of the 1990s settled on a 3-pane arrangement of folders, a message list, and a reading pane. The draggable splitter between panes hardened into standard operating-system furniture. Today’s champion is the programmer’s development environment: Visual Studio Code turns editing into a festival of splitters.


A Splitter Is an Apology in Advance

Resizable panes improve usability for three practical reasons.


Side-by-side viewing beats window juggling. Keeping both items on screen removes the window-management chores from comparing 2 documents, working through a master-detail list, or dragging items from one place to another. The information is available at a glance, and items are within dragging distance. Every switch between overlapping windows requires users to reorient themselves; panes eliminate that switch.


While windows were a great advance in graphical user interfaces, they impose interaction overhead, and overlapping windows by definition hide information the user may need. (GPT Image 2)


The designer’s guess is always wrong for somebody. However carefully you choose default proportions, the translator needs a wider source pane, the coder with 40-character file names needs a wider tree, and the analyst on a 32-inch monitor lives in a different world from the road warrior on a 13-inch laptop.


I put user control and freedom on my list of 10 usability heuristics back in 1994, and the splitter is that heuristic rendered in pixels. A default layout is a guess; a splitter lets users correct it when the demands of their work outgrow that guess.


It’s always the designer’s responsibility to create a default that works well. Giving users the ability to customize their view doesn’t lessen this responsibility. But no matter how good the default, it’ll never be perfect for everybody: users have different needs and perform different tasks. So allow them to change the view to suit the work in front of them. (GPT Image 2)


Content varies more than layouts do. The same person needs different proportions at different moments: he or she widens the preview while checking a design, then widens the list while hunting for a file. A fixed layout forces the average case on every case.


How Bad Splitters Torture Their Users

The pattern invites 5 recurring design sins.

  • Hairline hit targets. Fitts’s Law says that the time to acquire a target grows as the target shrinks, and a 1-pixel divider is about the smallest target a designer can inflict on a mouse user. People overshoot, undershoot, and give up. Keep the visible line thin, but make the invisible grab zone 8 pixels or wider. Reveal that zone with a resize cursor and a hover highlight.


Don’t require users to acquire a single-pixel target. Provide a generous grab zone. (GPT Image 2)


  • Accidental drags. A user aiming for the scrollbar grabs the splitter instead, and the layout lurches with no undo. Slight snap resistance and an undo for the last resize both help.

  • Mouse-only operation. A splitter that keyboard users can’t reach turns the whole layout into a mouse-only privilege.

  • The vanished pane. Drag a splitter to zero width, and the pane disappears, along with the user’s belief that the feature still exists. The functionality joins the application’s dark-matter features: present in the code, invisible in the experience. Never let a resize gesture silently hide an entire region of the interface.

  • Layout amnesia. The application discards the user’s carefully adjusted sizes on every launch, converting a one-time customization into a daily ritual. Users notice, and they correctly interpret it as the software failing to respect their work.


When users spend time adjusting the layout to their needs, the system should remember those preferences and restore the same arrangement next time they open the application. (GPT Image 2)


9 Design Guidelines for Resizable Panes

  1. Ship strong defaults. Most users never resize anything, so the default proportions carry most of the usability load. Test those proportions with users.

  2. Fatten the grab zone. A 1-pixel visual divider may sit inside an 8-pixel (or wider) invisible hit area. Show a resize cursor and a hover highlight so users can discover where to grab it.

  3. Enforce minimum pane sizes so no region can be squeezed into an unusable sliver of truncated text.

  4. Separate collapsing from resizing. If a pane can close, provide an explicit collapse control and leave a visible handle for reopening it. Dragging its splitter toward zero width or height should snap it back or produce a labeled collapsed state that users can recognize and reopen.

  5. Remember each user’s layout for each view across sessions. Curing layout amnesia costs only a few kilobytes of stored preferences.

  6. Provide a reset. Double-clicking a splitter should restore the default or auto-fit the content, and a menu command should reset the whole workspace.


The ability to return to the default view can be a lifeline. (GPT Image 2)


  1. Support the keyboard. Make splitters keyboard-focusable, identify them with the ARIA separator role, and let arrow keys resize panes in sensible increments.

  2. Resize live and smoothly. Reflow content during the drag. If rendering can’t keep up, show a guide line during the drag and apply the resize on release, so the display doesn’t stutter.

  3. Ration the pane count. Most tasks need only 2–3 panes. At 5 or more, the window turns into an airplane cockpit, and you should demand pilot-grade users before you build one.


You design the house; users live in it. A fixed layout welds the interior walls in place to suit an average resident who doesn’t exist.


Resizable panes let users move those walls, and doing it well takes only modest courtesy: a splitter thick enough to grab, a minimum size for every pane, a memory of what the user chose, and a way back when something goes wrong. Grant users that, and they can adjust your layout to fit the work in front of them.


Panes are great, but avoid designs that require users to balance too many panes. (GPT Image 2)


Final Thought of the Day


Top Past Articles
bottom of page