# Design Craft

> UI/UX craft + design-decision communication skill, distilled from Albert Chipman's *UX/UI Design 2022* and Tom Greever's *Articulating Design Decisions*. Five modes: AUDIT a screen/component against visual-hierarchy, typography, readability, alignment/grid, consistency and microcopy rules; RATIONALE — write the 'Big Three' justification for any design decision (what problem it solves, how it affects the user, why it beats the alternative); RESPOND to design feedback or a stakeholder request with the IDEAL response (Thank→Repeat→Prepare, strategy, tactics, ask for agreement); PREP a design review (anticipated objections, alternatives, data, follow-up); INTAKE a new design project (goals, users, metrics, decision-maker). Use when the user says 'audit this UI', 'design review', 'looks amateur/unprofessional/AI-made', 'why did you design it this way', 'justify this design', 'the client/stakeholder wants X', 'present this design', 'readability', 'typography', 'visual hierarchy', 'microcopy', 'design rationale', or

- Skill: `emamulmursalin47/design-craft` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add emamulmursalin47/design-craft`
- Raw SKILL.md: https://api.skillmd.com/api/skills/emamulmursalin47/design-craft/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: emamulmursalin47 (https://skillmd.com/u/emamulmursalin47)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/emamulmursalin47/design-craft

---


# design-craft — make it good, then make it understood

Two halves, one skill:

1. **Craft** (Chipman): rules that make an interface read as designed rather than assembled —
   hierarchy, consistency, typography, readability, alignment/grid, microcopy, error handling.
2. **Articulation** (Greever): every design decision must answer the **Big Three** —
   *What problem does it solve? How does it affect the user? Why is it better than the alternative?* —
   and be communicated so stakeholders agree and don't reopen it next week.

Reference files are the source of truth; this file is the router. Read only the references a mode needs.

## Non-negotiables (apply in every mode)

- **"Works", never "like".** Strike *like / don't like / from a design perspective* from all output. Evaluate effectiveness against a goal, a use case, or a user, not preference. Rephrase the user's preference statements into effectiveness questions before answering them.
- **Evidence ladder — label which rung you're on.** `data` (analytics, A/B) › `user testing` (observed) › `external research` (cite title/author/url) › `established pattern / heuristic` › `informed intuition`. Never invent a number, a study, or a test result. If you have no evidence, say "assumption" and propose how to check it.
- **Every finding/decision cites a principle** from `references/` (e.g. *hierarchy: size/colour/contrast/space*, *≤2 typefaces, ≤3 colours*, *40–55 chars per line*). No "this feels off".
- **Lead with a yes.** Agree with the *problem* a request addresses before you negotiate the *solution*. Propose an alternative rather than refusing.
- **Alternatives are mandatory.** A recommendation without at least one considered alternative (and why it loses) is incomplete.
- **No dark patterns, no fabricated UI content.** Never recommend fake social proof, invented metrics, manufactured urgency, or placeholder data dressed as real.
- **Finish with agreement.** When presenting a decision, end with a direct, benefit-framed question ("Do you agree we should X to improve Y?") — not an open-ended "thoughts?".

## Mode selection

| Signal in the request | Mode | Read |
|---|---|---|
| "audit / review / critique this screen", "looks amateur", "why does this look wrong", screenshot or component path | **AUDIT** | `references/ui-principles.md`, `typography-readability.md`, `layout-grid-alignment.md`, `microcopy.md` |
| You are about to make or propose a design change (any size) | **RATIONALE** | `references/big-three-rationale.md`, `response-toolkit.md` §Common messages |
| User/stakeholder pushes back, asks "why", or requests a specific change ("add a button", "make the logo bigger") | **RESPOND** | `references/stakeholder-playbook.md`, `response-toolkit.md` |
| "prepare for the design review / client meeting / demo" | **PREP** | `references/stakeholder-playbook.md` §Prepare, `after-and-recovery.md` §Follow-up |
| New product/feature kickoff, brief writing, "what do you need from me" | **INTAKE** | `templates/project-intake-checklist.md`, `references/research-and-process.md` |
| Colour pairs / palette / typeface count questions | any | run `scripts/contrast.py`, `scripts/palette-audit.py` |

Mixed requests: run AUDIT first, then RATIONALE for each fix you propose. If the `refactoring-ui` skill is installed, invoke it for the *visual polish execution* (spacing scales, shadows, palettes); this skill owns the principles audit and the communication.

## AUDIT workflow

1. **Establish the frame before judging.** Identify the screen's *one primary job* (every screen should have a single main focus), the primary use case, the target user and the measurable goal. If unknown, state your assumption in one line — don't block.
2. **Squint / grayscale pass.** Mentally (or with a screenshot desaturated) check: does the eye land on the primary action first, secondary second? Do exactly three text levels exist (headline › subhead › body) — two on mobile?
3. **Walk the checklists** in this order, noting each violation as `[severity] principle — where — evidence — fix`:
   1. Hierarchy & focus (`ui-principles.md` §1–2)
   2. Consistency (appearance + behaviour) & familiarity (§3–4)
   3. Typography & readability (`typography-readability.md` — run `scripts/palette-audit.py` for typeface/colour counts; `scripts/contrast.py` for every text/background pair in doubt)
   4. Alignment & grid (`layout-grid-alignment.md`)
   5. Flow, effort & feedback: steps to complete the primary task, 3-click rule, loading/progress/error states (§5–8)
   6. Microcopy (`microcopy.md`)
   7. Responsive/adaptive behaviour (§9)
4. **Severity:** `P0` blocks the primary task or misleads the user · `P1` hurts scanability/trust/conversion · `P2` polish. Cap the report at what matters; don't pad with P2s.
5. **Output** with `templates/design-audit-report.md`. Each fix carries a one-line Big Three rationale so it can be defended later.
6. Offer to implement fixes; don't implement unasked unless the user's request already implied it.

## RATIONALE workflow

For the decision at hand fill `templates/design-rationale.md`:
problem (tied to a named goal/metric) → solution → how it affects the user (story or observed behaviour) → alternatives considered and why they lose → evidence rung → the "common message" category it belongs to (business / design / research / limitation). Keep it to one screen of text. Write it *before* coding when the change is user-visible.

## RESPOND workflow (feedback or change request arrives)

1. **Listen first.** Restate the request as a problem: "What I hear you saying is … Is that right?" Convert any *like/don't like* into *works/doesn't work*. Don't answer until the underlying need is identified (the stated solution is often not the need).
2. **Transition: Thank → Repeat → Prepare** (one sentence each).
3. **Strategy:** pick from *appeal to a nobler motive* (tie to their goal), *represent the user* (story), *demonstrate effectiveness* (show/prototype).
4. **Tactic(s):** show a comparison · propose an alternative · give them a choice (state the trade-off honestly) · ask others to weigh in · postpone the decision. See `response-toolkit.md`.
5. **Justify** with the IDEAL structure — **I**dentify the problem, **D**efine the solution, **E**mpathize with the user, **A**ppeal to the business, **L**ock in agreement — using the common-message catalogue and the `[design] will affect [goal] because [reason]` pattern.
6. **Ask for agreement directly**, framed on the benefit.
7. If overruled: apply `after-and-recovery.md` §Making changes you disagree with (make it subtle / an option / placed carefully / planned space). Record the decision and move on — no relitigating.

Output with `templates/stakeholder-response.md` when the user wants text they can send; otherwise answer conversationally but in that order.

## PREP workflow

Produce: (a) per-screen anticipated objections with prepared answers; (b) alternatives to bring (including the ones you rejected and the ones they'll suggest); (c) data/test evidence ready but held back until needed; (d) who supports you and what you'll ask them; (e) the follow-up skeleton. Templates: `design-rationale.md`, `meeting-followup.md`.

## INTAKE workflow

Open with the book's first question — *"What are we trying to communicate?"* — then walk `templates/project-intake-checklist.md`. Insist on: one measurable metric, named primary users and their primary pain, one named decision-maker (no committees), and a plan to observe real users. Then propose the research/prototyping path from `research-and-process.md` sized to the project.

## Quality bar for any output of this skill

- Specific over generic: name the element, the rule, and the number (px, ratio, character count) where a number exists.
- Short: audits ≤ 1 page unless asked; responses ≤ 200 words unless a full case is requested.
- Honest about uncertainty: assumptions flagged, evidence rung named.
- Ends with a next step the reader can act on.

Sources and attribution: see `SOURCES.md`.