design-showcase-websites

Design Showcase Websites

Turn sparse briefs and scattered source material into a site that feels specific to its subject, audience, language, and purpose. Support focused landing pages, multi-page websites, and interactive web products. Use this skill as the workflow spine; combine it with any design, browser, image, product-interface, or framework skills the user explicitly names.

Core rules

• Design a conversion experience, not a collection of attractive sections.
• Derive the identity from the business, audience, place, product, and real imagery. Do not reuse the visual styling of an earlier project unless the user requests it.
• Separate verified facts from creative interpretation. Never invent addresses, prices, opening hours, reviews, clients, awards, features, or performance claims.
• Preserve original user assets. Optimize copies inside the project and document generated or temporary imagery.
• Choose language from the audience and brief. Never assume Korean, Chinese, English, Japanese, or bilingual content without evidence.
• Treat localized typography, line breaking, punctuation, reading order, content density, and culturally familiar actions as part of the design.
• Prefer one strong art direction over a collage of fashionable effects.
• When the user grants creative freedom, infer and commit to a justified direction instead of asking them to design the site for you.
• Make the prototype genuinely clickable and demonstrable when implementation is requested. Do not stop at a written concept unless the user asks only for strategy.
• Keep all essential information visible without animation and honor reduced-motion preferences.

Choose the engagement mode

1. Concept only: Produce positioning, page flow, visual direction, and key-screen descriptions. Do not mutate files unless asked.
2. Prototype: Build a responsive, runnable single-page or multi-page site with working primary interactions and presentation-quality content.
3. Redesign: Audit the existing page and repository first, preserve functional requirements and the current stack, then improve the interface.
4. Polish: Inspect the live or local page, identify the highest-impact gaps, implement focused changes, and re-verify.
5. Web product: Design task flows, states, navigation, and data presentation; pair this skill with a product-interface skill when the work is application-heavy.

When no repository exists, choose the simplest maintainable stack that fits the interaction needs. When a repository exists, inspect its conventions and reuse them.

Workflow

1. Frame the outcome

Resolve only decisions that materially change the result:

• audience and locale;
• site type, content scale, and whether the experience is single-page, multi-page, or application-like;
• primary and secondary conversion actions;
• delivery form and required interactions;
• source material and usage rights;
• desired first impression and unacceptable directions;
• launch constraints such as stack, route, viewport, or port.

Ask at most three compact questions at a time. If the user grants creative freedom and the evidence is sufficient, state reasonable assumptions and proceed.

For sparse briefs, map links, or mixed local assets, read discovery-and-research.md before gathering content.

Read site-types-and-localization.md when choosing information architecture, working in Chinese, English, Japanese, Korean, or building a multilingual experience.

2. Build a source-of-truth ledger

Inspect provided links, map listings, existing sites, files, images, and videos. Record:

• the verified value;
• its source and verification date;
• whether it can be published directly;
• anything requiring owner confirmation.

Keep operational facts centralized in data or content files instead of scattering them through components. Label placeholders explicitly. If public information conflicts, prefer the business-owned or most recently updated source and flag the conflict.

3. Define the conversion story

Write these before choosing visual effects:

• the one sentence visitors should remember after ten seconds;
• the primary CTA and one optional secondary CTA;
• a belief ladder from first impression to action;
• three to five proof points already supported by evidence;
• the minimum information needed to remove hesitation.

Create or update PRODUCT.md in implementation projects with audience, purpose, positioning, conversion, proof, voice, anti-references, and accessibility expectations.

4. Establish a specific art direction

Name one concept that combines category truth with an emotional promise and a deliberate contrast. Examples of useful contrasts include energetic but disciplined, local but editorial, technical but human, or premium but welcoming.

Set design dials before implementation:

• design variance, 1–10;
• motion intensity, 1–10;
• information density, 1–10;
• color strategy;
• photography strategy;
• typography strategy.

Create or update DESIGN.md with concept, tokens, type, layout, image treatment, motion, and responsive behavior. Read direction-and-structure.md when selecting the concept, page architecture, or media treatment.

Avoid automatic visual defaults: generic black-neon fitness styling, generic beige restaurant styling, decorative glass panels, random bento grids, glow without meaning, excessive pills, uniform cards, and repeated fade-up sections.

5. Compose the page around decisions

Choose the information architecture from the site's purpose. For multi-page work, define the smallest complete sitemap, global navigation, page-specific goals, and cross-page conversion path before styling individual sections. For web products, prioritize task completion and state coverage over marketing rhythm.

Use only the sections needed for the visitor's decision. A common conversion-page flow is:

1. hero with the promise and primary action;
2. immediate proof;
3. signature offering or product value;
4. experience, process, or differentiators;
5. practical details that remove objections;
6. location, contact, booking, purchase, or inquiry;
7. decisive final CTA.

Vary composition through scale, rhythm, crop, whitespace, and editorial alignment—not through arbitrary component variety. On mobile, keep the most valuable action within easy reach when appropriate, such as call, navigation, booking, buy, sign up, search, save, or continue.

6. Write content as interface

• Write in the audience's primary language first; add other locales only when required.
• Use short, direct headings that fit the visual rhythm.
• Replace generic claims with supported specifics.
• Keep CTA labels literal and culturally familiar.
• Test target-language line breaks at real widths; do not approve layout using English placeholders.
• Test every supported locale independently. Do not assume a translation fits the source-language component.
• Use real content rather than lorem ipsum.

7. Build the prototype

• Use semantic page structure and reusable tokens.
• Make links, calls, navigation, forms, menus, filters, galleries, and modals work at the level implied by the prototype.
• Optimize large images to appropriate web formats and sizes; retain meaningful crop focal points.
• Use motion to clarify hierarchy, reveal spatial relationships, or reinforce brand character. Keep it sparse and interruptible.
• Provide keyboard focus, meaningful alt text, sufficient contrast, 44px touch targets, and safe-area-aware mobile controls.
• Preserve essential content when JavaScript motion does not run.

Read prototype-and-qa.md before implementation or final review.

8. Verify in a real browser

Do not declare completion from a successful build alone. Verify at minimum:

• wide desktop around 1440px;
• intermediate/tablet width;
• mobile around 390px;
• narrow mobile around 375px;
• one reduced-motion or keyboard pass.

Inspect the hero and the complete page. Check target-language wrapping, image crops, horizontal overflow, safe areas, sticky controls, console errors, links, forms, menus, focus order, loading behavior, and final CTA reachability. Fix discovered issues and repeat the affected check.

Expected handoff

For a runnable prototype, deliver:

• working source and a successful production build;
• a local preview or clear run command;
• PRODUCT.md and DESIGN.md when the project warrants them;
• a source/placeholder note for operational facts and media;
• a concise list of implemented interactions and validated viewports;
• a short owner-confirmation list for facts that may change before launch.

Lead the final response with the preview or primary artifact. Mention only the most important design decisions and validation results.

Quality gate

Do not hand off until all are true:

• Specificity: The site could not be relabeled for a random competitor without redesign.
• Authenticity: Claims and media are real, sourced, or clearly marked as provisional.
• Conversion: The next action is obvious within seconds and remains easy on mobile.
• Hierarchy: One idea dominates each viewport; typography and imagery support it.
• Responsiveness: Compositions adapt intentionally rather than merely stack.
• Restraint: Motion and effects have a role; the site does not feel like an effects demo.
• Inclusion: Keyboard, contrast, touch targets, reduced motion, and semantic structure are covered.
• Reliability: Build, console, assets, and critical interactions are verified.