Search history

Problem Context

• Search activity is saved across sessions, products, devices, accounts, workspaces, or managed environments.
• Queries can reveal sensitive work, health, financial, legal, identity, or private intent.
• The product uses search activity for recall, personalization, suggestions, recommendations, analytics, or enterprise productivity.

Selection Rules

• Choose search history when the primary task is reviewing or managing stored query activity, not merely rerunning one recent query.
• Show each history entry as a query event with query text, product or source, timestamp, and account/device/workspace scope.
• Provide delete-one, delete-range, clear-all, pause future capture, and resume capture states where history is persistent.
• Explain that pausing future history capture does not delete existing entries unless the user also deletes them.
• Let users filter by source, product, scope, date range, and optionally device when the history spans multiple surfaces.
• Keep search history deletion separate from saved searches, saved filters, recently viewed items, bookmarks, downloads, recommendations, and underlying results.
• Use recently searched for a short inline recency list near a search box; use search history for the management and privacy surface.
• Use saved search when the user intentionally stores criteria for reuse, sharing, alerting, dashboarding, or subscription.
• Use audit log when the history must be immutable, administrative, actor-oriented, and compliance-grade rather than user-controlled activity data.
• Respect managed-account, legal hold, retention, sync, private browsing, signed-out, and shared-device constraints before promising deletion.

Required States

• Empty history state with storage scope and next steps.
• Populated history state with query, source, timestamp, and scope for each event.
• Filtered state by product, source, date, scope, or device.
• Delete-one state that removes a single search activity entry only.
• Delete-range or clear-all state with confirmation and affected count.
• Paused state where future searches are not stored but previous entries may remain.
• Managed or synced account state explaining retention, administrator, device, or account boundary.
• Error or unavailable state when history cannot be loaded, deleted, or paused.

Interaction Contract

• Opening search history shows stored search activity with enough metadata for users to judge sensitivity and scope.
• Deleting one entry removes that history event only and leaves saved searches, viewed items, results, and records intact.
• Deleting a range states the time period, sources, and approximate number of affected entries before confirmation.
• Pausing history affects future capture only and does not imply existing activity has been erased.
• Resuming history makes future capture explicit and should not restore deleted entries.
• Filtering history changes the visible set without changing what will be deleted unless the delete action names the filtered scope.
• History controls must preserve focus, announce deletion and pause outcomes, and avoid hidden hover-only destructive actions.

Implementation Checklist

• Define the data model for search activity events separately from recent searches, saved searches, viewed records, and audit events.
• Capture query text, source product, scope, timestamp, account or device identifier, retention class, and deletion eligibility.
• Add filters for date range, source/product, scope, and device where those dimensions exist.
• Implement delete-one, delete-filtered-range, clear-all, pause capture, and resume capture with explicit affected-data copy.
• Show managed-account, legal hold, retention, sync, and signed-out constraints before promising deletion.
• Keep search-history settings and deletion controls keyboard accessible and announce updates through a polite status region.
• Test sensitive queries, shared devices, account switching, private browsing, offline deletion failure, partial deletion, range deletion, pause/resume, and saved-search separation.
• Log deletion, pause, resume, and failed-history actions without storing the sensitive query text in unnecessary telemetry.

Common Generated-UI Mistakes

• Using search history as a generic label for a short recently searched dropdown.
• Deleting saved searches, viewed records, bookmarks, or filters when the user only chose to delete search history.
• Letting users pause future history but hiding that old entries remain stored.
• Showing another account's or shared device's sensitive queries without a scope label.
• Omitting product, device, or timestamp metadata from account-wide activity.
• Using vague destructive copy such as clear all without naming the data and range.
• Treating search history as an immutable audit log or compliance record.
• Storing or displaying partial keystrokes that were never submitted as search activity.

Critique Questions

• Is this a full management surface or just a short recently searched list?
• Can users tell what account, device, workspace, product, and date each query came from?
• Do delete-one, delete-range, clear-all, pause, and resume actions have different labels and consequences?
• Does pausing history clearly affect only future capture?
• Are saved searches, recently viewed items, and recommendations protected from search-history deletion?
• What retention, managed-account, sync, legal, or shared-device constraints change what deletion means?
• Can users recover from failed deletion or understand partial deletion?