Provided by TippyEntertainment

https://github.com/tippyentertainment/skills.git

UI/UX Designer Skill

1. Research and Discovery
2. Define Requirements
3. Information Architecture (IA)
4. Wireframing
5. UI Design

• Use

  target

  to document which product or website the skill primarily supports.
• Keep

  name

  and

  description

  present; other frontmatter keys like

  tags

  or

  priority

  are optional.

When to Use This Skill

• The user asks for a new feature, screen, flow, or product experience.
• Requirements are fuzzy, underspecified, or conflict with each other.
• Existing UX is confusing, inconsistent, or needs a redesign.
• Other agents need structured UX artifacts (requirements, flows, wireframes, specs).

• Small visual tweaks to an already well-specified component (e.g., “make this button blue”).
• Pure copywriting or content-only tasks.
• Pixel-perfect Figma implementation details tied to a specific team’s design system.

Overall Workflow

1. State the current phase.
2. Summarize the inputs you are using.
3. Produce concrete outputs/deliverables.
4. List assumptions and open questions.

1. Research and Discovery
2. Define Requirements
3. Information Architecture (IA)
4. Wireframing
5. UI Design

Phase 1 – Research and Discovery

Tasks

• Clarify business goals and success metrics.
• Identify primary users/personas and their goals.
• Understand the current workflow or status quo (what users do today).
• Capture constraints: platform, technical limits, compliance, brand.

Outputs

• Problem Statement: 2–4 sentences.
• Primary Users: bullet list with 1–3 user types.
• Goals and Jobs-to-be-Done: bullet list.
• Key Constraints/Assumptions: bullet list.
• Open Questions: what you would ask a PM/Stakeholder.

Phase 2 – Define Requirements

Tasks

• Derive user stories from the problem statement and user goals.
• Cover “happy path” and common edge cases.
• Separate must-have vs nice-to-have.
• Include non-functional requirements relevant to UX (accessibility, responsiveness, performance).

Outputs

• User Stories:

  As a <user>, I want <action> so that <outcome>.

• Acceptance Criteria: bullet list for each critical story.
• Constraints: anything that limits the solution (e.g., must reuse existing navigation).
• Risks / Tradeoffs: where requirements might conflict.

Phase 3 – Information Architecture (IA)

Tasks

• Define the main entities and sections (e.g., Dashboard, Project, Task, Settings).
• Decide navigation structure (global nav, subnav, breadcrumbs, etc.).
• Map primary user flows (e.g., “Create Project”, “Invite Member”, “Checkout”).
• Consider future extensibility where reasonable.

Outputs

• IA Outline / Sitemap: indented list of main sections and key screens.
• Key Entities: short definitions of core objects.
• Primary Flows: step-by-step text for 1–3 critical journeys.

Phase 4 – Wireframing

Principles

• Focus on layout, grouping, hierarchy, and states, not colors or fine typography.
• Prefer simple, textual/ASCII descriptions that map easily to components.
• Capture key states: default, empty, loading, error (where relevant).

Tasks

• Identify key regions (e.g., header, left sidebar, main content, right panel).
• Describe which components live where (cards, tables, forms, filters, CTAs).
• Call out priority and emphasis (e.g., “primary CTA in top-right of header”).

Outputs

• Screen Name and Purpose.
• Layout Description: 3–8 bullet points describing regions and contents.
• States: any notable state variations.
• Navigation Hooks: where users can go next from this screen.

Phase 5 – UI Design

Tasks

• Apply consistent spacing, typography levels, and radius/shadow tokens.
• Choose colors that meet contrast guidelines when possible.
• Map wireframe elements to concrete components (e.g., “PrimaryButton”, “Card”, “InputField”).
• Define interaction details: hover, focus, disabled, validation messages, error display.

Outputs

• Visual Style Summary: brief description of tone (e.g., “clean, modern, dark theme, soft rounded cards”).
• Component Mapping: list of major UI pieces and which design system component they map to.
• Screen Specs: for each key screen, describe how the final UI looks, including:
  • Typography levels for headings/body.
  • Colors (referenced by token names if provided).
  • Spacing rhythm (e.g., 8px grid).
  • Border radii, shadows, and any distinctive visual patterns.

Card

Stack

Button

Input

Table

Collaboration Rules

• If given partial work (e.g., requirements already defined), validate them briefly, then continue from the next logical phase.
• If another agent (PM, engineer, researcher) provides updated info that invalidates earlier work, revise upstream artifacts first, then propagate changes forward.
• Always keep outputs short, structured, and implementation-friendly; avoid long essays.
• Prefer clarity over cleverness. If something is ambiguous, state your assumption explicitly.

Example: Short End-to-End Pass

1. Summarize problem, users, and constraints (Phase 1).
2. List 5–8 user stories and key acceptance criteria (Phase 2).
3. Propose a sitemap (Dashboard, Invoices, Clients, Settings) and outline the “Create Invoice” flow (Phase 3).
4. Describe the dashboard layout (top bar, stats row, invoice table, filters panel) in bullets (Phase 4).
5. Specify a visual direction (e.g., dark theme, soft 16–20px card radius, muted accent color) and map each region to components (Phase 5).