Interaction Pattern Template for Product Managers

What This Template Is For

An interaction pattern is a reusable solution to a common UX problem. "How does the user dismiss a modal?" "How does inline editing work?" "What happens when a form has server-side validation errors?" These questions get answered differently by every designer and every engineer unless the answers are documented once and referenced everywhere.

Interaction patterns sit above components in the design system hierarchy. A button is a component. A confirmation dialog is an interaction pattern that uses buttons, text, and a modal overlay. A drag-and-drop reorder is an interaction pattern that uses list items, drag handles, and visual drop indicators. Patterns describe behavior across multiple components working together.

This template provides a structure for documenting each interaction pattern. It covers the pattern anatomy (what elements participate), triggers and actions (what initiates the pattern and what happens), state transitions (how the pattern moves between states), keyboard behavior, accessibility requirements, responsive adaptation, and common mistakes.

This works alongside the design system documentation template for the individual components that patterns compose. The motion design template defines the animation parameters that bring patterns to life. For teams building AI-driven interaction patterns, understanding established non-AI patterns is essential context. The design QA template provides the checklist for verifying patterns are implemented correctly.

How to Use This Template

1. Identify patterns by auditing your product for repeated behaviors. Any time two features solve the same interaction problem differently (two different approaches to inline editing, two different confirmation flows), that is a pattern waiting to be documented.
2. Document one pattern at a time. Start with the most common and most inconsistently implemented patterns.
3. Write for two audiences: designers (who need to know when to use the pattern and what it looks like) and engineers (who need to know exactly how it behaves, including keyboard interactions and edge cases).
4. Include a state diagram. A visual representation of states and transitions prevents ambiguity that text descriptions alone cannot resolve.
5. Always include a "When NOT to use" section. Half the value of a pattern library is steering people away from patterns that seem appropriate but are wrong for the context.

The Template

Pattern Overview

Description. [2-3 sentences. What interaction problem does this pattern solve? When does the user encounter it?]

When to Use

• ☐ [Scenario 1, e.g., "User is about to perform a destructive action that cannot be undone"]
• ☐ [Scenario 2, e.g., "Action has significant consequences the user should confirm"]
• ☐ [Scenario 3, e.g., "User needs to provide additional input before the action proceeds"]

When NOT to Use

• ☐ [Scenario where this pattern is wrong, e.g., "Low-stakes actions like closing a modal or toggling a setting. Use inline undo instead."]
• ☐ [Alternative pattern to use instead, with explanation]
• ☐ [Anti-pattern, e.g., "Never chain multiple confirmations. If the user confirms once, do not ask again."]

Pattern Anatomy

┌─────────────────────────────────────┐
│ [Element 1, e.g., Trigger Button]   │
│                                     │
│ [Element 2, e.g., Overlay/Backdrop] │
│                                     │
│ [Element 3, e.g., Dialog Content]   │
│   ├─ [Sub-element, e.g., Title]     │
│   ├─ [Sub-element, e.g., Message]   │
│   └─ [Sub-element, e.g., Actions]   │
│       ├─ [Cancel Button]            │
│       └─ [Confirm Button]           │
└─────────────────────────────────────┘

Element descriptions:

Trigger and Action Map

State Transitions

State diagram:

[Idle] ──trigger──> [Active]
  ^                    │
  │         ┌─────────┤
  │         │         │
  │      cancel     confirm
  │         │         │
  │         │     [Loading]
  │         │       │    │
  │         │    success  error
  │         │       │    │
  └─────────┘   [Success] [Error]
                    │       │
                    └───────┘──> [Idle] (after dismiss/retry)

Keyboard Behavior

Focus management:

Accessibility Requirements

• ☐ [ARIA role and properties, e.g., role="dialog", aria-modal="true", aria-labelledby]
• ☐ [Screen reader announcements, e.g., "Dialog title announced on open"]
• ☐ [Focus trapping, e.g., "Tab cycles within the dialog, does not escape to page"]
• ☐ [Reduced motion, e.g., "Open/close animations respect prefers-reduced-motion"]
• ☐ [High contrast mode, e.g., "All elements visible in Windows High Contrast Mode"]
• ☐ [Touch accessibility, e.g., "All touch targets 44x44px minimum"]

Responsive Adaptation

Content Guidelines

Common Mistakes

Implementation Notes

[Framework-specific code snippets, hooks, or component composition examples]
[Include the key behavioral logic, not the full component code]
[Focus on the interaction flow, not the styling]

Filled Example: Search Combobox

Pattern Overview

Description. The search combobox lets users type to filter a list of options and select one or more. It combines a text input with a dropdown results list. Used for entity search (users, projects, labels), command palettes, and any selection from a large set of options.

When to Use

• Selecting from a list of 10+ options where typing is faster than scrolling
• Entity lookup (searching for a user, project, or document by name)
• Tagging or labeling (applying one or more tags from a predefined set)

When NOT to Use

• Fewer than 7 options. Use a simple Select dropdown instead.
• Boolean choice. Use a toggle or radio group.
• Free-text input where no predefined options exist. Use a plain text input.

State Transitions

[Idle] ──focus/click──> [Open, Empty Input]
                              │
                        type query
                              │
                        [Open, Filtered Results]
                           │         │
                     select item   no results
                           │         │
                     [Idle + Selected] [Open, Empty State]

Keyboard Behavior

Accessibility

• role="combobox" on the input, aria-expanded reflects open state
• role="listbox" on the results list, role="option" on each item
• aria-activedescendant on the input points to the highlighted option
• Screen reader announces result count: "5 results available"
• Selected items in multi-select announced with aria-selected="true"

Responsive Adaptation

Desktop: Dropdown positioned below input, max-height 300px with scroll. Mobile: Full-screen overlay with sticky input at top, full-height scrollable results.

Key Takeaways

• Patterns describe behavior across multiple components. They answer "how does this interaction work?" not "what does this element look like?"
• Include a state diagram for every pattern. Text descriptions alone leave ambiguity that diagrams resolve
• Document keyboard behavior and focus management for every state transition. These are the most commonly missed implementation details
• Always include "When NOT to use" to prevent pattern misapplication
• Test patterns at every breakpoint. A modal on desktop may need to become a bottom sheet on mobile

About This Template

Created by: Tim Adair

Last Updated: 3/5/2026

Version: 1.0.0

License: Free for personal and commercial use