# Product and dashboard interfaces

Product UI should disappear into the task. Familiarity is a feature when users need to move quickly and trust the controls.

## Set the task and visual target

Follow the [Uizze image-first → 1:1 policy](../references/uizze-image-to-ui.md). Read the real workflow, components, assets and data/auth contracts; preserve the established shell and identity unless redesign is approved. Choose a coherent direction around the primary task, navigation, content density and real controls, not a decorative dashboard.

Inspect and use a supplied/approved target without regenerating it. For new visual work or an approved redesign, an available authorized image tool should produce a straight-on, realistic UI target before UI code: include actual copy, controls, assets and viewport. Inspect and correct false capabilities, illegible labels, impossible states and inaccessible arrangements, then save one stable target with its actual dimensions. For scoped refinements, constrain the target to an incumbent screenshot and approved changes. Small technical fixes, audits and backend work need no new concept image.

Without image generation, use a supplied target; if none exists, disclose the limitation and build from the brief and incumbent conventions. Do not install a provider or make paid references a prerequisite.

## Structure

- Make the current location, primary task, and next action obvious.
- Match information density to the work. Dense tables and compact controls are appropriate when users need them; decorative containers are not.
- Prefer standard navigation, forms, tables, tabs, menus, and dialogs over novel replacements.
- Use spacing and alignment for grouping before adding borders, cards, or backgrounds.
- Keep one component vocabulary across the surface.

## Build the target, not a new interpretation

Match the approved target at its original viewport: work regions, proportions, hierarchy, typography, text wrapping, spacing, colors, icons and crops. Reuse semantic components and real layout primitives; never flatten the image into UI or silently replace missing fonts/assets and claim an exact match. Preserve real routes, data, auth and backend behavior: a generated control does not create a capability. Resolve target conflicts with accessibility or product truth explicitly, without aesthetic drift. After matching the original size, adapt the structure to requested widths and reachable states while retaining its identity.

## States and behavior

- Cover the states the product can reach: loading, empty, error, success, disabled, selected, expanded, and recovery where relevant.
- Keep focus visible, controls labelled, contrast readable, and targets usable.
- Prevent overlays and menus from being clipped by scroll or overflow containers.
- Use quick motion only for state changes and feedback. Do not choreograph routine page loads.
- Make responsive changes structural: collapse navigation, reflow groups, and preserve access to important actions.

## Finish

Run the interface at representative sizes and exercise actual tasks, controls, focus and reachable states. Capture the target screen/state at its saved dimensions after fonts/images load and motion settles. Compare full context and details side by side or with an overlay; fix layout/proportions first, then type, spacing, color and assets, and recapture after corrections. Check untouched regions against the incumbent baseline for refinement. Do not redesign working areas outside scope.

Report the target/dimensions, capture environment, comparison method, exercised paths and remaining mismatches or unavailable assets/tools. A 1:1 claim requires a real target and inspected same-size render with no unresolved visible mismatch in that scope; without rendering/comparison, visual matching is unverified. A clean build or source review does not establish that the product works.