Standardized Interaction Patterns

Who this is for

Data Visualization Engineers, BI developers, and analytics engineers who build dashboards, reports, or embedded analytics and want consistent, accessible, low-friction interactions across charts.

Prerequisites

• Basic chart literacy (bar, line, scatter, map)
• Familiarity with events (hover, click, focus) and component states
• Basic accessibility concepts (keyboard navigation, focus, ARIA)

Why this matters

In day-to-day work you will:

• Define how tooltips, selection, and drill-down behave across dozens of charts.
• Make cross-filters predictable so users aren’t surprised moving between dashboards.
• Ensure interactions work with keyboard and screen readers.
• Reduce rework by giving engineers and designers a shared playbook for interactions.

Typical real tasks you’ll encounter

• Specify the same hover tooltip rules for line, bar, and scatter plots.
• Decide how click-to-filter and multi-select operate across charts and tables.
• Handle loading, empty, and error states without breaking user flow.
• Document keyboard equivalents and focus order for every interactive chart.

Concept explained simply

Standardized interaction patterns are reusable, named rules for how users interact with data visuals. They describe triggers (hover, click, key), feedback (highlight, tooltip, selection), outcomes (filter, zoom, drill), and states (idle, hover, active, selected, disabled, loading, empty, error).

Mental model: Interaction = Trigger → Feedback → Outcome

• Trigger: What the user does (hover, click, key press, drag).
• Feedback: What the UI shows immediately (highlight, tooltip, aria-live message).
• Outcome: What changes in data or view (filter applied, zoomed range, drill-down opened).

Core patterns to standardize

• Hover/Foucus tooltip: Appears on hover or keyboard focus; collision-aware placement; consistent formatting.
• Click to select/filter: Single-select vs multi-select; visual selection affordance; clear state reset.
• Legend toggle: Show/hide series with checkable items; maintain color and order; support keyboard.
• Brush/zoom: Drag to set range; wheel zoom; reset control; synced axes across charts.
• Drill-down: Clear affordance (cursor, icon, instruction); breadcrumb to go back.
• Cross-filtering: Selection in one chart filters others; loading skeletons; empty-state messaging.
• Keyboard access: Tab order, arrow navigation for marks, Enter/Space to activate, Esc to cancel.
• States: Idle, hover, active/pressed, selected, disabled, loading, empty, error.

Worked examples (3)

Example 1: Standard tooltip spec

1. Trigger: Hover a mark OR focus a mark via keyboard.
2. Placement: Top-right by default; flip or shift on collision with viewport.
3. Content: Title (series or category), primary value, secondary context (date, percentage), footnote for filters.
4. Behavior: 150–300 ms show delay, 100 ms hide delay; no pointer capture; follows cursor with throttling.
5. Accessibility: Tooltip content mirrored to an aria-live polite region when triggered by keyboard.

Example 2: Click to filter with multi-select

1. Single-click: Toggle selection on the mark; selected marks use a 2 px outline and 80% opacity fill.
2. Multi-select: Hold Ctrl/Cmd (desktop) or use a persistent multi-select toggle; show count badge.
3. Outcome: Apply filter to connected charts; show a compact filter chip row with a Clear All button.
4. States: While fetching, show skeletons in dependent charts; keep selected marks visible.
5. Error: Show non-blocking toast and retain previous data; selection remains but is flagged.

Example 3: Brush to zoom on time series

1. Trigger: Drag to create a brushed range. Mouse up commits the zoom.
2. Keyboard: Arrow keys move window by 1 unit; Shift+Arrow moves by 7 units; Enter commits.
3. Controls: Reset button; quick ranges (7d, 30d, YTD); wheel to zoom in/out around cursor.
4. Sync: Other aligned charts reflect the same x-range for comparison.

Design rules and naming

• Tokenize: Use tokens (e.g., interaction.focusOutline=2px #2684FF).
• Thresholds: Define hover tolerance in pixels for dense marks; throttle tooltips to 60–100 ms.
• Selection: Selected marks must be distinguishable in color-blind-safe palettes; do not rely on color alone.
• Latency: Show skeletons for >150 ms loads; show toasts for errors with actionable copy.

Accessibility checklist

• Every interaction has a keyboard equivalent (Enter/Space = click, arrows = move, Esc = cancel).
• Visible focus outline on interactive elements and marks.
• Logical tab order that follows the visual reading order.
• ARIA labels for chart regions, legend items, and selected states (e.g., “Bar, Category A, Value 42, selected”).
• Do not use color alone; combine with patterns, outlines, or icons.
• Provide non-hover path to tooltip info (focus or Details panel).

Exercises

Complete these and compare with the solutions in the expandable sections. Your answers don’t have to match exactly; focus on covering the required behaviors and states.

Exercise 1 — Standard tooltip pattern spec

Define a single tooltip pattern to be reused across bar, line, and scatter charts. Include: triggers, placement rules with collision handling, content structure, delays, motion, and accessibility notes.

• Expected output: A concise spec covering triggers, placement, content, timing, and a11y.

Exercise 2 — Cross-filter multi-select pattern

Design the cross-filter interaction for a dashboard where clicking bars filters a table and a line chart. Include: single vs multi-select, loading states, empty state, error handling, clear controls, and keyboard equivalents.

• Expected output: A flow description plus visual states and controls list.

Done checklist

• You used the Trigger → Feedback → Outcome mental model.
• You documented states: idle, hover/focus, active, selected, disabled, loading, empty, error.
• You included keyboard and screen reader behavior.
• You specified timing and collision rules where relevant.

Common mistakes and how to self-check

• Mistake: Different tooltip formats per chart. Fix: Centralize a shared content schema and formatter tokens.
• Mistake: Hover-only interactions. Fix: Provide focus/keyboard equivalents.
• Mistake: Instant data fetch on hover. Fix: Commit on click or mouse-up to avoid accidental requests.
• Mistake: Color-only selection. Fix: Add outlines, icons, or pattern fills.
• Mistake: No empty/error states. Fix: Add clear messaging and recovery actions.

Self-check

• Can a new chart reuse the same interaction spec with no new decisions?
• Are keyboard, mouse, and touch all supported consistently?
• Does cross-filtering behave the same across all pages?
• Can users always undo (Reset, Clear All, Back)?
• Are loading and empty states unmistakable and helpful?

Practical projects

• Create a reusable tooltip component spec (content schema, placement, a11y) and apply it to 3 chart types.
• Document a cross-filter pattern and implement it in a small dashboard (bar → line + table) with loading/empty/error states.
• Build an interaction states gallery showing the eight states for a bar mark and a legend item.

Learning path

1. Inventory interactions you already have; list inconsistencies.
2. Adopt the Trigger → Feedback → Outcome template for each pattern.
3. Define states and tokens (focus outline, selection color, animation timing).
4. Write accessibility rules once; reference them in all patterns.
5. Pilot the patterns on one dashboard; run a heuristic review; refine.
6. Publish as a mini design system page; socialize with engineers and QA.

Next steps

• Finalize your tooltip and cross-filter specs and add them to your team’s design system.
• Standardize legend toggles and brush/zoom next.
• Take the quick test below to check your understanding.

Mini challenge

Users complain that clicking a data point sometimes filters and sometimes drills down across different dashboards. Propose a single rule to resolve this.

Show one good answer

Rule: Click = select/filter; Double-click or a clear drill icon/button = drill-down. Keyboard: Enter = select/filter; Alt+Enter or the drill button = drill. Always show breadcrumb after drill and a visible Clear All for filters.

Quick test

This quick test is available to everyone. If you are logged in, your progress will be saved automatically.