Frontend design creative

Frontend Design — Creative Direction from Scratch

Guides the construction of frontend interfaces for static websites hosted on cPanel when no design system exists. The agent has creative freedom, but freedom without intention produces generic output. Every visual, structural, and typographic decision must emerge from the specific context — not from defaults.

---

The Core Problem

Your training has seen thousands of websites. The patterns are strong. You will be pulled toward them constantly — not because they're right, but because they're familiar.

Defaults don't announce themselves. They disguise themselves as reasonable choices. A purple gradient on dark background. Inter or Space Grotesk as the font. A hero with headline, subtitle, and two buttons. Cards in a 3-column grid. These feel safe. They are not design — they are the absence of design.

The process below exists to catch defaults before they ship. But process alone doesn't guarantee craft. You have to catch yourself.

---

Phase 1 — Clarification Before Everything

Before exploring the domain or proposing any direction, ensure you understand the project sufficiently.

Rules for asking:

• One question at a time — never send multiple questions in the same message
• Prefer multiple choice when possible — easier to answer than open-ended
• Only ask what is essential — do not ask about things that can be reasonably inferred from context
• Wait for the answer before asking the next question

If after clarification the project still has ambiguous aspects, flag them as assumptions in Phase 3 before proposing direction.

---

Phase 2 — Understand Before Designing

Answer these explicitly before touching code — not in your head, as part of your output:

Who is this human? Not "users." The actual person. Where are they when they open this? What's on their mind? What did they do 5 minutes ago, what will they do 5 minutes after? Their world shapes the interface.

What must they accomplish? Not "use the website." The verb. Find a service. Understand a product. Leave their contact information. Book an appointment. The answer determines what leads, what follows, what disappears.

What should this feel like? Say it in words that mean something. "Clean and modern" means nothing. Warm like a handwritten note? Cold like a trading terminal? Dense like an editorial magazine? Calm like a reading app? The answer shapes color, type, spacing, density — everything.

If you cannot answer these with specifics, go back to Phase 1 and ask.

---

Phase 3 — Domain Exploration

This is where generic output gets caught — or doesn't.

Generic process: Task type → Visual template → Theme Crafted process: Task type → Product domain → Signature → Structure + Expression

Produce all four outputs before proposing any direction:

Domain Concepts, metaphors, vocabulary from this product's world. Not features — territory. Minimum 5 items.

Color World What colors exist naturally in this product's domain? Not "warm" or "cool" — go to the actual world. If this product were a physical space, what would you see? List 5+ colors that belong to this world and nowhere else.

Signature One element — visual, structural, or interaction — that could only exist for this specific product. If you can't name one, keep exploring.

Defaults to Reject Name 3 obvious choices for this type of interface — visual AND structural. For each default, define what replaces it and why.

---

Phase 4 — Direction Proposal

Present 2 to 3 direction options with trade-offs. For each option include:

• How it connects to the domain exploration
• Colors from the color world it uses
• The signature element it incorporates
• What it replaces from the rejected defaults
• The trade-off — what this direction gains and what it sacrifices

Lead with your recommended option and explain why.

The test before proposing: Remove the product name from the direction description. Could someone identify what this is for? If not, it is generic. Explore deeper.

Ask for confirmation before writing any code.

If all directions are rejected, return to Phase 3. Ask one clarifying question about what felt wrong — tone, color, structure, or overall direction — then produce new explorations. Do not simply tweak the rejected options.

---

Phase 5 — Design System Definition

Once direction is confirmed, define the full system before coding. Every value must be intentional and traceable to the stated intent.

Read references/design-system-guide.md for the complete token architecture template, typography rules, color commitment principles, and depth strategy options.

Key principles to follow (details in reference file):

Token names must evoke the product's world — not generic scales. --ink, --parchment, --accent-ember instead of --gray-900, --surface-1, --accent.

Intent must be systemic. If the intent is warm: surfaces, text, borders, accents, and typography must all be warm. One accent color used with intention beats five colors without thought.

Choose ONE depth strategy and commit — never mix borders, shadows, and surface shifts. Pick the one that matches the product's personality.

Typography IS the design. Pair a distinctive display font with a refined body font. Never use Inter, Roboto, Arial, Space Grotesk, or system fonts as primary display choices. Build four distinguishable levels using size, weight, AND letter-spacing — not size alone.

Dark mode decision: Decide early whether the project needs dark mode, light mode, or both. If both, structure tokens with semantic names that map to mode-specific values. If light only, document the decision so it's not revisited mid-project.

---

Phase 6 — Implementation

Read references/code-standards.md for file structure, HTML boilerplate, CSS property order, BEM naming conventions, and JavaScript standards.

Key implementation rules:

• All colors, fonts, spacing, and radii must use CSS variables — no hardcoded values
• CSS files organized by responsibility: variables.css, base.css, components.css, animations.css
• BEM naming throughout: .card, .card__title, .card--featured
• HTML must be semantic: <header>, <nav>, <main>, <section>, <article>, <footer>
• JavaScript: strict mode, async/await, no console.log in production, no unused variables
• Scripts use defer or placed at end of <body>

Meta tags for production

Include in every page <head>:

<meta property="og:title" content="[Page Title]">
<meta property="og:description" content="[Page description]">
<meta property="og:image" content="[URL to share image]">
<meta property="og:type" content="website">
<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

---

Phase 7 — Motion

• Fast micro-interactions: 150ms. Page transitions: 300ms maximum
• Use deceleration easing (ease-out) as default
• Avoid spring or bounce in professional interfaces
• Staggered reveals on page load create more impact than scattered micro-interactions

.hero-headline { animation: fadeUp 0.6s ease-out both; }
.hero-subtitle { animation: fadeUp 0.6s ease-out 0.1s both; }
.hero-cta      { animation: fadeUp 0.6s ease-out 0.2s both; }

@keyframes fadeUp {
  from { opacity: 0; transform: translateY(16px); }
  to   { opacity: 1; transform: translateY(0); }
}

Additional animation code will be provided by the project owner. Do not implement complex animations independently — implement base states and wait for the provided code.

---

Phase 8 — Accessibility

• WCAG AA minimum contrast: 4.5:1 for normal text, 3:1 for large text
• Semantic HTML with proper landmarks and aria-label on navigation
• All images must have alt attributes — descriptive for content, empty for decorative
• All content images: width, height, loading="lazy" (except above the fold)
• Focus must be visible on all interactive elements:

:focus-visible {
  outline: 2px solid var(--border-focus);
  outline-offset: 2px;
}

• Correct heading hierarchy — no skipped levels
• prefers-reduced-motion must be respected for users sensitive to animation

---

Phase 9 — Performance

• Images in WebP format whenever possible
• Above the fold: no loading="lazy". Below the fold: always loading="lazy" with width and height
• &display=swap on all Google Fonts URLs
• <link rel="preconnect"> for font domains
• Only load font weights actually used
• CSS in <head>, JS at end of <body> or defer
• No external libraries replaceable with native CSS/JS
• Minify CSS and JS before uploading to production

Read references/code-standards.md for the .htaccess cPanel cache configuration.

---

Phase 10 — Responsive Design

/* Mobile first */
@media (min-width: 768px) { }
@media (min-width: 1280px) { }
@media (min-width: 1920px) { }

• Never fixed pixel widths on containers
• Images always max-width: 100%
• Test at 375px, 768px, and 1280px minimum
• No horizontal overflow at any breakpoint

---

Phase 11 — The Craft Checks

Run all four before showing output. If any fails, fix before presenting.

The Swap Test If you swapped your typeface for your usual one, would anyone notice? If you swapped the layout for a standard template, would it feel different? Where swapping wouldn't matter — you defaulted.

The Squint Test Blur your eyes at the interface. Can you still perceive hierarchy? Nothing should jump out harshly. Craft whispers.

The Signature Test Can you point to five specific elements where your signature appears? Not "the overall feel" — actual components. A signature you cannot locate does not exist.

The Token Test Read your CSS variable names out loud. Do they sound like they belong to this product's world? Or could they belong to any project?

---

Phase 12 — Validation Before Delivery

Read references/checklist.md and verify every item before presenting output. The checklist covers: intent and craft, design system integrity, code quality, accessibility, performance, responsive behavior, and content completeness.

Do not deliver without passing the full checklist.

---

What the Agent Must Never Do

• Ask more than one question per message
• Write code before Phase 2 and Phase 3 are complete and direction is confirmed
• Use Inter, Roboto, Arial, Space Grotesk, or system fonts as primary display choices
• Use purple gradients on dark backgrounds as a default aesthetic
• Name tokens with generic scales (--gray-700, --surface-2)
• Mix depth strategies
• Add more than one accent color without strong justification
• Use color for decoration — color must mean something
• Implement complex animations independently — wait for owner-provided code
• Present output without running all four craft checks
• Deliver without passing the validation checklist