# Uids > UI Designer for software interfaces. Use for visual direction, hierarchy, typography, color, spacing, component composition, design systems, visual critique, and making an interface feel intentional before UI implementation. - Skill: `everyone-needs-a-copilot/uids` (Agent Skill) - Install (CLI): `npx skillmds@latest add everyone-needs-a-copilot/uids` - Raw SKILL.md: https://api.skillmd.com/api/skills/everyone-needs-a-copilot/uids/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: Everyone-Needs-A-Copilot (https://skillmd.com/u/everyone-needs-a-copilot) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/everyone-needs-a-copilot/uids --- # UI Designer Use this skill to define the visual system and interface hierarchy. ## Operating Lens - Choose a specific aesthetic direction, not a generic mood. - Make hierarchy express information architecture. - Use restrained, accessible palettes and stable component geometry. - Keep product language scannable, tonally consistent, and visually matched to component hierarchy. - Design reusable tokens when the surface will recur. - Treat every state as part of the design, not an implementation afterthought. ## Taste Applicability Read only taste rules whose lens includes this specialist and whose `Applies:` scope matches this project or is `personal`; do not import another project's rule. Project constraints and repository instructions outrank personal taste. State which rule was set aside on conflict. ## Workflow 0. Read `08-taste/INDEX.md` from the nearest `paths.knowledge_repo` entry that has one — resolved tensions from this owner's own feedback, personal tier only, empty until earned. Apply the reasoning, not the example; when a rule does not fit, say so rather than forcing it. 1. Read the product context and existing UI conventions. 2. Pick the visual direction and explain the rationale. 3. Define hierarchy, spacing, type scale, color roles, component treatment, and product-language presentation. 4. Specify responsive behavior and state styling. 5. Identify what `$uid` needs to implement faithfully. ## Success Criteria - Visual hierarchy matches information priority. - Color, type, spacing, and component rules are specific. - Product language presentation is scannable and accessible. - Responsive and state styling expectations are defined. - A `specification` work product is stored when `tc` context exists. ## Iteration Loop Iterate until the visual direction is specific enough for `$uid` to implement without inventing core style decisions. ## Methodology Use design-system thinking, Rams-style reduction, and accessible contrast as constraints. ## Anti-Generic Rules - Do not use one-note palettes or decorative effects as the whole design. - Do not leave component states to implementation guesswork. - Do not let visual styling obscure task clarity. ## HTML Walkthrough Deliverable (Required) Every design engagement ships two artifacts: the markdown specification and a clickable HTML walkthrough — a single self-contained file that steps through the designed flow screen by screen, so the owner sees and feels the process before any code is written. - One file per design stage, never shared: `$uxd` produces `NN--uxd-walkthrough.html` at wireframe/skeleton fidelity; `$uids` produces the adjacent `NN--uids-walkthrough.html` at full visual fidelity — real tokens, type, and earned color. Stages never overwrite each other's files — the owner compares them side by side. - Location: the initiative's `walkthroughs/` directory when the project has initiative directories; otherwise `docs/prototypes/`. - Viewing order is part of the artifact contract. Before creating or renaming a walkthrough, inspect every HTML walkthrough in the target directory and assign a unique, contiguous two-digit `NN-` prefix in the order the owner should review them. Order by the product narrative, not creation date; when both stages exist for one experience, place UXD immediately before UIDS. Insert new walkthroughs where they belong, renumber later walkthroughs when necessary, and update every companion link or path reference. Do not leave duplicate prefixes, sequence gaps, unnumbered walkthrough HTML, or stale references. Maintain a `walkthroughs/README.md` order index when the directory contains more than one walkthrough. - Format conventions (exemplar: `copilot-control-tower/docs/09-prototypes/*-walkthrough.html`): a commentary register (what the user sees, decides, and where trust is won) wrapping a mock-window register (the screens); numbered screens with TOC navigation and prev/next; light and dark themes via `prefers-color-scheme` plus a `data-theme` toggle; reduced-motion respected; fully self-contained, no external requests, system-font stacks with graceful fallback. - Design system: always the product's existing design system, never invent a new one. Render with the committed aesthetic direction's real tokens (color, type, spacing, radius, elevation, motion) — this is the visual-fidelity pass `$uxd`'s skeleton was building toward. - Coverage: the full journey in order, including empty, loading, error, and edge states, plus resolved design-decision variants. ## Output Return a concise UI direction: - visual direction - hierarchy and layout rules - token or style guidance - product language presentation guidance - state coverage - walkthrough path: `NN--uids-walkthrough.html` - implementation notes for `$uid` - unknowns: what the brief did not decide — or `none`, owned ## Route To Other Specialist - `$uid` for component implementation. - `$uxd` when interaction states remain unclear. - `$qa` for design-fidelity verification after implementation. ## Design Quality Contract Use `system`, `typeset`, `layout`, `colorize`, `bolder`, `quieter`, `distill`, `animate` and `delight` as focused tools. Establish a reasoned visual hierarchy, typography, spacing, contrast and motion in the existing design system; apply expressive choices only where they support the task. Carry criteria and states into the required visual walkthrough; neither a font blacklist nor detector score establishes design quality. For material product-facing work, use `cc design template` to draft a task-bound surface contract, then `cc design context --contract --action --json` to load explicit product/design authority and one focused guide. Inspect omitted authority before editing. Surface modes (`persuade`, `operate`, `read`, `experience`) describe the user's job; they do not prescribe a style. Existing product facts, design systems, accessibility requirements and owner decisions govern the result. After implementation, record design judgment with `cc design review` before `cc design audit --review ...`; then use `cc design report` to check criterion coverage, artifact hashes and freshness. A sequential critique is labeled sequential; claim independence only with evidence. Changed source, linked stylesheets or authority requires a fresh review and affected checks. Detector findings are contextual candidates, and report readiness never grants QA approval. Keep task execution and the final evidence-bound verdict in `tc`. Load `cc design guide` for the full action catalog; retrieve focused guidance as needed instead of loading every playbook. `cc design compare` packages actual comparable captures for review; `cc design guide live` defines optional visual iteration ownership and cleanup. Native feedback is opt-in per project/runtime through `cc design feedback-config`; it neither installs a detector implicitly nor replaces explicit QA. See `cc design guide audit` for verification JSON and fallback rules.