iyuyoung/young-design

Young Design

Create websites that feel young, authored, and product-led without becoming childish, decorative, or generic. Treat visual quality and implementation quality as one system. Adapt the visual expression to the product rather than applying a fixed house style.

Select the task mode

Choose one mode before working:

• Direction: define the visual language, page hierarchy, tokens, and representative components.
• Design: create a complete page or mockup with realistic content and responsive intent.
• Implementation: translate an approved direction or reference into production code.
• Refinement: audit an existing site, identify the highest-impact gaps, and improve it without destabilizing behavior.
• Review: provide evidence-based visual feedback without modifying files unless asked.

If the user asks for design only, do not implement the production project. If the user asks to build or optimize the site, carry the work through verification.

Establish the design contract

Before choosing colors or components, determine:

1. Audience — who arrives and what emotional state they bring.
2. Promise — the one thing the first viewport must make clear.
3. Primary action — the most valuable next step.
4. Personality — three useful adjectives and three qualities to avoid.
5. Constraints — framework, brand assets, SEO, performance, accessibility, print, or deployment requirements.

Infer these from the repository, brief, and prior decisions when possible. Ask only when a missing answer would materially change the design.

Then define a design fingerprint from 1–5 for warmth, playfulness, tactility, density, precision, and visual contrast. Record the scores and one sentence explaining the resulting direction. Do not give unrelated products the same fingerprint by default.

Use realistic product copy and representative data. Lorem ipsum, generic dashboards, and invented social proof conceal hierarchy problems.

Build the visual system before the page

Read references/visual-language.md when defining or changing the look and feel. Derive one dominant visual motif from the product, audience, or workflow; paper and collage are options, not defaults.

Create a small coherent system:

• color roles, not a bag of colors;
• display, body, and optional annotation typography;
• spacing rhythm and content widths;
• border, radius, shadow, and material rules;
• icon and illustration language;
• interaction and motion behavior;
• desktop, tablet, and mobile composition rules.

Use design tokens or shared variables. Avoid styling each section as an isolated poster.

Preserve distinction between:

• brand layer — recognizable voice, mark, colors, typography;
• product layer — task flow, controls, states, feedback;
• content layer — hierarchy, scanning, trust, SEO copy;
• material layer — paper, tape, pencil, texture, or collage accents.

Material details must support hierarchy. Keep them sparse enough that the product remains credible and usable.

Compose around the product moment

Do not default to a headline on the left and an arbitrary dashboard screenshot on the right. Identify the moment that proves the product works: a recommendation, preview, result, transformation, worksheet, comparison, or next step.

The first viewport should usually contain:

• a specific promise;
• one legible product moment;
• one primary action;
• concise trust or constraint cues;
• enough asymmetry or material character to feel authored.

Make secondary sections answer distinct questions. Do not repeat the same card grid under different headings.

Read references/component-patterns.md when choosing hero, chooser, card, tool, directory, or editorial patterns.

Deliver the right artifact

Read references/output-contracts.md and follow the contract for the selected task mode. Make assumptions, decisions, responsive intent, and verification evidence explicit enough for another designer or engineer to continue the work.

Implement as a real system

Read references/implementation-playbook.md before modifying a repository or translating a reference into code.

When working in an existing project:

1. Inspect the framework, routes, shared layouts, tokens, components, tests, and generated assets.
2. Separate intentional source changes from generated output and formatting noise.
3. Preserve behavior contracts, URLs, analytics hooks, test selectors, semantics, and print rules.
4. Add or revise shared foundations before page-specific overrides.
5. Implement reusable components for repeated visual and behavioral patterns.
6. Check all meaningful states: initial, selected, hover, focus, loading, empty, error, success, and print when applicable.
7. Validate at desktop, tablet, and narrow mobile widths.

Prefer local or self-hosted fonts, SVG marks, and a consistent icon library. Use generated imagery only when it carries real narrative value. Do not compensate for weak hierarchy with decorative images.

Refine in impact order

When a site feels “old,” “generic,” or “not like the design,” fix issues in this order:

1. typography character and hierarchy;
2. first-viewport composition;
3. spacing rhythm and content density;
4. component geometry and interaction states;
5. color roles and contrast;
6. material details and micro-decoration;
7. motion and polish.

Do not start by adding shadows, gradients, blobs, or animations. Those rarely repair a weak composition.

Verify before calling it done

Read references/quality-gates.md for implementation or final review. Read references/review-rubric.md when deciding whether a result is ready to present, ship, or publish.

At minimum, verify:

• no accidental horizontal page overflow;
• visible interface text is at least 14px unless it is nonessential artwork;
• normal text contrast meets 4.5:1 and large text meets 3:1;
• keyboard focus is clear and interactive controls are comfortably touch-sized;
• mobile is recomposed rather than merely shrunk;
• type, radii, shadows, icons, and materials remain consistent;
• the implemented first viewport preserves the approved design's hierarchy;
• functionality, SEO structure, generated files, downloads, and print output still work;
• type checks, tests, build, and browser checks pass when the project provides them.

Require a score of at least 85/100 with no critical blocker before calling a result release-ready. Use the score diagnostically; do not inflate it to satisfy the threshold.

If browser execution is unavailable locally, state the environmental limitation and use the project's CI rather than claiming visual verification.

Avoid Young Design failure modes

Never default to:

• generic startup gradients and floating glass cards;
• an old-fashioned serif as the main source of “personality”;
• excessive pill shapes, oversized radii, or uniform card grids;
• pastel color everywhere with insufficient contrast;
• random rotations, tape, doodles, or paper textures on every element;
• tiny metadata and labels used to manufacture sophistication;
• mobile layouts that hide core product value or force page-level horizontal scroll;
• rewriting working product logic solely to accommodate a visual redesign;
• copying one reference literally across unrelated brands.
• applying warm paper, pastel colors, or rounded cards when the domain calls for sharper, denser, or more technical expression.

The result should feel authored, useful, and current: friendly without being childish, expressive without being noisy, and polished without feeling sterile.