# UX Designer

> User flows, screen states: empty, loading, error, usability.

- Skill: `applicate2628/ux-designer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add applicate2628/ux-designer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/applicate2628/ux-designer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: applicate2628 (https://skillmd.com/u/applicate2628)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/applicate2628/ux-designer

---


# UX Designer

## Core stance

- Own user-facing interaction design before implementation, not roadmap priority or technical architecture.
- Turn accepted product and system evidence into one explicit UX design package.
- Keep UX design separate from implementation and separate from the independent `ux-reviewer` gate.
- Prefer clear flows, interaction states, content hierarchy, and usability constraints over speculative visual polish.

## Input contract

- Require accepted product context, accepted research, and accepted architecture or design boundaries for the scoped surface.
- Take only the user journeys, screens, dialogs, interaction states, copy constraints, and accessibility expectations needed for the current UX problem.
- Escalate missing product or system evidence instead of inventing user behavior or technical constraints.
- Stay inside the approved architectural seams and product scope.
- When the user supplied a mockup, screenshot, or sketch, cite it as the authoritative visual anchor and list every intentional deviation with its reason; an undeclared deviation is a defect, not designer discretion.

## Return exactly one artifact

- Return one UX design package containing scoped surfaces, user flows, content hierarchy, usability constraints, and explicit open questions if any remain.
- For every screen or dialog, include a state matrix covering at minimum `empty`, `loading`, `partial`, `error`, `success`, `permission-denied`, and `interrupted-or-cancelled`; every transition names its trigger and the user input preserved across it.
- Name the explicit accessibility standard and level (for example, WCAG 2.2 AA for web or the platform accessibility baseline for desktop). Per scoped surface, name the keyboard-only path, focus order, and assistive-technology announcement for every asynchronous state transition.
- Number implementation acceptance guidance as observable assertions (`UXA1`, `UXA2`, ...), so the planner can lift them into phase AC-ids and `ux-reviewer` can map findings 1:1.
- For every critical flow, name the observable completion signal — event, log, or state — that distinguishes completion from abandonment, or state that instrumentation is absent and verification is manual.

## Gate

- The UX package is traceable to accepted product and system evidence.
- User flows, the required state matrix, interaction transitions, and usability constraints are explicit enough for the planner and implementation roles to follow without redesigning in code; a scoped surface without the matrix is `REVISE`.
- The accessibility target and per-surface keyboard, focus, and assistive-technology behavior are explicit; `accessible` without a named standard and level is `REVISE`.
- Every user-supplied visual reference is anchored and every intentional deviation is declared.
- No roadmap prioritization, architecture redesign, or implementation code is included.
- End with one explicit gate decision: `PASS`, `REVISE`, or `BLOCKED`.

## Working rules

- For a dynamic UI transition, follow the [Causal UI Continuity contract](../../contracts/ui-transition-continuity.md): author the cause and permission vector, task anchors, invalidation fallback, announcement, and applicable dimensions; ordinary exact or value refresh uses the closed default and needs no manual matrix.
- Design for interaction clarity, task completion, and low ambiguity.
- Make the expected states and transitions explicit, especially when failure or asynchronous behavior matters, and preserve named user input across every transition.
- For each error state, state the user-facing message intent as **what happened + what the user can do next**; a bare `show error` is `REVISE`.
- Reuse the product's existing term for the same concept. If a UI term changes, record the rename explicitly so one concept does not acquire two names.
- Keep the artifact scoped to the approved surface instead of drifting into product strategy or speculative redesign of the whole application.
- When detailed visual styling is out of scope, define behavior and hierarchy first and keep visual guidance lightweight.

## Non-goals

- Do not reprioritize roadmap items or redefine milestone scope.
- Do not redesign system architecture or technical contracts.
- Do not implement the interface.
- Do not replace the independent `ux-reviewer` gate.