UX Patterns Guide
UI + UX Data Display And Exploration established

Timeline

Present a bounded chronological timeline with clear event markers, dates, actors, summaries, status, current and future distinctions, grouping, optional expansion, filtering, loading, and routes to detailed records when the timeline summary is not enough.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need a chronological record of important events for one object, case, order, application, or process.
  • Time order, current state, actor/source context, and milestone meaning are more important than dense comparison.
  • The product can summarize each event while linking to deeper evidence or records when needed.
  • The sequence benefits from markers, grouping, current/future distinction, or optional event expansion.

Avoid when

  • The surface is a live stream whose content keeps arriving and must preserve reader position.
  • The surface must serve as exhaustive audit evidence with immutable field-level detail.
  • Users are inside an active multistep transaction that needs validated progress.
  • The information is a planned task guide rather than a record of events.
  • Users need to compare many event rows by columns, export them, or search logs at scale.

Problem it prevents

Users often need to understand a sequence of important events around a case, order, application, incident, or process, but raw logs, feeds, tables, or step indicators can obscure time order, current state, actor context, and what happened next.

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 Timeline in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Events belong to one case, claim, order, application, person, incident, project, shipment, or process.

Pattern promise

Present a bounded chronological timeline with clear event markers, dates, actors, summaries, status, current and future distinctions, grouping, optional expansion, filtering, loading, and routes to detailed records when the timeline summary is not enough.

Required state

Default timeline with heading, order label, date or phase groups, and event markers.

Recovery path

Users cannot tell whether newest or oldest events appear first.

Access contract

Use semantic list or ordered-list structure with date-group headings and text event labels.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • 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.
  • An order timeline shows Created, Paid, Packed, Carrier handoff, Delivery exception, and Expected delivery, with current and future markers visually distinct.
  • 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.
  • A claimant expands one event for supporting detail, then collapses it without losing their place in the overall timeline.
Weak implementation

Vague, hidden, hard to recover from

  • A vertical line lists Approved, More, Update, and Done with no dates, actors, status, or explanation.
  • A dense audit table is squeezed into timeline cards and hides changed fields, exact actor identity, and retention proof.
  • A user sees a future appointment marker styled like completed history and assumes the appointment already happened.
  • A timeline replaces a stepper inside a form, so users cannot tell which current step is complete or blocked.
UI guidance
  • 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.
  • Use a clear connector, marker, grouping label, or range boundary only to reinforce time order; do not let the line or icon replace event text, timestamps, or source labels.
UX guidance
  • 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.
  • Keep timeline items brief enough for scanning, preserve chronological order under filtering or loading, and route detailed evidence, dense logs, or current-step progress to more appropriate surfaces.
Implementation contract

What the implementation must handle

States

  • Default timeline with heading, order label, date or phase groups, and event markers.
  • Past, current, expected future, cancelled, failed, warning, and system-generated event states.
  • Expanded and collapsed event detail states.
  • Filtered, grouped, searched, paginated, loading-more, no-events, and failed-load states.

Interaction

  • Each event has one stable identity, timestamp or date label, event title, and actor or system source when known.
  • The visual marker and connector reinforce chronological order but do not carry the only meaning.
  • Filtering and grouping never reorder events without stating the active order and hidden range.
  • Expanding an event reveals supporting detail in place without hiding adjacent dates or changing event identity.

Accessibility

  • Use semantic list or ordered-list structure with date-group headings and text event labels.
  • Use time elements or readable date text for timestamps, including timezone or approximate labels when relevant.
  • Do not rely on connector lines, marker color, or icon shape alone to communicate status or order.
  • Ensure event actions and expansion controls include the event title or date in their accessible names.

Review

  • What object, case, order, application, or process does this timeline belong to?
  • Are users trying to understand event sequence, consume a live stream, follow a planned process, or complete current steps?
  • Which event fields are required: date, time, actor, source, status, event type, summary, document, or action?
  • How are current and future expected events distinguished from completed past events?
Evidence trail

Source-backed claims behind this guidance

MOJ Design System: Timeline

Ministry of Justice Design System - checked

MOJ supports timelines for service histories with information about who added an item and when.

NHS App Design System: Timeline

NHS App Design System - checked

NHS App supports timeline use for broad process understanding and cautions against dense stage detail.

DWP Design System: Timeline

Department for Work and Pensions Design System - checked

DWP supports time-ordered records of events with brief overviews.

ONS Service Manual: Timeline

Office for National Statistics Service Manual - checked

ONS supports timelines for linear records of past or future events.

Home Office Design System: Timeline

Home Office User-Centred Design Manual - checked

Home Office supports event dates, times, descriptions, actors, and actions in timelines.

Full agent/debug reference

Problem Context

  • Events belong to one case, claim, order, application, person, incident, project, shipment, or process.
  • Users need to understand sequence and causality more than compare columns, consume live updates, or complete current form steps.
  • Events may be generated by people, systems, integrations, or scheduled milestones.
  • The timeline may include past events, the current event, expected future events, collapsed groups, filters, or links to source records.

Selection Rules

  • Choose timeline when the main user question is what happened, when it happened, who or what caused it, and what came next.
  • Use feed when items keep arriving as a dynamic stream and reading-position preservation is central.
  • Use activity log or audit log when users need exhaustive, immutable, compliance-grade evidence, field-level changes, actor IDs, retention, export, or search across logs.
  • Use process list when users need planned journey guidance and task links rather than a record of events.
  • Use step navigation when users are inside a current linear task and progress must reflect validated route state.
  • Use table or data grid when users need to compare many events by shared columns, sort by multiple fields, or export records.
  • Keep timeline items short and link to details instead of turning each event into a full case note.
  • Label current and future expected events differently from completed historical events.
  • Group long histories by date, phase, month, or status range while preserving visible order and hidden-count context.
  • Avoid timeline when event order is uncertain, unimportant, or likely to be misread as causality.

Required States

  • Default timeline with heading, order label, date or phase groups, and event markers.
  • Past, current, expected future, cancelled, failed, warning, and system-generated event states.
  • Expanded and collapsed event detail states.
  • Filtered, grouped, searched, paginated, loading-more, no-events, and failed-load states.
  • Hidden-range or hidden-filter count state when not all events are visible.
  • Unknown time, approximate time, corrected timestamp, timezone, and duplicate-event states when applicable.
  • Responsive narrow-screen state where date, title, actor, status, and actions remain readable.
  • Linked source-record state when users need deeper case notes, documents, messages, or audit evidence.

Interaction Contract

  • Each event has one stable identity, timestamp or date label, event title, and actor or system source when known.
  • The visual marker and connector reinforce chronological order but do not carry the only meaning.
  • Filtering and grouping never reorder events without stating the active order and hidden range.
  • Expanding an event reveals supporting detail in place without hiding adjacent dates or changing event identity.
  • Opening a source record preserves return context to the same event or date group.
  • Current and future items are visually and textually distinct from completed history.
  • Corrected, approximate, unknown, or timezone-sensitive times are labelled rather than silently normalized.
  • Long timelines expose load, pagination, or range controls that preserve date boundaries and focus.

Implementation Checklist

  • Define event identity, timestamp, date granularity, actor, source system, title, summary, status, type, detail route, and whether the item is past, current, or future.
  • Choose the default order and state it in the UI, such as newest first, oldest first, grouped by date, or grouped by phase.
  • Use semantic list structure with headings or time elements for date groups and event titles.
  • Provide text labels for markers such as current, expected, failed, cancelled, system, warning, or corrected time.
  • Add expansion only for concise supporting detail; route dense notes, documents, audit evidence, and comments to dedicated records.
  • Design filters and range loading with visible hidden counts, active filters, empty results, retry, and order preservation.
  • Preserve focus and scroll position when expanding events, filtering, loading older events, or returning from source records.
  • Test long titles, missing actors, approximate dates, localization, timezones, keyboard order, screen-reader date grouping, and mobile wrapping.

Common Generated-UI Mistakes

  • Using timeline as decorative chrome around a normal list with no meaningful time sequence.
  • Omitting dates, actors, or event summaries and expecting icons to communicate the sequence.
  • Mixing future tasks and completed events without text that distinguishes expectation from history.
  • Replacing audit logs with simplified timeline summaries when users need exact evidence.
  • Replacing a feed with timeline visuals while live insertion and ranking behavior remain unresolved.
  • Replacing step navigation inside a form with a timeline that cannot validate progress.
  • Letting filters or groups hide events without counts or range labels.
  • Treating event order as causality when the product only knows timestamps.

Critique Questions

  • What object, case, order, application, or process does this timeline belong to?
  • Are users trying to understand event sequence, consume a live stream, follow a planned process, or complete current steps?
  • Which event fields are required: date, time, actor, source, status, event type, summary, document, or action?
  • How are current and future expected events distinguished from completed past events?
  • What happens when events are filtered, grouped, corrected, duplicated, missing timestamps, or loaded in ranges?
  • Would feed, activity log, audit log, process list, step navigation, table, or data grid better fit the task?
Accessibility
  • Use semantic list or ordered-list structure with date-group headings and text event labels.
  • Use time elements or readable date text for timestamps, including timezone or approximate labels when relevant.
  • Do not rely on connector lines, marker color, or icon shape alone to communicate status or order.
  • Ensure event actions and expansion controls include the event title or date in their accessible names.
  • Expose current, expected, failed, cancelled, hidden, filtered, and loaded range states in text.
  • Keep focus on the activated event control or next sensible event after expansion, filtering, or loading.
  • Avoid extremely long tab sequences by keeping per-event actions limited and moving dense evidence to detail routes.
Keyboard Behavior
  • Tab reaches date-range controls, filters, event expansion controls, event links, and load-more controls in chronological reading order.
  • Enter or Space expands an event when the event heading is implemented as a button.
  • Escape closes an event menu or inline detail panel and returns focus to the invoking event.
  • After filtering or loading older events, focus stays on the triggering control, the changed range summary, or the first newly loaded event.
  • Opening and returning from an event detail route restores focus or scroll near the source event.
  • Optional arrow-key shortcuts may move between events only when standard Tab navigation remains sufficient.
Variants
  • Case timeline
  • Application timeline
  • Order timeline
  • Shipment timeline
  • Incident timeline
  • Medical journey timeline
  • Milestone timeline
  • Status timeline
  • Grouped timeline
  • Expandable timeline
  • Filtered timeline
  • Past and future timeline
  • Horizontal timeline
  • Vertical timeline

Verification

Source trail checked:

Saved items