UX Patterns Guide
UI + UX Personalization And Preference emerging

User-controlled layout

Provide explicit user-controlled layouts that rearrange or reveal panes without changing data scope, preserve active task state, explain persistence and responsive fallbacks, and give users preview, save, reset, and recovery paths.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users work with multiple panes or regions around one active task and need different arrangements for comparison, editing, reading, or focus.
  • The product can preserve task state while panes are moved, hidden, stacked, or restored.
  • Layout scope and responsive fallback can be explained clearly enough that users know what will persist.

Avoid when

  • The only need is changing row spacing, text size, theme, or zoom.
  • Users need to save filters, columns, or sort as a view rather than arrange regions.
  • Users are composing dashboard widgets instead of changing a workspace layout around one task.
  • The product cannot preserve drafts, focus, validation, or hidden-pane state across layout changes.
  • The arrangement is safety-critical or policy-fixed and should not vary by user.

Problem it prevents

Complex work surfaces often contain lists, details, activity streams, inspectors, previews, and editors, but one fixed arrangement forces every user, device, and task phase into the same layout and can hide state when panes move or collapse.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch User-controlled layout in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The interface has multiple regions that support one task, such as a queue, selected record, notes, preview, activity, metadata, or action panel.

Pattern promise

Provide explicit user-controlled layouts that rearrange or reveal panes without changing data scope, preserve active task state, explain persistence and responsive fallbacks, and give users preview, save, reset, and recovery paths.

Required state

Default layout state with current layout name, scope, affected regions, and reset availability.

Recovery path

Changing to focus layout destroys the hidden activity pane and loses a draft comment.

Access contract

Expose layout name, scope, affected regions, hidden panes, reset availability, and managed state in text.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A review workspace lets users switch between Split, Focus, and Stacked layouts, labels the current scope as This workspace, and keeps the selected case and draft visible after each switch.
  • A record editor offers a right-inspector layout and a below-content layout with preview thumbnails, reset to default, and an explanation when mobile forces stacked order.
  • A support agent opens a case in Split layout, switches to Focus to write a long response, returns to Split, and the same case, filters, scroll position, and draft reply remain intact.
  • A tablet user chooses Stacked layout, moves between Queue, Case, and Activity regions with labelled controls, and can reset the layout without resetting queue filters.
Weak implementation

Vague, hidden, hard to recover from

  • A layout icon toggles panes with no names, no reset path, and no visible cue that the notes pane is hidden.
  • A focus layout removes the activity pane from the DOM and loses the user's unsaved comment draft.
  • A user saves a personal inspector layout and later discovers it changed the team's default workspace arrangement.
  • A responsive breakpoint hides the secondary pane off screen, so keyboard users cannot reach the validation errors inside it.
UI guidance
  • Render layout control as an in-context segmented control, menu, or layout picker with named arrangements such as Split, Focus, Stacked, Inspector, or Reading, plus scope, preview, save, and reset indicators.
  • Show affected regions with stable labels, order, visibility, and return paths so users can tell which pane moved, which pane is hidden, and how to restore the prior arrangement without losing work.
UX guidance
  • Use user-controlled layout when the same task can be done more effectively with different pane arrangements, such as comparing list and detail, focusing on one record, placing an inspector beside content, or stacking regions on narrow screens.
  • Preserve task state across layout changes: selected item, active filters, open panels, draft edits, validation state, scroll anchor, focus target, and unsaved-change warnings must survive pane reordering or hiding.
Implementation contract

What the implementation must handle

States

  • Default layout state with current layout name, scope, affected regions, and reset availability.
  • Split or side-by-side layout state showing primary and secondary regions together.
  • Focus layout state that hides secondary regions while preserving their state and return controls.
  • Stacked or mobile layout state with labelled navigation between regions.

Interaction

  • Changing layout rearranges regions but does not change the active record, dataset, filters, columns, sort, density, theme, or saved view unless the user explicitly chooses those changes.
  • The current layout and scope are visible before and after change, and a status region announces the new arrangement.
  • Hidden panes remain recoverable and keep their draft, scroll, validation, loading, and permission state.
  • Saving layout is a distinct action when persistence goes beyond the current session or current workspace.

Accessibility

  • Expose layout name, scope, affected regions, hidden panes, reset availability, and managed state in text.
  • Keep every region reachable by keyboard after layout changes, including panes that become stacked, collapsed, or hidden behind a region switcher.
  • Maintain visible focus and restore focus to the invoking control or equivalent region after the layout transition.
  • Avoid relying on icon shape, pane position, or drag handles alone to communicate layout choices.

Review

  • Which regions can move, hide, stack, or switch sides, and which task state must survive every change?
  • Can users distinguish layout from density, saved view, dashboard customization, and splitter resizing?
  • Is the selected layout temporary, personal, device-specific, workspace-wide, inherited, or policy-managed?
  • What happens to drafts, validation, scroll, focus, and hidden pane content when the layout changes?
Evidence trail

Source-backed claims behind this guidance

WAI-ARIA APG Window Splitter Pattern

W3C WAI - checked

Supports accessible pane resizing, collapse, restore, orientation, and keyboard behavior used inside layout-changing workspaces.

ServiceNow Horizon Resizable Panes

ServiceNow Horizon Design System - checked

Shows workspace panes that can be resized or hidden to fit user needs while preserving adjacent content.

Full agent/debug reference

Problem Context

  • The interface has multiple regions that support one task, such as a queue, selected record, notes, preview, activity, metadata, or action panel.
  • Users alternate between comparing regions side by side, focusing on one region, reading long content, editing details, or using a narrow screen.
  • Layout choice may be temporary, personal, device-specific, workspace-specific, inherited from an organization policy, or unavailable on small screens.
  • Pane arrangement affects focus order, screen-reader order, keyboard shortcuts, scroll anchoring, unsaved changes, validation visibility, and responsive navigation.
  • The product may also offer splitters, saved views, dashboards, density settings, themes, and preferences that must remain separate from layout arrangement.

Selection Rules

  • Choose user-controlled layout when users choose the arrangement, visibility, or order of workspace regions around the same task object.
  • Use window splitter when users only resize adjacent panes with a separator and the broader region arrangement does not change.
  • Use custom dashboard when users compose dashboard widgets, add or remove tiles, and persist a dashboard canvas.
  • Use dashboard layout when the product defines a fixed monitoring page with widget hierarchy, filters, and drill paths.
  • Use saved view when users persist columns, filters, sort, grouping, density, or display mode for one data surface.
  • Use user-controlled density when spacing or row height changes but region arrangement stays the same.
  • Offer named layouts only when each arrangement has a real task benefit and can preserve selection, focus, drafts, validation, and scroll position.
  • Show whether the layout change is temporary, this workspace only, device-specific, account-wide, workspace-wide, or organization-managed.
  • Provide reset to default and avoid resetting filters, density, theme, columns, dashboard widgets, or saved views when only layout is reset.
  • On mobile or high zoom, translate side-by-side layouts into explicit stacked or focus navigation rather than forcing horizontal scroll.

Required States

  • Default layout state with current layout name, scope, affected regions, and reset availability.
  • Split or side-by-side layout state showing primary and secondary regions together.
  • Focus layout state that hides secondary regions while preserving their state and return controls.
  • Stacked or mobile layout state with labelled navigation between regions.
  • Inspector-left, inspector-right, or below-content arrangement state when pane position changes.
  • Preview-before-save, saved personal layout, workspace-managed layout, and reset-to-default states.
  • Unavailable layout state when screen width, policy, permission, or content length makes an arrangement unsafe.
  • State-preservation proof for selected item, filters, draft edit, validation, scroll anchor, and focus target.

Interaction Contract

  • Changing layout rearranges regions but does not change the active record, dataset, filters, columns, sort, density, theme, or saved view unless the user explicitly chooses those changes.
  • The current layout and scope are visible before and after change, and a status region announces the new arrangement.
  • Hidden panes remain recoverable and keep their draft, scroll, validation, loading, and permission state.
  • Saving layout is a distinct action when persistence goes beyond the current session or current workspace.
  • Reset restores only the named layout scope and leaves data filters, density, saved view, and dashboard composition untouched.
  • Keyboard order and screen-reader order follow the visible arrangement or provide clear region navigation when stacked.
  • Responsive fallback maps each desktop layout to a usable mobile or high-zoom state with no off-screen essential pane.

Implementation Checklist

  • Define a layout model with layout ID, region order, region visibility, pane position, scope, persistence, responsive fallback, saved timestamp, and policy owner.
  • Keep layout state separate from filters, sort, columns, density, splitter sizes, theme, zoom, dashboard widgets, and saved views.
  • Provide named controls for switch layout, preview, save, reset, return to hidden pane, and explain managed or unavailable arrangements.
  • Preserve selected item, focused control, draft edits, validation messages, scroll anchor, open panels, loading state, and permission state across layout changes.
  • Align DOM order, keyboard order, visible order, and mobile navigation for every supported arrangement.
  • Test narrow widths, zoom, long localized pane titles, active form edits, validation errors in hidden panes, keyboard shortcuts, screen readers, and browser back behavior.

Common Generated-UI Mistakes

  • Treating layout as a cosmetic preference while losing task state when panes hide or move.
  • Combining layout with filters, density, columns, theme, or saved view settings so users cannot reset one without the others.
  • Saving a personal layout as a workspace default without scope warning or permission checks.
  • Using a side-by-side desktop layout on mobile and creating horizontal scroll or unreachable panes.
  • Offering vague icons for layout modes with no labels, preview, current state, or recovery.
  • Calling a single resizable splitter a full user-controlled layout when no arrangement or visibility choice exists.

Critique Questions

  • Which regions can move, hide, stack, or switch sides, and which task state must survive every change?
  • Can users distinguish layout from density, saved view, dashboard customization, and splitter resizing?
  • Is the selected layout temporary, personal, device-specific, workspace-wide, inherited, or policy-managed?
  • What happens to drafts, validation, scroll, focus, and hidden pane content when the layout changes?
  • Does the mobile or high-zoom fallback preserve region order and task completion without horizontal scrolling?
  • Can users preview, save, reset, and recover a layout without changing data filters or shared defaults by accident?
Accessibility
  • Expose layout name, scope, affected regions, hidden panes, reset availability, and managed state in text.
  • Keep every region reachable by keyboard after layout changes, including panes that become stacked, collapsed, or hidden behind a region switcher.
  • Maintain visible focus and restore focus to the invoking control or equivalent region after the layout transition.
  • Avoid relying on icon shape, pane position, or drag handles alone to communicate layout choices.
  • Announce layout changes through a stable status region when panes move, hide, or reorder.
  • Ensure DOM order, heading order, landmarks, and screen-reader navigation match the visible or declared region order.
  • Do not use layout changes to hide validation errors, required actions, permission limits, or unsaved changes.
Keyboard Behavior
  • Tab reaches the layout control, preview, save, reset, region navigation, and any return-to-hidden-pane controls.
  • Arrow keys may move within a segmented layout control when semantic roles support it.
  • Enter or Space applies a selected layout according to native control behavior.
  • After switching layout, focus remains on the layout control or moves to the corresponding region control with a status announcement.
  • Escape closes layout menus without changing arrangement and returns focus to the trigger.
  • Keyboard shortcuts for panes continue to target the same logical region even if the region has moved or stacked.
Variants
  • Split workspace layout
  • Focus mode layout
  • Stacked mobile layout
  • Inspector side layout
  • Reading layout
  • Comparison layout
  • Personal workspace layout
  • Device-specific layout
  • Managed workspace layout
  • Temporary layout preview

Verification

Source trail checked:

Saved items