The user's explicit instructions take precedence over this skill. Preserve existing product conventions, brand rules, and requested style choices unless the user asks to change them.
Use this skill to make visible interface work feel intentional and product-specific rather than like a statistically average generated frontend.
Core judgment
Do not treat individual components or styles as banned. Cards, gradients, pills, rounded corners, shadows, large type, serif fonts, glass effects, dense tables, sparse layouts, and animation can all be correct.
The failure mode is usually accumulated defaults without a product reason.
Prefer decisions that can be explained by at least one of these:
- the user's task
- the product's information structure
- the audience and usage frequency
- the existing visual language
- the content itself
- platform or domain conventions
- a deliberate visual direction supplied by the user
If a choice has no such reason, reconsider it.
Before changing visible UI
Infer or inspect enough context to answer:
- What is this screen for?
- What should attract attention first, second, and third?
- What information is primary, supporting, or optional?
- Is there an existing design system or repeated visual language to preserve?
- Is this a marketing surface, product surface, internal tool, operational console, editor, data view, or something else?
Do not invent decorative sections, fake metrics, testimonials, badges, helper text, status blocks, navigation, or controls just to make a page feel complete.
When the repository already contains a product UI, treat that product as the primary design reference before generic conventions or component-library defaults.
During implementation
Design the screen as a whole, not as a sequence of independently polished components.
Prioritize:
- hierarchy before decoration
- information structure before card structure
- meaningful grouping before visual containers
- intentional density before arbitrary whitespace
- product language before generic SaaS copy
- consistent system behavior before novelty
- real content and states before showcase content
Use the smallest amount of chrome needed to make relationships and actions clear.
If a component library is present, use it as implementation infrastructure, not as the visual concept. Adapt defaults where the product needs a different density, radius, spacing, typography, or composition.
Existing interfaces
When refining an existing UI:
- preserve recognizable product patterns unless they are part of the problem
- avoid redesigning unrelated areas to satisfy personal taste
- remove generated-looking repetition before adding visual novelty
- prefer fewer stronger decisions over many weak decorative ones
- compare the changed screen against neighboring screens, not against a generic portfolio aesthetic
Supporting references
Read references/heuristics.md when diagnosing or creating a visual direction.
Read references/final-pass.md before calling visible UI work finished.