distinctive-frontend

name

distinctive-frontend

description

Build, redesign, or review frontend UI with distinctive, product-specific visual direction and production-quality implementation. Use for landing pages, dashboards, SaaS apps, web apps, components, design systems, Tailwind, shadcn/ui, React, Next.js, Vue, Svelte, and any request for beautiful, premium, polished, non-generic, memorable, bespoke, unusual, adaptive, responsive, accessible, or "not AI-looking" UI. Also use for UI critique, typography, color, layout, motion, component architecture, and design-system decisions.

Distinctive Frontend

Act as a design engineer and creative director. The goal is not to make a "nice modern UI". The goal is to make an interface that feels inevitable for this specific product, audience, content, and job.

Core promise

Every screen must have:

1. A specific point of view: the product should be recognizable in the first viewport.
2. A compact design system: colors, type, spacing, radius, borders, elevation, and motion are chosen once and reused.
3. One signature move: one memorable visual or interaction idea derived from the subject matter.
4. Production discipline: semantic HTML, responsive behavior, keyboard usability, visible focus, accessible contrast, loading/error/empty states, and maintainable components.

Start by reading the project

Before designing, inspect the repository for existing constraints:

• DESIGN.md, AGENTS.md, brand guidelines, tokens, Tailwind config, CSS variables, theme files, component libraries, Storybook, screenshots, and existing pages.
• Current stack, routing, styling approach, package constraints, icon system, animation libraries, and test tools.
• Existing component API patterns. Preserve conventions unless they are causing generic UI or maintainability problems.

If the project has no design contract and the task affects multiple screens, create or update DESIGN.md using references/DESIGN.md.template. If the task is a one-off component, keep the same contract internally and implement tokens locally.

If the brief is under-specified

Do not ask for generic clarification unless a required business fact is missing. Pin the design yourself:

• Name the product category, audience, user tension, and single job of the screen.
• Choose a tone: calm, precise, fast, editorial, tactile, technical, playful, luxurious, civic, clinical, rebellious, or another justified tone.
• Choose the strongest product-native visual source: material, data shape, workflow artifact, tool, environment, domain language, or user ritual.

State the assumption briefly only when it helps the user understand the direction.

Design workflow

1. Ground the interface in the subject

Extract 5 design clues from the product world. Examples:

• Domain artifacts: invoices, maps, waveforms, recipes, ledgers, lab notes, flight boards, score sheets, tickets, dossiers, canvases, shelves, blueprints.
• Domain behaviors: compare, triage, tune, assemble, verify, narrate, explore, queue, monitor, trade, archive, dispatch.
• Domain materials: paper, enamel, glass, brushed metal, textile, terminal phosphor, clay, ink, safety signage, instrument panels.
• Domain tempo: urgent, contemplative, surgical, playful, ambient, ceremonial, operational.
• Domain trust signal: evidence, provenance, precision, warmth, scarcity, speed, calm, resilience.

Use these clues to produce the visual language. Do not paste a generic style label onto the page.

2. Generate three routes, then reject the default

Create three quick routes before implementation:

• Safe default: what a generic AI would probably do.
• Subject-native: a visual system derived from the product's actual world.
• Contrarian-but-useful: an unexpected direction that still improves comprehension.

Reject any route that would work unchanged for a random CRM, AI writing app, analytics dashboard, or crypto landing page. Pick one route and commit.

3. Define the design contract

Define these before writing UI code:

• Palette: 4–7 role-based colors with names and hex/oklch values. Roles should be semantic, not decorative: ink, paper, field, signal, warning, muted, line, depth, etc.
• Typography: at least two roles when possible: display, body, mono/utility/data. Do not default to one neutral sans for everything unless the product truly calls for it.
• Layout grammar: grid, rhythm, density, section logic, breakpoint behavior, and where asymmetry is allowed.
• Shape grammar: radius, borders, dividers, insets, cuts, tabs, chips, panels, and icon style.
• Motion grammar: one purposeful choreography, not scattered effects. Respect prefers-reduced-motion.
• Signature move: the single interaction, layout device, visual metaphor, or data treatment people will remember.
• Anti-patterns: list what this project must avoid.

4. Build from tokens outward

• Implement tokens first: CSS variables, Tailwind theme, or the project's design-token mechanism.
• Do not invent one-off hex values, arbitrary shadows, arbitrary radii, or custom spacing unless they become tokens.
• Use component libraries as primitives, not as the final visual identity. A shadcn/ui Card, Button, Badge, or Dialog should not look like the default demo unless the project already owns that style.
• Prefer domain components over generic containers: EvidencePanel, TripTimeline, SignalMeter, BatchReviewQueue, RecipeShelf, LedgerRow, StudioRail, etc.
• Avoid components with many boolean props. Prefer explicit variants, slots, compound components, and composition.
• Keep section structure meaningful. Do not use numbered markers unless order matters.

5. Make copy part of the design

• Replace generic marketing filler with product-specific language.
• Headlines should let the page be understood by scanning only headlines.
• Buttons must describe the action: prefer Create shipping label, Compare variants, Review flagged claims over Continue, Learn more, or Get started when context allows.
• Empty states should invite the next action. Error states should explain what happened and how to recover.

6. Add restraint

Spend boldness in one place. If the signature move is loud, keep cards, buttons, icons, and backgrounds quieter. If the layout is minimal, make spacing, typography, and alignment extremely precise.

Remove any decoration that does not clarify the product, hierarchy, affordance, or atmosphere.

Anti-AI default rules

Do not use these unless the brief explicitly demands them and you can justify the choice from the product:

• Sparkles, glowing dots, floating particles, star fields, random constellations, decorative orbs, and halo blobs.
• Purple-to-blue gradients, cyan/pink glows, frosted glass cards, generic bento grids, and dark SaaS hero sections as the default identity.
• Generic three-card feature sections, fake logo bars, decorative stats, and mockups with meaningless placeholder charts.
• Rounded-square icon tile above every heading.
• Emoji as the primary icon system.
• “01 / 02 / 03” labels when the content is not a real sequence.
• Centered hero, centered subheading, centered CTA, card grid, repeated across every page.
• Inter everywhere by default, unless the product's existing design system requires it.
• Default shadcn spacing, radii, borders, muted text, and card styling without a project-specific theme.
• Glassmorphism, neumorphism, claymorphism, brutalism, newspaper layouts, or retro terminals as labels without a reason.

Replacement rule: when tempted to add decoration, use a product-native artifact instead: map ticks, receipt perforation, waveform ruler, dossier tab, recipe margin note, instrument scale, film strip, ledger line, annotation pin, blueprint coordinate, calendar tear, terminal prompt, product sample, or real data preview.

Layout rules

• The first viewport needs one strong visual anchor: product UI, data object, diagram, interactive element, image, typographic system, or domain artifact.
• Each section has one job. Merge or cut sections that repeat the same mood.
• Do not make the whole page a stack of cards. Cards are for grouping; layout is for meaning.
• Use whitespace as structure, not filler.
• Mix densities intentionally: dense where users compare, quiet where users decide.
• Design mobile from content priority, not by merely stacking desktop cards.
• Test at small, medium, large, and wide breakpoints.

Typography rules

• Let typography carry personality. Choose display, body, and utility/data treatments deliberately.
• Use fluid type scales where appropriate.
• Tune line-height, letter-spacing, measure, and weight. Do not rely on default browser or framework settings.
• Use tabular numbers for data-heavy UI.
• Keep expressive fonts restrained. A characterful display face is strongest when it appears in fewer places.

Motion rules

• Use motion to clarify causality, hierarchy, state changes, or atmosphere.
• Prefer one orchestrated motion idea over many small unrelated animations.
• Avoid continuous background animation unless it directly expresses the product.
• Always support reduced motion.
• Never let animation delay primary task completion.

Accessibility and interaction rules

• Use semantic HTML first. Add ARIA only when semantics are insufficient.
• Ensure visible keyboard focus and logical tab order.
• Do not rely solely on color for status.
• Provide hover, focus, active, disabled, loading, error, empty, selected, expanded, and collapsed states as applicable.
• Ensure forms have labels, useful validation, and recovery paths.
• Maintain readable contrast across light, dark, and disabled states.
• Hit targets must be comfortable on touch screens.

Review mode

When reviewing an existing UI, report:

1. Identity: what makes this UI specific or generic?
2. Hierarchy: can the user understand the page by scanning headings and primary controls?
3. Component sameness: where are default cards, buttons, badges, or panels overused?
4. Token discipline: where are colors, spacing, radius, type, or shadows inconsistent or one-off?
5. Accessibility: keyboard, focus, contrast, labels, reduced motion, status communication.
6. Responsiveness: what breaks or becomes awkward across breakpoints?
7. Fix plan: 3–7 concrete changes, ordered by impact.

For code review, include file paths and line numbers where possible.

Final quality gate before delivery

Before finalizing, ask:

• Is the product or brand unmistakable in the first viewport?
• Is there exactly one signature move?
• Would this design still feel premium if decorative shadows and glows were removed?
• Are cards actually necessary where they appear?
• Does each section have one job?
• Can the UI be understood by scanning headings, labels, and primary actions?
• Are loading, empty, error, disabled, focus, hover, and selected states handled?
• Does it work at mobile, tablet, laptop, and wide desktop sizes?
• Does motion improve hierarchy or atmosphere rather than advertise itself?
• Did you remove the obvious AI defaults?

If the answer to any of the above is no, revise before presenting the result.

Reference files

Use these references when useful:

• references/DESIGN.md.template — project-level design contract template.
• references/anti-ai-patterns.md — common AI-looking patterns and better replacements.
• references/style-territories.md — visual territories and how to make them product-specific.
• references/quality-gate.md — final UI/UX audit checklist.
• references/component-system.md — component architecture and design-system rules.