Component Variant Finder

When to Use

• Before marking a component as “complete” in your design system
• During a component audit to find coverage gaps
• When product teams request variants you haven’t considered
• Planning the next iteration of a component

The Prompt

Analyze this component and identify missing variants, states, and edge cases.

Component: [COMPONENT NAME]
Current variants: [list what exists today]
Current states: [list what exists today]

Check for:
1. **Missing visual variants** — Based on common design system patterns, what variants are typically expected? (e.g., size options, color options, filled vs. outlined)
2. **Missing states** — Which interactive states are missing? Check: default, hover, active/pressed, focus, disabled, loading, error, success, selected, empty.
3. **Missing content combinations** — What about: with icon, without icon, icon only, with badge, with avatar, with description text, truncated text, multi-line?
4. **Missing compositional variants** — Can the component be used inside other components? (e.g., Button in a ButtonGroup, Tag in a TagList)
5. **Missing responsive behavior** — Does it adapt to mobile, handle touch, stack properly?
6. **Missing accessibility variants** — High contrast mode, reduced motion, right-to-left layout?

For each gap:
- Describe the missing variant
- Rate priority: Must have / Should have / Nice to have
- Give a one-line use case justification

Present as a table sorted by priority.

Example Output

## Variant Gap Analysis: Input Component

Current: text, email, password, number variants. Default, focus, error states.

| Missing Variant              | Priority    | Use Case                                    |
|------------------------------|-------------|---------------------------------------------|
| Disabled state               | Must have   | Forms with conditionally locked fields       |
| Loading state (with spinner) | Must have   | Async validation (email check)               |
| Success state                | Should have | Show valid input after async check           |
| Read-only state              | Should have | Display-only contexts like receipts          |
| With leading icon            | Should have | Search inputs, URL fields                    |
| With trailing icon           | Should have | Password visibility toggle, clear button     |
| With prefix text             | Should have | Currency inputs ($), URL inputs (https://)   |
| With suffix text             | Nice to have| Unit inputs (kg, px, %)                      |
| Textarea variant             | Must have   | Multi-line text entry                        |
| With character count         | Should have | Bio fields, tweet-length limits              |
| Autofill style               | Nice to have| Browser autofill changes background color    |
| RTL support                  | Should have | Placeholder and text alignment for Arabic/Hebrew |

### Summary
- 4 must-have gaps (ship blockers)
- 5 should-have gaps (next sprint)
- 3 nice-to-have gaps (backlog)