| UI or UX | UI + UX - Searchable and exportable record of system, user, or administrative events | UI + UX - Bounded chronological record of past, current, or expected events | UI + UX - Durable user-opened notification history and action drawer | UI + UX - Search activity management surface with deletion and capture controls |
| UI guidance | Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available. | Render the timeline as a labelled chronological sequence where each event has a visible date or time, event title, actor or system source when known, status or type, and a short summary. | 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 search history as a management page or panel with query text, product or source, account/device/workspace scope, timestamp, and clear controls for filtering and deletion. |
| UX guidance | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. | Use timeline when users need to understand what happened, where they are now, and what may happen next in a case, claim, application, order, incident, or process. | 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 search history when users need to review and control stored search activity across time, products, devices, accounts, or workspaces. |
| Good UI | An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields. | A benefits application timeline groups events by date and shows Application submitted, Evidence requested, Evidence received, Decision pending, and Next review, with actor, timestamp, and status marker. | 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. | An account activity page lists Gmail, Drive, and web searches with query text, source, device, time, delete-one controls, product filters, date range, and a pause switch. |
| Bad UI | A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source. | A vertical line lists Approved, More, Update, and Done with no dates, actors, status, or explanation. | A red badge says 42 forever because opening the drawer, reading items, and viewing related work never update the count. | A button labelled Clear history deletes saved searches, viewed records, and recommendations without naming the affected data. |
| Good UX | An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive. | A caseworker filters the timeline to System events, sees two date groups hidden, restores all events, and the event order and current marker stay stable. | Opening the notification drawer clears the new-notification badge while unread items remain available for later triage. | A user filters search history to Drive searches from last week and deletes two entries without deleting saved searches. |
| Bad UX | A user marks a notification read and the corresponding activity evidence disappears from the only log. | A user sees a future appointment marker styled like completed history and assumes the appointment already happened. | A payment failure that blocks the current checkout is only stored in the notification center and never appears in the task. | Users think pausing search history deletes past entries because the interface does not distinguish future capture from stored history. |
| Best fit | Users need to inspect recorded user, admin, system, security, or integration events. | Users need a chronological record of important events for one object, case, order, application, or process. | Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders. | Search activity persists beyond the current session and users need to inspect or control it. |
| Avoid when | The goal is only to show a readable milestone history for one case or process. | The surface is a live stream whose content keeps arriving and must preserve reader position. | The product has only occasional current-action feedback that a toast or inline status can handle. | The product only needs a short inline list of recent queries for quick rerun. |
| Required state | Default log state with event records, result count, visible timezone, retention window, and permission scope. | Default timeline with heading, order label, date or phase groups, and event markers. | Closed entry-point state with zero, new-unseen, and unread-but-seen counts. | Empty history state with storage scope and next steps. |
| Accessibility burden | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. | Use semantic list or ordered-list structure with date-group headings and text event labels. | Give the entry-point control an accessible name that includes new or unread count without relying only on a red dot. | Use headings and table or list semantics that expose query, source, date, and scope for each entry. |
| Common misuse | Calling a social feed or notification drawer an activity log without event evidence. | Using timeline as decorative chrome around a normal list with no meaningful time sequence. | Treating the badge count, unread count, and total notification count as one number. | Using search history as a generic label for a short recently searched dropdown. |