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

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 — Identify the problem, Define the solution, Empathize with the user, Appeal to the business, Lock 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.