Back to compare picker

Wearable glance vs Notification center vs Summary box vs Dashboard layout vs Progress bar vs Notification preferences

Choose wearable glance when users look at a wrist or wearable surface for a few seconds and need one compact answer such as next step, current metric, remaining time, alert priority, route cue, medication due, workout pace, battery state, or account-safe status.

Decision dimensions

Dimension Wearable glanceNotification centerSummary boxDashboard layoutProgress barNotification preferences
UI or UX UI + UX - Few-second wearable status surface with safe handoffUI + UX - Durable user-opened notification history and action drawerUI + UX - Highlighted region for key information from a longer pageUI + UX - Page-level arrangement of coordinated status, metric, and analysis widgetsUI + UX - Measurable system-operation progress indicatorUI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptions
UI guidance Render a wearable glance as one compact answer with a clear subject, current value, priority, freshness, privacy state, and tap destination that works in a tiny complication, Wear OS tile, widget, or wearable card.Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever.Render a summary box as a labelled region with a specific heading, short body, scannable key points or next steps, and only links that directly support the summarized page task.Arrange dashboard widgets into a purposeful page hierarchy with a named dashboard, scope, freshness, global filters, primary KPIs, secondary analysis, exceptions, and supporting tables or links placed according to monitoring priority.Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages.Render notification preferences as a structured matrix or grouped settings surface that shows notification type, source, delivery channel, device, frequency, quiet-time rule, preview privacy, override, and current saved state.
UX guidance Use wearable glance when users need to check a status, cue, or next step in seconds without entering a full app or phone workflow.Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later.Use summary box when users need the essential facts, eligibility notes, deadlines, documents, or next steps from a longer page before reading every detail.Use dashboard layout when users need one page to monitor several related signals, compare current state against targets, spot exceptions, and decide which detailed view or workflow to open next.Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later.Use notification preferences when users need to reduce noise without missing important mentions, assignments, security notices, incidents, reminders, or followed-object updates.
Good UI A medication complication shows Next dose 8:30, due in 12 min, taken state, and opens the medication app for details.A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order.A benefits guide has a summary box headed Before you apply with deadline, required documents, and Start application link above the detailed eligibility rules.An operations dashboard opens with date range, region filter, last updated time, four KPI cards, an exception panel, a trend chart, and a priority table in a stable grid.A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable.A notification preferences page groups Mentions, Assigned work, Followed threads, Security, Digest, and Marketing, with columns for In-app, Email, Push, Banner, and Digest frequency.
Bad UI A watch tile compresses five dashboard charts, filters, and drill links into tiny unreadable panels.A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count.A pale box repeats the entire page introduction, every related link, and several unrelated policy notes.A dashboard is a wall of same-sized charts with no primary metric, no filter scope, no freshness, and no explanation of which tile matters first.A blue bar fills across the top of the page with no label, no percent, and no affected object.A single Notifications off switch disables email, push, badges, and mention banners without saying whether security alerts or approvals still arrive.
Good UX A user raises their wrist, sees that boarding starts in 9 minutes at Gate B12, and taps to open the boarding pass only when needed.Opening the notification drawer clears the new-notification badge while unread items remain available for later triage.A user scans the box, learns they need photo ID and proof of address, then continues into the detailed instructions with the same terms repeated in context.A manager changes Region to West, sees every tile show the same filtered scope and updated timestamp, then opens the exception table from the SLA breach card.A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds.A user keeps mentions and assigned-work banners on, moves repository watch updates to daily digest, mutes marketing email, and sees a preview of what will still notify them during quiet hours.
Bad UX A user tries to act from a tiny complication and accidentally dismisses an important alert.A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task.Users miss an eligibility rule because it appears only inside a sidebar summary and not in the main instructions.A user sees revenue down on one tile but cannot tell whether it is filtered, stale, a pinned snapshot, or live data.A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.A user disables email for a noisy project and still receives duplicate push and desktop banners because those channels live in separate hidden settings.
Best fit A wearable surface can answer a status, next-step, or current-metric question in seconds.Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders.A longer page has a small set of key facts or next steps that users need early.Users need to monitor several related metrics, exceptions, and analyses together.A system operation has a measurable total or bounded progress value.Users receive enough notifications that they need control over type, channel, device, frequency, timing, or source.
Avoid when The task requires long reading, comparison, filtering, editing, authentication, payment, or destructive review.The product has only occasional current-action feedback that a toast or inline status can handle.The highlighted content is an urgent status, outage, validation result, or severe consequence.Only one chart, table, status message, or record list is needed.Progress cannot be measured or would be guessed.The product has only a few low-volume notifications that can be handled by defaults and inline controls.
Required state Configured and unconfigured complication, tile, or widget state.Closed entry-point state with zero, new-unseen, and unread-but-seen counts.Default summary box with heading, concise body, key points or next steps, and optional task-specific link.Default dashboard with name, purpose, global scope, active filters, freshness, KPI tier, sections, and widget grid.Idle state before the operation starts.Default notification preferences state.
Accessibility burden Provide a readable label and value; do not rely on icon-only status, color-only urgency, or haptic-only cues.Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.Expose the box as a labelled region or group with a heading that fits the page heading hierarchy.Give the dashboard a heading, purpose, filter summary, refresh status, and section headings that screen-reader users can navigate.Provide an accessible name that identifies the operation and affected object.Group preferences with headings and fieldsets for event type, delivery channel, device, and frequency.
Common misuse Shrinking a mobile dashboard or full card list into a watch tile.Treating the badge count, unread count, and total notification count as one number.Repeating the whole page in a highlighted box.Filling a page with charts before defining dashboard purpose, audience, hierarchy, and decisions.Fabricating progress values just to make users feel movement.Offering one master notification switch for a complex collaboration product.

Wearable glance

UI or UX
UI + UX - Few-second wearable status surface with safe handoff
UI guidance
Render a wearable glance as one compact answer with a clear subject, current value, priority, freshness, privacy state, and tap destination that works in a tiny complication, Wear OS tile, widget, or wearable card.
UX guidance
Use wearable glance when users need to check a status, cue, or next step in seconds without entering a full app or phone workflow.
Good UI
A medication complication shows Next dose 8:30, due in 12 min, taken state, and opens the medication app for details.
Bad UI
A watch tile compresses five dashboard charts, filters, and drill links into tiny unreadable panels.
Good UX
A user raises their wrist, sees that boarding starts in 9 minutes at Gate B12, and taps to open the boarding pass only when needed.
Bad UX
A user tries to act from a tiny complication and accidentally dismisses an important alert.
Best fit
A wearable surface can answer a status, next-step, or current-metric question in seconds.
Avoid when
The task requires long reading, comparison, filtering, editing, authentication, payment, or destructive review.
Required state
Configured and unconfigured complication, tile, or widget state.
Accessibility burden
Provide a readable label and value; do not rely on icon-only status, color-only urgency, or haptic-only cues.
Common misuse
Shrinking a mobile dashboard or full card list into a watch tile.

Notification center

UI or UX
UI + UX - Durable user-opened notification history and action drawer
UI guidance
Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever.
UX guidance
Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later.
Good UI
A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order.
Bad UI
A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count.
Good UX
Opening the notification drawer clears the new-notification badge while unread items remain available for later triage.
Bad UX
A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task.
Best fit
Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders.
Avoid when
The product has only occasional current-action feedback that a toast or inline status can handle.
Required state
Closed entry-point state with zero, new-unseen, and unread-but-seen counts.
Accessibility burden
Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot.
Common misuse
Treating the badge count, unread count, and total notification count as one number.

Summary box

UI or UX
UI + UX - Highlighted region for key information from a longer page
UI guidance
Render a summary box as a labelled region with a specific heading, short body, scannable key points or next steps, and only links that directly support the summarized page task.
UX guidance
Use summary box when users need the essential facts, eligibility notes, deadlines, documents, or next steps from a longer page before reading every detail.
Good UI
A benefits guide has a summary box headed Before you apply with deadline, required documents, and Start application link above the detailed eligibility rules.
Bad UI
A pale box repeats the entire page introduction, every related link, and several unrelated policy notes.
Good UX
A user scans the box, learns they need photo ID and proof of address, then continues into the detailed instructions with the same terms repeated in context.
Bad UX
Users miss an eligibility rule because it appears only inside a sidebar summary and not in the main instructions.
Best fit
A longer page has a small set of key facts or next steps that users need early.
Avoid when
The highlighted content is an urgent status, outage, validation result, or severe consequence.
Required state
Default summary box with heading, concise body, key points or next steps, and optional task-specific link.
Accessibility burden
Expose the box as a labelled region or group with a heading that fits the page heading hierarchy.
Common misuse
Repeating the whole page in a highlighted box.

Dashboard layout

UI or UX
UI + UX - Page-level arrangement of coordinated status, metric, and analysis widgets
UI guidance
Arrange dashboard widgets into a purposeful page hierarchy with a named dashboard, scope, freshness, global filters, primary KPIs, secondary analysis, exceptions, and supporting tables or links placed according to monitoring priority.
UX guidance
Use dashboard layout when users need one page to monitor several related signals, compare current state against targets, spot exceptions, and decide which detailed view or workflow to open next.
Good UI
An operations dashboard opens with date range, region filter, last updated time, four KPI cards, an exception panel, a trend chart, and a priority table in a stable grid.
Bad UI
A dashboard is a wall of same-sized charts with no primary metric, no filter scope, no freshness, and no explanation of which tile matters first.
Good UX
A manager changes Region to West, sees every tile show the same filtered scope and updated timestamp, then opens the exception table from the SLA breach card.
Bad UX
A user sees revenue down on one tile but cannot tell whether it is filtered, stale, a pinned snapshot, or live data.
Best fit
Users need to monitor several related metrics, exceptions, and analyses together.
Avoid when
Only one chart, table, status message, or record list is needed.
Required state
Default dashboard with name, purpose, global scope, active filters, freshness, KPI tier, sections, and widget grid.
Accessibility burden
Give the dashboard a heading, purpose, filter summary, refresh status, and section headings that screen-reader users can navigate.
Common misuse
Filling a page with charts before defining dashboard purpose, audience, hierarchy, and decisions.

Progress bar

UI or UX
UI + UX - Measurable system-operation progress indicator
UI guidance
Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages.
UX guidance
Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later.
Good UI
A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable.
Bad UI
A blue bar fills across the top of the page with no label, no percent, and no affected object.
Good UX
A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds.
Bad UX
A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.
Best fit
A system operation has a measurable total or bounded progress value.
Avoid when
Progress cannot be measured or would be guessed.
Required state
Idle state before the operation starts.
Accessibility burden
Provide an accessible name that identifies the operation and affected object.
Common misuse
Fabricating progress values just to make users feel movement.

Notification preferences

UI or UX
UI + UX - User-controlled rules for notification type, channel, frequency, timing, privacy, and exceptions
UI guidance
Render notification preferences as a structured matrix or grouped settings surface that shows notification type, source, delivery channel, device, frequency, quiet-time rule, preview privacy, override, and current saved state.
UX guidance
Use notification preferences when users need to reduce noise without missing important mentions, assignments, security notices, incidents, reminders, or followed-object updates.
Good UI
A notification preferences page groups Mentions, Assigned work, Followed threads, Security, Digest, and Marketing, with columns for In-app, Email, Push, Banner, and Digest frequency.
Bad UI
A single Notifications off switch disables email, push, badges, and mention banners without saying whether security alerts or approvals still arrive.
Good UX
A user keeps mentions and assigned-work banners on, moves repository watch updates to daily digest, mutes marketing email, and sees a preview of what will still notify them during quiet hours.
Bad UX
A user disables email for a noisy project and still receives duplicate push and desktop banners because those channels live in separate hidden settings.
Best fit
Users receive enough notifications that they need control over type, channel, device, frequency, timing, or source.
Avoid when
The product has only a few low-volume notifications that can be handled by defaults and inline controls.
Required state
Default notification preferences state.
Accessibility burden
Group preferences with headings and fieldsets for event type, delivery channel, device, and frequency.
Common misuse
Offering one master notification switch for a complex collaboration product.
Decision rules
  • Choose wearable glance when users look at a wrist or wearable surface for a few seconds and need one compact answer such as next step, current metric, remaining time, alert priority, route cue, medication due, workout pace, battery state, or account-safe status.
  • Choose notification center when users need a durable inbox of events, read/unread state, filters, cleanup, history, or follow-up across many sources; a wearable glance may surface one timely item but should not become the notification archive.
  • Choose summary box when the information belongs inside a page or task as a concise textual recap with next steps; wearable glance owns wrist-sized ambient or quick-view display outside the full page.
  • Choose dashboard layout when users compare several widgets, charts, filters, and drill paths at once; wearable glance should not compress a dashboard into tiny unreadable tiles or hidden drill-down controls.
  • Choose progress bar when users need a measurable operation timeline with percent, remaining time, cancellation, or stages; wearable glance can show one current progress fact but not replace detailed progress recovery.
  • Choose notification preferences when users configure channels, quiet hours, device routing, critical exceptions, or privacy previews; wearable glance should reflect those rules rather than define them in-place.
  • A wearable glance must define priority, freshness, source, privacy level, complication or tile shape, ambient or dimmed state, tap handoff destination, and what changes when data is stale, unavailable, sensitive, or action-required.
  • Do not show private content, long names, hidden controls, dense charts, unlabelled icons, or stale sensor values on a watch face without privacy, freshness, and fallback cues.
  • When a glance is actionable, limit it to one safe primary action or a clear handoff; require phone/app continuation for complex input, destructive decisions, payments, or long forms.
  • Wearable glance surfaces must respect battery, always-on display, reduced motion, haptics, notification privacy, wrist-down state, small circular or rectangular slots, and intermittent connectivity.
Inspect live examples
Failure modes
  • A tiny watch complication tries to show a full dashboard with multiple charts and filter controls.
  • A private message preview appears on the wrist while notification privacy is enabled.
  • A stale heart-rate or delivery ETA value is shown as current with no timestamp or unavailable state.
  • A glance opens a destructive action directly on tap instead of handing off to a review surface.
  • Every notification is mirrored as a wearable glance until the surface becomes an unreadable inbox.
  • A progress glance shows a spinner forever with no remaining time, source, or phone handoff.
  • The design ignores ambient or dimmed mode and becomes illegible in always-on display.