Skill detail

product-design

Directly supports production-quality UX structure, interaction, states, and reviews.

MatchDirectReviewed for product designers
Sourcesyntheticrecon/synthetic-skillsExternal source
Reported installs6Popularity signal only

Inspect before use

Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from review. The external source remains the complete and most current version.

---
name: product-design
description: Designs and reviews production-quality user experiences for web and desktop applications with strong information hierarchy, interaction design, and state management. Use when building interactive apps, dashboards, admin panels, settings flows, multi-step workflows, or data-dense interfaces where the product needs to feel real and operational rather than decorative. Also use for UX reviews, critiques, and audits of existing product interfaces — "review my dashboard UX", "critique this flow", "audit this screen", or complaints about missing loading/empty/error states, modal overuse, or interfaces that feel like a demo. Other triggers include "make it feel like Linear", "production-quality UX", "real app feel", "good UX", or requests involving command palettes, keyboard shortcuts, inline editing, progressive disclosure, dense tables, or multi-screen flows. Pair with a visual design skill when the user also needs styling, theming, or brand expression.
---

# Product Design

I help turn vague UI requests into product-quality interaction decisions. I focus on how the product works, what the user sees first, which actions stay on the critical path, and how the interface behaves across empty, loading, error, and edge states.

Use me for UX structure and interaction behavior. Pair me with a visual design skill when the user also needs aesthetic direction, theming, or brand polish.

## Workflow

1. Classify the product paradigm and load the matching reference file.
2. Enter plan mode before multi-screen, multi-file, or architecture-shaping implementation work.
3. Write down the job to be done, hierarchy, critical path, and state inventory before coding.
4. Choose interaction, layout, and data presentation patterns that fit the product paradigm.
5. Build or review the interface with keyboard support, accessibility, and realistic product states.

## Step 0: Choose The Paradigm

Read the closest matching reference before making UX decisions:

- **Power-user / keyboard-first tools**: [references/power-user-patterns.md](references/power-user-patterns.md)
- **Consumer / prosumer apps**: [references/consumer-patterns.md](references/consumer-patterns.md)
- **B2B SaaS / data-dense dashboards**: [references/b2b-data-patterns.md](references/b2b-data-patterns.md)

Use these signals to choose:

- **Power-user**: Users spend hours per day in the product, value speed, and benefit from dense layouts and shortcuts.
- **Consumer**: The audience is broad, the experience must feel obvious, and mobile or onboarding quality matters heavily.
- **B2B data**: The primary job is analyzing data, monitoring systems, configuring operations, or managing records at scale.

If the paradigm materially affects the result and the request is still ambiguous, use `AskUserQuestion` to present these options:

- **Power-user**: Faster, denser, keyboard-first workflows for expert repeat users.
- **Consumer**: More obvious, guided, touch-friendly flows for broad audiences.
- **B2B data**: Data-dense tables, filters, dashboards, and operational workflows.

When a follow-up would only add delay, state the assumption you are making and proceed with the closest fit.

## Step 1: Think Before Coding

Do not jump straight to implementation for non-trivial UI work. Write the minimum viable UX brief first.

### 1a. Job To Be Done

State the user's job in one sentence:

`The user needs to _____ so they can _____.`

This sentence filters every later decision. If an element does not support the job, cut it.

### 1b. Information Hierarchy

Rank every element by importance:

- **Primary**: The main task or information the user came for.
- **Secondary**: Context that helps the user complete the primary task.
- **Tertiary**: Useful but non-urgent details revealed through progressive disclosure.
- **Remove**: Anything that does not earn space on the screen.

Ask: "If the user only saw this screen for two seconds, what should they remember?"

### 1c. Critica
Read the full source on GitHub (opens external page)
Context

Related work