From visual clue to behavior contract
How the UI pattern finder works
A component name is useful only when it leads to the correct interaction, focus, keyboard, dismissal, and mobile behavior.
01
Describe observable evidence
Start with what opens the interface, where it appears, whether the page behind it remains usable, what content it contains, and how it closes. You do not need to know the component name. A concrete behavior such as “a card opens on focus and contains a link” is more useful than a visual label such as “small popup.”
02
Compare nearby alternatives
The diagnostic keeps two or three plausible candidates instead of pretending the first keyword match is correct. It then asks only questions that can change the result. This matters because Tooltip, Popover, and Hover Card may share a floating shape while requiring different interactivity and persistence rules.
03
Copy a testable brief
The final output turns the selected pattern into an implementation contract. It records trigger, dismissal, modality, focus, keyboard behavior, placement, mobile behavior, excluded alternatives, and observable acceptance checks. Give that brief to a coding agent, then test the result instead of trusting the label alone.
Need a manual process first? Read the step-by-step guide to identifying an unnamed UI pattern.