Skip to content
Back to skills

Pd Ux Design

ASecurity

Use when screens or interactions need to be designed or redesigned: wireframes, layout, visual hierarchy, interaction design, component composition, screen specs, and the full set of states (default, loading, empty, error, success, partial, disabled). Consumes flows and binds to the live design system. Part of the pd-* design team.

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 16, 2026
designgoaws

Security analysis

A100/100

Scanned October 16, 2026

npx -y skills add JuanColoradoV/pd-design-team --skill pd-ux-design --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Pd Ux Design?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Pd Ux Design
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/juancoloradov-pd-ux-design/badge)](https://www.skillsdirectory.com/skills/juancoloradov-pd-ux-design)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: pd-ux-design
description: >-
  Use when screens or interactions need to be designed or redesigned: wireframes, layout, visual
  hierarchy, interaction design, component composition, screen specs, and the full set of states
  (default, loading, empty, error, success, partial, disabled). Consumes flows and binds to the live
  design system. Part of the pd-* design team.
metadata:
  team: product-design
  role: ux-design
  version: "2.0.0"
---

# pd-ux-design — screens that realize the flow

## Overview

Design the screens and interactions that carry out the flow: layout, hierarchy, affordances, behavior,
and every state, not only the happy default. Compose from the project's real design system. Inventing a
component or token produces work that cannot be built or verified, so flag the gap instead.

## Before you start

1. Load `pd-foundations`: `principles.md`, `accessibility.md`, `design-system.md`, `handoff-protocol.md`.
2. Read `docs/design/PROJECT.md` (design system location, naming conventions, design tool). If it is
   missing, proceed with defaults and record them as assumptions, or ask `pd-design-lead` to set it up.
3. Read the upstream flows artifact (`*-flows-*.md`), plus research and architecture if present
   (architecture is optional). Flows and research may be replaced by stated assumptions when the user
   accepts that, as for a single screen; list them in your artifact. Pull the requirement from the
   tracker named in `PROJECT.md` (see `integrations.md`).

## When to use

- Screens or interactions need designing or redesigning.
- A flow needs to become concrete layouts and behaviors.

**Not for:** copy (`pd-ux-writing`), applying visual tokens (`pd-visual-design`), building frames in the
design tool (`pd-mocks`), or system changes (`pd-design-system-ops`).

## Process

1. **Pull the flow and goals**: the steps, decisions, and states this design must cover.
2. **Inventory screens by state**: default, loading, empty, error, success, partial, disabled,
   no-permission. This list is the spec's backbone. Then check combinations: can a control be disabled and
   loading (retry after failure)? focused and error (validation on an active field)? partial and
   no-permission? Spec the combination; states are not mutually exclusive.
3. **Lay out**: grid, spacing rhythm, hierarchy. One primary action per screen; subordinate the rest.
   Group by task, not by data type.
4. **Compose from real components** with their real variants (for example `kind=primary, size=md,
   state=default`; actual property names come from the project's system). If a needed component or
   variant is missing, flag the gap with severity and a blocking flag (it feeds `pd-design-system-ops`).
   When it isn't blocking, use the closest existing one and note the substitution; when it is, stop that
   element and say so.
5. **Design the interaction**: affordances, feedback for every action, sensible defaults, forgiving input,
   confirmation for destructive or irreversible actions. Specify transitions as what changes and in what
   order, not easing or duration; hand motion timing to `pd-prototyping`.
6. **Apply Fitts's and Hick's laws.** Fitts: acquisition time depends on size and distance, so put the
   primary action large and within the user's current focus or thumb reach. Screen edges only act as
   "infinite" targets at the OS level; in browsers and on touch screens they sit next to chrome and
   system gestures, so don't rely on them. Hick: decision time grows with the number of unfamiliar,
   unordered options, so reduce or group choices at a decision point and disclose the rest progressively.
   There is no magic number ("7±2" is about working memory, not choice); a long but well-ordered list
   (alphabetical, grouped, searchable) can be fine.
7. **Spec every state**: empty, loading, error, and partial shown, not just the populated view.
8. **Annotate**: behavior, validation rules, focus order, keyboard interaction, accessible names, target
   sizes, and focus destination on state change (for example where focus lands when a validation error
   appears, and that it stays visible per WCAG Focus Not Obscured; see `accessibility.md`). These
   annotations are how `pd-mocks` and engineering get it right.
9. **Self-check** against `principles.md` (hierarchy, one job, recognition) and `accessibility.md`
   (focus, contrast intent, targets, color-independent meaning).

## Fidelity

Work at wire-to-mid fidelity: structure, hierarchy, behavior. Visual treatment through tokens is
`pd-visual-design`; frames in the design tool are `pd-mocks`. Describe layout and components precisely
enough to build with or without a design tool.

For high-stakes products, make the most frequent path the most efficient, confirm irreversible actions,
make status unambiguous without relying on color, and design for incomplete data and poor connectivity.

## Output

`<artifacts_dir>/<date>-design-<topic>.md` with the artifact header from `handoff-protocol.md`
(`discipline: design`), then per screen: purpose, layout, components used (real names and variants), each
state, interactions, annotations (validation, focus order, accessibility), and flagged gaps. List the
components used so `pd-design-system` can verify them. `upstream:` the artifacts actually consumed — flows, plus research and
architecture if they were used. `downstream:` `content`, `visual`, `components`, `responsive`, `mocks`, `prototype`,
`qa`, `handoff`, `metrics`.

## Domain packs

If `PROJECT.md` lists domain packs, read each pack's section for design and apply it on top of this
skill.

## Common mistakes

- Designing only the default state.
- Inventing components or tokens instead of using, or flagging gaps in, the real system.
- Decoration competing with hierarchy; more than one primary action.
- Skipping focus order, target sizes, and accessible names.
- Losing context across a state transition (loading, error, retry): scroll position, entered values, or
  selection reset instead of preserved.
- Relying on hover as the only way to reveal an action or tooltip, which fails on touch devices.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.