Custom dashboard

Problem Context

• The product has reusable widgets, charts, KPI cards, saved views, queues, shortcuts, or reports that different roles prioritize differently.
• Users need a persistent personal or role-based arrangement rather than only global filters on a fixed dashboard.
• Dashboard composition may affect shared workspaces, role defaults, navigation shortcuts, alert visibility, or mobile order.
• Widgets can fail, become unavailable, require permission, have different refresh cadences, or be removed from the product catalog.
• Users may customize with a pointer, keyboard, touch, narrow screen, or assistive technology.

Selection Rules

• Choose custom dashboard when users need to choose which widgets appear, where they appear, and how much space they occupy.
• Use dashboard layout when the product team defines one coherent monitoring page and users mainly read, filter, or drill from it.
• Use saved view when users persist the presentation of one data surface rather than composing several dashboard widgets.
• Use preference center when users configure communications, privacy, notification, or account preferences rather than dashboard content.
• Use pinned items or favorites when users only need quick access shortcuts and are not arranging a widget canvas.
• Offer shared-dashboard editing only when ownership, edit permission, audience impact, review, and rollback are explicit.
• Avoid custom dashboard when the widget set is too small, unrelated, or unreliable to support meaningful personal composition.
• Avoid drag-only customization; every widget move, resize, remove, save, cancel, and reset action needs a keyboard-accessible path.

Required States

• Read-only dashboard state with current layout name, owner or scope, active widgets, freshness, and customize entry point.
• Customization mode with selected widgets, available widget gallery, unsaved changes, move, resize, remove, save, cancel, and reset controls.
• Personal save, shared save, save as copy, discard changes, reset to default, and restored default states.
• Widget added, widget removed, widget reordered, widget resized, duplicate-widget blocked, and maximum-widget-count states.
• Unavailable, permission-limited, retired, loading, failed, stale, empty, and source-disconnected widget states.
• Responsive preview and narrow-screen state where critical widgets, edit controls, save status, and reset remain reachable.

Interaction Contract

• Entering customization mode freezes dashboard reading interactions and makes layout-editing controls explicit.
• Adding a widget places it in a predictable location, announces the change, and marks the dashboard as unsaved until saved or canceled.
• Moving or resizing a widget updates visual order, keyboard order, and responsive order together.
• Saving states whether changes apply to only this user, a role default, or a shared team dashboard before committing.
• Cancel and reset restore the previous persisted layout without changing dashboard filters, selected data, or saved views inside widgets.
• Permission-limited or retired widgets remain explainable with remove, replace, or request-access paths.
• Responsive preview shows how widget order and size will adapt before users save a desktop arrangement.
• The system records enough metadata to recover from failed saves, conflicting shared edits, and removed widgets.

Implementation Checklist

• Define a dashboard layout model with dashboard ID, owner, scope, widget IDs, widget order, widget sizes, responsive priority, data bindings, and saved timestamp.
• Separate layout state from data filters, query state, saved view definitions, and widget data refresh state.
• Provide add, remove, move earlier, move later, resize, save, cancel, reset, duplicate handling, and shared-impact confirmation.
• Validate every widget against permissions, source availability, retired-widget catalog state, mobile size, and maximum dashboard constraints.
• Persist personal layouts separately from team defaults and provide a way to copy a shared dashboard before editing.
• Announce customization changes through a stable status region and keep focus on the edited widget or next safe control.
• Test pointer drag, keyboard moves, touch reordering, narrow widths, long widget titles, failed saves, conflicting shared edits, and reset recovery.

Common Generated-UI Mistakes

• Treating a fixed dashboard with filters as a custom dashboard even though users cannot choose widgets, order, or size.
• Letting users drag widgets without save, cancel, reset, keyboard movement, or shared-impact confirmation.
• Saving a personal layout over a team default without owner or audience warning.
• Using customization to hide mandatory operational alerts or compliance widgets with no policy explanation.
• Losing widget order on mobile or making keyboard order differ from the visible arrangement.
• Showing blank spaces when a widget is retired, permission-limited, or disconnected from its source.

Critique Questions

• Can users tell whether they are editing layout, filtering data, or changing a saved view inside a widget?
• Which changes are personal, shared, default, temporary, unsaved, or policy locked?
• Can each widget be added, removed, moved, resized, replaced, and restored without pointer-only interactions?
• What happens when a widget becomes unavailable, loses permission, fails refresh, or is removed from the catalog?
• Does responsive order preserve user intent and keep critical widgets before decorative or low-priority widgets?
• Would dashboard layout, saved view, pinned items, favorites, or preference center better match the user task?