UX Research in the Wild

How Primary Nav Bars Should Work

Trevor Calabro — Sat, 16 May 2026 13:03:23 GMT

Summary: This week’s article is based on official documentation that explains how primary navigation bars should work. This is all you’ll ever need to know about proper interaction design for primary navigation bars.

Over the last 10+ years, I’ve written essentially the same series of documents for different orgs around interaction design and accessibility best practices for primary navigation bars.

I finally sat down and combined all those documents into this master best-practice guide. This is intended to be more of a reference guide, and I’m happy to share it because, if you’re anything like me, you hate wasting time going back and forth with your front-end devs on all the little nuances that go into doing something as foundational as a nav bar.

My hope is that many of you bookmark this article, just like I will, and send the link anytime you need to share guidance with others.

This guide details the following topics:

Navigation bar interaction behavior
Dropdowns, mega menus, and mobile menus
How to think about hover
How to handle parent-child relationships
All the different UI component interaction states
Keyboard and screen-reader navigation
Proper semantic HTML and ARIA execution

📌 2 Ways to Use This Document

As a reference document: The best way to use this document is to press Control + F and find specific guidance around the primary navigation bar topics you care about.
As source material for Gen AI tools: This kind of document has also been used as source material for Gen AI tools that generate UI designs, interaction specs, or front-end code.
When the tool has clear guidance up front, the first output is more likely to follow better primary navigation bar behavior around links, buttons, hover, focus, keyboard interaction, semantic HTML, and ARIA.

If you want more general information about how to design a primary navigation bar, start with this article: Why Your Navigation Stinks.

The Purpose of This Guide

This document defines interaction design standards for the UI pattern primary navigation bar. Primary navigation bars must help users move between major feature areas, understand where they are, and predict what will happen when they activate an item. The interaction model should remain consistent across desktop and mobile, even when the layout changes across breakpoints.

The goal is to make primary navigation predictable, scannable, keyboard operable, and understandable without requiring users to guess how each item behaves.

⚠️ Disclaimer: For this pattern guide, “activate” means an intentional user action using a mouse, touchpad, touch gesture, Enter key, Space key, or similar input method, depending on the item type.

Hover is not activation. Hover may provide visual feedback, but in this navigation pattern, hover must not open, close, reveal, or dismiss navigation menus.

This is intentionally stricter than some general web guidance because this navigation system prioritizes predictable behavior across cursor, keyboard, and touch input.

2. Core Principles

2.1 Use clear information scent

Items must help users predict what they will find or what will happen after activating them.

A primary navigation item should clearly communicate one of the following:

A destination
A major feature area
A user task
A meaningful content category
A parent category that exposes related child destinations

Item labels should match the language users expect within the web application. They should not rely on internal team names, implementation structure, roadmap language, or terminology that only makes sense to the organization.

❌ Avoid labels that are too broad, abstract, or internally meaningful to create a clear expectation for users. If a label could reasonably mean several different things, it likely does not provide enough information scent.

A user should be able to scan the primary navigation and make a confident choice without needing to pause and interpret what the item might contain.

2.2 Support recognition over recall

Primary navigation should not require users to remember where something lives from prior experience.

Users should be able to recognize available paths by scanning:

Visible labels
Group headings
Dropdown indicators
Parent-child relationships
Current page indicators
Visual grouping inside dropdown menus or mega menus

Do not rely on hidden meaning, icon familiarity, or prior training. If an item opens a child menu, the UI should make that behavior visible. If an item sends the user directly to a page, the UI should make that behavior feel different from a Menu item.

2.3 Maintain consistent interaction behavior

Items with the same function must behave the same way throughout the application.

Primary navigation items should follow one of two interaction models:

Destination behavior: The item takes the user directly to a page or route.
Disclosure behavior: The item opens or closes a child menu.

✔️ Requirements:

Destination items use link behavior.
Menu items use button behavior.
Menu items include a dropdown indicator.
Destination items do not include a dropdown indicator.
Parent items that expose child menus should not also act as direct destination links.
Parent landing pages should be represented as child overview links when needed.
Menus must open only through intentional activation.
Menus must close only through intentional dismissal behavior.
Hover must not open, close, reveal, or dismiss a menu in this navigation pattern.

❌ Avoid interaction ambiguity. A user should not have to determine whether activating the label does one thing and activating the dropdown indicator does another.

2.4 Keep the hierarchy as flat as practical

Primary navigation should reduce unnecessary hierarchy.

Each additional level creates more interaction cost and more abstraction for the user to understand. A flatter structure makes it easier for users to scan available destinations and make a confident choice.

❌ This does not mean every destination must appear at the top level. It means child menus should expose terminal nodes clearly and avoid unnecessary nested categories.

A good primary navigation structure should:

Make major feature areas visible.
Group related destinations under meaningful parent items.
Expose terminal nodes inside dropdown menus or mega menus.
Avoid forcing users through multiple nested levels before they can reach a destination.

3. Primary Navigation Anatomy

3.1 Navigation landmark

Primary navigation must be represented as a semantic navigation landmark.

From an interaction design perspective, this matters because users of assistive technology need a predictable way to identify and move to the primary navigation region.

✔️ Recommended default:

If the page includes only one navigation landmark, an accessible name is optional. If the page includes more than one navigation landmark, each landmark should have a clear accessible name.

Use distinct names when navigation landmarks serve different purposes, such as Primary, Utility, Breadcrumb, or Footer.

If the same navigation is repeated in more than one place with identical links, the repeated landmarks may use the same accessible name.

✔️ Preferred naming order:

Use a visible or visually hidden heading with aria-labelledby.
Use aria-label only when no visible or referenceable label is available.

Example when a referenceable heading exists:

Primary

Example when no visible or referenceable label exists:

Do not use aria-label=”Primary navigation” as the default. This is usually redundant rather than a severe accessibility failure, because screen readers already announce the landmark as navigation. The accessible name should usually identify which navigation it is, not repeat the word navigation.

3.2 Navigation list

Primary navigation should use a list structure when presenting a set of related items.

✔️ Recommended structure:

for the navigation landmark
- for the item collection
- for destination items
The interaction design rule is straightforward:
- If the item moves the user to a destination, it is a link.
- If the item opens or closes a child menu, it is a button.
This distinction should be reflected in both the interaction behavior and the visual design.
3.3 Item types
Primary navigation items must be one of two types.
1. Destination item
A destination item takes the user directly to a page or route.
✔️ Interaction requirements:
✔️ Implementation requirement:
- Use an element.
Example:
```
Item label
```
2. Menu item
A Menu item opens or closes a child menu.
✔️ Interaction requirements:
- Activating the item opens the child menu.
- Activating the same item again closes the child menu.
- Hovering over the item must not open the child menu in this pattern.
- Hovering out of the item must not close the child menu in this pattern.
- The item includes a dropdown indicator.
- The item has distinct expanded and collapsed states.
- The child menu appears in a predictable spatial relationship to the item.
- The child menu can be dismissed through expected dismissal behaviors.
✔️ Implementation requirements:
- Use a
- Use aria-expanded.
- Use aria-controls only when the control-to-menu relationship needs to be explicit. aria-expanded is the essential ARIA state for the Menu item.
Example:
3.4 Stronger code example
The following example shows the preferred structure for a primary navigation landmark, one current destination item, and one Menu item with a child menu.
```
Primary


  
    
      Dashboard
    

    
      

      
        Reports overview
        Activity reports
        Compliance reports
      
    
  
```
This example demonstrates the expected implementation model:
- The navigation region uses a semantic
  landmark.
- The landmark is named by a referenceable heading.
- The item collection uses a list structure.
- Destination items use native links.
- Menu items use native buttons.
- The disclosure button uses type=”button”.
- The disclosure button exposes its open or closed state with aria-expanded.
- This example includes aria-controls because the controlled submenu has a stable id. aria-expanded remains the essential ARIA state for the disclosure button. If aria-controls is used, it must reference the menu controlled by the disclosure button.
- The closed child menu uses hidden so it is removed from the visual interface and the accessibility tree.
- When toggling a menu, update hidden, keyboard focusability, and aria-expanded together so the visual state, keyboard state, and accessibility tree stay synchronized.
- If the menu is animated, the transition must not leave focusable content hidden from sighted users or visible content hidden from assistive technologies. Animation cannot break synchronization between visual state, focusability, hidden, and aria-expanded.
- The dropdown indicator is decorative and hidden from assistive technology with aria-hidden=”true”.
4. Information Architecture Standards
4.1 Parent-child relationships
A parent item must represent a meaningful category. Child items must belong logically under that parent.
The parent-child relationship should be clear from the user’s point of view, not just from the organization’s point of view.
Good parent-child relationships are based on:
- User tasks
- User goals
- Feature areas users recognize
- Common workflows
- Expected content groupings
❌ Avoid using the primary navigation to mirror internal departments, feature team ownership, or implementation structure.
4.2 Terminal nodes
A terminal node is an item that takes the user to a page or route.
In a dropdown menu or mega menu, the primary activatable child items should usually be terminal nodes. This lets users move from the menu to a destination without needing to understand additional hidden layers.
Terminal nodes may include:
- Landing pages
- Overview pages
- Feature areas
- Filtered results pages
- Task-specific pages
- Settings pages
- Reports or dashboard views
❌ Avoid menu structures that require users to move through several abstract layers before finding a destination.
✔️ Preferred pattern:
```
Primary navigation item
  Child destination
  Child destination
  Child destination
```
❌ Avoid:
```
Primary navigation item
  Category
    Subcategory
      Sub-subcategory
        Destination
```
4.3 Parent landing pages
If a parent category has a landing page, do not use split-button behavior.
The parent item should not behave as both:
- A link to the parent landing page
- A Menu item that opens a child menu
That interaction model creates ambiguity because the same row appears to have two different functions.
For this navigation system, hybrid parent link plus disclosure behavior is not allowed. The restriction is a design-system rule intended to preserve one clear interaction purpose per row.
✔️ Required pattern:
- Make the parent item a Menu item.
- Add a child destination item labeled [Parent Category] Overview.
Example structure:
```
Parent Category
  Parent Category Overview
  Child Destination
  Child Destination
```
In this pattern:
- Activating the parent item expands or collapses the child section.
- Activating the overview item navigates to the parent landing page.
- The row has one interaction target.
- The dropdown indicator is not a separate interaction target.
- The user does not need to understand a split-button interaction.
This pattern should apply consistently across levels of the primary navigation hierarchy. Do not use the split-button UI control.
4.4 Duplicate destinations
A destination should generally appear only once in primary navigation.
Duplicating the same destination in multiple navigation areas can make users question whether the items lead to the same place or different places.
❌ Avoid duplicate destination items unless user research shows users strongly expect the same destination in more than one category.
When a destination could reasonably belong in more than one place, choose the location that best matches the user’s mental model.
4.5 Child item grouping
Child items should be grouped by user expectations.
❌ Do not group items by:
- Internal team ownership
- Feature architecture
- System architecture
- Department names
- Release structure
- Roadmap structure
✔️ Groups should be:
- Descriptive
- Mutually distinct
- Medium-granularity
- Ordered intentionally
❌ Use medium-granularity groups. Avoid very large groups that take too long to scan. Also avoid very small groups that create too many headings and make the menu feel fragmented.
Group order may be based on:
- Task frequency
- Workflow sequence
- User importance
- Natural conceptual order
If none of those apply, place the most commonly used or most important group in the top-left area of the mega menu.
5. Navigation Labeling Standards
5.1 Label clarity
Item labels must clearly describe the destination, task, or category.
A strong label should answer the user’s basic question:
What will I find if I activate this?
❌ Avoid labels that are too broad to create a clear expectation. Labels should not require users to know internal terminology, team ownership, feature history, or implementation details.
A label is too vague when it could plausibly contain several unrelated destinations or when users would need to open it just to understand what it means.
5.2 Label consistency
Use the same term for the same concept across the application.
Do not alternate between similar labels unless each term has a distinct user-facing meaning.
If multiple related terms are needed, each term should represent a distinct concept and appear in the navigation only where that distinction is meaningful to users.
5.3 Label differentiation
Items in the same set should be easy to distinguish from one another.
❌ Avoid placing labels near each other if users are likely to read them as overlapping categories.
Each label should create a distinct information scent trail.
5.4 Icon labels
Icons in primary navigation must include visible text labels.
Do not use icon-only primary navigation items. (buttons/links)
Icons may support recognition, but they should not carry the meaning on their own. This applies to desktop and mobile navigation.
For mobile primary navigation, the menu control should include a visible text label such as Menu. The menu icon may appear with the label, but the icon should not be the only visible cue.
6. Desktop Primary Navigation Behavior
6.1 Opening menus
Dropdown menus and mega menus must open only by intentional activation.
For this primary navigation pattern, hover must not open, close, reveal, or dismiss dropdown menus, mega menus, or child navigation items.
✔️ Required behavior:
- Activate a Menu item: open the child menu.
- Activate the same Menu item again: close the child menu.
- Activate another Menu item: close the current menu and open the activated menu.
- Activate a destination item: navigate to the destination.
- Hover over an item: show only the visual over state.
- Hover out of an item: remove only the visual over state.
This interaction model gives users control because menus open based on intentional activation, not cursor movement.
6.2 Hover behavior
Hover state may indicate that an item is interactive.
✔️ Hover may change:
- Background
- Text decoration
- Border
- Color
- Elevation
- Dropdown indicator styling
❌ In this pattern, hover must not:
- Open a menu
- Close a menu
- Reveal child items
- Dismiss child items
- Replace focused state
- Replace current page state
- Trigger behavior that changes the available navigation structure
Hover is visual feedback only. It should communicate that an item is interactive, but it must not change menu visibility.
6.3 Hover out behavior
Hover out removes the hover state.
Hover out must not close a dropdown menu or mega menu in this pattern.
Users must be able to dismiss an open menu through deliberate actions, not through cursor movement. This prevents fragile interaction paths where a menu closes unexpectedly because the cursor moved slightly outside the menu boundary.
✔️ Required rule:
- If a menu was opened by activation, it remains open until the user intentionally dismisses it.
6.4 Menu dismissal
Users must be able to close an open dropdown menu or mega menu by using deliberate dismissal methods.
✔️ Required dismissal methods:
- Activate the Menu item again.
- Activate outside the menu.
- Press the Esc key.
- Move focus out of the open navigation region, when this dismissal behavior is intentionally defined. Moving focus from the Menu item into its child menu must not dismiss the menu.
- Activate another Menu item.
- Activate a destination item.
When the Esc key closes the menu, focus must return to the Menu item that opened it.
This keeps the user oriented and prevents keyboard users from losing their place in the navigation.
6.5 Animation timing
Dropdown and mega menu animations should be brief.
✔️ Recommended duration:
- 100 to 150 milliseconds
Animation may help users understand that a menu has opened or closed, but it should not slow down navigation.
❌ Avoid animations that:
- Delay access to child items
- Make the interface feel less responsive
- Create unnecessary motion
- Interfere with focus visibility
- Make it harder to track the current state
- Ignore user motion preferences
- Desynchronize hidden, keyboard focusability, and aria-expanded during open or close transitions
6.6 Motion preferences and reduced motion
Navigation animation must not create unnecessary motion or make the interface harder to use.
If menu animation is used, implementation should respect user motion preferences, including prefers-reduced-motion.
✔️ Requirements:
- Animations must not delay access to child items.
- Animations must not interfere with visible focus indicators.
- Animations must not be required for users to understand whether a menu is open or closed.
- When users request reduced motion, non-essential menu animation should be reduced or removed.
- Open, closed, expanded, collapsed, focused, and current page states must remain clear even when animation is reduced or removed.
- When animation is used, visual visibility, keyboard focusability, hidden, and aria-expanded must remain synchronized throughout the open and close behavior.
Reduced motion should not change the interaction model. Menus still open by activation and close through defined dismissal behavior.
7. Dropdown Menu and Mega Menu Behavior
7.1 Dropdown indicators
Menus must include a dropdown indicator.
Acceptable indicators include:
- Down chevron
- Disclosure arrow
- Caret
The dropdown indicator communicates that activating the item will expose child navigation items.
Destination items must not include dropdown indicators.
This distinction helps users tell the difference between:
- Items that navigate directly
- Items that open child menus
Dropdown indicators should be visually consistent across the primary navigation system.
The dropdown indicator should not behave as a separate interaction target. Activating the label area or the indicator area should perform the same disclosure action.
7.2 Open state
When a dropdown menu or mega menu is open:
- The Menu item must show an open visual state.
- The Menu item must use aria-expanded=”true”.
- The child menu must be visible.
- The child menu must appear in a predictable spatial relationship to the Menu item.
- The dropdown indicator should visually reflect the expanded state.
- The menu should remain open until intentionally dismissed.
The open state should make it clear which top-level item controls the visible menu.
Opening a menu must be triggered by activation, not hover.
7.3 Closed state
When a dropdown menu or mega menu is closed:
- The Menu item must show a collapsed visual state.
- The Menu item must use aria-expanded=”false”.
- The child menu must be hidden visually.
- The child menu should be hidden from assistive technology unless there is an intentional reason not to do so.
- The dropdown indicator should visually reflect the collapsed state.
The closed state should communicate that child items are available, but not currently visible.
Closing a menu must be triggered by intentional dismissal behavior, not hover out.
7.4 Esc key behavior
When the user presses the Esc key while a menu is open:
- The menu closes.
- Focus returns to the Menu item that opened the menu.
- The Menu item updates to aria-expanded=”false”.
- The visual state updates from expanded to collapsed.
This behavior should be consistent for all dropdown menus and mega menus in the primary navigation.
7.5 Focus behavior
When a menu opens, focus behavior must be predictable and consistent.
The design team should choose one focus model and apply it consistently across primary navigation menus.
Acceptable patterns:
1. Focus remains on the Menu item: The menu opens, and the user can continue forward through the tab order into the child items.
2. Focus moves into the opened menu: Focus moves to the first focusable item inside the opened menu.
In either pattern:
- Open menu items must be reachable by keyboard.
- Users must be able to move focus out of the menu.
- Focus should not be trapped inside standard desktop dropdown menus or mega menus.
- Focus order must follow the visual and logical order of the menu.
- Esc must close the menu and return focus to the Menu item.
- Focus movement may dismiss the menu only when that dismissal behavior is intentionally defined. Moving focus from the Menu item into the opened child menu must not dismiss the menu.
Focus behavior should not depend on hover.
7.6 Mega menu layout
Mega menus should organize terminal nodes into visible groups.
Each group should include:
- Descriptive group heading
- Related destination items
- Clear visual separation from other groups
- Logical reading order
✔️ Preferred structure:
```
Primary navigation item
  Mega menu
    Group heading
      Destination item
      Destination item
      Destination item
```
❌ Avoid deep nested structures inside mega menus:
```
Primary navigation item
  Mega menu
    Category
      Subcategory
        Sub-subcategory
          Destination item
```
Mega menus work best when they expose meaningful destination choices in a scannable layout. They should not become a complete site map or a visual representation of the full feature architecture.
7.7 Current page inside a dropdown or mega menu
If the currently displayed page is represented by a child item inside a dropdown or mega menu, the child item should receive the current page indicator.
Example structure:
```
Parent Item
  Child Destination
  Child Destination ← current page
  Child Destination
```
In this pattern:
- The current child destination receives the current page indicator.
- The current child destination uses aria-current=”page”.
- The parent item may receive a visual parent-active treatment.
- The parent item should not use aria-current=”page” unless the parent item itself is the current page.
The parent-active treatment helps users understand which primary navigation section contains the current page. It should be visually distinct from the child item’s current page indicator.
8. Mobile Primary Navigation Behavior
8.1 Menu control
The mobile primary navigation control must include a visible text label.
✔️ Preferred label:
- Menu
The menu icon may appear with the label, but the visible text label must remain present.
❌ Avoid icon-only mobile primary navigation controls. The menu control should not rely on users recognizing the hamburger icon or remembering what it means.
The control should clearly communicate that activating it opens the primary navigation.
The Menu control and any close control must provide a target area large enough for accurate cursor and tap activation. Use at least 24 by 24 CSS pixels unless a valid exception applies. This is a minimum, not the ideal target size. In practice, mobile menu controls, close controls, and accordion rows should be larger than the minimum whenever layout allows.
8.2 Opening and closing mobile navigation
Mobile navigation must open and close by intentional activation or defined keyboard dismissal.
✔️ Required behavior:
- Activate Menu: open primary navigation.
- Activate Menu again or activate a close control: close primary navigation.
- Press Esc: close primary navigation when keyboard focus is inside the menu.
- Focus returns to the menu control when the menu is dismissed.
Hover must not open, close, reveal, or dismiss mobile navigation or child navigation sections in this pattern.
The open and closed states should be visually clear.
When the mobile menu is open:
- The menu control should show an open state or be replaced by a clear close control.
- The navigation panel or menu region should be visible.
- The first available item should be reachable through the expected tab order.
- The user should be able to dismiss the menu without activating a destination.
If the mobile navigation panel blocks interaction with the rest of the page, treat it as a modal-style experience: prevent background interaction, provide a clear close control, support Esc, and restore focus to the Menu control when dismissed. If the panel does not block interaction with the rest of the page, focus should remain free to move through the page and should not be trapped inside the navigation.
8.3 No split-button behavior
Mobile navigation rows must not use split-button behavior.
❌ Avoid this pattern:
- Text label navigates to a parent landing page.
- Adjacent chevron opens a child menu.
This creates two interaction targets within what appears to be one navigation row. Users may not understand that the label and chevron perform different actions.
✔️ Required pattern:
- Each row has one interaction target.
- A row either navigates to a destination or opens a child section.
- A row must not do both.
If the row opens a child section, the whole row should operate as the Menu item. The dropdown indicator may remain visible, but it should not be a separate interaction target.
8.4 Parent category with landing page
If a parent category has a landing page, include that landing page as a child destination item.
✔️ Required pattern:
- The parent row opens or closes the child section.
- The parent landing page appears as the first child destination item.
- The parent landing page uses an explicit overview label.
Example structure:
```
Parent Category
  Parent Category Overview
  Child Destination
  Child Destination
```
This keeps the parent row’s interaction simple and gives users a clear way to reach the parent landing page.
8.5 Accordion behavior
Mobile child navigation should use disclosure or accordion behavior.
✔️ Required behavior:
- Activate parent row: expand child section.
- Activate the same parent row again: collapse child section.
- Expanded state is visually indicated.
- Expanded state is programmatically exposed with aria-expanded.
- Child items appear directly under the parent row.
- The dropdown indicator visually reflects expanded or collapsed state.
Accordion behavior should preserve the parent-child relationship visually. Child items should appear close enough to the parent row that users can understand the relationship without relying on memory.
Hover must not expand or collapse accordion sections in this pattern.
8.6 Mobile current page indication
The currently displayed page, section, or route must have a visible current page indicator in mobile navigation.
✔️ Requirements:
- The current page indicator must be visible when the relevant navigation section is displayed.
- The indicator must be persistent and not depend on hover or focus.
- The current destination item must use aria-current=”page”.
- If the current page is inside a collapsed parent section, the parent row may receive a visual parent-active treatment.
- The parent row should not use aria-current=”page” unless the parent row itself represents the current page.
This allows users to reopen the mobile navigation and understand where they are within the application structure.
9. Keyboard Interaction Requirements
9.1 Tab order
Tab order must follow the visual and logical order of the primary navigation.
The goal is for keyboard users to experience the navigation in the same order that sighted cursor users visually scan it.
✔️ Recommended order:
1. Logo or home link, if present
2. Top-level primary navigation items
3. Open child menu items
4. Utility items, if present
5. Main page content
When a dropdown menu or mega menu is closed, its child items should not be included in the tab order.
When a dropdown menu or mega menu is open, its child items must be reachable through the keyboard.
Tab order should not jump unexpectedly between unrelated areas of the page. Users should be able to move through the navigation predictably and understand where they are at each step.
Hover must not affect tab order. Child items should enter or leave the tab order based on the menu’s activated open or closed state, not cursor position.
9.2 Keyboard commands
Primary navigation must support standard keyboard behavior.
Keyboard behavior should match the item type.
Destination items behave like links:
- Enter activates the item.
- The user is taken to the destination.
Menu items behave like buttons:
- Enter activates the item.
- Space activates the item.
- The child menu opens or closes.
Keyboard activation is intentional activation. A menu may open or close through Enter or Space on a Menu item. A menu must not open or close because the cursor is hovering over the item while it has focus.
9.3 Focused state
Every interactive item must have a visible focused state.
The focused state tells keyboard users where they are in the navigation. It should be treated as a required interaction state, not a visual enhancement.
Focused state must be:
- Clearly visible
- Persistent while the item has focus
- Distinct from hover state
- Distinct from current page state
- Distinct from expanded and collapsed states
- Distinct from active / pressed state
- Not dependent on color alone
Do not remove browser focus styling unless it is replaced with an equally clear or stronger focused state.
The focused state should work across:
- Top-level items
- Child items
- Dropdown indicators when they are part of the same disclosure control
- Menu controls
- Close controls, if present
Focused state must not automatically open a dropdown menu or mega menu. If a Menu item receives focus, it should show focused state only. The menu opens only when the user activates the Menu item.
9.4 Focus management
Focus behavior should help users stay oriented.
When a menu is opened by activation, the team should choose one focus model and apply it consistently.
Acceptable patterns:
1. Focus remains on the Menu item: The menu opens, and the user can continue forward through the tab order into the child items.
2. Focus moves into the opened menu: Focus moves to the first focusable child item inside the opened menu.
In both patterns:
- Child items must be keyboard reachable.
- Users must be able to move focus out of the menu.
- Focus should not be trapped inside standard dropdown menus or mega menus.
- Esc must close the menu and return focus to the Menu item that opened it.
- Focus order must match the visual and logical order of the menu.
- Focus behavior must not depend on hover.
Focus should only be trapped when the navigation is intentionally presented as a modal experience, such as a full-screen mobile menu that blocks interaction with the rest of the page. In that case, prevent background interaction, provide a clear close control, support Esc, and return focus to the Menu control when dismissed. If the mobile menu does not block the page, do not trap focus inside the navigation.
If focus movement is used as a dismissal method, it must be intentionally defined and consistent. Moving focus out of the open navigation region may dismiss the menu; moving focus from the Menu item into its child menu must not dismiss it.
10. Cursor Interaction Requirements
10.1 Hover / over state
Hover state may indicate that an item is interactive.
Hover state may change:
- Background
- Text decoration
- Border
- Color
- Elevation
- Indicator styling
⚠️ Hover is visual feedback only.
In this pattern, hover must not:
- Open a menu
- Close a menu
- Reveal child items
- Dismiss child items
- Change expanded or collapsed state
- Change tab order
- Replace focused state
- Replace current page state
- Trigger behavior that changes the available navigation structure
The user may hover over an item and see an over state, but the navigation structure must not change until the user intentionally activates an item.
10.2 Hover out
Hover out removes the hover state.
Hover out must not close a dropdown menu or mega menu in this pattern.
Users should not have to move the cursor through a narrow path or maintain exact cursor placement to keep a menu open. That creates fragile navigation behavior and increases accidental dismissal.
✔️ Required rule:
- If a menu was opened by activation, it remains open until the user intentionally dismisses it.
Open menus should close through deliberate dismissal methods, such as:
- Activating the Menu item again
- Activating outside the menu
- Pressing the Esc key
- Moving focus out of the menu, when defined
- Activating another Menu item
- Activating a destination item
10.3 Activate outside
Activating outside an open menu should dismiss the menu.
This applies to:
- Dropdown menus
- Mega menus
- Mobile navigation panels, when appropriate
Activate outside behavior should not interfere with destination activation. If the user activates a valid destination item, the destination action should take priority.
Activating outside is intentional dismissal. Hovering outside the menu is not dismissal.
10.4 Cursor movement
Menus must not depend on precise cursor movement.
❌ Avoid interaction paths where minor cursor movement causes the menu to close unexpectedly.
This is especially important when:
- A child menu appears below or beside the parent item
- The menu has multiple columns
- The user must move the cursor across spacing between the parent item and child menu
- The menu contains visual groups
The user should be able to move from the parent item into the child menu without fighting the interaction model.
Cursor movement may change hover / over state. Cursor movement must not change whether the menu is open or closed.
10.5 Target size
Interactive targets in primary navigation must be large enough to activate accurately with cursor and touch input.
Minimum target guidance:
- Primary navigation links, disclosure buttons, mobile menu controls, close controls, and accordion rows should provide a target area of at least 24 by 24 CSS pixels unless a valid exception applies. Treat this as the minimum threshold, not the preferred size. For mobile menu controls, close controls, and accordion rows, aim larger than the minimum whenever layout allows.
- Adjacent targets should have enough spacing that users are not likely to activate the wrong item by accident.
- The visible label, icon, or dropdown indicator may be smaller than the target area, but the interactive target area itself must be large enough.
- Do not rely on tiny chevrons or icons as the only practical target for expanding or collapsing navigation sections.
This requirement supports cursor, tap, motor accessibility, and general usability. It is especially important for mobile navigation, dense desktop navigation bars, and any close or menu control.
11. Interaction States
Each interactive item should define the following states as applicable.
The visual system must also define how states combine. A single item can be focused and hovered, focused and active, focused and current, hovered and current, focused and expanded, or focused and disabled. Combined states should not be treated as new semantic roles. They are visual combinations of existing states.
For example, focused + active means the item has keyboard focus and is currently being activated. It does not mean the item has a special hybrid role. focused + current page means the item represents the current page and currently has focus. It does not mean the current page state and focused state are the same thing.
11.1 Default state
Default state is the base visual treatment for an available item before temporary interaction states such as hover, focus, active, or pressed are applied.
For Menu items, the default visual treatment may appear together with collapsed state. A collapsed Menu item can still be in its default visual presentation.
✔️ Requirements:
- Default state should make the item readable.
- Default state should make the item appear available.
- Default state should not visually compete with current page state.
- Default state should not be confused with disabled state.
- Default state should not imply that a child menu is open.
11.2 Hover / over state
The cursor is over the item.
✔️ Requirements:
- Hover state must visually indicate interactivity.
- Hover state must be visually distinct from focused, current page, expanded, and active / pressed states.
- Hover state must be subtle enough that it does not compete with the current page indicator.
- Hover state must not open, close, reveal, or dismiss a menu in this pattern.
- Hover state must not change expanded or collapsed state.
Hover state is visual feedback only.
11.3 Focused state
The item has keyboard focus.
✔️ Requirements:
- Every interactive item must have a visible focused state.
- Focused state must be clearly visible.
- Focused state must not rely on color alone.
- Focused state must be visually distinct from hover, current page, expanded, and active / pressed states.
- Focus must follow the defined tab order.
- Focused state must not automatically open a menu.
Focused state should always answer the user’s question:
Where am I right now?
A focused Menu item opens or closes its child menu only when the user activates it with Enter or Space.
11.4 Active / pressed state
The item is actively being activated.
This state occurs during intentional activation, such as when the user presses the mouse buttons, Enter, or Space.
✔️ Requirements:
- Active or pressed state should provide immediate visual feedback.
- Active or pressed state should be temporary.
- Active or pressed state should not be used to represent the current page.
- Active or pressed state should not be confused with focused state.
- Active or pressed state should not be confused with current page state.
This state communicates that the user’s input has been received.
Hover does not create active or pressed state. The item enters active or pressed state only during intentional activation.
11.5 Current page state
The item representing the currently displayed page, section, or route must have a visible current page indicator.
✔️ Requirements:
- The current page indicator must be visually persistent.
- The current page indicator must be visible without hover or focus.
- The current page indicator must be visually distinct from hover, focused, expanded, and active / pressed states.
- The current page indicator must not rely on color alone.
- The current destination item must use aria-current=”page”.
- Only one item in the same navigation set should use aria-current=”page”.
Example:
```
Current item
```
If the current page is represented by a child item inside a dropdown menu or mega menu, the child item should receive the current page indicator.
Example structure:
```
Parent Item
  Child Destination
  Child Destination ← current page
  Child Destination
```
In this pattern:
- The current child destination receives the current page indicator.
- The current child destination uses aria-current=”page”.
- The parent item may receive a visual parent-active treatment.
- The parent item should not use aria-current=”page” unless the parent item itself is the current page.
The parent-active treatment helps users understand which top-level section contains the current page. It should be visually distinct from the child item’s current page indicator.
Current page state must not depend on hover, focus, or menu open state.
11.6 Selected state
Selected state should not be used as the normal way to represent the current page in primary navigation.
Use selected state only when the component supports selection as a state separate from navigation.
Examples of appropriate selected state:
- A selected item inside a picker
- A selected item inside a switcher
- A selected item inside an application-style component
- A selected tab in a tablist
✔️ Requirements:
- Selected state must be visually distinct from hover, focused, current page, expanded, and active / pressed states.
- Selected state must not be used as a substitute for current page state.
- Do not use aria-selected for standard primary navigation links.
- Use aria-selected only for components with true selection semantics, such as tabs, listboxes, grids, or tree views.
For standard primary navigation, the user is usually not selecting an item into a persistent selection set. They are navigating to a location. In that case, use current page state instead.
If a visual state guide uses the phrase Selected (Current Page), the implementation should still treat that state as current page state and expose it with aria-current=”page”, not aria-selected.
11.7 Expanded state
The Menu item’s child menu is open.
✔️ Requirements:
- Expanded state must be visually indicated.
- The Menu item must use aria-expanded=”true”.
- The dropdown indicator should visually reflect the expanded state.
- Expanded state must be visually distinct from hover, focused, current page, and active / pressed states.
- Expanded state must result from intentional activation, not hover.
Expanded state should answer the user’s question:
Which item opened this menu?
11.8 Collapsed state
The Menu item’s child menu is closed.
✔️ Requirements:
- Collapsed state must be visually indicated.
- The Menu item must use aria-expanded=”false”.
- The dropdown indicator should visually reflect the collapsed state.
Collapsed state should still communicate that child items are available, usually through the dropdown indicator.
Collapsed state must result from initial page state or intentional dismissal behavior, not hover out.
11.9 Disabled state
The item is visible but not currently available.
Use disabled navigation items sparingly.
✔️ Requirements:
- Disabled items must not be activatable.
- Disabled state must be visually distinct from default state.
- Disabled state must not rely on color alone.
- Disabled items should not receive keyboard focus unless there is a specific accessibility reason.
- Disabled items must not open, close, reveal, or dismiss menus.
- Hover over a disabled item may show a disabled visual treatment, but it must not trigger behavior.
📝 Implementation note: Standard links do not support the native disabled attribute. If a destination is unavailable, prefer removing it, explaining the unavailable state nearby, or implementing an intentionally disabled pattern with clear visual, keyboard, and screen reader behavior. If aria-disabled=”true” is used, the implementation must still prevent activation and communicate the disabled state visually.
When possible, avoid showing disabled items unless the unavailable option helps users understand status, permissions, or workflow constraints.
If users cannot do anything with the item and do not need to know it exists, consider removing it from the navigation instead of showing it as disabled.
11.10 Combined interaction states
Interaction states can combine. The design system should document these combinations visually so implementation teams know which cue takes priority.
Common combinations include:
✔️ Requirements:
- Combined states must preserve focus visibility.
- Combined states must preserve the current page indicator.
- Combined states must not imply that focus, current page, active, or selected are the same concept.
- Combined states must not create a hybrid interaction model.
- Combined states must not change whether an item behaves as a destination item or Menu item.
- If the dropdown indicator is present for a Menu item, it should remain visible across applicable states.
The attached primary navigation item state guide should be treated as a visual reference for documenting state combinations. The language in this pattern should describe these as combinations, such as Focused + Hover or Focused + Active + Current Page, not as single blended states.
12. Accessibility Requirements
12.1 Semantic HTML first
Use semantic HTML before ARIA.
From the interaction design perspective, semantic HTML matters because it gives users expected behavior for free. Links behave like links. Buttons behave like buttons. Navigation landmarks behave like navigation landmarks.
✔️ Required:

A/B Test Strategies That Work

Trevor Calabro — Sat, 09 May 2026 17:08:23 GMT

Summary: A/B testing can be useful, but only when the variations being tested are grounded in a clear user problem, a strong hypothesis, and a realistic understanding of what the test can prove. UX researchers should help teams shape better A/B testing strategy by clarifying the problem, improving the variation, adding guardrail metrics, and making sure “winning” does not get confused with meaningful learning.

⚠️ Disclaimer: This article is for situations where you absolutely must run an A/B test. I typically prefer other, more robust methods for learning about design variations. If you are interested in alternatives to A/B testing, start with these articles:

Have you ever been in a meeting where everyone on the team starts debating a call to action, a dashboard card, an onboarding step, standard form field behavior, or some other part of a design, and everyone seems to have a strong opinion? One person thinks the button label should be more direct. Someone else thinks the page needs more explanatory text. Someone else wants to move the action higher on the screen because they are worried users will miss it. Then someone says that dreaded question, “Why don’t we just A/B test it?”

To all the non-UX researchers in the room, that sounds like a valid question. It feels objective and data-driven. I get the appeal. Instead of arguing, the team can let users decide through behavior. Easy peasy. Done and done.

We all know that in the right context, that can be a good instinct. A/B testing can be useful because it gives teams a way to compare real behavior in a live product. It can reduce opinion-driven decision-making, help teams avoid endless internal debates, and sometimes reveal that the version everyone loved in a meeting is not the version users actually respond to in practice.

The problem starts when the team treats the test itself as the thing that creates rigor.

The A/B mechanics can produce clean results while the thing being tested is still weak as hell. I see teams often randomly assign users, define a success metric, run the test long enough, and still end up with a result that does not teach them much.

A/B testing only compares the variations the team puts into the test. It does not make those variations are any good. If the variation is shallow, the learning will probably be shallow too. If the variation is based on a misunderstanding of the user problem, the result may only tell the team which version of the misunderstanding performed better.

In this article, I want to help reframe the way UX professionals respond to the question, “Why don’t we just A/B test it?” Instead of shutting the idea down outright, a better response is to slow the team down just enough to ask what the variation is actually testing. That is where UX research can add a lot of value before the test ever goes live.

What A/B Data Leaves Out

To run good A/B tests, you need to focus on the work that happens before the traffic split. The team has to clearly define what problem they believe exists, what user behavior they are trying to learn about, and what design variation would best test that belief. You guessed it: this is called strategy and study design. If your strategy sucks, the test can still produce clean-looking data, but it can also be super misleading.

The example I like to use is what I call the “make it more obvious” variation. You know the type of test. Let’s say Version A has a standard button at the bottom of a screen. Version B has a larger, higher-contrast button with more urgent language. The team runs the test, and Version B gets more clicks, so the result gets interpreted as proof that the new design is better. That may be true in one narrow sense. Version B produced more clicks on the metric the team selected.

Here are several different explanations packed into that result:

The button may have been easier to find.
The copy may have been clearer.
The visual treatment may have pulled attention away from other information.
The urgent language may have pushed users to act before they fully understood the decision.

Those are not small differences. They point to different design problems and different next steps. If the real issue was discoverability, the team might need a better layout hierarchy. If the real issue was unclear copy, the team might need a better label. If the improvement came from pressure, the team may have increased short-term clicks at the expense of trust or downstream success.

The A/B test by itself does not sort all of that out. It tells the team what happened between two variations under the conditions of the test. That’s it. Full stop.

In UX research, we are usually trying to understand how people make sense of a system, where they struggle, what they need to know before acting, and whether the design helps them complete the task with confidence. A/B testing can support that work, but it does not replace the thinking needed to create a meaningful variation. This is where I see the method misused the most. In the overuse and overinterpretation of the data.

Strong Variations

I see too many of these misleading and weak A/B test strategies in the real world. A weak A/B test often starts with a super vague hypothesis. “We think this version will perform better” is technically a prediction, but it does not give the team much to go off of. It does not explain what user problem the team thinks it is solving, what part of the design is expected to change behavior, or what the team will learn if the variation wins or loses.

A stronger UX hypothesis is much more specific. For example, “We believe users are missing the primary action because the current button label is vague and visually disconnected from the task. If we make the label more specific while keeping the button placement, size, and color the same, more users will continue to the next step.” The value in this reframing is that it forces the team to be clear about the link between the user problem, the design change, and the expected behavior change.

This is where we can make our A/B testing strategies much stronger. Before the team creates a variation, research can help explain what is actually happening in the current experience:

Usability testing can show where users hesitate, misread the interface, or misunderstand the next step.
Interviews can reveal concerns users have before committing to an action.
Behavioral analytics can show repeated backtracking, abandonment, or drop-off patterns.
Session replay can reveal behaviors like misclicks or repeated attempts to use unavailable or hidden controls.

Those findings lead to better variations because they ground the design change in observed behavior. The team is no longer guessing if the button needs to be a brighter color because someone in the room thinks bright colors buttons perform better. Instead, they are responding to a specific problem within the experience, in the real world.

This is an overly simplistic example, but I hope you can see how this changes the quality of the test. Instead of comparing two versions of a screen because the team has two opinions, the team is testing a specific explanation for user behavior. The A/B test becomes a way to measure whether a research-informed design change improves the outcome the team cares about.

To be clear, that does not guarantee the variation will win. In some cases, the research-informed version will underperform. That data is still useful if the original hypothesis was clear. Losing variations can teach us as much as winning ones, and in many cases, they are more insightful because they unearth institutionalized bias.

How to Think About Claims

The phrase “A/B test” is powerful in many orgs, especially product-led ones that have taken a page out of the debunked Silicon Valley “move fast and break things” playbook. The power comes for the misunderstanding I’ve been talking about.

A/B tests commonly make almost any comparison sound more precise and definitive than it really is.

In the real world, teams often use A/B testing to compare two designs that differ in several ways at once. That can be useful, but the team needs to be honest about what kind of claim the test can support, and we, as UX researchers, should be there to help them with that.

Imagine Version A has a button labeled “Continue” at the bottom of the page. Help text is hidden behind an icon. The page has three sections, and users have to scroll to review everything before moving forward.

Version B changes the button label to “Review and Submit,” makes the button sticky, adds visible help text, reduces the page to two sections, and introduces a progress indicator.

If Version B performs better, the team has learned something. The new version, as a full design package, performed better than the old version. That may be enough if the team’s goal is simply to decide whether to ship the redesigned flow.

The problem comes when the team tries to make a narrower claim than the test design supports. If five things changed, the result does not prove that the button label caused the improvement. Any of those changes may have helped. Several may have worked together. One may have helped while another made the experience worse.

Here are some examples:

One button label changes, while placement, size, color, and flow stay the same - Reasonable claim: evidence about the effect of the label change.
A full-page redesign changes layout, copy, hierarchy, and interaction patterns - Reasonable claim: comparison between two design packages, not proof that one specific element caused the result.
Several elements change at once without a clear hypothesis - Reasonable claim: the team may know which version won, but interpretation will be weak.
Multiple variables need to be studied separately - Better fit: a multivariate test or staged testing plan that can isolate the contribution of each variable.

This is why the learning goal has to match the variation. If the team wants to know whether clearer button copy reduces hesitation, the variation should isolate the button copy as much as possible. Keep the placement, visual treatment, surrounding content, and flow stable. That gives the result a cleaner interpretation.

If the team wants to compare two broader design directions, a bundled variation may be fine. A larger redesign often changes layout, information hierarchy, interaction patterns, content, and visual emphasis together because those pieces are connected. In that case, the test is answering whether this complete version performs better than that complete version.

Both types of tests can be useful. They just answer different questions. A focused variation supports a focused claim. A bundled variation supports a broader comparison. Trouble starts when a team runs the second kind of test and talks about the result as if it came from the first.

For UX researchers, this is one of the most important places to push for clarity. The goal is to help the team understand what they will actually be able to learn. Sometimes that means isolating one variable. Other times it means testing a larger design direction. Either way, the variation should match the decision the team needs to make.

These Metrics in Context

A/B testing gets especially tricky when the success metric is too narrow. A variation can win on the primary metric and still make the overall experience worse. That is one of the easiest ways teams accidentally turn A/B testing into a machine for optimizing local behavior instead of improving the actual user experience.

This happens a lot with clicks. Clicks are easy to measure, so they often become the thing the team optimizes for. If Version B gets more clicks than Version A, the dashboard looks good. The test has a winner. The team can point to a number and say the variation worked.

But more clicks are not always better. A user can click because the next step is clearer. A user can also click because the design pressured them, distracted them, interrupted them, or made one action more visually dominant than everything else on the screen. Those are very different outcomes, even if they produce the same short-term metric.

This is where guardrail metrics matter. A team should know what the variation is supposed to improve, but they should also know what they do not want to make worse. Otherwise, the team may optimize one behavior while quietly damaging another part of the experience.

Some common examples:

More clicks, but lower downstream completion
More signups, but more support contacts
More feature activation, but more abandonment later
More engagement, but lower trust
More interaction, but worse accessibility

The point is not that every A/B test needs a giant measurement framework. That would be overkill for many product decisions. The point is that the team should think beyond the one number that declares the winner.

A modal that increases feature activation might also increase dismissals, frustration, and support questions. A more aggressive confirmation message might push more users through a flow while making them less confident in what they just agreed to. A redesigned call to action might improve one user segment while creating problems for another segment with different goals, permissions, or prior knowledge.

In complicated software, this gets even messier because the thing being tested is often part of a larger workflow. A design change can make one screen perform better while creating confusion two steps later. The test result may look positive if the team stops measuring at the first click, but the user experience may not actually be better.

This is another place where UX researchers can add useful context. The question is not only, “Did the number go up?” The better question is, “What else might this variation affect?” That one question can change the quality of the test. It can push the team to look at completion, error rates, backtracking, support clicks, time on task, accessibility concerns, or downstream abandonment. It can also prevent the team from declaring victory too early, just because the easiest metric moved in the right direction.

A/B testing is useful because it measures behavior. But behavior still needs interpretation. A winning variation should be judged by whether it improves the experience in a way the org can responsibly defend, not just by whether it wins one metric in one part of the flow.

Don’t Skip Step 1

UX researchers do not need to own the experimentation platform to improve the quality of A/B testing. In many orgs, the platform, instrumentation, traffic allocation, and statistical setup will sit with product analytics, engineering, data science, or growth teams. That does not mean UX research has nothing to contribute.

The most valuable UX contribution often happens before the test launches. That is when the team is still deciding what problem they are solving, what variation should be created, and what the result will actually mean. Once the test is live, a lot of the important decisions have already been made.

A researcher can help the team slow down just enough to make the test more meaningful. That does not have to mean a long research project. It might mean a quick usability check, a review of prior findings, a look at session behavior, or a conversation about whether the proposed variation actually matches the problem the team says they are trying to solve.

The practical UXR role often looks like this:

Clarify the user problem before the variation is designed.
Turn a vague idea into a testable hypothesis.
Identify whether the proposed change matches the observed problem.
Flag when too many things are changing at once.
Recommend guardrail metrics.
Run a quick prototype or usability check before the test goes live.
Help the team interpret the result without overstating what it proves.

This is a playbook for how UX research can help keep the interpretation grounded. The team can say, “In this flow, for this user population, under these conditions, this variation improved this metric.” That may sound less exciting, but it is usually more accurate. It also makes the finding more useful because future teams can understand when the result might apply and when it probably does not.

Also, in a perfect world, A/B testing should not be the first time users encounter a variation, especially in complicated enterprise software. If the design has obvious usability issues, the live experiment will measure those issues along with everything else. A quick round of UX evaluation before launch can remove problems that would otherwise muddy the test. Literally, try anything to help put context around a problem before running an A/B test. That additional evaluation does not need to be elaborate. For some changes, a short prototype review with a few users may be enough. The goal is to make sure the variation is coherent before it gets measured at scale.

Better Variation Design Examples

Let’s say your team started with the old “let’s test a more prominent button” hypothesis. A better version of the conversation starts with questions that you, as the researcher, should be asking.

Questions like:

Why does the button need to be more prominent?
Are users missing it altogether?
Are they unsure what it does?
Are they afraid of committing to the next step?
Are they distracted by competing actions on the page?

The answers to these questions lead to a different variation. That is why the design change should come after the problem is understood, not before. Otherwise, the team is just picking a visual change and hoping the test makes it meaningful.

Example questions worth asking before the test:

What user behavior are we trying to change? - Keeps the test focused on a real behavior, not just a design preference.
What do we think is causing the current behavior? - Forces the team to name the assumption behind the variation.
What exactly are we changing? - Makes the variation easier to interpret later.
What are we keeping the same? - Helps isolate the design variable when possible.
What is the primary metric? - Defines how the team will judge the result.
What are the guardrail metrics? - Helps catch harm outside the primary metric.
What will we know after the test? - Keeps the test connected to a learning goal.

That structure does not need to become a formal template every team fills out before every test. It is more useful as a thinking tool. If the team cannot answer those questions in plain language, the variation probably is not ready.

Weak variation vs. stronger variation examples:

❌ Weak: “Make the button more noticeable.”
✔️ Stronger: “Increase visual prominence while keeping the label, placement, and flow unchanged to test whether discoverability is the issue.”

❌ Weak: “Try different copy.”
✔️ Stronger: “Change the label to clarify what happens next because users are hesitating before a commitment-heavy action.”

❌ Weak: “Test the new design against the old one.”
✔️ Stronger: “Test whether exposing required information earlier reduces abandonment before the confirmation step.”

❌ Weak: “Add help text.”
✔️ Stronger: “Add one line of contextual help under the field users misinterpret most often.”

Note that the stronger versions are not necessarily more complicated, but they are more specific. They connect the design change to a user problem and a learning goal. That makes the result easier to interpret, even when the result is not what the team expected.

This also helps with stakeholder conversations. When the variation is specific, the result is easier to explain. The team can say what changed, why it changed, what metric moved, and what the result suggests. That is much more useful than saying, “The new version won,” especially when the new version changed several things at once.

Better variation design does not mean every test has to be small. Some tests should compare broader design directions. The important thing is to be honest about the level of learning. A focused variation can tell the team something focused. A broader variation can help the team choose between broader directions. The test design should match the decision the team needs to make.

Conclusion

So, when a product team says, “Let’s just A/B test it,” the instinct to shut them down is reasonable, but we need to do better. As UX researchers, part of our job is to help shape how our orgs use user data, and A/B testing is a perfect example of where that responsibility shows up in practice. We need to lead A/B testing conversations as sense makers, not blockers. We have the opportunity to show how real users respond to real changes in the real world, and we should take those opportunities when they come.

But A/B tests are only as good as the thing being tested. If the variation is shallow, messy, or disconnected from the actual user problem, the result will inherit those weaknesses. It may still produce a winner, but winning is not the same thing as learning. That is the part I wish more teams took seriously. Better A/B testing does not start in the experimentation platform. It starts when the team asks a better question about the variation.

How do you help with A/B testing strategy in your org? Any tactics I missed? If so, comment here or DM me with the details. I’m always happy to add more things to my toolkit, especially when it comes to this misused and misunderstood method. Thanks for reading!

Stop Throwing Away Time-on-Task Data

Trevor Calabro — Sat, 02 May 2026 16:56:11 GMT

Summary: Time-on-task with small samples is often misunderstood as not useful, but it can still produce meaningful behavioral evidence. This article explains why the median should usually be the default, how to report outliers honestly, and how to avoid overstating what small samples can tell us.

A while back, an earlier-career UX researcher came to me with a common time-on-task question. They had just run a moderated usability study with 8 participants. The task was fairly straightforward, and all participants completed the task successfully. Most participants moved through the flow in about 45 to 70 seconds, which lined up with what the researcher saw in the usability study sessions. The task took a little effort, but most folks experienced very little friction. Except for one participant. (Cue the ominous music. 🎵 Dun Dun Dun 🎵) You know the one. The participant who flat-out got stuck had to reread the content, misclicked a lot, ended up backtracking, and eventually recovered to complete the task, but barely. In this case, they completed the task, but it took them 4 minutes.

After the study, the researcher did what a lot of people are taught to do. They put the task times into a spreadsheet and calculated the average. The spreadsheet gave them a number. The number looked official enough to go into a report. But this earlier-career UX researcher knew that the final calculation didn’t represent what they had seen with their own eyes. At the same time, she knew the long task time from that one participant who got stuck clearly mattered. It was not random noise. It was one of the most useful moments in the study because it showed a real failure path in the design.

As UX professionals, we need to understand that when usability issues are found during small-sample research studies, they should be documented, explained, and seriously considered for fixing, even when they only show up once or twice. I see wayyyyyy too many UX professionals misunderstand this in the real world, and that makes me sad.

These misguided UX pros believe that if an issue only shows up once or twice, it holds less weight. Even worse, I have seen instances where an outlier like this would be removed from the dataset to make the report look more “clean.” This is a huge problem. It is risky and flat-out unethical.

Back to the story. So the earlier-career UX researcher came to me with a question that was basically:

I know this average is technically right, but I don’t think it represents what happened in the study.

That question is why I chose to write about this topic today, specifically, time-on-task calculations with small sample sizes. In this case, the average was pulled upward by that one participant who experienced a serious usability issue. That is the problem with using the mean as the default calculation method here.

For this kind of study, I would usually start with the median. The median gives a clearer read on the typical observed experience. Then I would report the slower case separately and explain what happened, because that struggle is still meaningful evidence.

But I know what you are thinking. All that leads us to an even more foundational question. Why would we want to measure time-on-task with a small sample size anyway? Let’s talk about that a little bit first.

Time-on-Task with Small Samples

Some UX professionals hear “small sample size” and immediately assume time-on-task is not worth calculating. I 100% understand where that comes from.

If we are trying to estimate the exact average task time for an entire user population, 8 participants is a very small number. That kind of claim needs a larger sample, cleaner instrumentation, and a much stronger quantitative design. So yes, there is a real limitation here. The mistake is treating that limitation as a reason to throw out the task time data entirely.

In a small moderated usability study, time-on-task can still tell us something very very useful. It can show whether most participants moved through the task in roughly the same amount of time. It can reveal whether one or two participants had a very different experience. It can help us separate a generally slow task from a mostly smooth task with one serious failure path. The problem happens when people are confused about the kind of claim we are making.

For example, with a small sample, I would not say:

The average task time for this workflow is 78 seconds.

I would say something more like:

In this study, the median task time was 56 seconds. Most participants completed the task in about a minute. One participant took 4 minutes after misinterpreting the account-selection step, which points to a real usability issue we should address.

That second version is much more honest and will be less likely to be misinterpreted by stakeholders. What it doesn’t do is pretend 8 people can give us a precise population estimate. It also does not ignore useful behavioral evidence just because the sample is small. Win/win. I hope you are starting to see my argument here.

That is the middle ground, I think, that UX researchers need to get better at. Small samples do not give us permission to make inflated claims. They also do not require us to ignore measurable behavior. They require better wording, better summaries, and more care about uncertainty.

That is the basic argument of this article. When UX researchers calculate time-on-task with small sample sizes, which we should be doing, the median should usually be the default starting point, and the reason starts with the shape of the data.

Skewed Time-on-Task Data

Time-on-task data almost never behaves like the tidy examples we learned in statistics classes.

Lower Limits - A user task has a practical lower limit. The user has to read, scan, decide, click, wait for the interface, and move through the flow. Even in a beautifully designed experience, there is some minimum amount of time the task is going to take.

Upper Limits -The upper limit is much messier. A user can take a long time because they misunderstand the task. They can miss a label. They can hesitate because two options sound too similar. They can reread the instructions three times. They can get interrupted. They can hit a slow-loading page. They can accidentally go down the wrong path and recover. They can also run into a real usability problem that nobody on the team realized was there.

That creates a pattern we see all the time in UX research, where most people cluster somewhere near the lower end, while a few slower cases stretch the distribution upward.

Here is a simple example from an 8 participant usability test:

But what if we only show the task times? Then the table looks like a small dataset. Once we add what happened, it starts looking like UX research again.

Now compare the basic summary statistics:

Both the median and the mean are mathematically correct. The issue is that they answer different questions.

Median - Tells us that the typical participant, in this study, completed the task in about a minute. That lines up with the behavior we saw across most usability test sessions. (Note the words “in this study.”)

Mean - Tells us that the average task time was 78 seconds in this study. That number is higher because one participant had a much slower experience.

That slower experience might be the most important finding in the whole study. We should not ignore it, hide it, or treat it like an inconvenience just because it makes the numbers messy. At the same time, it should not quietly redefine the typical experience for the other seven participants.

This is the core reason the median is usually a better default for time-on-task. It answers the question UX researchers usually care about in a moderated study; what was the middle experience?

The mean makes all observed task times and spreads them evenly across everyone. That can be useful in some contexts, especially when you are working with large-scale behavioral analytics or trying to estimate total time burden across a large population. In a small moderated study, though, it is usually not the best starting point.

Most of the time, we are trying to answer questions like:

Did most users move through the task smoothly?
Was the task generally fast but still fragile?
Did one severe confusion point create a long delay?
Was the experience workable for most people?
Was there a risky failure path for users who misunderstood one key label?

But the median gives us a better first read on that typical observed experience. It does not explain everything. It does not replace watching the sessions. It does not tell us why someone struggled. It gives us a less fragile summary of what happened, a nd in small-sample UX research, less fragile is usually a very good thing.

Report Median

The median should usually be the starting point for time-on-task, and it should travel with the surrounding evidence. But a median by itself can still hide too much.

If all we say is “the median task time was 56 seconds,” we have improved the statistic, and we still have not explained the experience. We have a better summary number. We still need the behavior that gives the number meaning.

For small-sample usability studies, I would usually report time-on-task with a few pieces of context:

The goal here is pretty simple. We want the number and the observation to support each other.

A stronger write-up might look like this:

Median task time was 56 seconds. Observed times ranged from 42 seconds to 240 seconds. 6 of 8 participants completed the task in under 70 seconds. The longest task time came from one participant who misunderstood the account-selection label and opened the wrong account panel before recovering.

That gives the reader the summary, the range, and the user behavior. It also helps prevent a common reporting problem. Time-on-task gets treated like a standalone performance score, floating outside the rest of the study. Someone sees the number and assumes the number is the finding. Time-on-task rarely explains itself.

A slow task time tells us that one participant took longer than the others, and that’s it. Analyzing the full usability test session tells us everything else that happened. The research synthesis tells us whether that behavior looks like a minor hesitation, a recoverable issue, or a serious failure path.

This is why I like writing the findings in a way that includes both the statistics and the behavior, like this:

Median task time was 56 seconds. Most participants completed the task in about a minute. One participant took 240 seconds after misinterpreting the account-selection step. This suggests the flow may be efficient for users who understand the account structure, with a clear failure path for users managing multiple accounts.

That version gives stakeholders something they can use in the real world. They can see the typical task time, the slow cases, and the design issue all in one view. This gives you the mechanism needed to ensure your stakeholders understand why the outlier participant matters. Your report should make the shape of the data visible. For very small samples, I often think the simplest option is the best one, show the individual task times.

Something like this is easy to understand:

I hope you can see how that table does a lot of work. It shows the cluster. It shows the extreme case. It shows why the extreme case happened.

This is mixed methods thinking at its finest. It lets people understand the data without pretending 8 participants are enough to support a highly precise estimate.

The same idea applies when talking through the readout. Stakeholders often ask for averages because averages are familiar. That is fine. We can answer the real question behind the question.

A simple explanation might sound like this:

I’m using the median because time-on-task data is usually skewed, especially with small samples. In this study, most people completed the task in about a minute. One person took much longer because they misunderstood the account-selection step, so I’m reporting that separately as an important usability issue.

In my experience, that explanation is usually enough. It avoids making the conversation about statistics for the sake of statistics. It brings the conversation back to the user behavior. That is where the research value is.

Mean Is Still Useful

If you are working with a large analytics dataset, the mean may help answer questions about the total time burden. If a task is completed hundreds of thousands of times per month, long task times may represent real operational cost.

For example, imagine a repetitive common workflow that gets completed 500,000 times per month. If one version of the flow adds 20 seconds on average, that could represent a meaningful amount of user time across the whole system. It could also increase abandonment, support contacts, frustration, or downstream errors.

In that context, the mean might help answer questions like:

Those are valid questions. They are also different from the questions we usually ask in a small moderated usability study.

In a small study, we are usually trying to understand how the experience behaved for the people we observed. We want to know where users moved smoothly, where they hesitated, where the design created confusion, and what moments created delays. For that work, the median is usually the better starting point.

A helpful sequence is:

Start with the median.
Show the range.
Explain the slowest cases.
Decide whether the mean adds anything useful.
Use the mean only when it answers a specific research or business question.

It also helps avoid a common readout problem where one average becomes the center of the conversation. Once that happens, people start debating the number instead of the experience. They ask whether the task was “fast enough.” They compare it to some remembered number from another study. They want to know whether 78 seconds is good or bad.

Trust me on this, the better conversation is much more specific. Most participants completed the task in about a minute. One participant took four minutes because the account-selection label sent them down the wrong path. The risk is not general slowness across the whole task. The risk is a specific failure path for users who interpret that label differently than the team intended.

That is a much more useful product conversation. The mean may still be worth including in an appendix or supporting detail. I would just avoid making it the headline metric unless it directly supports the decision being made. For small-sample usability studies, the headline should usually be the median plus the observed behavior.

Match the Data

A lot of UX research gets into trouble when we make the analysis look more precise than the study can actually support. Time-on-task is one of the places I see this error in thinking a lot!

As a rule of thumb, I always ask myself if the method I’m using matches the data.

For small-sample time-on-task analysis, the practical approach is pretty simple:

Use the median as the primary summary.
Show the range.
Show the individual task times when the sample is small.
Explain the slowest cases.
Be careful with p-values when the sample is tiny.
Use non-parametric methods when comparing groups and the data is clearly skewed.
Consider bootstrapping when you need an uncertainty interval around a statistic like the median.
Consider transformations for highly skewed timing data when you are doing more formal modeling, and explain the results in plain language.

Most UX researchers do not need to turn every time-on-task report into a methods appendix. The practical standard is much simpler.

Use a method that fits what you actually collected. If you have eight task times and one of them is 240 seconds, show that shape. Do not hide it inside a clean-looking average. If you have a small sample and a skewed distribution, do not write as though you have a stable estimate of normal behavior across the entire user population.

There is a difference between being quantitative and being precise beyond what the evidence supports.

That distinction matters because stakeholders often want numbers to carry more certainty than they deserve. A number in a report can feel settled. It can feel objective. It can feel like the debate is over.

UX researchers have to be careful with that power. A good time-on-task write-up should make the strength of the evidence visible. It should help people understand what happened, how often it happened in the study, and how much confidence we should place in the pattern.

Here is a practical reporting pattern I would trust:

Median task time was 56 seconds across eight participants. Seven participants completed the task between 42 and 67 seconds. One participant took 240 seconds after misinterpreting the account-selection step and navigating into the wrong account panel. Because the task-time data was skewed, the median is a better summary of the typical observed experience than the mean. The slowest case is reported separately because it reflects a meaningful usability issue. Additional quantitative research should be done if you want to better understand the actual time-on-task for the entire user population.

That paragraph does several useful things:

It gives the primary metric.
It shows the spread.
It names the sample size.
It explains the skew.
It preserves the slow case.
It connects the slow case to a design issue.
It clarifies that this does not represent the whole user base.
It points to the need for additional quant research.

That is the kind of reporting that helps teams make better decisions.

Conclusion

Time-on-task is easy to calculate and easy to misuse. That is probably why this problem shows up so often. Averages feel familiar, fit nicely in slides, and make messy behavior look clean. They give teams a number they can compare, track, and, quite frankly, stakeholders are suckers for them, which is why many PMs weaponize this kind of data for manipulation purposes. We need to be the antidote to this trend. We, as UX researchers, need to be the data experts and truth tellers within our organizations.

For example, when we collect time-on-task in a small usability study, we are measuring people trying to complete a task inside a real interface. Their time reflects comprehension, hesitation, confidence, confusion, recovery, and sometimes failure.

The median helps us summarize the typical observed experience without letting one extreme case dominate the headline number.

The range helps us show the spread.
The individual task times help us keep the data honest.
The observed behavior helps us explain what the numbers mean.

Together, these give teams a better read on the experience than a single average ever could. So the next time someone asks for the average time-on-task, I would still answer the question behind the question. Thanks for reading, and I hope this is helpful!

Onboarding & In-App Help Strategy

Trevor Calabro — Sat, 25 Apr 2026 21:42:45 GMT

Summary: Decades of usability and accessibility data have shown that many common onboarding and in-app help design patterns just don’t work well in the real world. This post details a reusable framework for how best to display help content in complex applications.

I recently wrote a document to help define a reusable set of UX best practices for product onboarding and in-application help. This week’s post is a generalized version of that document that you can use in your own day-to-day work.

My goal was to make help content decisions more strategic across products, platforms, and teams, so this guidance is intentionally technology- and domain-agnostic. Everything in this week’s post focuses on widely accepted usability best practices, helping users complete real world tasks, and giving users guidance at the moment they actually need it.

And I think this matters because a lot of UXers and product teams don’t seem to know about these best practices anymore. Products like Pendo make it easy to add UI elements into apps, and I worry that many UXers have started favoring these quick-win methods over foundational user-centered principles.

If you need a starting point for discussion with your team, I encourage you to share this post. My hope is this info is especially useful for UXers trying to create more consistent guidance across teams without turning every onboarding or help experience into a maze of popups, tours, and misunderstood help widgets.

⚠️ Disclaimer: This is meant to be used as a reference guide, so you’ll notice that a few ideas repeat across some sections.

Core Strategy Principles

Keep guidance contextual and just-in-time. When possible, information should appear at the moment a user needs it to make the next decision or take the next action. Avoid front-loading instruction that users must remember for later interactions and decisions.
Require only what is necessary up front. Use step-by-step onboarding only for information the system genuinely needs in order to function, or for required security, compliance, or activation steps. Everything else should be deferred until it becomes relevant and displayed just-in-time in the workflow.
Make the next action explicit. Each step should make it obvious what the user is expected to do next. The goal is not the fewest possible words. The goal is the minimum amount of text needed to make the next action or decision clear and explicit.
Show only what is relevant to the current user and context. Where possible, the experience should adapt based on role, permissions, product access, workflow stage, and device context. Users should not be exposed to features, instructions, or decisions that do not apply to them.
Prevent errors and make recovery easy. Onboarding and self-serve setup or data management should reduce the chance of mistakes through clear structure, validation, and review processes. When errors do occur, the system should make correction options straightforward, visible, and explicit.
Keep help inside the workflow whenever possible. The primary support strategy should be built directly into onboarding, self-service configuration, and the product experience itself. It should not depend on separate documentation systems, long text-heavy help panels, or standalone training content.

Help & Onboarding Specifics

Use wizards selectively. A wizard is appropriate when the task needs a clear sequence of required setup steps. It should not be used to force optional configuration, introduce broad product education, or present every available feature at once.
Organize around decisions and tasks, not system structure. Each onboarding step should support one main action, one main decision, or one coherent group of closely related inputs.
Keep progress visible. Required setup should be broken into clearly named steps so users understand where they are, what remains, and what has already been completed.
Defer nonessential setup. Optional details, secondary preferences, and lower-priority configuration should not be added to upfront onboarding steps. These items should be introduced just-in-time, in context, when they become relevant to the user’s workflow.
Use progressive disclosure carefully. Show the information most users need directly on the screen. Following the 80/20 Rule, the default view should include the guidance most users need to move forward without extra clicks. Secondary details, exception paths, and less common cases can be placed behind a clearly labeled expand option or another explicit interaction. Do not hide essential guidance by default.
Design for exceptions without breaking the primary workflow. Even when the underlying onboarding work is not literally linear, the experience should still impose a clear sequence whenever that creates a more understandable path through setup. That sequence should accommodate all valid scenarios without blocking users whose path differs from the common case. (This could be implemented using progressive disclosure in the frontend, supported by conditional logic in the backend.) The default flow should be optimized for the 80/20 path, while less common cases can be handled through branching, progressive disclosure, or guided exceptions inside the overall sequence.
Support save and return at all cost. Users should be able to pause and resume onboarding without losing work or losing their place when the process is likely to span multiple decisions or sessions.
Validate in place. Errors and warnings should appear close to the relevant UI control or user action, using plain, user-centered language with explicit guidance on how to correct the issue. However, first look for all possible methods to avoid system errors in the first place. (Allow the system itself to do the bulk of the work.)
Provide a review point before commitment. Users should have a chance to confirm important choices before activation, submission, or any downstream consequence that is difficult to undo.
Confirm irreversible actions. Any choice that is irreversible, or that would require manual support intervention to correct, should trigger an explicit confirmation modal that clearly states the consequence.

End-User Onboarding Best Practices

In general, end-user experiences should focus on fast, confident entry into core product use. The product should not assume that new users want a tour, a lesson, or a lengthy profile setup process before they can begin.

Minimize first-run friction. Only the steps required for access, security, compliance, or immediate product use should appear up front.
Avoid forcing completion of nonessential profile or preference fields. If information can be added later, it should be deferred and requested just in time, and only when it becomes useful to the user.
Introduce features at first meaningful use. If a user is about to encounter a task or feature for the first time, contextual instruction may be appropriate when delivered just-in-time.
Tie guidance directly to the relevant interface components. When a prompt or instructional message appears, it should point to the exact UI control or choice the user is working with and explicitly explain what to do now in context.
Use the same standards on mobile. A mobile experience should follow the same just-in-time and contextual model. For accessibility and usability reasons, do not rely on hover behavior, hidden affordances, or dense text patterns that are difficult to use on smaller screens.

System Admin Onboarding Best Practices

System admin onboarding should be treated as a guided setup experience, not a general product introduction. These users are usually configuring important parts of the system, making decisions that affect other users, and managing settings that may have downstream consequences. The experience should help them move through required setup tasks with enough structure, context, validation, and review to feel confident before anything is activated or applied.

Prioritize structured setup over broad education. The setup experience should lead admin users with setup responsibilities through required decisions and setup activities in a deliberate sequence instead of expecting them to learn the system through large amounts of introductory content. Even when the underlying work is not fully linear, the experience should create a clear sequence if one can support all necessary scenarios. That sequence should be designed to work for all such users, while being optimized for the most common (80/20) paths wherever possible.
Keep the experience focused on the task at hand. Do not expose unrelated features, settings, or reference material during setup or configuration tasks if possible.
Make system state clear. Admin users should always be able to tell where they are in the setup process, what has been completed, what is in progress, what still needs review, and where action is required. Also consider including additional push notifications to encourage progress where possible.
Design for confidence before activation. The experience should favor review, preview, validation, and confirmation over workflow speed, especially where configuration choices have impactful downstream effects.
Support error prevention and correction as part of the workflow. The experience should assume that some information will need to be revised during setup. Editing, revisiting earlier decisions, correcting errors, and continuing forward should feel like part of the intended process and be explicit.
Use just-in-time embedded help at decision points. Admin users should receive concise guidance where choices are made, especially during setup moments that require interpretation, review, or error correction. This is especially important for bulk setup actions. Guidance should use language framed from the user’s task perspective. The system should not send them away to search through general documentation to understand a required setup decision if possible.
Respect role and permission context. Different admin user segments should only see the configuration choices, instructions, and follow-up guidance that apply to their responsibilities where possible.

Help & In-App Guidance Best Practices

Help should be treated as part of the product experience, not as a separate system. The goal is to give people enough information to move forward from the screen they are already on, without requiring them to stop, search, and interpret a large external help system.

Remember me?

Make embedded guidance the default. The first choice should be inline instructions, targeted helper text, well-written empty states, clear labels, and task-level prompts placed within the workflow.
Write from the user’s point of view. Help text should be framed around what the user is trying to do, what action to take, and what happens next. It should not be written from the system’s perspective.
Keep required help visible. If most users need a piece of guidance in order to proceed correctly, that guidance should appear on the face of the interface. It should not be hidden behind a click, tooltip, or icon-only control.
Use progressive disclosure only for secondary help. Expandable content is appropriate for extra explanation, edge cases, definitions, or deeper detail that only a smaller portion of users will need. All uses of progressive disclosure should be accessed via an explicitly labeled UI component.
Avoid icon-only help patterns. All help-triggering controls should be explicitly labeled. For accessibility and usability reasons, do not rely on question-mark icons or other symbols alone to communicate that useful information is available.
Do not put essential help in tooltips alone. Tooltips and similar patterns may support supplemental explanation, but they are not strong enough to carry required instructions or critical decision support. Also, keep in mind that hover-only controls are deeply inaccessible in all UI context and inherently unusable on mobile.
Use empty states as guidance moments. When a screen or area has no content yet, the empty state should explain what belongs there and what the user can do next.
Use error states as guidance moments. Messages should explain what went wrong, what the user can do now, and whether the issue can be resolved in the product or requires support.
Treat external help systems as secondary. A separate documentation system may still exist, but it should act as backup reference material. It should not be the primary method for explaining how to complete onboarding or common in-product tasks.
Design content for reuse across contexts. Help content should be modular enough to be placed near relevant tasks across the product rather than stored only as long, standalone pages.

Example Patterns to Avoid

Avoid showing the full complexity of the system too early. Sometimes complex products still need sequencing. The right response to complexity is guided structure and contextual disclosure, not exposure of every option at once. See Wizards: Definition and Design Recommendations, UI: Proper Indicators for Hidden Elements, and Design for Optimal Experience.
Avoid onboarding carousels or introductory tours. Do not present users with a sequence of pop-up slides or feature-overview screens at first login as the primary onboarding method. These patterns usually ask users to remember abstract guidance before they have a real task or decision in front of them. See Carousel Interaction Stats, Onboarding Tutorials vs. Contextual Help and Mobile Tutorials: Wasted Effort or Efficiency Boost?.
Avoid broad first-run walkthroughs that explain the whole interface. Even when step-by-step guidance points at specific UI elements, this pattern is often difficult for users. It can interrupt task flow, appear out of context, and force users to memorize instructions they can’t easily recall or apply when needed. See Onboarding Tutorials vs. Contextual Help, Instructional Overlays and Coach Marks for Mobile Apps, and Help and Documentation (Usability Heuristic #10).
Avoid global “help” entry points as the main solution. A global help button, floating chatbot, generic right-side help pane, or detached knowledge base should not carry the primary burden of teaching the workflow. These patterns can be useful as secondary support, but they often force users to leave the task, search for the right answer, interpret generic content, and then apply it back to the screen they were already using. See Help and Documentation (Usability Heuristic #10) and Onboarding Tutorials vs. Contextual Help.
Avoid non-contextual help panes. A right-side help panel can be useful when it is tied directly to the current screen, task, role, or decision. It becomes much less useful when it acts like a generic documentation drawer that displays broad reference content without knowing what the user is trying to do. Help should reduce interpretation work, not add another layer of searching inside the product. See Help and Documentation (Usability Heuristic #10) and Onboarding Tutorials vs. Contextual Help.
Avoid unlabeled icons and ambiguous controls. If a control is important enough to influence comprehension or decision-making, it should be labeled clearly. Do not hide required guidance behind a “?” icon, icon-only button, hover-only tooltip, or any other symbol that users have to discover, interpret, and activate before they know useful help exists. See Icon Usability and Tooltip Guidelines.
Avoid putting essential help in tooltips alone. Tooltips and similar patterns may support supplemental explanation, but they are not strong enough to carry required instructions or critical decision support. They are easy to miss, often depend on hover behavior, and can create serious usability and accessibility problems on mobile, touch devices, and keyboard-only workflows. See Tooltip Guidelines, UI: Proper Indicators for Hidden Elements, and Design for Optimal Experience.
Avoid walls of text. Large blocks of explanatory copy are difficult to scan and are usually a sign that the content is not tightly aligned to the decision the user must make. See Plain Language Is for Everyone, Even Experts and F-Shaped Pattern of Reading on the Web: Misunderstood, But Still Relevant (Even on Mobile).

A Pattern That Works

At a high-level, onboarding and help should make the next step clear at the moment it matters. Required setup should be structured and guided. Optional setup should be deferred. Help should be embedded, explicit, role-aware, and written from the user’s point of view.

This approach is especially important for complex, role-based products. The more the product can tailor onboarding and guidance to the user’s role, permissions, and current task, the more intuitive and self-sufficient the digital experience becomes.

UX Strategy for Key Workflows

This section translates the onboarding and in-application help principles into concrete experience direction for high-value workflows across products and platforms. The consistent approach across workflows is to keep the primary screens task-focused, introduce complexity only when it becomes relevant, make the next action explicit, validate in place, provide review before commitment, and keep required help visible within the flow.

Reusable Building Blocks

Guided task flows (wizard only when required): Use step-by-step guidance when there is a strict sequence (e.g., review → confirm → submit). Otherwise, keep users on a single primary screen with clear sectioning and strategic use of conditional logic and progressive disclosure.
Workflow checklists + system state: A persistent checklist showing what’s complete, what’s blocked, what’s next, and what requires attention (especially for multi-session work).
Strong empty states: When there’s nothing to display yet, explain what belongs here and provide one clear call to action (CTA) to get started.
Inline validation and guardrails: Validate as users type or select, keep errors near controls, and explain how to fix issues in plain language. Reserve blocking errors for truly blocking constraints.
Review/confirm screens for consequential actions: Provide a preview of impacts (what changes, effective timing, downstream consequences) before final submission or activation.
Contextual help at decision points: Short helper text, definitions, examples, and “what happens next” messaging embedded in the flow. Use progressive disclosure for edge cases; avoid icon-only help.
Save-and-return + drafts: Support long or multi-stakeholder tasks with drafts, autosave, and clear “resume where you left off” entry points.
User role- and permission-aware tailoring: Show only actions and guidance relevant to the user’s role, access level, and workflow stage.
Notifications: Use in-app and (where applicable) email notifications to drive completion for time-bound or multi-session workflows (missing items, pending approvals, approaching deadlines).

Conclusion

In practice, a lot of teams do not follow these guidelines. Sometimes it is because the product is complex. Sometimes it is because onboarding gets treated like a communication problem, a training problem, or a feature-adoption problem. And sometimes it is because patterns like tours, popups, floating chatbots, generic help panes, and “?” icons feel like easy solutions when a complex workflow is hard to design for across multiple teams.

But the usability and accessibility data gives us a pretty clear reason to reconsider. Required guidance works better when it is visible, contextual, and tied to the task a real user is trying to complete in the real world. Users should not have to remember instructions from five screens ago, hunt through generic help content, or discover hidden guidance before they can move forward.

So if your team is using this post as a starting point, I hope it helps you push for onboarding and help decisions that are more grounded in evidence, more consistent across products, and more respectful of how people actually use software in the real world. Thanks for reading!

Citations

Baymard Institute, UI: Proper Indicators for Hidden Elements
Interaction Design Foundation, Design for Optimal Experience
University of Notre Dame, Carousel Interaction Stats
Nielsen Norman Group, Onboarding tutorials vs. contextual help
Nielsen Norman Group, Wizards: Definition and design recommendations
Nielsen Norman Group, Instructional overlays and coach marks for mobile apps
Nielsen Norman Group, Help and documentation (Usability Heuristic #10)
Nielsen Norman Group, Mobile tutorials: Wasted effort or efficiency boost?
Nielsen Norman Group, Plain language is for everyone, even experts
Nielsen Norman Group, Tooltip guidelines
Nielsen Norman Group, Icon usability
Nielsen Norman Group, F-Shaped Pattern of Reading on the Web: Misunderstood, But Still Relevant (Even on Mobile)

Conclusion

A lot of my writing ends up circling the same basic truth from different angles: small interface decisions are rarely small once real users have to deal with them. A missing label, a vague icon, a bad default, a poorly timed validation rule, or a control that tries to do too much can quietly turn a simple task into something slower, riskier, and more frustrating than it needed to be.

That’s part of why I wanted to make this list narrower than some of the broader roundup posts I’ve done before. This version is really for the people who care about the craft side of interface design. The folks who still think details matter because they do.

If any of these posts helped you think through a design problem, feel free to share them, quote them, I encourage you to share these links. Thank you for reading.

Fixing Bad Status Design

Trevor Calabro — Sat, 11 Apr 2026 17:08:55 GMT

Summary: This week's article argues that enterprise UX teams spend too much time designing a specific interaction point and not enough time designing what happens after that interaction. I show how vague status labels, spinners, toasts, and dashboards create extra work for users, and what UX teams can do instead to make system feedback clearer and easier to trust.

In my 20+ year career in UX, I’ve noticed that a lot of enterprise/complex software does a decent job designing the moments when users take action, but it seems like far less work goes into designing everything that happens after that. Over time, I’ve seen a lot of the real usability burden shift into that post user action space. Users are trying to understand what the system is doing, what happens next, and whether they can trust what they are seeing in that moment.

That’s the topic I want to rant about this week. I believe that in complex software, a lot of the most important UX work starts after the click, because that is the point where users need clear system feedback to stay oriented, make good decisions, and keep the work moving. Let’s dive in a little.

After the Action

A lot of the worst user experiences I have seen were not caused by a button being hard to find, a form being impossible to complete, or a navigation model that made no sense. They happened after all of that stuff. You fill out the form, upload the file, submit the request, assign the ticket, or approve the change, and for one brief second, it feels like the hard part is over. Then the system gives you some tiny piece of feedback like “Submitted” or “In Progress,” and now you are left trying to figure out whether it actually worked or not.

That is the part I think UX teams underestimate. The action itself may have taken three seconds, but the full experience now stretches across time and whatever mental model the user has constructed. And that guessing becomes the majority of the experience, because the user is no longer thinking about the task at hand. Instead, they are too busy trying to stay oriented inside a process that has suddenly become completely opaque. Not good.

I’m confused.

Think about all the extra interaction costs we as UXers have caused users of complex systems over time, forcing them to hover over a nondescript UI element, refresh a table, check their email for some kind of update, ping a coworker, and open a second application just to understand whether the first one actually worked. My point is, it does not really matter that the submit button was clear, accessible, and placed exactly where best practices say it should be. The interaction did not end when they clicked it. It just became wayyyyy less visible.

Worse in Enterprise Software

My main argument is that this is more painful in enterprise environments because enterprise workflows usually unfold over multiple touchpoints over time.

I think of these touchpoints dealing with these 4 areas:

People
Approvals
Dependencies
Backend Processes

That kind of workflow creates a lot more room for uncertainty if the system does a poor job communicating state.

That is why I do not think this is really a complexity problem, at least not in the way UXers usually talk about it. In my experience, most enterprise users can handle a fair amount of complexity. They can learn terminology, navigate layered workflows, and deal with not-so-standard processes. But what I see wearing users down the most is system status ambiguity. They can work inside a complicated system if that system is explicit about what just happened, what is happening now, and what comes next. What really drains users is a system that looks simple on the surface but keeps forcing them to infer its actual state from vague labels, partial updates, and a lot of silence.

This is also why the good old visibility of system status heuristic still matters. The principle sounds basic until you apply it to a real enterprise workflow, where the “system” is no longer just one screen responding to one click. It is a chain of events that may involve timing, queueing, routing, review, exception handling, and another person picking up the work later. Once you look at it that way, it becomes obvious that a spinner or a tiny success message is often nowhere near enough.

The way I see enterprise UX teams talk about this stuff is still very page-level, but we are really dealing with a time-based problem. That mismatch is where a lot of this friction starts.

Showing Don’t Tell Status

A lot of interfaces technically show status, and that is exactly why this problem gets missed so often. Anyone can point to a badge, banner, icon, or label and claim the state is visible, therefore it’s communicated to the user. In the narrowest possible sense, that may be technically true, but the leap from “it’s visible” to “it’s communicated well” is a wild one. (It’s also counter to any basic logic.)

For example, a status like “Pending” might be accurate from the system’s point of view and still nearly useless from the user’s point of view, because that single label can hide several completely different realities. It might mean waiting on review, waiting on a sync, waiting on another team, waiting on a nightly process, or sitting in a broken state that nobody has noticed yet. Do any of these hidden ambiguities sound familiar to you?

That is where this starts to become a language problem as much as a status problem.

One of the oldest usability ideas in the field is that systems should speak the user’s language rather than their own internal shorthand, and enterprise software violates that rule constantly.

Enterprise systems often expose backend categories, workflow abstractions, and generic state labels, then act as if the user has been meaningfully informed. I’m looking at you, Workday, hahaha! In reality, the user has often just been handed a term that still requires interpretation, and interpretation is work.

The real question is whether the state it displays helps the user answer what they actually need to know in that moment:

Did my action work?
What is happening right now?
Do I need to do anything else?
Can I safely leave this screen?
Is another person responsible now?
Should I expect this to update in ten seconds, an hour, or tomorrow morning?

Those are the questions users are carrying around, and a lot of enterprise interfaces answer them very poorly, even when they appear to be full of status signals.

A status indicator can satisfy the design team because something is present on the screen, while still failing the user because it does not reduce uncertainty in any meaningful way. In my experience, that is where a lot of enterprise friction actually lives. The interface has not gone fully silent. It has done something even worse. It has spoken just enough to sound informative while still leaving the user with the actual cognitive burden of figuring out what the information means.

The Hidden Cost

When a system does a bad job of communicating system status, the most obvious cost is user confusion. But the bigger cost is the amount of extra user effort that gets layered on top of the workflow just to make the workflow usable. You’ve seen this before, users start refreshing screens, checking neighboring tabs, reopening records, scanning their email for confirmation messages, and asking coworkers whether something is normal. None of that work is the real job. It is orientation work that only exists because the interface failed to make the process legible.

Think about how this plays out in the real world. If a user is unsure whether a request actually went through, they are likely to submit it again. If someone can’t tell whether another team has the next step, they might start following up too early or too often. If a user can’t make sense of an item’s status, they might just create their own spreadsheet to track it manually in parallel. (You get the idea.) Over time, those behaviors stop being exceptions and start becoming the actual workflow.

This is when the official system becomes the place where tasks are technically entered, but the real tracking happens somewhere else outside the system, and that is a big reason why these problems create so much downstream noise within our orgs.

There is also a trust cost that is harder to measure but very easy to overlook. For example, once users learn that a system’s status indicators are unreliable, they’ll likely stop taking them at face value. And in my experience, that kind of thing will totally change how users interact with the product over time. That is a bad place for enterprise software to land, especially when the work inside that software is high stakes.

Why UX Teams Miss This

Part of the reason this problem survives so often is that it hides in plain sight. UX teams spend a lot of time reviewing entry points into workflows because those are the parts that show up cleanly in mocks, prototypes, and design critiques. Team members can comment on layout, labels, form fields, hierarchy, and button placement with a lot of confidence. But the moment after submission is much messier. It involves time, dependencies, handoffs, conditional logic, and states that may only become visible hours later or in another part of the product. My theory is that this kind of design work is harder to capture in a static review, so it simply gets less consideration and attention.

Now I’m confused and waiting indefinitely… cool, cool.

I also think product teams regularly underestimate how much of their own understanding comes from being too deep in the weeds. The people building the system usually know what happens after the click because they know the architecture and business rules that drove the original workflow. These folks know that a request enters a queue, gets validated overnight, routes to a specific team, or changes state only after another process runs. Because they already know the story behind the workflow, they can look at a status label like “Pending” and mentally fill in the missing detail without noticing that the interface never actually communicated it. And of course, as user advocates, we all know that the user does not have that advantage.

There is a more structural issue underneath this too. I see a lot of orgs treat post-action states like an afterthought, then try to solve the problem later by blindly throwing a handful of UI components at it and calling it done.

The most common culprits I see in the real world are:

a badge
a toast
a status column in a table
a filter that lets users sort by state
a tooltip
a color-coded icon or dot

All of these can be useful, but are often added after the core workflow has already been defined. By that point, the team is not really designing state communication. The result is usually a collection of indicators that reflect technical states or fragments of the process, but do not add up to a coherent explanation of how the work is actually moving. (noise vs. signal.)

The 3 Problem Children

Here are 3 of the most common UI patterns I see in the real world. All are often used as stand-ins for better status design, even though they usually leave users doing far too much interpretation on their own.

1. Progress Indicator Spinners

The spinner is probably the most familiar example of this whole issue because it gives the appearance of feedback without always providing much explanation. For very short waits, that is usually fine. People do not need a full narrative when something takes two seconds. The problem starts when teams use the same pattern for situations that are no longer short, simple, or predictable. At that point, the spinner stops functioning like useful feedback and starts functioning more like a placeholder for missing design. Motion is still happening on the screen, but the user has learned very little about what the system is doing, how long it might take, or what they should do if the wait continues.

2. Toasts

The toast creates a slightly different problem. It is often meant to reassure the user that their action was successful, but in practice, it tends to confirm only the thinnest possible version of success. A message like “Saved” or “Submitted” can be technically true while still leaving the most important questions unanswered. Saved where? Submitted to who? Finished for now or sent into a longer process. Then, of course, the message disappears, the user is left staring at the same screen or a slightly updated one, and the real burden of interpretation begins. That pattern is especially weak in enterprise systems because the action that just occurred is often not the end of the story. It is the beginning of a larger sequence, and a fleeting little confirmation message is nowhere near enough to orient someone inside that sequence. And of course, we have decades of usage data showing that temporary UI elements like toasts are often completely missed by users, so that’s still a thing too.

3. Dashboards

Then there is the dreaded dashboard, the junk drawer for the info your org thinks users need. The logic seems reasonable on the surface. If users need to understand status across time, give them a centralized place to monitor status. Sometimes that does help.

An enterprise-level dashboard only improves the experience if it turns raw status into something interpretable and actionable.

A table full of badges, timestamps, and vague labels does not automatically do that. In a lot of cases, it just relocates the confusion. The user can now see ten things marked “Pending” instead of one, but still has very little help understanding which of those items are healthy, which are stuck, which need intervention, and which are simply waiting their turn.

📝 NOTE: What ties all 3 of these patterns together is that they can make a system look responsive while still leaving the user underinformed. That is why teams often feel like they have handled status communication when they really have not. There is motion, there is confirmation, there is a place to view records later, and from a distance that can look like solid coverage. But if the person using the system still has to translate the interface for themselves, then the design has only surfaced state in a shallow sense.

Better Status Design

Despite what many UXers seem to think, better status design does not require turning every workflow into a verbose tutorial. (And it also does not mean adding a Pendo-style pop-up walkthrough, you lazy bums. hahaha.)

Most users do not need the system to narrate every little event in exhausting detail. What they need is enough explicit context to stay oriented without having to do detective work.

That usually means the interface needs to communicate more than a bare state label. It needs to communicate where the work is, what that state means in practical terms, whether anything is expected from the user right now, and what kind of change they should be watching for next.

This all sounds obvious when stated plainly, but a lot of enterprise products still stop at the thinnest possible layer of feedback. They tell the user that something exists in a state, but not what that state actually means for the work. A better system closes that gap. If something is under review, say that. If another team has the next step, say that. If processing typically takes until the next business day, say that. If the user is done for now and can safely leave, that should be explicit too. The goal is not to stuff the interface with more words. The goal is to reduce interpretation work.

This is also where good status design starts to feel more usable. When the system is clear about all of this, users stop floundering. You know the status design is working when users can move on and come back later because the interface has given them a usable explanation of the current situation. That is wayyyyyy more valuable than any generic success message.

A lot of the strongest examples I have seen do this by clearly separating the current state from the next-step meaning. That distinction matters because it is what turns status from a technical label into something a user can actually work with.

❌ Bad: “Submitted”
✔️ Better: “Submitted for manager review”

❌ Bad: “Processing”
✔️ Better: “Processing. No action needed. Expected completion by tomorrow morning.”

❌ Bad: “Pending”
✔️ Better: “Pending legal approval”

The better versions do more than report a state. They help the user understand what is happening, who or what owns the next step, and whether they need to do anything right now.

The other thing better systems do well is make status legible across time instead of only in the moment.

❌ Bad: “Saved” shown only in a disappearing toast
✔️ Better: “Changes saved at 2:14 PM” shown in a stable, visible location

❌ Bad: a vague status badge with no history
✔️ Better: a clear status label paired with a timestamp or status history

❌ Bad: a table update that gives no clue what changed or when
✔️ Better: a visible update that shows what changed, when it changed, and what happens next

A user should not get one brief chance to understand what happened and then lose the thread as soon as the screen refreshes, the toast disappears, or the table updates. If the work continues later, the interface should help them come back and quickly figure out where things stand.

The Bigger HCI Point

What makes this topic interesting to me is that it looks like a small interface issue until you sit with it for a while. On the surface, it can seem like a complaint about wording, spinners, or whether a status badge should be blue or green. But the deeper issue is that enterprise software often fails to help users build an accurate mental model of work that is unfolding across time. That is a much bigger design problem than most teams acknowledge.

A lot of UX conversations still treat interaction as something that happens in a neat little burst between the user and the screen. The person clicks, the interface responds, and the experience is more or less contained inside that exchange. That model breaks down pretty quickly in enterprise environments because the work is often distributed. A request can move through systems, rules, queues, reviewers, exception states, and downstream teams long after the user has stopped actively touching the interface. If the design only accounts for the visible moment of interaction, then it leaves the user in the dark during the part of the workflow where understanding matters most.

That is why I think poor status communication creates so much unnecessary cognitive load. It forces users to simulate the system in their own heads. They have to infer what happened from partial clues, remember how similar cases behaved last time, and guess which delays are normal and which ones signal a problem.

Some users eventually learn those patterns through repetition, but that does not mean the design is good. It just means the users have been trained to compensate for missing information.

In complex environments, that compensation can start to look like expertise. (This is the power-user fallacy.) But in reality, it is often just an adaptation to a system that never explained itself clearly enough in the first place.

This is also one of those places where usability and organizational clarity run directly into each other. When software communicates status and state poorly, it does not just confuse an individual user. It makes it harder to tell whether work is moving, waiting, stuck, or owned by someone else. In other words, the interface stops being a useful representation of the process. And that is where I have seen a huge amount of waste happen, all while UX teams are still debating small UI details in the hope that they will fix the core problem. (Spoiler, they won’t, no matter how good the UI is.)

Conclusion

To wrap things up, I’ve noticed for a long time that in complex and enterprise software, a lot of the most important UX work starts after the user takes action. That is the point where people need the system to clearly communicate what is happening, what comes next, and whether the work is moving the way it should.

Here’s an idea. Instead of leaving users to compensate, UX teams can design system feedback that does more real work. We can use clearer status labels, make ownership and next steps explicit, show when no action is needed, add timestamps or status history that help users reorient later, and explain what the system is actually waiting on. That kind of status design reduces interpretation work, makes workflows easier to follow across time, and gives users something they can actually trust in the real world. (e.g., basic old-school UX principles.)

Have you seen this kind of system-status confusion play out in the complex tools your team uses or builds? If you have, comment here or send me a DM. I’d be interested to hear where you’ve seen ambiguous system feedback create extra work and workaround behavior. Thanks for the continued support and for reading this week’s article.

Honest UX Artifacts

Trevor Calabro — Fri, 03 Apr 2026 16:17:58 GMT

Summary: Journey maps are one of the easiest UX artifacts to misuse because they often let teams simulate user understanding without doing the real user research work. Service blueprints, on the other hand, are often the more honest place to start because they document how user flows actually work before teams begin interpreting what users think or feel about them.

I’m in the middle of facilitating a service blueprint creation workshop at work, and it has had me thinking about a pattern I have seen in more than one past role. Does this sound familiar to you? A product has grown large enough that people across the org no longer share the same understanding of how the experience is actually delivered to end users because teams are somewhat siloed. One team understands the interface. Another understands the policy constraints. Another knows the manual steps happening behind the scenes. The Support team may know where users get stuck, while engineering knows which systems are patched together just well enough to keep the whole thing moving. At that point, the org does not just need design ideas. It needs a reliable picture of how the service currently works holistically.

In several past orgs, I watched that exact need get answered with a journey-mapping exercise. Stakeholders wanted the workshop version of user understanding. They wanted a Post-it wall full of stages, pain points, emotional states, and sticky notes that translated internal beliefs into something that looked user-centered. The result often felt productive in the moment. It gave people something visible to react to and something easy to circulate afterward. What it usually did not give them was a more accurate look into the root causes behind a disjointed user experience.

Service blueprints and journey maps are completely different tools, yet they are often conflated in UX circles. Nielsen Norman Group has a useful way of defining service blueprints. (NOTE: I’ll be using this definition and framework throughout this article.) They describe them as tools for mapping the relationships between service components, including people, processes, and touchpoints, and note that they are especially useful for cross-functional, multi touchpoint experiences. That is often the kind of understanding enterprise teams are missing. They do not need a workshop that helps everyone imagine what the user is thinking. They need something much more simple and straightforward. They need a way to document what the org is currently doing to create the experience users are having.

Journey maps can give teams the feeling that they have done that work when they have not. That gap between the feeling of learning and the presence of actual learning is a big part of why I have grown more skeptical of them over time.

The Problem

This is not a general comparison article about journey maps and service blueprints. (Many, many people have already written that article.) It is also not an article about how to run a better journey-mapping session. (That horse has already been beaten enough as well. hahaha.) I am not trying to rescue any methods or explain the ideal version of how they are supposed to work. Instead, I want to tell the real-world truth about journey maps and service blueprints.

I want to stay focused on how journey maps are often used in real orgs. In practice, they are frequently done incorrectly, and they are easier to mess up than many UX pros seem comfortable admitting. That becomes even more important in larger enterprise environments, where the system itself is already complicated and where polished internal artifacts can carry more authority than they deserve.

Service blueprints do answer a different question. Nielsen Norman Group makes that distinction clearly. Journey maps focus on understanding the end user’s journey, including actions, thoughts, and emotions, while service blueprints document how the org creates that experience through frontstage actions, backstage actions, and support processes. I agree with that distinction. I also think it helps explain why service blueprints are often the more useful strategic move in practice.

In my experience, orgs are not facing a shortage of made-up user emotions, but they are facing a shortage of shared operational understanding. Most orgs need to know who is doing what, where the process breaks down, which teams influence the experience, and where additional research is actually needed. A service blueprint gives them a more grounded way to start that work.

That is the argument I want to make in this week’s post. Journey maps are often easier to misuse. Service blueprints are more objective in nature. In large orgs with complicated products and layered service models, that difference starts to matter very quickly.

Stop Weaponizing Journey Maps

Journey maps are one of the easiest UX artifacts to turn into “UX Theater” because they let teams simulate user-centeredness without doing the real work of learning from actual users. And of course, the design thinking workshop format helps create that problem. A group gets together, starts filling in what they think users think and feel, and before long, the output begins to look like insight, whether or not insight is actually present. This is the standard critique that I’m sure most of you have heard many times.

That visual credibility carries a lot of weight inside orgs. A journey map tends to look substantial. It is detailed, well-structured, and full of language that sounds user-centered. Once it is on the wall or turned into a polished deliverable, people can start treating it like research simply because it resembles the kinds of artifacts research teams produce. The format does a lot of persuasive work on its own.

The first reason this happens is that journey maps invite workshop participants to make up how they think the typical user behaves without actual user data. Once a workshop starts assigning motivations, frustrations, and expectations to users who were never studied, the group is no longer synthesizing evidence. It turns into a baseless projection exercise filled with bias.

Even when the workshop participants are knowledgeable, close to the product, and genuinely care about the user, internal familiarity is still not user evidence, no matter how hard people try to make it seem that way.

A second problem is that the artifact creates confidence too easily. Stakeholders leave the session feeling aligned. Teams feel like progress was made. Leadership sees something concrete that appears to capture the user experience. Those reactions are understandable, but they are not proof that the artifact is accurate. A workshop can create momentum and still produce a distorted view of reality.

Journey maps also tend to mix different categories of information together until the boundaries disappear. A real process fact can sit next to a stakeholder’s guess. A present-state observation can sit next to a future-state aspiration. An imagined user pain point can get written in the same format as a finding that actually came from research. Once all of that is arranged into a single visual system, the weaker claims borrow credibility from the stronger ones.

This becomes more dangerous in enterprise settings because the experience is shaped by a lot of things that do not fit neatly into a simplified user story. Internal policies shape what can happen. Support workflows affect resolution time. Permissions, exceptions, legacy systems, and manual workarounds all influence what the user experiences. When a team tries to compress that kind of environment into a neat narrative about what the user is thinking or feeling, the result can be very misleading while still sounding strategic.

That is why I use the word weaponized. I do not mean that every journey map is made in bad faith. I mean that the artifact can be used to create the appearance of user understanding, reassure stakeholders that the team is being user-centered, and move decisions forward without doing the harder work of gathering real evidence. At that point, the journey map is no longer functioning as a research artifact. It is functioning as a persuasion artifact.

Service Blueprints Are Honest

The distinction between service blueprints and journey maps matters a lot because the organizational side of the experience is usually where the end user confusion is derived from.

The aesthetics of the interface might look simple enough on the surface, but the actual experience is being shaped by siloed team handoffs.

A service blueprint gives you a way to document those handoff thresholds without pretending to know more than you know about the user.

Nielsen Norman Group also points out that service blueprints are especially useful for experiences that are omnichannel, involve multiple touchpoints, or require cross-functional coordination. That description fits a huge amount of enterprise work. It also helps explain why service blueprints tend to hold up better in those environments. They are built to make organizational complexity visible.

That does not make service blueprints perfect. They can still be incomplete and executed in a sloppy way. But, they often still unearth organizational blind spots even if the wrong people are in the room or the wrong inputs are used. And unlike journey mapping, what they are less likely to do is drift into fake empathy-land. The fundamental structure of service blueprints keeps the team closer to observable reality. They ask what happens, who does it, what supports it, and where things break down. That is a much safer place to start than a workshop built around simulated user feelings.

This is why I keep coming back to the idea that service blueprints are often the more honest strategic move. They do not claim to give you a deep understanding of the user. They just thoroughly document how the end-to-end service actually works in the real world. In a lot of orgs, that is the thing people need before they are ready to make bigger claims about the user experience.

Document Then Interpret

A lot of teams skip past the documentation step. They start interpreting the experience before they have documented the service that creates it. That mixed-up order of operation causes problems because user experiences do not emerge out of thin air.

They are shaped by how the org operates in very specific ways, including things like:

users getting inconsistent information from different teams or channels
processes feeling disjointed because work moves from one department to another without a clean transition
tasks taking longer than they should because approvals, reviews, or manual steps slow them down
duplicated work happening across teams
unclear ownership over who is responsible for fixing a problem
workarounds people rely on because the official process does not work well
approval flows that add friction or delay
support processes that never show up in a simplified user story

Service blueprints are useful because they force teams to look at those underlying structures directly. Nielsen Norman Group describes blueprinting as a way to discover weaknesses, eliminate redundancy, and coordinate future changes by helping orgs visualize who is doing what and when. That is often the work that needs to happen first. Before a team starts speculating about emotion, it needs to understand the machinery behind the experience.

That is also why service blueprints tend to be more productive, especially in enterprise environments. They give teams a shared picture of the service as it currently operates. They show where departments intersect, where internal work supports user-facing work, and where breakdowns are happening across the system.

Nielsen Norman Group’s service-blueprinting research found that practitioners often use blueprints as a shared source of truth across departments, helping teams build common understanding and better project planning.

That kind of clarity is a big deal. A lot of enterprise problems survive because each team understands only its own slice of the work. The blueprint does not magically solve that, but it gives people a more grounded way to talk about it. It puts the service itself on the table instead of letting the conversation drift into assumptions about the user.

I think that is one reason service blueprints feel less theatrical to me. They are still workshops. They still involve collaboration. They still depend on facilitation. The difference is that the output is tied more directly to what the org is actually doing. That makes the conversation more disciplined. It also makes the next steps more useful.

Ultimately, service blueprints create a more honest sequence for teams that are trying to improve complex experiences. First, document how the service currently works. Then identify where the breakdowns are, where the org lacks clarity, and where user research should go deeper.

That is a much cleaner process than gathering stakeholders in a room and asking them to fill in what they imagine users are thinking.

It also respects the limits of the artifact. A service blueprint does not need to overclaim in order to be useful. It can simply show what is happening, where support structures are helping or failing, and where more evidence is needed. That kind of restraint is valuable. In my experience, teams make better decisions when the artifact in front of them is honest about what it knows and honest about what it does not.

Alignment Is Not Evidence

One of the reasons journey maps keep surviving in this form is that they do produce something people genuinely want. They can create stakeholder alignment, a shared language, and make it easier for a room full of people to discuss the same flow together. I understand the appeal. I understand why teams walk out of those sessions feeling like useful work got done.

The problem is that alignment and evidence are not the same thing, and many times the artifacts produced after a journey-mapping workshop are treated as user data. Rule of thumb: if there are no users in the room, it ain’t user-centered.

I think this is where a lot of UX pros get themselves into trouble. They confuse the visible outputs of a workshop with the quality of the knowledge behind it. Don’t get me wrong, a well-facilitated session, a collaborative artifact, and a room full of engaged stakeholders can be useful. Journey mapping workshops are useful as organizational internal alignment tools, but they are not useful for better understanding real users.

That distinction is worth holding onto because it protects the discipline from drifting into performance. If the artifact makes claims about users, those claims should be grounded in user evidence. If the artifact is documenting how the org works, it should be grounded in operational evidence.

This is also why I have less patience now for the softer defenses of these workshops. People will sometimes say that the point is not accuracy. The point is conversation. Or alignment. Or ideation. I understand what they mean, but that defense falls apart pretty quickly once the artifact starts getting circulated as if it says something true about the user experience.

In real orgs, these things rarely stay contained as innocent workshop exercises. They become reference points that influence priorities. They shape how leaders talk about user problems and become part of the decision-making environment, whether they deserve that role or not. A service blueprint is not immune to misuse, but it is less likely to create that same kind of false legitimacy as a journey map because it is anchored in a narrower and more honest claim.

It is trying to accurately document how the service works. That is a much more defensible job for a collaborative workshop artifact. It stays closer to what a room of stakeholders can actually know, especially when the right people are involved.

I think the distinction between performative UX artifacts and artifacts that more honestly document reality matters for the future of UX work in general. Our value does not come from making polished artifacts that feel strategic. It comes from improving the quality of understanding inside orgs.

Sometimes that means doing direct user research. Sometimes that means documenting the service well enough to know where direct user research is needed next. Both are legitimate. Pretending to know what users think because a workshop produced a good-looking map is not.

Conclusion

The confusion between service blueprints and journey maps has been around for a long time, and I do not think it is going away anytime soon. Journey maps look strategic. They look user-centered. They give people something visible to point at. They give teams a fast way to feel aligned. All of that makes them easy to overvalue, especially in environments where the underlying service is complicated and no one fully understands how all the pieces fit together. That is exactly why I trust them less.

Service blueprints are not doing the same job, and I am not claiming they should replace every other artifact in UX. I am saying something much simpler. In a lot of enterprise settings, they are the more honest place to start. They stay closer to observable reality. They make operational complexity visible. They help teams document what is actually happening before they start making bigger claims about what users think or feel.

If a team wants to understand user journeys, it should study its own systems first.

Have you used service blueprints to bring more clarity to a messy product, service, or internal workflow? If so, comment here or DM me. I’d love to hear where you’ve seen service blueprints help teams build shared understanding, uncover operational gaps, or make smarter decisions in complex environments. Thanks for reading!

Missing Brick

Trevor Calabro — Sat, 28 Mar 2026 20:47:53 GMT

This week, we go silly. Thanks for reading the blog each week. I have 2 larger posts coming soon, so stay tuned.

In the meantime, I found a missing brick in this wall...

Boom, UX!

Most ResearchOps Problems Start with Hand-Offs

Trevor Calabro — Sat, 21 Mar 2026 18:43:31 GMT

Summary: UX research rarely falls apart because the team lacks methods or talent. It falls apart in the hand-offs, where participant data, scheduling, evidence, synthesis, and storytelling get separated from one another and turn good research into fragmented busywork instead of a connected study.

A while back, I was watching a researcher try to get a pretty normal study out the door. Nothing fancy. A handful of participants, a few stakeholder observers, some straightforward user interviews, and a plan to turn the findings around quickly.

This researcher pulled participant information from one system, cleaned it in Excel, scheduled sessions through a third-party tool, hosted the calls in a different platform, tracked incentives in a spreadsheet, downloaded recordings manually, used an LLM to create transcripts, and then started trying to stitch everything back together for analysis. By the time this person got to synthesis, the study already felt fragmented. Not because the research was bad, but because the workflow around it introduced a lot of noise. Sound familiar to anyone else?

That’s when I started thinking that a lot of research pain is not caused by a lack of methods, talent, or rigor. It comes from broken hand-offs between steps within a process.

The Problem

When I tell others this story, many peeps start solutionizing in their heads, and it is usually about how to reduce the number of tools used in the process. My hot take is that I don’t think most UXR teams are suffering because they use too many tools in some abstract sense. In practice, most orgs are always going to have some sort of tech stack. Their email, calendar, and meeting systems have been chosen for them. General customer data probably lives in some CRM that the research team does not control. The problem is not that the workflow spans multiple systems. The problem is that the systems do not behave like a single workflow. It’s the hand-offs between systems that’s the real problem.

Any well-designed user research process needs to work across several tools and still feel coherent in the transitions. But when every transition creates more admin work, more duplication, or more opportunities for something to break, the researcher ends up doing tool-to-tool busywork instead of research.

Recruitment & Outreach

Recruitment is usually where the cracks in a research process tend to show first. Participant data often lives in CRMs, customer databases, spreadsheets, support systems, or a mix of all of them. That part is normal. What is not normal is how much manual effort researchers are often expected to spend just getting that information into usable shape. Exporting files, cleaning fields, checking for duplicates, verifying preferences, re-uploading lists, and trying not to mishandle sensitive information should not be the hidden cost of running a study.

This feels more like admin work wrapped around research than valuable research work in and of itself. With a more strategic process, participant data can come from where it already lives, stay reasonably up to date, and be managed without someone rebuilding the pool every time a new study starts.

A more strategic ResearchOps process saves time, but more importantly, it also reduces the chances of using outdated information or making preventable mistakes with participant records.

And of course, the same thing shows up in outreach. Participants are much more likely to trust and respond to an invitation when it feels legitimate and connected to a real person. We all know that instinctively because we have all ignored emails that looked vague, generic, or slightly off. Yet research teams still end up using awkward workarounds to make outreach happen, especially when the recruitment system and the communication system do not play nicely together. That creates unnecessary friction on both sides. The participant gets less trustworthy communications, and the researcher gets more coordination work. Neither of those helps the study.

And in a world in which users are less likely to engage than ever, even small signs of friction or illegitimacy in the outreach process can lower response rates before the research even has a chance to start.

Scheduling & Incentives

Another administrative task that eats away at our time is scheduling research. Real research scheduling is rarely as simple as finding an open hour on a calendar.

In my experience, you’ll likely be juggling these types of constraints:

coordinating a participant, a moderator, a note taker, and multiple observers at the same time
limiting how many sessions can happen in a single day
building in buffers between interviews so moderators can reset
setting notice periods so nobody wakes up to a surprise session the next morning
protecting stakeholders from booking themselves into parts of the process they should only observe

These things aren’t rare edge cases. This is what real research operations look like. When teams try to force research scheduling into generic workflows that were not built for those realities, they end up compensating with manual effort. That manual effort may look small in isolation, but across multiple studies it adds up fast.

This is the same with incentives. Incentives are one of those things that sound simple until you are the person managing them. Then suddenly you are checking attendance, verifying completion, making sure the right person gets the right amount, tracking who has already been sent something, and following up on exceptions. None of it is intellectually difficult, but all of it takes attention, and it creates yet another opportunity for error in a workflow that already has too many of them.

That matters because research quality is not only about how well you ask questions or how carefully you synthesize patterns. It is also about whether the operational side is stable enough that the researcher can stay focused on the study itself. Every extra tracking step pulls attention away from the work that actually requires judgment.

Method Flexibility

Most mature research teams use a mix of methods. In my opinion, that’s how it should be. Interviews, surveys, usability tests, diary studies, card sorts, and other methods all serve different purposes. The issue is not whether a team uses multiple methods. The issue is whether switching methods breaks the continuity of the study, and that is the part I see even experienced UXR’s miss.

Can the researcher keep the participant details, invites, reminders, session logistics, observers, recordings, and follow-up connected as they move between approaches? Or does every method change force the team to rebuild the operational side from scratch?

I’ve seen a lot of teams quietly accept that rebuilding is normal. In my experience, that is one of the clearest signals that the workflow is not serving the research.

Chains of Evidence Have Momentum

Recording and transcription are other places where this shows up in very obvious ways. A surprising number of teams still move evidence through a chain of disconnected steps. Record here. Download there. Upload somewhere else. Wait for a transcript. Move it again. Tag it later. Clip the useful moments once enough time has passed that half the context is already fading. Technically, that works, but in practice, it slows synthesis down and creates distance between the researcher and the evidence.

When notes, recordings, transcripts, highlights, and clips stay connected, the study remains alive while it is happening. Researchers can start noticing patterns earlier. They can pull supporting moments while the interviews are still fresh. They can move more naturally from observation to synthesis without having to perform three rounds of file management first.

That continuity matters because momentum matters. And this is the thing we researchers bring to the table. The ability to hold all of this user-centered context in our heads as we learn is what will be the key differentiator for our discipline moving forward.

We all know that tech executives are looking to reduce headcount and replace many menial tasks with AI solutions. UX researchers are the human in the loop when it comes to orgs learning about users.

If we concentrate on making these hand-off points a way to carry human context through our development processes, we will have the ultimate level of job security.

A Study is not A Single Deliverable

This is the part I care about most and the main point of this week’s article. Too many UXers still act like the final report or readout is the study. Have you ever heard a team, after they get a polished presentation, say, “Great job, and the work effectively ends there? I know I have, and that has never made much sense to me.

A single study usually creates several layers of material, and those layers serve different purposes:

the source data
the notes and transcripts
the tagged moments that start to show patterns
the individual clips that make a point visible
the highlight reel that helps tell the story quickly
the deeper report for people who need the full thinking
the presentation deck for stakeholders who need the version that travels well

These are different ways of communicating findings from the same study, because we all know that more than half of our job is telling stories with data.

Different stakeholders need different kinds of evidence. Sometimes the raw data tells the story best. Other times, it is the synthesis wrapped in context. And some stakeholders do not really understand the issue until they see a short clip of a participant struggling through the workflow in real time. This is where strategic communication matters most. Good research communication is not about forcing every finding into one format. It is about preserving the connection between these layers so the study can do more than one job.

When those layers get separated from each other, the evidence weakens and the report becomes less reusable. Those powerful clips lose important context, and your readout deck becomes a snapshot in time that feels dated almost immediately after you deliver it. Then the final nail in the coffin is that the raw data disappears into storage, and the team moves on.

But when those layers stay connected, the opposite happens. Research becomes easier to revisit, easier to share, easier to adapt for different audiences, and much more likely to remain useful after the first presentation is over. This is the big idea. The hand-offs are the critical ops moment for strategic UXR workflows.

What Good Looks Like

Okay, so that was the bad news. Most research departments are not struggling because they lack methods, smart researchers, or one more feature in a tool. They are struggling because the process keeps breaking between steps.

I think a lot of UXR teams get distracted by platform feature lists and software sales pages. They start comparing transcription, templates, repositories, incentives, dashboards, and all the other stuff vendors like to compare on a chart on a landing page filled with marketing speak.

Some of those features do matter a lot, but they are not the real standard we should be focusing on. The real standard is much simpler and much more important: does the workflow actually hold together in practice?

A good ResearchOps system is about connecting the building blocks that make up a cradle-to-grave research study. It keeps recruitment connected to outreach. It keeps outreach connected to scheduling. It keeps scheduling connected to sessions. It keeps sessions connected to evidence. It keeps evidence connected to synthesis. And it keeps synthesis connected to all the different outputs a study may need, instead of letting the work collapse into one static artifact that dies in a folder.

That is why I do not think researchers need more software; we just need less process fragmentation and a workflow that keeps the study connected from start to finish. This means everything from the raw data to the synthesized insight to the final stakeholder story. If those things stay tied together, you will inevitably reduce the administrative and cognitive drag, compromising your researchers.

When research turns into a chain of broken hand-offs, teams start losing the things that make the work useful in the first place: clarity, momentum, and time that should have been spent understanding users and helping the org make better decisions. From what I see in the real world, that is often what separates research that gets reused and remembered from research that gets presented once and then fades out over time.

Checklist: How to Fix Broken Hand-Offs

If you want to improve a research process in the real world, do not start by shopping for a new platform. Start by tracing where the study breaks.

The easiest way to do that is to follow one recent project from beginning to end and look for the moments where the researcher had to stop doing research and start managing the process instead. That is usually where the hand-off problem lives.

Here is the checklist I would use:

Map the full study lifecycle
- Write out every step from recruitment to final readout.
- Include where participant data comes from, how outreach happens, how sessions get scheduled, where recordings live, how transcripts get created, how incentives get tracked, and where findings get turned into deliverables.
- If the team cannot map the process clearly, that is already a sign the workflow is too fragmented.
Mark every point where information has to move
- Highlight every export, upload, copy-paste, spreadsheet update, file rename, manual reminder, and hand-entered status check.
- These moments may look small, but they are often where time gets wasted and errors get introduced.
Look for duplicate effort
- Ask where the same information gets recreated in multiple places.
- Common examples are participant status, calendar details, attendance tracking, incentive logs, transcript files, and study metadata.
- If the same fact has to be updated in two or three places, the process is fragile.
Notice where the researcher has to rely on memory
- If the workflow depends on someone remembering who got paid, which participant rescheduled, where the latest transcript lives, or which clip matches which finding, the process is carrying too much invisible risk.
- Good systems do not require researchers to hold the workflow together in their heads.
Find the steps that slow down momentum
- Ask where the study loses energy.
- Does it stall between interview and transcript?
- Does synthesis get delayed because files need to be cleaned up first?
- Does reporting take longer because the clips, notes, and evidence are no longer connected?
- Wherever momentum drops, the hand-off probably needs work.
Separate high-judgment work from low-value admin
- Be honest about which steps actually require research skills and which ones are just operational maintenance.
- Moderating an interview requires judgment.
- Deciding what evidence supports a finding requires judgment.
- Re-entering attendance into a tracking sheet does not.
- Broken hand-offs usually show up where too much researcher time is being spent on low-value coordination work.
Check whether each output stays connected to the evidence
- Look at the final deliverables and ask whether they still point back to the source material.
- Can someone move from the deck to the clip, from the clip to the transcript, and from the transcript to the original study context?
- If not, the study is already starting to decay the moment it gets shared.
Fix the highest-friction hand-off first
- Do not try to redesign the whole process at once.
- Pick the one transition that causes the most wasted time, confusion, or risk.
- In some teams, the recruitment will be for outreach.
- In others, it will be sessions to evidence, or evidence to synthesis.
- Start where the pain is most visible and most repeated.
Use process fixes before platform fixes
- Sometimes the answer is a tool change, but often the first improvement is simpler than that.
- Standardize naming conventions.
- Create one source of truth for participant status.
- Define who owns incentive tracking.
- Set rules for where recordings, transcripts, and clips live.
- Add a clear hand-off owner for each step so the process does not become everyone’s responsibility and no one’s responsibility at the same time.
Measure whether the fix actually worked
- After you change a hand-off, look for real signs of improvement.
- Did scheduling take less time?
- Did researchers spend less effort tracking logistics?
- Did synthesis start sooner?
- Were findings easier to reuse later?
- If the fix did not reduce friction in practice, it was not really a fix.

In my experience, this kind of audit is where a lot of teams uncover the truth about their process.

Conclusion

My main point is that a lot of UX research pain does not come from weak methods, underqualified researchers, or a lack of enough software solutions. It comes from the spaces between steps, where the study gets handed from one system, one format, or one person to the next and loses continuity along the way. That is why I think hand-offs deserve a lot more attention than they usually get. And a more strategic research process is what will make your team’s work easier to trust, easier to reuse, and much more likely to influence decisions over time.

So if your team is feeling buried in admin, struggling to keep momentum, or watching good research disappear after the deck gets presented, I would not start by asking whether you need more tools. I would start by asking where the hand-offs are breaking. From what I have seen, that question usually gets you much closer to the real problem, and a lot closer to a process that actually supports the work.

Have you seen UXR teams treat hand-offs like an afterthought instead of recognizing how much they shape the quality, speed, and usefulness of the work? If so, comment here or DM me. I’d love to hear where you’ve seen broken hand-offs show up in real-world research processes. As always, thanks for reading!

Reframing Accessibility

Trevor Calabro — Sat, 14 Mar 2026 14:10:57 GMT

Summary: This article reframes accessibility as a real-world usability standard. I argue that, in practice, accessibility is not a separate step in the design process, but a proxy for good usability best practices, both upfront and as a second-order effect.

One time, while consulting with a large org, I was reviewing a website with a team that was feeling really, really good about how everything on the site looked. And I totally understood why. The UI design was clean, there was the perfect use of white space, and the typography stack was balanced and well thought out. It had that kind of modern visual quality that makes people in design reviews feel like they are looking at something very well-crafted and high-end.

Then we started walking through the end-user top tasks. We were simply trying to use the thing in the way a real-world user would. That is when the vibe in the room started to change. Important help content was hidden behind hover interactions. Important placeholder text disappeared once we clicked into a field. Some prime nav bar interaction choices behaved differently on desktop than they did on mobile. Information that users clearly needed to compare was tucked inside tabs, which meant they had to rely on memory instead of simply seeing the content side by side. Any of these issues sound familiar?

None of these interaction friction points seemed too bad in isolation to the aesthetic-minded UXers in the room, but once they experienced them back to back in an actual workflow, the flaws became pretty obvious. The design looked clean, partly because the interface was offloading more effort onto the end user. I have thought about that moment a lot over the years because it connects to something I talk about all the time, how soooooo many teams still confuse polished UI with strong UX. If something looks modern, organized, and intentional, people start giving it credit for being intuitive before it has actually earned that credit.

That same confusion shows up all the time in accessibility conversations. A lot of teams still think accessibility is a separate concern, something technical, something specialized, or something you evaluate after the main UX decisions have already been made. From what I have seen, that framing is completely wrong and backwards. Accessibility is often the first place where weak UX becomes impossible to ignore.

Reframing Accessibility and Usability

The main idea I want to make in this article is pretty simple, accessibility is usability under real-world conditions. I do not mean accessibility replaces usability, or vice versa. I mean accessibility can be used as a lever to reveal whether the usability of an interface was actually strong to begin with.

In my experience, when teams talk about usability in the abstract, they often imagine a pretty forgiving or overly narrow scenario. They picture a focused user in a static environment with their full attention on the product. Everything is in this idealized user’s full vision, full dexterity, good memory, a stable device, a standard browser, no time pressure, no interruptions, and no physical or cognitive limitations affecting the interaction. That is not the real world, and I think that distinction matters more than a lot of product people realize.

We all know the real world is much, much messier than that. People are distracted, people are tired, people switch devices, and people forget what they just read. People come back after long gaps, use keyboards instead of mice, rely on screen readers, have low vision, have motor limitations, have temporary injuries, are older, and are trying to complete real tasks in imperfect environments while also dealing with everything else in life.

Once you evaluate an experience against that reality, a lot of so-called “good UX” starts looking like aesthetic-only smoke and mirrors. That is why I think accessibility is better understood as a real-world standard, not a side topic. It gives us a more honest way to judge whether an interface really works.

Quick Level-Setting

When we talk about usability, we are usually talking about whether people can use something easily and successfully. Can they learn it, move through it efficiently, remember how it works, recover from mistakes, and feel reasonably confident while using it? That is the broad frame most UXers already understand.

When we talk about accessibility, we are talking about whether people with disabilities can perceive, operate, understand, and reliably use the same interface. Those two things are obviously related, but I think the relationship is stronger than many teams realize.

So my super basic and obvious theory is that a lot of the practical building blocks of accessible design are also just the building blocks of strong UX.

I have no clue why so many UXers struggle with this concept, but in my experience, they do, which is why I’m writing this today. It’s pretty simple: keep important information visible, make interactions predictable, support multiple ways of navigating, reduce memory burden, write clearly, structure content well, avoid unnecessary complexity, make controls understandable, and ensure the experience holds up across contexts. And furthermore, while I’m on this rant, that should not be perceived as a niche list. That list is the foundation for basic interaction quality.

A Simple Framework I Use

When I explain this to teams, I usually try to simplify it into something practical. The framework I use is this:

4 Signs Your UX Breaks in Real Use

If a design depends on any of these 4 things, it is probably weaker than it looks.

1. It relies on memory

If users need to remember instructions, labels, previous content, hidden options, or what a control used to say, the experience is already asking too much of them. This is one reason I dislike labels inside form fields so much. Once the user starts typing, the label disappears, and now the interface has taken a simple recognition task and turned it into a memory task.

That is not just an accessibility issue. It is a usability issue that becomes even more fragile for users with cognitive load, divided attention, or screen reader needs. The more a design depends on recall instead of recognition, the less forgiving it becomes in the real world.

Left: labels placed inside form fields. Right: labels placed outside form fields.

2. It hides important information

Users should not have to hunt for content that matters. When key information is hidden behind tabs, accordions, tooltips, carousels, or hover-only interactions, the design may look cleaner, but the user now has to do more work to understand the experience.

That extra work does not affect all users equally. It gets highly amplified for people using only the keyboard, assistive tech, smaller screens, or less stable attention. But decades of HCI research have proven that even outside of formal accessibility concerns, it still makes the interaction worse for all users. This is one of those areas where accessible design and usable design are almost impossible to separate.

3. It changes behavior across contexts

The more an experience changes from desktop to mobile, mouse to keyboard, or visual browsing to assistive browsing, the more relearning the user has to do. A lot of people start tasks on one device and finish them on another. They revisit products in different contexts, and they shift between interaction methods depending on the situation.

So when navigation, menus, or control logic behave very differently across those contexts, the experience becomes less trustworthy. That is not just a consistency problem. It is a real-world usability problem because it adds friction exactly when users need stability.

An old Google study found that up to 90% of users move between devices while completing tasks, so inconsistent navigation creates friction fast.

4. It rewards precision instead of clarity

If the interface only works well when someone can hover precisely, click tiny targets, interpret subtle cues, or decode visual minimalism correctly, then it is relying too much on precision and not enough on clarity. Strong UX should not require users to be unusually careful just to succeed.

I see this show up in prime nav bar menu designs all the time. Hover-based navigation, ambiguous click targets, split buttons, overly subtle controls, or menus that ask users to guess what will happen next all create unnecessary fragility. Accessibility simply makes that fragility easier to see, but the weakness was already there.

Taken together, these 4 signs work as a stress test for UX. They help reveal whether an interface is genuinely clear and resilient, or whether it only feels usable when conditions are perfect. The framework is less about catching isolated accessibility issues and more about exposing the deeper design choices that make an experience fragile in the real world.

What This Looks Like in Practice

Once you start using this framework, a lot of design decisions become way easier to discuss upfront. Take content hidden inside a tooltip. The question is not just, “Is this accessible?” The better question is, “Why is this information hidden at all if the user needs it to proceed?”

Take form labels inside fields. The question is not just, “Will a screen reader handle this?” It is also, “Why are we removing visible guidance in a task that already depends on accuracy?” Take radically different mobile navigation. The question is not just, “Can users technically get through it?” It is also, “Why are we making them relearn the system when they change devices?”

This is why I like the reframe so much. It stops accessibility from feeling like a separate audit category and pulls it back into the core UX conversation where it belongs.

Once that happens, teams can start evaluating design decisions in a way that is more grounded in actual use.

Familiar Does Not Mean Boring

Another point worth making here is that accessible design is not about making everything plain or lifeless. It is about making things understandable. I think some teams hear “accessible” and imagine a stripped-down, rigid, or visually uninteresting product. That has not been my experience at all.

Don’t get me wrong, you can still build beautiful interfaces, and you should. You can still build distinctive products that solve real problems in the real world. And you should still make something feel polished and intentional. The difference is that the visual decisions cannot come at the expense of interaction clarity.

The rule of thumb here is that the UXer’s burden is to 1st prioritize making designs accessible, and then, and only then, shift to making them look aesthetically polished.

That is where a lot of UXers get in trouble. They are not really choosing between beauty and accessibility. They are choosing between surface elegance and actual ease of use. Those are not the same thing, and once we start talking about it that way, accessibility stops feeling like a limitation and starts feeling like a design discipline that protects what matters. We, as a discipline, need to stop assessing our interfaces like artwork.

So my argument is this: does the experience still hold up when the user cannot rely on hover, cannot see subtle cues, is using keyboard-only navigation, cannot remember instructions from prior pages, is trying to get something done quickly, switches devices, is distracted, or needs things to be explicit rather than implied? That is a far more honest framing and test of UX quality.

I think that is part of why accessibility work is so valuable beyond simple compliance. It gives teams a better lens for evaluating whether the product is actually usable in the first place.

Accounting for accessibility compliance should be step number 1 in your process. This makes accessibility a proxy for good usability best practices, both upfront and as a second-order effect. Instead of asking whether the interface passes a narrow review, ask whether the experience can stand up to use under less-than-ideal conditions.

Conclusion

Over the years, I have come to think about accessibility less as a separate domain and more as a reality check for usability. It is one of the clearest ways to find out whether an interface was designed for real use or just for a surface-level, smoke-and-mirrors style of design review.

If the experience only seems usable under perfect conditions, then the UX is not nearly vetted enough to move forward. If it falls apart the second someone needs more explicit structure, more visible guidance, more predictable interaction, or more resilient navigation, then those were not edge cases. They were the stress test, so there was no need to test with end users at that point yet. Instead, follow accessibility best practices first, then incorporate usability best practices, and lastly look at aesthetics within those constraints. This is the best order of operation for UXers.

That is the shift I hope more folks make. Not seeing accessibility as a final layer, not seeing it as a side checklist, and not seeing it as something separate from UX. Accessibility is usability. I would much rather see teams treat it as one of the most practical ways to tell whether the experience can survive contact with the real world.

At this point, that is the standard I care about most. I care less about whether the interface looks clean in a static frame and more about whether it still works when real life shows up.

Have you seen teams treat accessibility like a side checklist instead of a basic test of whether the UX actually works? If so, comment here or DM me. I’d love to hear the patterns you’ve seen in the real world. Thanks for the support, everyone!

Behavioral Evidence > Self-Reported Evidence

Trevor Calabro — Sat, 07 Mar 2026 20:48:39 GMT

Summary: Using a real usability test example, this week’s article shows how teams often give too much weight to what users say after the fact and not enough weight to what actually happened during real-world tasks.

Years ago, I ran a moderated usability test on a complex workflow redesign. The test consisted of a handful of top tasks. One of those tasks could have been described as, “This is the core value of the product.” For this test, the participant was a perfect match for the user segment we wanted to learn more about. They understood the domain, and they used the tool we were testing in their day-to-day work. In other words, everything was on the up-and-up. hahahaha

When we reached that one critical task, everything started normally. Then the participant hit the first decision point and hesitated. They clicked into the wrong area, backed out, tried a different path, and started narrating little “wait, what” comments that you only hear when someone is quietly losing confidence. A few minutes later, they were deep into a workaround that looked nothing like the intended path. After some more struggling, the participant asked me, half-jokingly, if the system was supposed to do something that it was not doing. The flow never fully recovered, and they ultimately did not successfully complete the task.

Soon, we had gone through all of the remaining tasks, and I moved into the post-task interview style wrap-up questions. I started that wrap-up section with a pretty simple prompt. “Talk me through how task X went for you.” The participant shrugged and paused as he thought back for a second, then said something like, “Honestly, it was real easy. Pretty intuitive.”

This is the exact phenomenon I’d like to discuss in this week’s article. It is why we must observe what users do and not blindly accept what users say. It is also why eyewitness testimony can be unreliable in court. Most of all, I think this psychological phenomenon is one of the main drivers behind the dilution of user research I see happening in the real world, so I’m hoping this article helps explain the problem and pushes us to start correcting it.

After that usability test I remember sitting there thinking, if that task were truly tied to their job in the real world, the experience would have landed much much differently. Someone whose work depends on completing a task does not casually forget the moment they got blocked right before submission. That person ends up frustrated, escalates to a coworker, searches for documentation, opens a support ticket, or does whatever it takes to get the work done before the deadline hits.

The behavioral record of the session told the full story. Uncertainty, backtracking, and task failure actually happened despite what the participant said at the end. That retrospective perception data sounded nice, but it also contradicted everything we just watched.

And this is where things get uncomfortable. A couple stakeholders latched onto the “real easy and intuitive” quote. The quote fit what they already wanted to believe. It aligned with the story they had been telling themselves about the workflow. It validated their expectations, so it became the main takeaway of the study. Meanwhile, the behavioral evidence was treated like a weird anomaly and was largely dismissed. That kind of misunderstanding is the entire point of this article.

Teams keep giving way too much weight to anecdotal and retrospective feedback, especially when it supports a preconceived conclusion. Confirmation bias does the rest.

Quick Level Setting

Let’s level-set around something the HCI field has understood for decades. When the question is usability, the best evidence comes from observing behavior during task execution.

The closer you get to real tasks, real constraints, and real consequences, the more trustworthy your data becomes. Full stop.

That statement is not a philosophical preference; it’s a real-world one. Products fail in the real world because people cannot complete tasks, cannot recover from errors, cannot find the right thing, cannot understand what the system is doing, or cannot operate the interface with their access needs. Those are behavioral outcomes.

Perception data can still be useful, but it does not carry the same evidentiary weight when it conflicts with what happened on screen. This is why I keep pushing back on the research culture that treats “user feedback” as one big bucket.

The “User Feedback” Trap

A quote from a discovery interview, a post-task sentiment rating, and a screen recording of task failure are all forms of data. Treating them as interchangeable is where teams start making bad decisions. Here is a simple way that I like to think about it.

Behavioral Evidence answers questions like:

Did the user complete the task
Where did they get stuck
What did they misunderstand
What did they miss entirely
What did they do when the interface did not support them

Perception and retrospection answer a different set of questions:

What the user thinks happened
What they remember happening
What they believe they typically do
How they want to describe themselves and their competence
How they feel about the experience after the fact

Again, user perception data is not meaningless. It just has a very specific failure mode. It can sound confident while being wrong, especially when the experience was confusing, stressful, or unfamiliar. That is exactly what happened in the usability test scenario I described above.

The Misunderstanding

In my experience, this confusion happens for mainly 3 extremely predictable reasons:

Perception data is easy to package.
A clean quote looks good on a slide and travels well in an organization. It can be repeated in meetings without needing much context. A short clip of failure, or a detailed behavioral breakdown, requires people to sit with discomfort and accept that the interface did not work.
Perception data often aligns with what stakeholders already want to be true.
That is where confirmation bias turns a single quote into a decision driver. Behavioral evidence is more likely to challenge the story, so it gets treated as noise.
A lot of modern “lean UX” culture has trained teams to over-index on lightweight discovery.
Interview-driven discovery creates a false sense of certainty because it produces coherent narratives quickly. Those narratives often become a substitute for validation, and validation is the part that reveals whether the narrative holds up.

This “lean UX” culture reason is the one that drives me the most nuts because the HCI field is not new.

We have decades of research about how to best evaluate interaction quality. Observed behavior has always been the gold standard that actually works.

Usability testing, accessibility evaluation, and task-based observation exist because they force the interface to prove itself under real conditions. Yet a bunch of lightweight, discovery-only, vibe-forward practices have convinced many teams that they can skip the hard part and still claim they are doing user-centered design.

More Practical Standards

The rule of thumb I wish everyone would adopt is this:

If behavioral evidence and perception evidence conflict, behavioral evidence wins. That does not mean you ignore what the person said. It means you interpret what they said through the lens of what happened.

In the example from my usability test session, the useful interpretation is not “the workflow is easy.” The useful interpretation is “the participant is describing how they want the experience to be remembered, while the interface still created a task-ending failure.”

That reframing matters because it changes what the team does next. The team either fixes the workflow or it ships a broken workflow that only feels successful in a meeting. This weighting problem becomes even more damaging when the topic is accessibility.

Accessibility is not primarily a sentiment topic. It is an interaction and capability topic.

The question is not whether the interface feels intuitive. The question is whether someone can operate it with their access needs, complete the task, and recover when something goes wrong. A screen reader does not care about the user’s post-task optimism. If a keyboard-only user gets stuck in part of the interface, that problem is still real, no matter how nicely they describe the experience later. A missing label does not become usable because the design looks clean. We must all remember the fact that behavioral evaluation reveals these failures early, while they are still fixable.

Where UX Went Wrong

I think the confusion is partly cultural. Some product environments reward speed more than truth and reward alignment more than accuracy. Others reward clean, confident narratives more than messy evidence that creates follow-up work. Once that becomes the incentive structure, teams start valuing research outputs that help move decisions along, even when those outputs are built on weaker evidence. It can turn into a “group think” thing.

That is also how stakeholders accidentally train teams to ignore the most important signals. Positive, simple feedback like “users liked it,” “users said it was easy,” or “the design tested well” creates a sense of closure. It makes it feel like the research did its job and the team can move on. Behavioral evidence does the opposite. It surfaces friction, ambiguity, failure points, and uncomfortable obligations.

So even when nobody is trying to be careless, the org slowly drifts toward the kinds of findings that feel good to present and away from the kinds of findings that force change. Over time, that drift becomes culture. And once it becomes culture, the same mistake repeats itself across teams, products, and years.

That is how you end up with an org that can run “discovery” every quarter and still ship workflows users cannot complete. It is also how PM-centric and aesthetic-centric mindsets quietly reshape the research hierarchy until teams start acting like clean UI and positive quotes are enough to prove good UX.

A Real-World Framework

I have found that stakeholders rarely need or want education about our research methods. They need a simple way to keep evidence categories straight.

Here is the framework I use that has worked wonders in orgs of all different shapes and sizes:

Category A: Outcome evidence

This is the stuff that tells you whether the workflow actually worked.

Task completion or failure
Critical errors and where they happen
Backtracking, hesitation, and wrong-path selection
Time on task when it is meaningful
Moments where the user needs help to proceed
Accessibility outcomes like keyboard operability and screen reader comprehension

Category B: Interpretation evidence

This helps explain why the outcome happened.

What the participant believed the system was doing
What they thought a control meant
What goal they were trying to accomplish in that moment
What information they felt was missing
What they expected to happen next

Category C: Preference and sentiment

This helps you understand taste, comfort, confidence, and perceived value.

“I liked it”
“It feels modern”
“I would use this”
“It was intuitive”
Ratings, NPS-style questions, lightweight satisfaction prompts

The mistake seems to happen in most product-level conversations; teams treat Category C as if it can overrule Category A.

Category C can help influence direction and priorities, but Category A is backed by high-confidence research we can rely on. Once stakeholders buy into that idea, they will usually agree that Category C data can no longer be used to claim success when Category A proves failure. Once you explain it this way, it becomes much much harder for someone to wave a nice quote around like it is proof.

Reframing in the Real World

To me, this reframing is the part that matters most in practice. When a stakeholder grabs onto a quote like “it felt easy” or “that was intuitive,” you need language that calmly redirects the conversation back to the stronger evidence without turning it into a personal disagreement.

The clearest move is to separate perception from outcome. You can say something like, “That comment is useful as perception data, but the task still did not complete, so we should treat this as a usability issue,” or “The quote is worth noting, but it cannot be our main takeaway because the behavioral record shows the workflow actually broke down while in use.” Framing it this way keeps the discussion grounded in evidence quality rather than in who is right.

I think this becomes even easier to explain when you connect it to accessibility. Accessibility already forces teams to be more precise about what counts as valid evidence. A keyboard-only user getting stuck in part of the interface is a behavioral outcome that no one can ignore. Nobody would seriously argue that a participant saying “it felt accessible enough” is strong proof that the experience is actually accessible.

Usability should be treated the same way. A participant saying a flow felt easy or intuitive does not override the fact that they got stuck, failed the task, or needed help to continue. The same weighting rule applies in both cases. When perception and behavior conflict, behavior is the evidence that should carry more weight.

Conclusion

My hope for the future is that teams stop treating behavioral research like an optional upgrade. Behavior is the main evidence type for usability, accessibility, and workflow success, and I’d love to see perception treated as supporting evidence that helps teams interpret and prioritize. When the two conflict, that conflict is itself a finding, and it usually points to a social dynamic, a memory effect, or a mismatch between conceptual clarity and operational execution.

If you are a user researcher, I’m begging you to be more aware of this and to protect this distinction carefully. Do that by making it explicit in your readouts. Label data with the categories I described above, and do not let a quote become the takeaway when the behavioral evidence says something else.

If you are a stakeholder, please resist the temptation to grab the quote that makes you feel better. The job is not to feel better. It’s to ship products that work for real users doing real tasks in the real world. At the end of the day, your users will either complete the tasks they need your products for, or they’ll find a competitor who can do what you cannot.

Have you ever seen this misinterpretation of perception data in your work? If so, comment here or DM me with your stories. I’d love to know whether I’m the only one seeing this. Thanks for reading!

Stop Weaponizing Conversational UX

Trevor Calabro — Sat, 28 Feb 2026 22:14:45 GMT

Summary: Conversational UX is an old framework for designing user-centered interactions, but it often gets watered down into “friendly” sounding copy that justifies upsells, guilt buttons, and other dark patterns. This post aims to reset the idea back to its original intentions and provides a simple tool for testing your own product’s content.

Somewhere along the way, the principles behind “Conversational UX” started to get treated like a license to write sales copy inside interfaces.

You know what I’m talking about. The kind of copywriting that shows up in onboarding tours, upsell modals, paywalls, and error messaging. The kind of copy that tries to sound like a casual friend talking to you, except what it’s saying feels more like the ShamWow guy trying to sell you a drop cloth.

Just looking at this picture, I can almost hear the kind of CTA button copy he would write. “If you hate savings, then click this button.” Hahahaha

If you want to leverage Conversational UX as a framework, you have to go back to its origins in 2017, when Robert J. Moore and Raphael Arar’s Natural Conversation Framework (NCF) model was created. Read more on the Natural Conversation Framework (NCF) here.

This is how I think about their main point. I love it because it’s simple and real-world applicable.

People already know how conversation works in the real world, so we can design interactions that follow those mechanics instead of forcing people to adapt to system logic.

In this week’s post, I want to revisit the original intention of the Conversational UX movement and see if we can right the ship on how it’s been bastardized over the years.

What is Conversational UX?

Conversational UX is a user-centered framework for designing interactions that unfold over time.

Conversational UX consists of:

Turn-taking: the system responds to what a user just did, instead of dumping everything up front. (just-in-time info)
Context: language and choices reflect where the user is in a workflow and what they are trying to do right now.
Repair: when something breaks, the system helps the user recover and keep moving forward.
Shared meaning: labels and terms align to what users already recognize in their domain, not what the system calls things internally.

Conversational UX principles are also great for understanding how to properly use progressive disclosure when designing user flows. I often see progressive disclosure treated as a UI pattern consideration, but if you frame it as a conversational mechanic, the outcomes are usually much more user-centered.

Conversations are inherently user-centered.

For example, you wouldn’t introduce yourself by telling a new acquaintance every single little detail of your life story. You’d go back and forth and respond to their questions as they come up. Proper use of progressive disclosure is the same idea translated into an interface structure. A good rule of thumb is to show people what they need to succeed just in time, and defer the rest until it’s requested or clearly needed.

That’s how I think of Conversational UX. It’s information architecture plus timing plus language that matches the user’s mental model.

How It Gets Weaponized

The weaponization of conversational UX principles often starts when teams shrink the whole idea down to its surface-level, meaning “make it sound conversational.” That oversimplification leads people to treat “conversation” as editorial tone, not content structure. From there, it’s a short leap to assuming Conversational UX supports overly persuasive interface copy. And once you’ve crossed into persuasionville, the slippery slope to dark patterns is right there.

In my experience, I’ve seen more UX practitioners misuse Conversational UX principles to justify dark patterns than any other philosophy.

For example, you’ll often see this in the real world when a website frames an upsell or conversion push as if it’s a two-way conversation. It might appear as a friendly question in a modal, a guided step-by-step prompt, or a pair of buttons that force you to “respond.” But the interaction isn’t centered on the person’s real-world task. It’s centered on what the business wants, like upgrading, turning on tracking, or accepting an offer.

Don’t make a deal with the devil. Be more user-centered.

Let’s look at an example to clarify my point better.

Real World Example

The scenario: Picture a B2B data analytics platform. A user logs in because they want to export last month’s report.

But instead of helping with that task, the product does this:

An onboarding tour starts automatically. It introduces “Workspaces,” “Automations,” “Integrations,” and “Dashboards” before the user has even seen the main interface.
The user immediately skips the onboarding because the content feels irrelevant at that point in their flow. Another modal pops up. It claims to offer a path to an appropriate next step, but it’s really an upsell. The secondary CTA button says something like “No thanks, I don’t care about saving time,” which makes the user hesitate. (And that’s the dark pattern right there.) They eventually click it anyway because they don’t want to pay for the upgrade right now.
The user clicks into the reporting area via a primary navigation link, tries exporting the data they need, and hits an error message that says “Something went wrong.” No explanation. No recovery. No next step.
Completely frustrated, the user goes to settings, thinking they can troubleshoot the problem on their own. The top half of the page is basically a marketing panel for add-ons, and the actual configuration controls needed to fix the data issues are buried.

Do any of those things resonate with you? Have you encountered any of these terrible design patterns? I know I have, and I hate when I encounter them.

None of that is conversational in the NCF sense. It breaks the mechanics that make conversation work.

It does not start with user-centered intent.
It does not respect task-driven sequencing.
It does not support error recovery and repair.
It does not use language to create shared understanding.

This is a monologue, not a conversation and I see it all too often in the real world. The system keeps interrupting the user, and it was most likely justified by a misreading of the basic principles of Conversational UX.

A Quick and Easy Test

Here’s a simple guerrilla-style test I’ve used to see whether the UI language in a product is user-based or system-based, and whether it’s sliding into dark patterns.

Choose the interface you want to test: onboarding tour, a modal, an upsell/paywall moment, an error state, a settings page, etc.
Print the text that is on those screens on paper.
Hand the printouts to a colleague. They will be roleplaying “the system.”
Bring in a representative user, or another colleague if you don’t have access to a user for this quick test, and have them roleplay “the user.”
Give the “user” a task prompt: For example, “Find last month’s report and export it.”
The rule is the “user” can only ask questions out loud like a conversation to finish the task.
Then the “system” can only respond using the words on the paper. No improvising.

You learn everything you need from what happens next. If the system cannot answer basic questions without making up new content or changing the language on the paper, your interface is not carrying its side of the conversation.

If the system keeps changing the subject to upgrades and tours, your interface is not cooperating. Also, take note if the system’s words try to shame the person, you are in dark-pattern territory.

Conclusion

Conversational UX is a design framework for how an interaction unfolds over time, based on how human conversations work in the real world. Turn-taking, context, repair, shared meaning, and progressive disclosure all matter more than a friendly tone.

When UXers oversimplify it to “just make it sound conversational,” they keep the voice but lose the user-centered intent. This is typically how I see persuasion tactics creep into design discussions and how many dark patterns end up in real products.

I hope this post inspires some of you to revisit the Conversational UX framework in your own designs. Thinking in terms of real conversation is a cheat code for user-centered writing and sequencing information.

Have any of you used the Conversational UX framework successfully in the past? Have you also seen it misinterpreted and misused in the real world? If so, comment here or DM me. I’d love to hear about your experiences with this niche topic. Thanks for reading!

5 Analogies for Big UX Concepts

Trevor Calabro — Thu, 19 Feb 2026 15:14:16 GMT

Summary: Over the years, I’ve learned that one of the fastest ways to communicate UX concepts is to borrow examples from the real world, straight out of Don Norman’s The Design of Everyday Things playbook. Here are 5 analogies I use all the time because they help people quickly understand these high-level ideas.

I’ve been accused of overly complicating and intellectualizing UX concepts. So over the years, I’ve tested different ways of explaining things with a goal of sharing ideas with others with the least amount of explanation required. Of course, this isn’t a new way of thinking about UX concepts. Don Norman wrote an entire book about this almost 40 years ago.

In the vein of Don Norman’s The Design of Everyday Things style communication, I’ve decided to share the 5 most useful real-world analogies I use to help other UXers understand some foundational concepts that are often overlooked or misunderstood.

1. Push or Pull Door Handles

For those of you who need a refresher, this one is taken directly from The Design of Everyday Things. This analogy still holds up today. It’s one of the simplest ways to explain affordances and signifiers without sounding like you’re giving a lecture.

Most of us have walked up to a door, grabbed the handle, and pulled, only to realize we were supposed to push. It’s instantly relatable which is why it makes for the perfect analogy. The classic version is the glass door with a handle on both sides. Many aesthetically-minded people love those doors because they look sleek and clean. (The parallel to UX design is crazy, right?) But functionally, they create complete ambiguity when a real human walks up and tries to open them.

If I had a dollar for every time I pulled a push door and looked like an idiot, I’d be rich.

Once you get someone thinking about these common doors, I then hit them with the UX concept:

Affordance = what actions are actually possible in the world because of the object’s properties (a door handle affords pulling, a flat plate affords pushing, a button affords pressing).
Signifier = the perceivable cue that tells you what action to take (a protruding handle is a cue for pulling; a push plate is a cue for pushing; a label like “PUSH” is a cue too).

Unfortunately, I’ve noticed that some more aesthetic-minded UXers have picked up a watered-down, skewed version of this concept secondhand. So “affordances” and “signifiers” become vague buzzwords, and the practical point gets lost.

That point here is simple. Our interface designs should not make users guess what action is possible or what will happen next. When a UI is overly focused on being clean, modern, or minimalist, it often strips away the very cues people rely on. Icon-only buttons, links that look like plain text, controls that look disabled when they aren’t, and unlabeled actions all recreate the same push pull door moment. The user hesitates, makes an error, or backtracks, and then we call it “user error” when it was really a predictable outcome of bad design. If users have to guess, it’s not intuitive.

2. Curb Ramps

Curb ramps on street corners are one of my favorite analogies because they make the case for accessibility without sounding like you’re making a moral argument. They were built so wheelchair users could actually navigate sidewalks and crosswalks. But once you notice them, you start seeing how many other people benefit from them in day-to-day life. A parent pushing a stroller. A delivery person pushing a dolly stacked with boxes. Someone walking with a cane. Someone pulling a suitcase. The examples go on and on.

The positive unintended consequences of basic accessibility improvements are endless.

Accessibility changes rarely only help one group. They usually remove friction that lots of people run into, just in different ways and at different times.

The transfer to UX is pretty direct. Color contrast is not just for low-vision users. It also helps people using their phone in bright sunlight, people with tired eyes, and people trying to scan content quickly. Larger click targets are not just for motor impairments. They also help everyone on a bumpy train, using one hand or rushing. Clear focus states and keyboard navigation are not just for a small segment of users. They are part of building interfaces that work reliably when people are in less-than-ideal conditions.

So when someone frames accessibility as a nice-to-have, I bring them back to curb ramps. We did not build those because someone wanted to be nice. We built them because without them, the system does not work for a portion of the population. And once you build them, you realize you made the system better for almost everyone.

3. Unlabeled Spice Rack

This one is basically the classic recognition vs recall heuristic in physical form. Imagine a spice rack where every spice has been dumped into identical glass jars for a clean, aesthetic look. I can’t tell you how many times I’ve seen this setup on an HGTV show. The interior decorator comes into someone’s kitchen, remodels it, and arranges the spices by color. Really cool idea in theory, until you know, you need to actually cook in your kitchen. Cumin next to ground mustard. Paprika next to chili powder. Garlic powder next to onion powder. Everything looks “clean” and perfectly organized, and yet cooking in that kitchen would be super annoying because now you’re doing memory tests.

Good luck making dinner. Hahahaha.

That is what happens in software when teams confuse “minimal” with “clear.” When interactive UI elements are unlabeled, you’re supposed to learn them through trial and error. Some will argue, just like with the uniform spice rack, that everything looks elegant, therefore it’s good, even delightful. But in the real world, we all know we’d hate that because it forces users to recall what things mean instead of letting them recognize them.

The bottom line is, if you want users to move quickly and confidently through your digital products, make the interface do more of the remembering so the user doesn’t have to.

📝NOTE: I think about this the same way I think about people who organize their bookshelves by the color of the book spines. Sure, it makes for a great photo. But I have a hard time believing anyone actually reads those books, because good luck finding a specific one when everything is color-coded. It’s the sameish problem as the Martha Stewart-style unlabeled, uniform container spice rack. In practice, you’d have to memorize the exact order of everything, then do this weird mental translation from “the thing I need” to “the color it probably is,” and then back again.

4. IKEA Missing Screw

IKEA instructions assume a world that almost never exists.

The sheet shows Step 1, a little diagram with four screws, and a clear message that you will need all four to attach the bracket. Then you look down and you only have three screws. Everything was fine until the exact moment it wasn’t, and now you’re stuck. You can’t continue, you can’t easily backtrack, and the only “next step” is to stop building furniture and start troubleshooting the system.

Missing a critical piece. Now what?

That’s why this analogy works so well for explaining just-in-time information and point-of-need guidance. A lot of teams try to solve usability problems by dumping instructions on people up front. You seen it before, multi-step onboarding tours, long docs, walls of text, and giant process pages. The intention is good, but it assumes users will read, remember, and correctly apply guidance later when it matters. But in the real world, people don’t work that way, they learn in context.

Users need the right information precisely when they hit a decision point, a risk point, or a moment of uncertainty. That’s when the brain is ready to absorb it, because it’s immediately useful.

The UX version of “the missing screw” is all over the place. It’s the form that lets you fill out fifteen fields and only tells you after you hit submit that one of them was required. It’s the workflow that allows an invalid state and only throws an error after you’ve already invested time.

Decades of HCI research have proven that the fix is not “write better instructions.” The fix is to design the workflow so guidance appears at the moment it prevents friction. It’s about contextual guardrails that make the right action obvious and easier than the wrong one. The right info at the wrong time is still the wrong info.

5. Express Lane

I’m sure you’ve seen the “10 items or less” checkout lines at your local grocery store. And of course, someone rolls into that lane with a cart full of groceries, nobody says anything, and everyone waiting in line learns the actual rule. The real-world rule is not 10 items or less. The real-world rule is whatever gets enforced, which in practice often means, “Go ahead, all you Karens and Kevins, do whatever you want!”

The grocery store express lane analogy is one of the fastest ways I know to explain why ResearchOps policies don’t solve UX problems by themselves.

Some UX teams love writing rules like design guidelines, process documents, and governance statements etc. The problem is that a rule without a mechanism is not a solution. It’s a suggestion. And if the system makes it easy to ignore, people will ignore it, especially under time pressure.

That’s why enforcement in product design usually looks like guardrails, not reminders. If a field is required, the system should enforce it. If a workflow has a critical step, the system should prevent you from skipping it. If consistency matters, the design system should be supported by tooling, review gates, and reusable components that make the compliant path the default path.

Otherwise, you end up with the product equivalent of the express lane, where the sign is big, the intent is clear, but the experience still breaks because the system never actually changes behavior.

The Common Thread

The reason I keep coming back to these analogies is that they all expose the same underlying problem, the mismatch between what a system claims to support and what it actually makes easy.

The push/pull door looks elegant but makes people guess. The unlabeled spice rack looks organized but forces memory tests. The IKEA sheet pretends the world is linear and tidy until one missing part collapses the whole flow. The express lane sign claims there’s a rule, but the system is designed in a way that allows the rule to be ignored. Even the curb ramp example, which is the most optimistic of the five, still makes the same point from the opposite direction. When you design for real constraints, the system works better for more people.

In other words, these are not cute stories. They’re small, everyday demonstrations of how humans actually behave. They help people see that “usability” is not taste, and accessibility is not a special case, and process is not a PDF. It’s all just foundational user-centered system design.

And once someone sees that pattern, you usually do not need to argue about it. The conversation shifts. Now you can talk about the product with the same common sense people already apply to doors, sidewalks, kitchens, and grocery stores.

Analogies Playbook

Here’s the simplest way I’ve found to use analogies without making it awkward.

First, pick an analogy that almost everyone has personally experienced. If they have to imagine it, it loses the effect.

Then run a short sequence that makes them do the work of connecting the dots:

Introduce it quickly: “Let me use a quick real-world analogy.”

Ask the recognition question:

“Have you ever pulled a door that was supposed to be pushed?”
“Have you ever tried to cook in a kitchen where nothing is labeled?”
“Have you ever hit a step in instructions where you were missing a part?”

Let them confirm it:

Give them a second to say yes and react. This is the whole point. Now you have shared reality.

Name the mechanism in plain language:

“That’s what happens when the design makes people guess.”
“That’s what happens when the system relies on memory instead of recognition.”
“That’s what happens when guidance shows up too early or too late.”

Transfer it directly to the product:

“And that’s why this button needs a label.”
“And that’s why the validation needs to happen here, not at the end.”
“And that’s why a policy needs an actual guardrail in the workflow.”

If you do it right, the analogy is not the argument. It’s the door you walk through so you can have a normal conversation about behavior, constraints, and predictable failure modes. It gets people out of the mindset of “prove UX to me” and into the mindset of “yeah, obviously we should not make users guess.”

Conclusion

If there’s a theme running through all five of these, it’s that most UX debates aren’t really about UX. They’re about how someone is framing the problem. Analogies are the quickest way I know to reset that framing because they move the conversation out of opinions and into shared, lived experience. Once someone has mentally replayed the push/pull door, or pictured themselves cooking with unlabeled spices, you don’t have to fight as hard for the point. This takes the conversation out of academic theory land and brings it down to earth. Once you’ve found that relatable trigger, you can talk about the product with the same common sense people already apply to doors, sidewalks, kitchens, and grocery stores.

Do you have real-world analogies you use to explain UX ideas to others? If so, drop them in the comments or DM me. I’m always looking for more. As always, thanks for reading.

A Love Letter to UX Research: Part 3

Trevor Calabro — Sat, 14 Feb 2026 20:24:03 GMT

Summary: Every year, I write a stupid love letter to my true love, UX Research. Enjoy!

Most of what I write on this blog is pretty dry and dense, so I try to keep it from reading like an academic paper by doing two things. I use goofy retro illustrations, and every now and then I post something intentionally silly. Writing this blog helps me clarify how I think about UX Research, but I also like having fun with it.

I’ve added links to a bunch of past posts throughout this love letter. If the dumb rhymes nudge you to click a couple and poke around, even better. Either way, I hope you enjoy the poem.

Roses are red,
UXR methods are strict,
If your “insight” is vibes,
I will call it out quick.

Some teams want shortcuts,
A chatbot, a hack,
But real human behavior
Is what most teams lack.

Icons are silent,
They do not explain,
So label those things
Or users will experience pain.

Animations sparkle,
They dance, they insist,
But most of the time
They should not exist.

Your nav is a maze,
Your labels are bad,
It’s not “user error,”
It’s your design that is sad.

And ROI is awkward,
But still we persist,
Because UX work that saves money
Will not be dismissed.

So here’s my confession,
My Valentine truth,
I love you, UX Research,
Because you demand proof.

With all my heart (and a dash of skepticism),

Still, A Love-Struck UX Researcher

Happy Valentine’s Day, everyone!

5 UX Ideas That Often Do More Harm Than Good

Trevor Calabro — Sat, 07 Feb 2026 13:32:14 GMT

Summary: 5 UX ideas that are widely repeated, frequently misunderstood, and often used as shortcuts in design and research decisions. I explain what each idea actually means, how I’ve seen it misapplied in real products, and a practical rule of thumb to help you spot the issue and course-correct quickly.

Every few days, the “UX internetverse” seems to latch onto an old-school, time-tested UX idea and totally misinterpret its meaning. Sometimes that misinterpretation is, interestingly enough, counter to the original intention of the idea in the first place. Despite being backed by 30+ years of HCI research, many of the folks misrepresenting our discipline online seem to be completely unaware that they are doing this. Then those ideas, most of which have some sort of shorthand name, get weaponized and turned into a buzzword of sorts, and they lose their practical meaning.

In this post, I want to highlight five of the most commonly weaponized UX buzzwords and lazy shorthand misinterpretations, and shed light on what I see happening with them in the real world. My hope is that calling out these things will encourage other UXers to recognize them when they crop up in their day-to-day work and then course-correct.

⚠️ Disclaimer: None of the 5 ideas below are inherently bad, and most of them started as genuinely useful attempts to describe how people learn, perceive, and move through digital systems. But the way these ideas get misapplied in practice is exactly how teams end up shipping friction with a straight face, often while believing they are doing user-centered work.

Aesthetic-Usability Effect

The aesthetic-usability effect describes a real phenomenon, which is that users can perceive visually appealing interfaces as easier to use. Still, the critical word is perceive because the effect is more about a bias in perception, not as much a method for increasing ease-of-use. That difference matters a lot once you put a design in front of real users trying to complete real tasks in the real world.

In the real world, I see aesthetically-driven UXers invoke this effect as if it gives them permission to overlook usability concerns. They often seem to think that strong visuals can compensate for interaction problems, unclear information hierarchy, and weak affordances. That flawed logic almost always collapses the moment you run a legit usability test and watch a real user struggle through a basic workflow, no matter how great the UI looks.

Apple’s V1.0 Liquid Glass visual styling is a perfect example of a misunderstanding of the aesthetic-usability effect.

A clean layout, modern style, and pixel-perfect, polished design can absolutely make a product feel more approachable. Still, those things do not magically reduce cognitive load, clarify system state, prevent errors, or help users form accurate mental models within interfaces.

The aesthetic-usability effect is why aesthetics alone so often become an alibi for skipping behavioral research and calling it ‘done’ after a few rounds of preference-driven feedback.

💡 Rule of thumb: Validate usability with task-based testing before investing heavily in visual polish.

User Delight

The term user delight shows up in OKRs, UXR job postings, and product strategy decks so often that it can start to feel like a foundational UX concept. The problem is that teams rarely define what “delight” means, so they default to adding decorative touches on top of a user flow and calling it a day. That’s how non-functional UI elements find their way into an interface even when they don’t improve clarity, speed, or task completion. In fact, most of the time, adding decorative-only elements into your designs has been shown to harm usability and accessibility.

I’m spinning. Aren’t you delighted?

When teams set out to “add delight” without grounding it in interaction best practices, they usually reach for surface-level tools like cheeky microcopy, celebratory animations, and visual polish, even when the underlying task flow is still confusing. That’s how products end up actually being perceived as slow loading, inaccessible, and more cognitively taxing while still being defended as “more delightful.”

A better way to think about delight comes from Bill Scott’s concept of “interesting moments,” which frames delight as an outcome of a system that feels responsive. He describes these moments as well-timed, supportive transitions where users either stay in a flow state or get knocked out of it. In this framing, delight shows up when the system prevents errors, gives timely feedback, maintains continuity, and reduces effort in ways users actually feel during real-world usage.

Bill Scott makes the argument that users don’t consciously notice real delight when they’re mid-task; instead, user delight is experienced as a byproduct of smooth, low-effort, responsive, and predictable systems.

💡 Rule of thumb: Reduce effort before adding anything new by removing steps, consolidating decisions, and eliminating unnecessary confirmations. That’s what’s actually been proven to produce user delight in the real world.

Jakob’s Law

Jakob’s Law is one of the most grounded principles we have because it recognizes that users don’t learn interfaces in isolation; they learn patterns through repeated exposure across the tools they use every day. The practical implication is that leveraging time-tested interaction conventions reduces cognitive load because those conventions align with what users already know how to do.

We know how to make forms that work, yet I see forms like this every day.

The reason Jakob’s Law ends up doing harm is not because the idea is flawed, but because it gets weaponized in design reviews as a rhetorical shield. I see this in the form of retroactive justification, where a UXer proposes an entirely new interaction pattern, gets challenged on usability, and then tries to “prove” its validity by citing a single screenshot from a random, cherry-picked product.

The other common misuse is copying patterns from famous FAANG companies and treating them as universal best practices. This practice ignores the fact that huge ecosystems can train users over time through repeated exposure, while most other products depend on users being able to complete one-off or infrequent tasks quickly, correctly, and without having to learn a new interaction language.

A more responsible way to apply Jakob’s Law is to turn it into a concrete exercise rather than a vague principle: define the user task in plain language, gather multiple examples from similar products serving similar users, and then look for the repeated patterns that users are most likely to have internalized.

Doing it that way shifts the conversation away from personal taste and toward actual user exposure in the real world.

💡 Rule of thumb: Use familiar UI controls and patterns as a first step (standard buttons, menus, layouts, search, labels, etc.) unless you have evidence that users don’t recognize them in your context.

UI Element-Level Animations

UI element-level animations are not inherently bad. When used properly, they can clarify state changes, reinforce cause and effect, and make complex interfaces feel more responsive. In the real world, though, they’re often treated as a default layer of polish. This becomes especially problematic when animations trigger automatically, loop indefinitely, or exist mainly to make an interface feel “modern” instead of helping users understand what’s happening.

Don’t force users to chase your content.

The core issue with animation is that UI motion often competes with the user’s task. When motion isn’t explicitly triggered by a user interaction, it becomes a tax on attention and challenges the user’s comprehension. That’s why autoplaying videos, auto-forwarding carousels, bouncing tooltips, pulsing “new feature” prompts, and scroll-triggered reveals so often cause users to miss critical information. These extraneous animations also tend to increase time on task and cognitive load. Decades of research have proven that users often find these animations to be annoying, distracting, and exhausting.

The accessibility cost is even more serious. Uncontrolled motion can create barriers for users with vestibular sensitivity, attention-related conditions, slower reading speed, non-native language processing needs, motor constraints, and a wide range of cognitive processing differences. Restraint around animations is a usability and inclusion requirement, especially in complex products where users are already juggling high intrinsic cognitive load.

Animations that are genuinely helpful tend to share the same characteristics: they respond to an explicit user action, they communicate something meaningful about system status, they end quickly, and reduce confusion instead of adding it with flare.

💡 Rule of thumb: If an animation isn’t triggered by a user action, remove it unless it communicates essential system status or progress.

Synthetic Users in UX Research

Synthetic users, proxy users, and LLM interview bots are appealing to business folks for the same reason most too-good-to-be-true shortcuts are appealing. They feel fast, clean, and productive. They also avoid the messy parts of real user research, like recruiting, observation, contradiction, and actual human behavior. But the moment teams treat LLM output as user evidence, they are no longer doing research. They are generating plausible language and confusing it for something insightful.

Even with detailed personas and careful prompts, LLMs cannot provide valid findings yet. They are not drawing from lived experience, real constraints, habits, workarounds, social dynamics, emotional stakes, or the real-world context that shapes how people actually behave. That means basic logic tells us they can’t reveal the kinds of unknown unknowns researchers routinely uncover when real users hesitate, misunderstand, mistrust, adapt, and do things that could never have been predicted.

This misunderstanding is especially dangerous because it scales bad research culture. It produces outputs that look like real research artifacts, complete with quotes and themes that slide neatly into decks. At the same time, it often confirms whatever assumptions were embedded in the prompt in the first place. That creates an illusion of learning that’s hard to challenge in meetings because the language sounds coherent and confident.

AI can absolutely support research in legitimate ways. But replacing users with a chatbot collapses the distinction between evidence and imagination.

I predict that once a team gets used to the speed and comfort of synthetic “insights,” the organization drifts further away from human-centered decision-making. And this will be done while still believing and claiming it’s being user-centered.

💡 Rule of thumb: For now, treat Gen AI outputs as simple brainstorming inputs only, and require human user evidence before making product decisions.

Conclusion

All 5 of these ideas have something real behind them. That’s exactly why they’re so easy to repeat and so easy to misuse. The common pattern is that teams turn nuanced concepts into shortcuts. Then they use those shortcuts to justify choices that should have been validated with behavioral evidence, accessibility considerations, and real-world task outcomes.

If you want a safer, research-driven default mode, anchor your UX decisions in task outcomes, predictable interaction patterns, and real human evidence.

Prioritize task completion over surface appeal.
Treat delight as something that emerges from interaction quality, not something you paste on at the end.
Use Jakob’s Law to respect patterns users have already learned, not as a shield for novelty.
Keep animation rare, functional, and under user control.
Don’t blur the line between real participant evidence and AI-generated text without lived experience behind it.

If you agree or disagree, I’d love to hear your take. If you’re seeing any of these ideas get misused on your own teams, I’d also love to hear real-world examples. This stuff shows up differently depending on product context, how often users are in your product, and the kinds of tasks people are actually trying to complete, so I’m sure I have more to learn in this area. Thanks for reading!

UX Book Recommendations

Trevor Calabro — Fri, 30 Jan 2026 15:52:53 GMT

Summary: My obligatory list of recommended UX reading. A simple, grabbed-from-my-desk list of UX books that helped me level up in the real world.

I recently had the privilege of having a conversation with during a Condens-sponsored webinar titled Charting UX Success in a Changing Landscape. During that webinar, I mentioned how much of my upskilling throughout my career came from reading a lot of books. Of course, the Condens moderator, Phillis Chang, asked if I could send a list of those books. Darren, being the consummate professional, already had all of his book recommendations in a blog post, so all he had to do was provide a link. I, on the other hand, had nothing to share. So this is it. This is my recommended reading list.

This list is not comprehensive. In fact, all I did was grab the books that were closest to my work desk, put them on the floor, snapped this picture, and then wrote the list below. I hope some of you find this helpful. Thanks!

📝 NOTE: In no particular order. I listed these in the same order they appear in the photo, starting at the top-left and reading across each row.

Conclusion

That’s it, not a definitive “top 10 list,” just the books I’ve personally leaned on when I needed to get better at my job. If you want to stay relevant in our fast-evolving profession, consider picking up one or two of these that match the kind of projects you’re doing right now and start there.

If you’ve got a book you think belongs on this list, reply and tell me what it is and what it helped you do in practice. Thanks for reading!

The Anatomy of an Input Field (Part 2)

Trevor Calabro — Sat, 24 Jan 2026 14:43:35 GMT

Summary: This is a follow-up to Part 1, where I respond in depth to reader pushback on one of the recommendations I made in last week’s article. I break down why required field indicators aren’t “visual clutter,” and how they reduce errors, reduce memory burdens, and reduce user error in the real-world.

Last week’s article, The Anatomy of an Input Field (Part 1), struck a nerve with some readers, so I wanted to address it in this week’s post as a Part 2. Last week’s post is basically a reference doc I made for a past org, and I shared it because I keep seeing the same input field mistakes show up in UX designs, even though we’ve had established best practices for those for decades now.

📝 NOTE: I recommend reading Part 1 first so you have the context for why I’m doing such a deep dive on an obscure topic.

A few readers DM’d me with some pushback on one specific recommendation in last week’s post:

All Required Fields Must Be Marked With An Indicator (Even when every field in a form is required).

I have had this conversation a lot in my career, and I totally understand why many UXers don’t agree with this best practice recommendation. If you’ve ever looked at a form with a lot of required asterisk indicators in a row, it feels like overkill. But looking at a mockup or prototype is not the same as trying to fill out a form in the real world. So I see why it’s easy to argue that if everything is required, then clearly the user should just assume it’s required. That’s the argument I kept hearing in a nutshell.

So this week’s post is me responding to that disagreement directly, because I don’t think it’s a styling preference. 40+ years worth of HCI research has proven that this tradeoff isn’t about aesthetics. It’s about behavior.

Level Setting

Let’s level-set by describing what we know about how end users actually fill out web forms in the real world. In practice, users experience forms as a step-by-step interaction sequence. They fill out one field at a time, staying focused on the active field, the field’s label, and whatever nearby text helps them make the next micro-decision. They’re not stepping back to admire the overall “cleanliness” of the form. They’re trying to finish the task quickly without hitting validation errors or having to redo anything.

This is what some aesthetic-minded UXers think users do with forms. Spoiler… they don’t.

So when the information users need isn’t right there, just-in-time, they tend to slow down, and make a errors. And then the system ends up cleaning up the mess later with error messages, system warnings, and forced backtracking.

That’s why, as one disgruntled reader put it, these “minor” form best practices like persistent labels and required indicators aren’t nitpicky details. I argue that they’re the difference between a form that is frictionless and a form that feels broken, especially when multiple best-practice breaches start to pile up within a single form.

The Required-Field Problem

Like I said earlier, I think this debate keeps resurfacing because design teams are looking at required-field indicators as a visual problem. Design systems make that even worse, because many UX teams want a single clean rule they can apply everywhere, and the old “All fields are required” instructional text at the top of the form looks great in a static design spec.

The real issue is that required cues need to show up at the moment of decision, not out of context, and only once at the top of the form. That’s why field-level required indicators are a best practice and why UX thinktanks like NN/g recommend them. A red asterisk or the word “Required” next to each label gives users the information exactly when they need it, without forcing them to remember anything. They are perfect just-in-time affordances.

When you remove those affordances and rely on one line of instructional text at the top, you’re asking users to read it, comprehend it, store it in working memory, and apply it perfectly across the whole form. You’ll never guess how that actually works for real users filling out real forms. hahaha

But in the real world, we know that users often skip over instructional text. And even if users do read it, research has shown that many are likely to forget it the further down the form they get. And if they treat even one field like it’s optional, the form fails at submission and turns into an error recovery task. That user error outcome is preventable when the required cue lives next to the label. So, like it or not, research has also shown that only marking optional fields makes forms harder to complete and can create a huge amount of confusion for users who rely on screen reader technology.

The Type 1 vs Type 2 Error Reframe

Type 1 vs Type 2 Errors is the mental model that I use to help other UXers reframe what they think is a clutter issue into a conversation about risks and tradeoffs.

From a straightforward logic and systems thinking standpoint, there are two ways user error can happen when filling out an input field:

Type 1: Over-signaling (low cost)

Type 1 is showing a required indicator on every field, even when everything is required.

The interaction cost and cognitive tax are low. You’re adding a small, familiar signal next to each label that most users process automatically as they move through the form.

Worst case, it adds a bit of visual noise, and even that tends to fade once the user starts working.

Type 2: Under-signaling (high cost)

Type 2 is removing field-level indicators entirely and relying on one line of text at the top.

That has a very different failure mode. If the user misses even one field, submission fails. The interface creates a single point of failure across the entire form, and one mistake blocks completion.

Once you look at it through this lens, the decision becomes about choosing the best tradeoff by picking the least harmful failure mode.

My main argument is that a tiny amount of repeated visual information is a low price to pay to avoid a task-ending error.

The Working Memory Problem

This is the part that rarely gets discussed in design system meetings, and it’s the part that can have the biggest impact across an org.

Like I said earlier, in the solution where you put a single line of text at the top that says “All fields are required,” you’ve created a memory task. In the real world we know that most users are thinking about the content they’re entering. They’re checking an account number, typing an address, flipping over to an email to copy a reference ID, or trying to remember which version of a date format your system expects. Their mental space is already being used for something.

This is why a field-level indicator removes that burden. The user doesn’t have to store anything. They get the information at the moment they need it, while their eyes are already on the label. We have decades of eye-tracking data confirming that this is how users actually behave. And this is where the “asterisks create cognitive load” argument starts to collapse.

The top of form instructional text creates cognitive load by forcing the active recall mechanism in users’ brains. The repeated asterisk creates almost no memory load at all because it’s recognized instantly during scanning. If you’ve watched enough usability sessions, you’ve seen this play out. People don’t pause and deeply process an asterisk. They just keep moving because the form is giving them what they need.

The “People Don’t Read” Problem

Whenever this topic comes up, someone usually says, “Well, we’ll write clear instructions at the top.” That sounds responsible but it assumes that users will actually notice and read the extra text.

In practice, users treat most explanatory text as background noise until the moment it proves useful. They don’t show up to a form with the mindset of reading documentation. Decades of research have proven that users start entering information and respond to what the interface tells them in the moment.

Please, why won’t anyone read me?

There’s a reason usability researchers have repeated the “eyes are where the cursor is” idea for so long. You can watch it happen. Users tend to look at the label, look at the input control, type the value, and move on. Their attention stays anchored to whatever they are actively doing, and the top-of-form instructions solution sit outside that flow.

And if the user misses reading the text entirely, the interface has no backup plan. The system waits until the end of the task to reveal the consequences, usually through an error message that forces the user into a hunt for whatever they missed.

Why This Gets Misunderstood

I don’t think this misunderstanding sticks around because designers are careless or inexperienced. I think it sticks around because the required fields debate gets evaluated through a visual lens first.

Unfortunately, the standard asterisk affordance is often misunderstood and treated like decoration. A form full of them feels busy. Busy gets equated with cognitive load. Cognitive load gets equated with user confusion. So teams assume they’re helping users by removing the asterisk indicators altogether.

That line of thinking sounds plausible in a design review because a design review is a static environment. Everyone is staring at the interface as a layout. Nobody is actually trying to complete a task while juggling distractions, context switches, and partial attention.

Design systems also push teams toward global rules that can be applied everywhere. That’s part of their value. Consistency keeps products predictable and reduces decision fatigue for builders. The downside is that global rules can start optimizing for what looks clean in documentation instead of what performs well during real interactions.

The final reason this is easy to miss is that the harm of the error shows up late in the user’s journey. The user doesn’t get punished at the beginning of the form, they get punished at submission. That’s far enough away from the original design choice that people forget what caused it in the first place. Then the team sees the error state, shrugs, and says, “Validation will catch it.” Validation does catch it. It catches it after the user has already done the work and already believes they’re finished. This is not user-centric thinking.

Recommended Standard

If a design system is going to set rules for forms, I argue it should standardize the part that prevents user failure.

Baseline Rule

Required fields get a required indicator at the field label level
That means each label carries the signal, right where the user is about to make a decision. It keeps the form consistent, predictable, and easy to scan. It also prevents the whole form from becoming a memory test.

Supporting Rules

If all fields are required, still mark them
You can keep the little line of helper text at the top if you want but it can’t be the only signal. Users are likely to miss it. (Even when they do read it, users tend to forget instructions once they start typing.)
If there are optional fields, label them explicitly as optional
This only applies when some fields are required and others aren’t. In mixed forms, don’t make users guess which fields they can safely skip. Add “(Optional)” right in the label next to the optional fields. It removes hesitation, reduces second-guessing, and prevents users from treating optional questions like required ones.

Keep it consistent. Same indicator. Same placement.
(Same meaning across products as well.) If a design system is doing its job, nobody has to relearn how required fields work in a different workflow.

🚨 IMPORTANT: This rule also needs to be accessible by default. A red asterisk alone is not enough. Pair it with programmatic required state so screen readers announce it, and make sure the required indicator is visible even for users who struggle with color perception.

Simple 2 Step Fix

Here are the 2 steps I walk teams through to help frame this issue around outcomes and reduce the tendency to over-index on visuals.

Step 1: Identify the failure mode by asking questions

Walk your team through these series of questions:

What happens if a user misses one field?
Does the system block submission?
Does it trigger an error that forces them to hunt for what they missed?
Does it send them back through the form with no clear guidance?

If the answer is yes to any of that, point out that the cost of getting this wrong is high.

Step 2: Decide what you’re optimizing for

Establish the context that some UI default rulesets are optimizing for visual cleanliness, while others optimize for task completion. Then point out that you can’t optimize for both equally, and a tradeoff needs to be made.

Once you’ve made that point, have your team decide on what they believe is more critical: the user’s overall perception of the form, or the user’s ability to fill it out quickly and accurately on their first attempt. Use the failure mode framework from above to illustrate this point if necessary.

That’s it. That right there is usually enough to get teams aligned on this user-centered, research-backed best practice.

💡 Key Takeaway: These 2 steps are the quickest way I’ve found to influence teams to think critically and adopt this best practice without spending too much time debating, educating, or convincing. This approach allows individuals to come to their own conclusions on that matter in the quickest way possible.

Conclusion

This required fields debate keeps coming up, even though the research has been clear for a long time now. Here’s what we know is most likely to be true:

Users fill out forms one field at a time, and required indicators work because they show up right where the decision happens. A single line of helper text at the top is easy to miss, easy to forget, and the worse tradeoff decision when it leads to a submission error at the end. And if you’re building a design system, standardize field-level required indicators, make them accessible, and keep them consistent across products.

If you’ve stuck it through to the end of this week’s post, give yourself a hand. I now deem you a bona fide UX dork. Going this deep in the weeds on one specific UI component is a weird thing to do, I know, but I think an exercise like this can be beneficial across a huge number of UX decisions. DM me if you found the tactics and arguments in this article convincing, and if you think the process is transferable to other UI elements. Thanks again for reading!

The Anatomy of an Input Field (Part 1)

Trevor Calabro — Sat, 17 Jan 2026 20:12:39 GMT

Summary: Input fields seem simple, but small decisions around labels, placeholders, and help text can cause usability problems. This post shares a real internal reference document and explains how input fields work best in the real world, not just in design specs.

I was talking with a senior UXer the other day about best practices for labeling input fields and was honestly surprised by how little they knew about the input control. That conversation sent me digging through my Dropbox, where I found an old Anatomy of an Input Field document I had created for an organization back in the day. That conversation prompted me to share that document here in this week’s post.

ℹ️ Disclaimer: This document was created for an org. that used the MUI as one of its default design systems. Because of that, each example shows the ideal best practice first, followed by the closest you can reasonably get with MUI.

The Document

UI Controls: Input Fields

At {Insert Company Name} we have 2 different design patterns for input fields:

Standard style (on the left below)
MUI style (on the right below)

⚠️ Important Note About MUI
Avoid using the Floating Label design pattern that is available in MUI. (the pattern pictured below)
Floating Label: The label text itself moves to the top of the input field when selected.
Floating input labels are proven to create major usability and accessibility issues, so we don’t use them. Here’s why:
Input fields with text in them are less noticeable. Users often assume there’s already a default value entered in the field, which can lead to errors.
Many browsers and assistive technologies don’t reliably read placeholder text. That makes floating labels problematic for accessibility compliance.
Quote From NN/g: “Ultimately, floating labels do offer a better user experience than the label as a placeholder. But if you have the screen space, placing the label and hint outside the field is still the best way to go.” Learn more about the harms of floating labels here.

Input Field Anatomy

Asterisk (*) - Indicates a required field. All required fields must have an asterisk. Read this NN/g article to find out why. The asterisk should be on the left of your labels, have a space added before the label, and be in a color that stands out, like red.
Label - The word(s) above the UI control describing the user’s expected input. Good labels are explicit and succinct. They allow users to understand what the input field is for without having to gather more information. All input fields must have a label.
Optional Indicator - Indicates a non-required field. Only use the optional indicator when a mix of required and non-required fields in a form becomes confusing. The optional indicator should be on the right of your labels, in parenthesis, and have a space added after the label.
Explanatory Text - An optional element used to further explain an input field’s purpose when a label is not enough by itself. This text should be context-specific and user-centered. (Explanatory text should be visible without requiring user interaction. For example, do not hide explanatory text behind an “i” icon or within a tooltip.)
Input Field Control - Standard UI control allowing users to type into the system. 40+ years of research has proven users understand how to interact with a standard input field just by seeing it. (It’s an affordance in and of itself. No placeholder text needed.)
Placeholder Text - Instruction or help text inserted within the input field itself. Placeholder text is usually grayed out and sometimes italicized.
1. ⚠️ Warning: The rule-of-thumb is to never use placeholder text. In a vast majority of cases, placeholder text is very very bad for users. Read this NN/g article to learn why placeholder text is typically harmful to usability.
System Help Text - An optional element used to communicate system-related requirements or instructions to users. Examples include field requirements, data-related warnings, and just-in-time system status notifications. System help text should always appear last, at the bottom of an input field (including below any explanatory text in the MUI style).

Real-World Examples

✅ Ideal Standard Style: Simple Example

✅ Ideal MUI Style: Simple Example

❌ Difficult for Users: Simple Example

✅ Ideal Standard Style: Complex Example

✅ Ideal MUI Style: Complex Example

❌ Difficult for Users: Complex Example

Bonus: Auto-Formatting Fields

Look for opportunities to implement auto-formatting. Unlike placeholder text, auto-formatting makes it easier for users to validate information as they go. For example, it’s easier to validate a phone number when it’s displayed in standard groupings rather than as a long string of numbers.

Auto-formatting can also guide users during data entry and help them avoid mistakes. For example, once you start typing a ZIP code, it becomes clear that you only need to enter five digits.

Conclusion

I hope you find this document helpful even if you don’t use MUI.

Here’s the data-based TL;DR:

All Input Fields Need A Label
Labels Must Always Be Visible And Persistent
All Required Fields Must Be Marked With An Indicator (Even when every field in a form is required).
- 📝 A Note On Visual Clutter: Many argue that labeling every field with a required indicator creates unnecessary visual clutter, causing cognitive load. Although this is true, decades of research have shown that the better of two evils is to use the required indicator on every single field within a form, as opposed to the alternatives. For example, just putting a single line of text at the top that says all fields are required. It’s a type 1 error vs. type 2 error tradeoff. Although showing all required indicators does create visual clutter, it’s better to be explicit than to have a design that is more likely to create false positive errors (users thinking an indicator-less input field is optional and having to go back and fix it after submitting causes a form error).
  We have decades’ worth of research that basically says users’ eyes are where the cursor is, and they’re doing one mini-task at a time while in a form. Because of this, the solution of a global statement at the top of a form saying all fields are required is likely to get missed and forces users to keep that information in their working memory, which has been shown to be worse than the cognitive load tax placed on users when interacting with many single fields, one at a time, as recommended here.
  Read more about this recommendation in a follow-up article I wrote titled The Anatomy of an Input Field (Part 2).
An Asterisk Is A Widely Understood Indicator For Required Fields
“Optional” Indicators Should Only Be Used When Required And Optional Fields Are Mixed
Placeholder Text Should Almost Never Be Used
Floating Labels Create Usability And Accessibility Issues And Should Almost Never Be Used
System Help Text Should Appear Below The Field If Possible
Input Controls Can Genuinely Help Users When Auto-Formatting Is Used

None of this is new research, and that’s kind of the point. Input fields have been studied for decades, yet teams still redesign them as if the basics are up for debate. Most of the problems I see in forms today don’t come from lack of creativity. They come from ignoring well-established interaction patterns in favor of aesthetic-only arguments or design system convenience.

If this document does anything, I hope it gives you a concrete reference you can point to when these discussions come up. Input fields aren’t a place to experiment. They’re a place to reduce friction, prevent errors, and let users move quickly through forms.

Thanks for reading! If you’ve had to argue about labels, placeholders, or floating fields on your own team, I’d be curious to hear how it played out. DM me or comment here with your own experiences.

Stop Weaponizing Jakob’s Law

Trevor Calabro — Sat, 10 Jan 2026 13:35:31 GMT

Summary: Jakob’s Law is meant to help UXers design around the way users already think, yet it is often misused to justify bad or overly fashionable designs. This article explains what the law actually means, how it gets twisted in practice, and offers a concrete way to apply it that stays grounded in real user behavior.

Over the past 20+ years of working in UX, I have watched a very specific weird thing play out again and again. Aesthetically minded UX designers often take Jakob’s Law, bend it just enough to fit a design they already like, and then use that warped version of the principle to justify designs that break usability best practices. I have come to think of this as the weaponization of Jakob’s Law.

What makes this especially frustrating is that Jakob’s Law is actually one of the most grounded and practical ideas in UX. It is meant to protect users from unnecessary complexity, not to give UX charlatans cover for playing around with bad ideas. In this article, I want to go back to what Jakob’s Law actually says, explain the way I have always interpreted it, and share a way to spot when it is being misused so that teams can course-correct without turning the conversation into a fight.

Jakob’s Law Refresher

This is Jakob’s Law as defined by Jakob Nielsen himself on the NN/g website:

Jakob’s Law of the Web User Experience: Users spend most of their time on other sites. Thus, anything that is a convention and used on the majority of other sites will be burned into the users’ brains and you can only deviate from it on pain of major usability problems.

In plain language, it is a reminder that people do not learn how to use software by studying each interface in isolation. They build their understanding of interfaces by moving through dozens of apps and sites every day, slowly forming mental models about how things tend to work.

The way I think of it is much simpler. Just don’t reinvent the wheel.

Your users come to your product carrying years of experience with other digital tools. They already know what standard UI controls are supposed to look like, what standard menus do, how standard UI controls behave, and how basic navigation elements usually work. Jakob’s Law is telling us we might as well leverage that existing knowledge in order to make our products more usable by default.

When teams follow Jakob’s Law in this spirit, they reduce cognitive load and make products feel easier to use because the interface lines up with patterns people have already absorbed from the rest of the world.

Users are not standing back, looking at their computer screens like a painting in a gallery, and saying themselves, wow, look at how intuitive this looks. Instead, we know that their eyes are likely where their cursor is, and they’re just trying to get some tasks done quickly and easily. A positive unintended consequence of following Jakob’s Law properly is that you avoid all that nonsense.

Intuitive interaction design isn’t static artwork.

How Jakob’s Law Is Weaponized

On the surface, Jakob’s Law sounds so obvious that it feels almost impossible to misuse, yet I have seen it twisted in hundreds of design reviews. The pattern usually shows up in one of two ways.

Bad Pattern 1

The first is what I think of as retroactive justification. A UX designer or a team comes up with a solution they find appealing, whether that is a new interaction, a stripped-down control, or a novel layout. Once someone raises a usability concern, the team starts searching for any example on the internet that looks vaguely similar. As soon as they find one, Jakob’s Law gets invoked as if that single example somehow proves that users are already familiar with the pattern.

For example, I once worked with a team that introduced hidden controls into a dense data table so the interface would look “cleaner.” When users struggled to discover those controls in early testing, someone produced a screenshot from a niche analytics tool that did something similar and claimed that Jakob’s Law justified the choice. What was missing from that argument was any serious look at how often users encounter that pattern across the kinds of tools they actually use.

💡 Key Take Away: One isolated example does not create a mental model, yet Jakob’s Law is often being used as if it did.

Bad Pattern 2

The second and even more common misuse happens when teams copy something from a large consumer product and treat it as a universal best practice. Google is the example that comes up most often. For example, Google products use many icon-only buttons with no labels, so designers will propose unlabeled buttons in a completely different context and then argue that Google has tested it and therefore it must be good UX.

What that line of reasoning ignores is that Google operates under a very different set of conditions than most companies. Their value in the market comes from being ubiquitous. People use Gmail, Calendar, Docs, Search, and many other Google products constantly, which gives Google the ability to introduce new patterns and force users to gradually learn them through repeated exposure across their ecosystem, even when they break common UX best practices.

Most products do not have that advantage. A ride-sharing app, a banking app, or an enterprise tool depends on people being able to complete one-off and infrequent tasks quickly and without confusion. When someone gets stuck in those experiences, they often leave and try a competitor. Decades of usability research have shown that small points of friction can have an outsized impact on whether people stick with a product or abandon it.

💡 Key Take Away: Treating Google, or any other large tech platform, as a model for making design decisions creates a dangerous blind spot because it assumes that your users will invest the same time and patience in learning your interface that they do in those environments.

In the real world, very few products have that kind of margin for error or can afford usability standards as poor as Google’s.

How To Not Fall Victim

The most reliable way I have found to keep Jakob’s Law from being misused is to turn it into a very specific design exercise instead of a vague principle that people can wave around in meetings.

When someone wants to use Jakob’s Law to justify a design decision, I ask them to do three things.

Step 1: Define what the interface is actually doing in plain terms

Not what the feature is called internally, but what the user is trying to accomplish. For example, “select a time for a ride,” “filter a list of transactions,” or “navigate between sections of an account.” This matters because Jakob’s Law applies to tasks, not to brand names. If you cannot describe the user’s goal in a simple way, you are not ready to claim that a familiar pattern exists.

Step 2: Collect examples from at least five products that solve the same kind of problem for similar users

If you are working on a finance app, that means other finance apps. If you are working on a logistics tool, that means other logistics tools. Screenshots from a popular interface only count if they are actually doing the same kind of work your product does. This step forces the conversation out of personal preference and into what users are actually exposed to in the real-world.

Step 3: Lay those examples side by side and look for what repeats

Do most of them use labeled buttons? Do they all put filters in the same place? Do they present options in a fixed, predictable layout, or does the layout change based on context in a way users have to learn? The patterns that show up again and again are the ones users are most likely to have internalized. Those are the patterns Jakob’s Law is pointing you toward.

If the design being proposed lines up with what you see across those examples, then Jakob’s Law probably supports it. If it only matches one or two cherry-picked interfaces, then what you have is a novel design idea, not a familiar one, and it should be treated as something that needs validation through testing rather than defended as a known best practice.

I have used this exact process in design reviews many times, and it changes the tone of the room.

With this context, people magically stop arguing about whether something looks cool and start talking about what users already know how to do.

That shift alone prevents most of the misuse, because Jakob’s Law no longer belongs to whoever can find the flashiest example. It belongs to the collective experience of the users you are designing for.

Conclusion

Here is the way I think about Jakob’s Law after watching it get misused for so long. It is meant to be a user-centered principle that helps teams respect the knowledge users bring with them into a product. When it gets reduced to a way to defend a favorite design or to copy a big tech company without considering context, it stops serving that purpose.

Strong UX work starts from shared mental models and proven patterns, especially in products where users have little patience for confusion.

Jakob’s Law is at its best when it guides teams toward those patterns and keeps them grounded in how people actually use technology day to day.

Thanks for reading! If this connects with something you have seen on your own teams, I would love to hear about it, and I hope it gives you a few new ways to push for design decisions that truly respect how users learn and work.

2025 in Review

Trevor Calabro — Wed, 31 Dec 2025 14:05:59 GMT

Summary: 2025’s most read articles, topic trends, and predictions for 2026.

As 2025 comes to a close, I’m happy to report that UX Research in the Wild’s weekly blog posts are still cookin’. This year pushed me to write more from direct experience, focusing on what consistently works and what quietly breaks down in day-to-day UX practice.

Looking ahead to 2026, I’m feeling even more optimistic than last year at this time. 2025 was filled with reframing old ideas, sharing tools for the real world, and some wild off-the-cuff rants. Here are some 2025 highlights and a look at what might be coming up in 2026.

Article Groupings

I saw some patterns in this year’s posts that I want to share here. The most growth and success I saw in reader engagement was around these 3 groupings:

Group #1: Thought Pieces

This list is full of articles that explore broader ideas about the UX profession. Let’s call these “opinionated reflections” I’ve had over the last year while deep in the trenches of real-world UX work. Some of these are rants, some are critiques, and all are meant to challenge how we think about our work.

Every Icon Needs a Label
Weaponized Institutional Knowledge in UX
Why I Stay an IC
Bad UI Patterns Don’t Need Checklists
Most UI Animations Shouldn’t Exist
The Dangerous Appeal of Fake AI Users
Usability Tests vs. Concept Tests
Apple Chose Aesthetics Over Access, Again
Why Your Navigation Stinks
Users Don’t Care About Your Figma File
The Problem With Split Buttons
UX Is Thankless and That’s a Good Thing
Research Questions Aren’t AI Prompts

Group #2: Free Tools

These 11 articles share free UX tools I built and provided throughout 2025 to support UX work in the real world. Each tool was created to solve a specific, practical problem I kept seeing teams struggle with in their day-to-day work. I hope you find something here you can put into use in 2026.

Group #3: The Reframing Series

This final list is articles that start with UXR things we already know, but I put a new spin on them. I hope these help UXers better navigate doing good UX work in the real world. I encourage you to take another look at a few of these and see whether a small shift in perspective can make a big difference for your career in the new year.

Reframing Interaction Design Basics
Reframing Error Bars
Rethinking User Delight
Rethinking Correlation
UX Research Debriefs Reframed
Reframing User Research Plans
Reframing Dark Patterns: 2025 Edition

2026 Predictions

Now, for the tradition of me making ill-thought-out predictions for the upcoming year. Hahahaha. Without further ado, here are my thoughts for 2026, a few predictions I’ve been thinking about lately:

📝 NOTE: Check out last year’s predictions here to see what I got wrong and what I got right. After my own assessment, I think I got about 8.5/10 correct. (1 flat-out wrong and 1 partially right. Hahahaha.) Check it out and tell me what you think.

Senior UXRs will be valued more for their judgment - By the end of 2026, the strongest researchers will be hired less for what methods they can run and more for what they can stop. Saying no, slowing teams down, and calling out weak logic will become core expectations of senior roles. This will make the job harder, not easier, and far more important.
Calculating the ROI of UX will become a must-have - It is not inherently a UX researcher’s job to build financial models, but it sits squarely within our strengths. We already connect behavior, outcomes, and decisions across teams, which puts us in a rare position to translate research impact into something the business actually understands. In 2026, the senior researchers who can clearly show how UX work changes cost, risk, or revenue will have far more influence than those who only report research insights.
Synthetic users will quietly fall out of favor - After a year of LLMs pretending to be users, orgs will start to recognize that simulated conversations are not a substitute for real human behavior. What looks like insight is often just automated bias confirmation, reinforcing existing assumptions while skipping observation, friction, and context. By late 2026, using AI proxy users will start to feel embarrassing in serious research orgs.
UX maturity will split cleanly into 2 camps - Companies will increasingly fall into either system-driven UX orgs or vibes-driven UX orgs. The gap between these two approaches will become impossible to ignore. One group will likely be able to explain decisions, tradeoffs, and ROI. The other will keep shipping confident-looking products that underperform once they meet real-world market conditions.
UXRs will spend less time running studies and more time fixing inputs - The best researchers will increasingly be pulled upstream to define questions, success criteria, and evidence standards before any research happens. This work will be less visible and harder to explain, but wayyyyy more valuable. UXers who skip this step will keep getting fast answers to the wrong problems.
Heuristic reviews will regain credibility as a senior skill - As teams get tired of expensive studies answering obvious questions, heuristic analysis will quietly creep back into favor. I’m talking expert-driven evaluations grounded in task flow and real-world context. Less mature teams will still underestimate heuristic analysis, but don’t worry, senior leaders will likely keep relying on them once they see the impact they have in action.
User “delight” will continue to be misunderstood - The word “delight” will still be showing up everywhere, and most teams will again confuse aesthetics with actual user benefit. This will lead to more bad animation, less proper labeling, and ultimately more user friction. But the small number of teams that understand what user delight really is will outperform the rest.
UX research ops will matter more than ever - Orgs will likely slowly start to realize that one great researcher cannot fix a broken system. The teams that improve will invest in templates, decision logs, evidence standards, and repeatable workflows. The ones that do not will keep burning out their strongest people.
Accessibility will stop being framed as a checklist - I think it’s inevitable that teams will start talking about accessibility in terms of failure modes, legal exposure, and task breakdowns rather than WCAG checklist items. This shift will make accessibility less “optional” and more operational. It will also expose how little many teams actually understand about real user constraints.
UX research reporting will get shorter and sharper - Long decks will be replaced by more concise readouts, shared docs, and short video clips, and they will all include real-world recommendations. Stakeholders will not suddenly fall in love with user research, but they will tolerate it more when it is clearly scoped and obviously impactful to the bottom line. User researchers who can’t summarize impact in plain language and do so with a clear point of view will struggle in 2026.

What do you think of these predictions? Agree, disagree, or have a different take? Drop a comment below or send me a DM to keep the discussion going.

Conclusion

2025 was a year of heads-down UX work in the real world for UX Research in the Wild. A lot of what I wrote came directly from patterns I kept seeing across teams, products, and orgs, both the stuff that works and the stuff that keeps breaking down. My goal this year was not to chase trends, but to document what actually holds up when UX meets real-world constraints and business pressure. I hope you found some of my thoughts helpful in 2025.

Thank you for following along this year! I’m looking forward to sharing more about the UX topics that have been popping up in my day-to-day work. Wishing you a happy holiday season and a user-centered, insightful 2026!

UX Research in the Wild

How Primary Nav Bars Should Work

📌 2 Ways to Use This Document

The Purpose of This Guide

2. Core Principles

2.1 Use clear information scent

2.2 Support recognition over recall

2.3 Maintain consistent interaction behavior

2.4 Keep the hierarchy as flat as practical

3. Primary Navigation Anatomy

3.1 Navigation landmark

Primary

3.2 Navigation list

2. Menu item

3.4 Stronger code example

Primary

4. Information Architecture Standards

4.1 Parent-child relationships

4.2 Terminal nodes

4.3 Parent landing pages

4.4 Duplicate destinations

4.5 Child item grouping

5. Navigation Labeling Standards

5.1 Label clarity

5.2 Label consistency

5.3 Label differentiation

5.4 Icon labels

6. Desktop Primary Navigation Behavior

6.1 Opening menus

6.2 Hover behavior

6.3 Hover out behavior

6.4 Menu dismissal

6.5 Animation timing

6.6 Motion preferences and reduced motion

7. Dropdown Menu and Mega Menu Behavior

7.1 Dropdown indicators

7.2 Open state

7.3 Closed state

7.4 Esc key behavior

7.5 Focus behavior

7.6 Mega menu layout

7.7 Current page inside a dropdown or mega menu

8. Mobile Primary Navigation Behavior

8.1 Menu control

8.2 Opening and closing mobile navigation

8.3 No split-button behavior

8.4 Parent category with landing page

8.5 Accordion behavior

8.6 Mobile current page indication

9. Keyboard Interaction Requirements

9.1 Tab order

9.2 Keyboard commands

9.3 Focused state

9.4 Focus management

10. Cursor Interaction Requirements

10.1 Hover / over state

10.2 Hover out

10.3 Activate outside

10.4 Cursor movement

10.5 Target size

11. Interaction States

11.1 Default state

11.2 Hover / over state

11.3 Focused state

11.4 Active / pressed state

11.5 Current page state

11.6 Selected state

11.7 Expanded state

11.8 Collapsed state

11.9 Disabled state

11.10 Combined interaction states

12. Accessibility Requirements

12.1 Semantic HTML first

A/B Test Strategies That Work

What A/B Data Leaves Out

Strong Variations

How to Think About Claims

These Metrics in Context

Don’t Skip Step 1

Better Variation Design Examples