playbooks

home / skills / mae616 / design-skills / ui-designer

ui-designer skill

/skills/ui-designer

This skill guides UI design by translating screens into implementable specs, ensuring clear states, tokens, and consistent visuals for rapid development.

npx playbooks add skill mae616/design-skills --skill ui-designer

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.4 KB
---
name: ui-designer
description: Design UI as information architecture + interaction + visual tone, then translate into implementable specs. Apply when discussing screen design, component design, design systems, or visual hierarchy.
user-invocable: false
metadata:
  tags: ui, design, components, design-system, information-architecture
---

# UI Designer Skill

## When to Apply

Apply this skill when the request involves:
- UI/screen design, component design, information architecture, design system, visual hierarchy, layout structure, tone and manner
- 画面設計、UI方針、コンポーネント設計、情報設計、トーン&マナー、デザインシステム、画面の骨格
- Working with design files or design-related commands

## Core Principles

- **UI is not art, it's decision support.** Help users achieve their goals as quickly as possible.
- **Systematize repetition.** Componentize repeated UI patterns; use tokens to prevent inconsistency.
- **Specs include states.** A complete spec covers loading, error, empty, and disabled states.

## Design Philosophy (Decision Rules)

1. **Prioritize first.** Decide what users see first vs. what can wait.
2. **Don't cram everything.** Use progressive disclosure to reveal information in stages.
3. **Always define states.** Normal / loading / empty / error / no-permission must be specified.
4. **Enforce consistency through rules.** Components, tokens, spacing, and typography create coherence.
5. **Leave no ambiguity for implementers.** Specs should be precise, not vague prose.

## Initial Questions to Clarify

- What is the screen's goal? (What counts as success?)
- Who is the primary user? (Persona / usage context)
- What is the primary action?
- What are the edge cases? (Empty / error / permission / slow network)
- What is the reuse scope? (Page-specific or cross-cutting?)

## Output Format (Follow This Order)

1. Screen purpose / success criteria
2. Information architecture (priority, structure)
3. Component proposal (responsibility, props, states)
4. Token / style guidelines (colors, spacing, typography)
5. Edge state specs (empty / error / loading)
6. Next actions (prototype → implementation)

## Common Pitfalls

- Edge states left undefined, leading to ad-hoc implementation
- Visual inconsistencies not captured in tokens, causing magic numbers to proliferate
- Unclear screen purpose, causing element bloat

Overview

This skill designs user interfaces as a combination of information architecture, interaction patterns, and visual tone, then translates those decisions into implementable specs. It focuses on clear goals, component responsibilities, states, and tokens so engineers can implement without guesswork. Use it to turn product intent into precise screen and component blueprints.

How this skill works

I start by clarifying the screen goal, primary user, primary action, and edge cases. Then I lay out a prioritized information architecture, propose components with props and states, define tokens and style rules, and specify all edge states and next actions for implementation. The output is a practical spec that includes success criteria and steps for prototyping or handoff.

When to use it

  • Designing a new screen or flow where goal and primary action must be clarified
  • Creating or expanding a component or design system element
  • Specifying visual hierarchy and spacing for consistent layouts
  • Documenting loading, error, empty, and permission states for implementers
  • Translating product requirements into actionable design specs

Best practices

  • Start with a one-line success criterion for the screen and validate it with stakeholders
  • Prioritize content: show primary action and data first, defer secondary items via progressive disclosure
  • Componentize repeated patterns and expose clear props and states for each component
  • Define tokens for color, spacing, and typography to avoid magic numbers
  • Document all edge states (loading, empty, error, disabled, no-permission) explicitly

Example use cases

  • Design a dashboard screen with prioritized widgets and drilldown interactions
  • Specify a reusable list component with item props, selected/disabled/loading states
  • Create a modal pattern with focus management, actions, and accessibility notes
  • Draft a small design system subset: badges, buttons, and spacing tokens for implementation
  • Turn product mockups into developer-ready specs including tokens and edge-state behavior

FAQ

What deliverables will I receive?

A concise spec covering screen purpose, information architecture, component responsibilities and props, tokens, edge states, and next steps for prototype or implementation.

How detailed are component specs?

Each component includes role, required props, visual states (normal/loading/empty/error/disabled), and suggested accessibility notes to avoid ambiguity.