# Semantic Landing Design > Use whenever designing, auditing, redesigning, or implementing landing pages, marketing websites, SaaS sections, heroes, pricing, roadmap, FAQ, bonuses, onboarding, partner/ecosystem, product demo, or conversion UI. Forces meaning-first visual metaphors, section-specific components, purposeful motion, mobile behavior, and anti-generic design validation before user-facing frontend work. - Skill: `maybackcompany/semantic-landing-design` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add maybackcompany/semantic-landing-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/maybackcompany/semantic-landing-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: MaybackCompany (https://skillmd.com/u/maybackcompany) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/maybackcompany/semantic-landing-design --- # Semantic Landing Design Use this skill when UI work must feel designed, not assembled from generic cards. It translates product meaning into visual structure, motion, and acceptance criteria before code. ## Activation Rule For landing pages, marketing sites, SaaS/product pages, conversion sections, pricing, FAQ, roadmap, benefits, bonuses, testimonials, product demos, or ecosystem/partner sections: 1. Use this skill before implementing or reviewing the UI. 2. Inspect the existing brand/design system first. 3. Preserve project tokens and site DNA unless the user explicitly asks for a new direction. 4. If the user provides reference websites, screenshots, or extracted design artifacts, ground the design in those references. For generic backend, data, infrastructure, CLI, or algorithm work with no user-facing interface, do not use this skill. ## Required Design Chain Before editing a section, define this chain in your implementation notes: | Step | Requirement | |---|---| | Purpose | What job does this section do for the user or buyer? | | User state | What is the user feeling or deciding here? | | Visual metaphor | What should the section symbolize visually? | | Component structure | What custom primitives are needed beyond generic cards? | | Motion | What movement proves or reinforces the metaphor? | | Mobile behavior | How does the metaphor survive below 768px? | | Accessibility | Keyboard, focus, contrast, semantics, labels, reduced motion. | | Acceptance | How will we know it is not generic? | If a section can be replaced by normal cards without losing meaning, it is not finished. ## Semantic Pattern Map Use these as defaults when the product context does not provide a better metaphor: | Section | Meaning | Better Visual Metaphor | Useful Primitives | |---|---|---|---| | Hero | First proof of product identity | Product object, signature scene, operating surface | `HeroScene`, `ProductSurface`, `ProofRibbon` | | Roadmap | From confusion to clear path | Map, route, labyrinth, checkpoints | `RoadmapLabyrinth`, `AnimatedRouteLine`, `PathCheckpoint` | | How it works | Removes uncertainty | Process rail, pipeline, operating sequence | `ProcessRail`, `StepNode`, `ConnectorLine` | | Bonuses | Extra value received | Gift, vault, reward bundle, claimed perk | `GiftVault`, `BonusUnlockCard`, `RewardBadge` | | FAQ | Doubts becoming answers | Question maze, answer path, person asking | `QuestionMaze`, `QuestionAvatar`, `AnswerAccordion` | | Diagnostic | See hidden problems | X-ray, scan, report, health system | `ScanPanel`, `HealthScore`, `ReportRows` | | Pricing | Choose the right fit | Product ladder, decision matrix | `PlanLadder`, `FitSelector`, `ComparisonGrid` | | Ecosystem | Compatibility and credibility | Network, orbit, connected tools | `EcosystemMap`, `OrbitChip`, `ConnectorGraph` | | Proof | Trust without invention | Evidence wall, receipt strip, public metrics | `ProofWall`, `MetricReceipt`, `LogoRail` | Read `references/semantic-section-patterns.md` when building one of these sections and you need more detailed acceptance criteria. ## Motion Rules Motion must explain state, path, reveal, or feedback. - Animate only `transform`, `opacity`, SVG stroke progress, or canvas/WebGL internals. - Respect `prefers-reduced-motion`. - Keep common UI transitions short: 100ms, 200ms, 280ms, 420ms, or 800ms when a section reveal needs weight. - Avoid random floating cards, decorative motion, and animation that makes pricing or forms feel untrustworthy. - Use scroll-linked or long-running motion only when the metaphor needs it, such as route drawing, diagnostic scanning, or marquee proof. ## Anti-Generic Gate Reject or revise designs that contain: - Generic AI SaaS visuals, purple gradients, random glow blobs, bokeh/orb backgrounds, fake glass, or decorative blur. - Repeated same-size card grids for every section. - Random icons that do not explain the section. - Placeholder proof, invented testimonials, fake logos, or unverifiable claims. - A roadmap that is only a vertical list or basic timeline. - A bonus section that is only a feature list. - FAQ that is only a plain accordion when the brief asks for personality. - Buttons, tabs, toggles, forms, or cards without hover/focus/active/selected/disabled states where relevant. - Mobile layouts where the metaphor disappears, overlaps, or requires horizontal page scroll. ## Implementation Workflow 1. **Inspect** Read nearby components, CSS/tokens, design docs, brand assets, and existing page sections. If references exist, extract or inspect their palette, type, component anatomy, motion, spacing, and section rhythm. 2. **Plan briefly** State the design chain. Keep it short unless the user asked for a full audit or PRD. 3. **Create custom primitives** Prefer named primitives that encode meaning, such as `RoadmapLabyrinth`, `GiftVault`, `QuestionMaze`, or `ServerXRayPanel`. Do not solve all sections with `Card`, `Badge`, `Grid`, and `Accordion`. 4. **Implement within the existing system** Use the project’s framework, tokens, CSS variables, component library, and file organization. Do not add dependencies unless the section cannot be done well without them. 5. **Validate** Check desktop and mobile rendering when possible. Verify no horizontal overflow, readable text, accessible focus, reduced motion, and purposeful animation. Run the smallest relevant code checks. ## Review Checklist Before finalizing a design change: - Every major section has one clear job. - Every major section has a visual metaphor tied to its meaning. - Components are section-specific where meaning requires it. - Motion reinforces the metaphor or interaction state. - Mobile preserves the concept without overlap or tiny unreadable elements. - Light/dark behavior is intentional if the project supports themes. - Copy is specific and avoids hype. - Proof is real or clearly marked as pending. - The page does not read as a generic SaaS template. When validating agent-built design work, use `bot-validator` as the review lens after implementation.