Perceptual UI Design

Create interfaces that are visually stable and legible in their real context, not merely geometrically tidy in an enlarged canvas.

Establish the design problem

Before choosing a visual treatment, identify or reasonably infer:

• platform, viewport, input method, and target rendering density;
• user goal and primary action;
• the primary/default state and lower-frequency variants;
• real content constraints, including long text, localization, numbers, and empty data;
• accessibility requirements, including text scaling, contrast, and reduced motion;
• existing product tokens and conventions that should be preserved.

Do not block on missing details that can be represented as explicit assumptions. Ask only when a missing choice would materially change the product or visual direction.

Design from hierarchy to optics

1. Define a specific visual direction tied to the product's purpose. Avoid an interchangeable “clean modern” default.
2. Establish information hierarchy and semantic grouping before decoration.
3. Use a small, coherent family of typography, spacing, radius, stroke, cap, join, color, and motion decisions. Reuse existing product tokens when available.
4. Make group relationships visible through proximity: spacing within a group should read as tighter than spacing between groups.
5. Treat negative space as an active shape. Check whether empty regions create unintended holes, crowding, or top-/side-heavy composition.
6. Optimize the primary state first, then adapt secondary states deliberately. Do not force every state into identical geometry when content changes its visual weight.
7. Apply optical corrections only after the structure works. Typical candidates include asymmetric icons, triangles, circular marks, mixed text and icons, small counters, strokes beside fills, and compact status displays.

For icons, dense controls, small type, stateful compact UI, or high-fidelity visual critique, read references/optical-qa.md before finalizing.

Validate perception in context

Inspect the result at actual output size, not only zoomed in. Use the checks that fit the artifact:

• silhouette or monochrome check for visual weight;
• grayscale check for hierarchy independent of hue;
• slight-blur or squint check for dominant masses and grouping;
• light and dark backgrounds, plus nearby UI context;
• measured contrast for meaningful text, glyphs, strokes, component boundaries, and focus indicators against every adjacent surface; visual inspection alone is insufficient;
• primary, selected, disabled, loading, empty, error, and dynamic-content states;
• longest plausible copy, localization expansion, and accessibility text sizes;
• keyboard focus, pointer/hover, touch target, and reduced-motion behavior where applicable.

If implementation is requested, verify the rendered artifact with screenshots or the project's normal visual test loop. Fix issues found in the render rather than defending the source geometry.

Separate evidence from interpretation

Label important design claims when the distinction matters:

• Standard — platform guidance, an established design system, or an accessibility requirement.
• Heuristic — a generally useful perceptual or composition principle.
• Inference — a plausible explanation of an observed design without creator confirmation.
• To validate — a choice that depends on real content, device rendering, or user testing.

Golden ratio, Fibonacci circles, and the golden angle may be used as optional exploratory constraints. Never present them as proof of quality or as the construction method of an existing design without primary evidence. A reconstruction grid can explain a shape; it does not prove how the shape was made.

Deliver the result

Lead with the design outcome. Include only the supporting material that helps the user evaluate or continue the work:

• the intended visual direction and hierarchy;
• key tokens or reusable decisions;
• meaningful state differences;
• optical corrections and why they were made;
• validation performed and remaining assumptions.

Prefer a small number of purposeful alternatives over many cosmetic variants. When showing alternatives, change a consequential design decision and explain the tradeoff.

Guardrails

• Do not copy Apple assets or use “Apple-like” as a substitute for a product-specific direction.
• Do not equate mathematical centering with visual centering.
• Do not add construction grids or arbitrary ratios merely to make the rationale look rigorous.
• Do not sacrifice accessibility, error clarity, or long-content behavior to perfect a hero state.
• Do not invent universal optical-offset numbers; judge corrections in the target size and context.
• Do not reuse one accent palette across light and dark surfaces without measuring each meaningful foreground/background pair. Create surface-specific state tokens when needed.
• Do not replace a working product design system unless the request calls for redesign.