browser-extension-ui

Fit the experience to the browser surface

Read the accepted task, visual direction and interaction behavior before selecting layouts or components. Inspect existing tokens, typography, primitives and framework versions. Chrome's surface constraints affect implementation; they do not require a Google-like palette, a new font system or a component-library migration. Use general interface design expertise for shared hierarchy, flow and visual consistency when relevant; contribute browser-surface lifecycle, entry/exit and permission constraints before a layout is settled. A popup's dismissal contract or a host site's focus ownership may require different interaction structures than a full-tab application. This specialist can still design a complete extension experience when no generic interface skill is installed; it must not require another plugin or impose its own visual identity.

Derive the experience from the kind of work

Start with what someone is trying to accomplish, not with a popup template. A bookmark clipper, a searchable vault and a page assistant may all have a toolbar icon while needing different primary experiences. Conversely, a collection browser can work in a popup, a side panel or a full tab. Product type describes the work; surface describes where it happens.

For a new experience or substantial revision:

1. Identify the main loop. What brings someone in, what object do they recognize or change, and what tells them they are done? Establish whether the task concerns a page/selection, a site, a collection or a browser session. Include how often people repeat it and how long unfinished work may last.
2. Match a reference structure. Read the selector in extension types and UI structures, then the relevant patterns. Combine patterns when the accepted product genuinely contains several loops. A shared header or settings page does not make two extensions the same type.
3. Allocate work to surfaces. Use the platform table below to decide which parts need proximity to a page, persistence, comparison space or direct browser entry. Make each additional surface earn its place; a command-only utility may not need a popup at all.
4. Adapt the structure. Map the actual product objects, actions, roles and states into the selected arrangement. Account for the accepted component system, appearance policy and accessibility requirements. Resolve mismatches rather than adding features merely because a reference product has them.
5. Trace the transitions. Establish entry, location, affected scope, unfinished work, result freshness and return behavior. Read experience patterns for cross-surface contracts and configuration as one of those transitions.