Skip to content
Development
Skill

/frontend-design

Create distinctive, production-grade frontend interfaces with top-tier product design and UI/UX quality. Use this skill when the user asks to build web components, pages, or applications. Combines product thinking, UX discipline, and creative visual design.

From plugin
ultraship
12245 skills13 agents16 commands3 hooks
+1
Install
$ npx -y skills add Houseofmvps/ultraship --skill frontend-design --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/frontend-design

Context preview

The summary Claude sees to decide when to auto-load this skill.

Create distinctive, production-grade frontend interfaces with top-tier product design and UI/UX quality. Use this skill when the user asks to build web components, pages, or applications. Combines product thinking, UX discipline, and creative visual design.

SKILL.md

frontend-design.SKILL.md
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with top-tier product design and UI/UX quality. Use this skill when the user asks to build web components, pages, or applications. Combines product thinking, UX discipline, and creative visual design.
license: Complete terms in LICENSE.txt
argument-hint: "<component-or-page-description>"
paths: ["**/*.tsx", "**/*.jsx", "**/*.css", "**/*.html"]

This skill combines three disciplines: **product design** (does it solve the right problem?), **UX design** (can users accomplish their goals without friction?), and **visual design** (is it distinctive and polished?). All three must be present. Beautiful but unusable is a failure. Usable but ugly is a failure. Both beautiful and usable but solving the wrong problem is the worst failure.

The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

Product Design Thinking

Before touching aesthetics, think like a product designer:

**1. User Intent**

  • What is the user trying to accomplish on this page/component?
  • What is the ONE primary action? (every screen has one — if you can't identify it, the design is confused)
  • What information does the user need to make a decision? Show that, hide everything else.

**2. Information Hierarchy**

  • What should the user see FIRST? (headline, hero, key metric, CTA)
  • What should they see SECOND? (supporting evidence, features, social proof)
  • What can they discover on scroll or click? (details, secondary actions, edge cases)
  • Apply the 5-second test: if someone sees this page for 5 seconds, do they know what it does and what to do next?

**3. Conversion Design**

  • Every page has a goal. What is it? (signup, purchase, upgrade, share, learn)
  • Is the primary CTA visible without scrolling?
  • Is there a clear value proposition above the fold?
  • Are there unnecessary choices that create decision paralysis? Reduce them.
  • Does the page have social proof near the CTA? (testimonials, user count, logos, ratings)

**4. User Psychology**

  • **Cognitive load**: Fewer choices = more action. Hick's Law — every option added increases decision time.
  • **Loss aversion**: "Don't lose your progress" converts better than "Save your progress."
  • **Anchoring**: Show the recommended plan in the middle. Show the expensive plan first so the middle feels reasonable.
  • **Social proof**: "2,847 teams use this" near the signup button. Specific numbers beat vague claims.
  • **Progress indication**: Show users where they are in multi-step flows. Completion drives commitment.

UX Design Discipline

**Interaction Design:**

  • Every interactive element must have 4 states: default, hover, active, disabled. Missing states feel broken.
  • Loading states for every async operation. Show skeleton screens, not spinners (skeletons preserve layout and feel faster).
  • Empty states with actionable guidance ("No projects yet. Create your first one."), not blank screens.
  • Error states that explain what went wrong AND how to fix it. "Something went wrong" is not a UX — it's giving up.
  • Success states with clear next-step guidance. "Saved!" then what? Guide the user forward.

**Navigation & Wayfinding:**

  • Users should always know: where they are, where they can go, and how to get back.
  • Breadcrumbs for deep hierarchies. Active state on current nav item. Back buttons that go where expected.
  • Mobile navigation: hamburger menu for secondary pages, bottom tab bar for primary actions (thumb zone).
  • Maximum 7 items in any navigation level (Miller's Law). More than 7 = reorganize, don't scroll.

**Form Design (where most UX fails):**

  • One column. Always. Two-column forms have measurably lower completion rates.
  • Labels above fields, not inside (placeholder text disappears on focus — users forget what the field is for).
  • Inline validation on blur, not on every keystroke. Show errors next to the field, not in a banner at the top.
  • Auto-focus the first field. Auto-advance in multi-step flows. Pre-fill what you can.
  • Submit buttons that say what they do ("Create Account") not generic ("Submit").
  • Show password requirements BEFORE the user types, not after they fail validation.

**Accessibility (not optional):**

  • Semantic HTML: `<button>` for actions, `<a>` for navigation, `<nav>`, `<main>`, `<header>`, `<footer>`.
  • Color contrast: 4.5:1 minimum for text, 3:1 for large text and UI components (WCAG AA).
  • Keyboard navigation: every interactive element reachable via Tab. Focus ring visible. Escape closes modals.
  • Screen reader support: `aria-label` on icon-only buttons, `aria-live` for dynamic content, `alt` text on meaningful images, `role` on custom widgets.
  • Touch targets: minimum 44x44px on mobile (Apple HIG). Don't make users precision-tap.
  • Motion: respect `prefers-reduced-motion`. Provide alternatives for animation-dependent interfaces.

**Responsive Design:**

  • Design mobile-first, then scale up. Not the other way around.
  • Breakpoints: 640px (mobile), 768px (tablet), 1024px (desktop), 1280px (wide). Use your framework's system.
  • Touch interactions on mobile, hover interactions on desktop. Don't rely on hover for critical functionality.
  • Typography scales: smaller on mobile, larger on desktop. Use clamp() for fluid sizing.
  • Images: serve appropriate sizes. A 2400px hero image on a 375px phone is a performance crime.

**Performance as UX:**

  • A page that loads in 1s feels instant. 3s feels slow. 5s and users leave.
  • Lazy load below-the-fold images and components.
  • Defer non-critical JavaScript. Inline critical CSS.
  • Skeleton screens for data-dependent sections — they make perceived load time 30% faster.
  • Measure: if Lighthouse performance is below 80, the UX is degraded regardless of how good it looks.

Visual Design — The Aesthetic Direction

Before coding, commit to a BOLD aesthetic direction:

  • **Tone**: Pick an extreme
Read more
Ships withultraship

"ULTRASHIP" Claude Code plugin — 39 skills, 33 tools, 11 agents for ship-ready workflows: planning, review, pentesting, safety guardrails, canary monitoring, SEO/AI-readiness check, penetration testing, code review, competitive analysis, incident response. 1 dependency. 180 tests. MIT.

Get the whole plugin

Other skills on ultraship.