Guide 01 · Unknown component to testable contract

How to identify a UI pattern you cannot name.

Stop searching by silhouette. Observe the user task, trigger, content, focus, keyboard, dismissal, modality, placement, persistence, and mobile behavior, then eliminate patterns that cannot satisfy the evidence.

01 · The real problem

A component name is compressed requirements

When someone asks “what is this UI element called,” the visible shape is usually the easiest part of the answer and the least reliable part of the implementation. A small floating rectangle could be a Tooltip, Popover, Hover Card, menu, validation message, or something custom. The correct term depends on what the surface does, what users can operate inside it, and what interaction contract must survive the build.

The name matters because developers, coding agents, design systems, and accessibility guidance attach expectations to it. If you ask for a Tooltip but place links inside it, the implementation may close before keyboard or pointer users can operate those links. If you ask for a Select but users must type an arbitrary value, the chosen control may make the required task impossible. Naming is therefore not a vocabulary exercise. It is a way to choose and communicate constraints.

There is also a limit: not every familiar label lives at the same conceptual level. Dialog describes semantics; Drawer can describe edge-based presentation; Autocomplete can describe behavior attached to a Combobox; Banner can describe a visual container. More than one term may apply to one interface. Your goal is not to force a single label. Your goal is to make every required property explicit.

02 · Evidence inventory

Record what a user can observe

Before opening a component library, write a short field report. Avoid framework names and avoid interpreting the interface too early. Use complete statements that another reviewer could verify in a browser.

User task: What is the user trying to accomplish: read clarification, preview an object, choose a value, issue a command, navigate, acknowledge a condition, or complete a focused task?
Trigger: Does it open from hover, keyboard focus, click, right-click, long press, text input, page load, or a system event? Must more than one trigger work?
Content: Is the content short text, rich preview information, links, form controls, commands, navigation destinations, or a complete task? Can users interact with it?
Focus: Does keyboard focus remain on the trigger, move into the surface, become contained inside it, or follow ordinary document order? Where does focus return on close?
Keyboard: Which keys open, operate, navigate, select, dismiss, or move between items? Is Escape expected? Are arrow keys controlling a list or merely scrolling the page?
Dismissal: Does it close on Escape, outside interaction, selection, a dedicated button, timeout, navigation, or completion? Could accidental dismissal lose work?
Modality: Can the page behind the surface remain interactive, or must background content become inert until the focused task is completed or dismissed?
Placement and persistence: Is the surface anchored to a trigger, centered, edge-aligned, inline, page-wide, or attached to the viewport? Does it persist, auto-dismiss, or remain available in a history?
Mobile behavior: What replaces hover, right-click, dense columns, edge gestures, or narrow anchored surfaces on touch screens and small viewports?

03 · Six-step process

Move from candidates to an implementation decision

Write the behavior without a component name.
Use one or two sentences. For example: “A small surface opens when a link receives hover or keyboard focus. It previews the linked person, contains no required action, and must remain reachable without pointer hover.” This description preserves evidence while avoiding an early label.
Choose the semantic job.
Ask whether the interface explains, previews, collects, commands, navigates, notifies, discloses, or interrupts. This first partition removes many visual lookalikes. A menu issues commands or navigation choices; a selection control updates a value; a notification communicates an event or state.
Generate two or three nearby candidates.
Do not compare the whole design-system catalog. Select the few patterns that solve the same broad job or share the observed presentation. The UI pattern library groups 20 reviewed concepts into six ambiguity clusters so the candidate set stays manageable.
Find the decisive difference.
Look for the requirement that makes one candidate fail. Interactive controls eliminate a Tooltip. Background blocking separates a Modal Dialog from a non-modal Dialog. Editable text separates a Combobox from a native Select. A collection of linked headings separates an Accordion from a single Disclosure.
Keep uncertainty explicit.
If the evidence does not confirm modality, value constraints, focus containment, or persistence, mark that field as an assumption. Do not convert an internal ranking score into a confidence percentage. A useful diagnosis shows what is known, what remains undecided, and which answer would change the choice.
Turn the result into checks.
Write the selected pattern, excluded alternatives, trigger, open and close behavior, focus, keyboard operation, interactive content, placement, mobile adaptation, and accessibility requirements. Finish with observable acceptance checks that a reviewer can run in the actual product.

04 · Worked examples

Use one requirement to reject a near match

Tooltip, Popover, or Hover Card?

A short, non-interactive label that appears on hover and focus points toward a Tooltip. A surface with links or controls that must remain open while users operate it points toward a Popover. A richer preview of a referenced person or object may be a Hover Card, but it still needs a keyboard or explicit path because hover alone excludes touch and keyboard users.

Do not decide from size or shadow. Ask whether the content is interactive, whether it previews a referenced object, and whether click persistence is required. Use the Tooltip vs Popover vs Hover Card comparison to verify the boundary.

Select, Combobox, or Autocomplete?

If the final value must come from a small fixed set and users do not need to type, a Select can be appropriate. If users type or edit a value while an associated popup presents options, the semantic contract is a Combobox. Autocomplete describes how suggestions filter or complete text and commonly exists as behavior within an editable Combobox.

The decisive questions are whether typing is allowed, whether arbitrary values are accepted, and whether suggestions change as the user types. The Select vs Combobox vs Autocomplete comparison makes those value rules explicit.

05 · Coding-agent handoff

Write requirements that survive generation

A weak prompt says “build a modern dropdown.” It leaves purpose, value behavior, focus, keyboard access, dismissal, placement, and mobile adaptation unspecified. A stronger handoff names the pattern only after stating the contract. It also records alternatives that must not be substituted.

Pattern: [reviewed pattern or combined semantic and presentation terms]
Purpose: [user task]
Trigger: [observable trigger]
Open behavior: [when and where it appears]
Dismissal behavior: [Escape, outside action, selection, completion, or explicit close]
Modality: [background available or inert]
Focus behavior: [initial focus, containment, and return]
Keyboard behavior: [required keys]
Interactive content: [allowed controls or text only]
Placement: [anchored, inline, centered, edge, page, or viewport]
Mobile behavior: [touch and narrow-screen adaptation]
Assumptions: [unconfirmed requirements]
Do not implement as: [rejected alternatives and why]
Acceptance checks: [observable browser checks]

After generation, test the interface with a keyboard, pointer, touch-sized viewport, and the browser behavior your users receive. The pattern name does not prove conformance. The checks do.

06 · Common failure modes

Avoid false certainty and content-shaped answers

Choosing from screenshots alone and never observing open, close, focus, or keyboard behavior.
Treating semantic roles, presentation forms, behavior variants, and visual containers as mutually exclusive peers.
Copying a component library name without checking whether that library implements the behavior you require.
Using a confidence percentage that has not been calibrated against a reviewed answer set.
Hiding unknown requirements instead of marking them as assumptions that a product owner must answer.
Stopping after naming the component instead of writing and running observable acceptance checks.

Frequently asked questions

Identifying UI patterns: common questions

Direct answers based on the reviewed behavior contract above.

Can I identify a UI pattern from a screenshot alone?

A screenshot can suggest candidates, but it cannot confirm trigger, dismissal, focus, keyboard behavior, modality, persistence, or mobile adaptation. Treat visual evidence as a starting point and inspect the running interface or ask for behavior requirements before finalizing the pattern.

What if two UI pattern names both seem correct?

Check whether the terms describe different layers. One may be a semantic pattern while another describes presentation or behavior. Record both only when each adds a real requirement. If the terms compete at the same layer, use the decisive difference to reject the near match.

Should I ask an AI coding agent to choose the pattern?

You can use an agent to generate candidates, but require it to show observable evidence, excluded alternatives, assumptions, and acceptance checks. Do not accept a label based only on visual similarity or a confident tone.

How many candidates should I compare?

Usually two or three nearby candidates are enough. A larger list adds noise unless the initial description lacks a semantic job. If no reviewed candidate fits, return no match and request better behavior evidence rather than inventing an answer.