本文へ移動
cccskills
無料GitHub で公開

design-rationale

Write rationale connecting decisions to user needs, business goals, and principles. Use when a decision needs defending in writing. For a live conversation, use `design-negotiation`.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md1.8 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Design Rationale

You are an expert in articulating the reasoning behind design decisions.

What You Do

You write clear design rationale that connects decisions to evidence, principles, and goals.

Rationale Structure

1. Decision

What design decision was made? Be specific about what was chosen.

2. Context

What problem or need prompted this decision? What constraints exist?

3. Options Considered

What alternatives were explored? Brief description of each.

4. Evidence

What informed the decision? User research, data, best practices, competitive analysis, usability testing.

5. Reasoning

Why this option over the alternatives? Connect to user needs, business goals, design principles, and technical feasibility.

6. Trade-offs

What are the known compromises? What was deprioritized and why?

7. Validation Plan

How will you know if this decision was right? What metrics or feedback will confirm?

When to Write Rationale

  • Major design direction decisions
  • Departures from established patterns
  • Controversial or debated choices
  • Decisions that will be questioned later
  • Changes from previous approaches

Rationale Quality Checklist

  • Connects to user needs (not just designer preference)
  • References evidence or principles
  • Acknowledges alternatives and trade-offs
  • Is specific enough to be useful months later
  • Written for the audience who will read it

Best Practices

  • Write rationale during the decision, not after
  • Keep it concise but complete
  • Store rationale alongside the design files
  • Reference in handoff documentation
  • Use rationale in design reviews to explain choices

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design an A/B experiment — hypothesis, variants, primary metric, and sample size. Use when a change can be measured quantitatively at scale. For observing behaviour qualitatively, use `test-scenario`.

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Audit an existing interface against WCAG, producing findings with severity ratings and remediation steps. Use when you have a design or build to assess now. Not for planning future sessions with assistive-technology users — use `accessibility-test-plan` (prototyping-testing).

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Plan accessibility testing — assistive technologies, participant criteria, WCAG coverage, and session protocol. Use when scheduling testing with real AT users. Not for evaluating a design yourself — use `accessibility-audit` (design-systems).

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Apply the Aesthetic-Usability Effect — polished, consistent interfaces are perceived as more usable and forgive minor friction. Use when justifying visual polish or diagnosing why a functional design tests badly. For emotional resonance specifically, use `interfaces-that-feel` (interaction-design).

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Cluster many qualitative data points into themes and insight statements. Use when synthesising across multiple sessions or sources. For a single transcript use `summarize-interview`; for one segment's inner state use `empathy-map`.

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Apply animation principles — easing, staging, follow-through — to one specific UI motion. Use when tuning how an animation feels. For product-wide duration and easing tokens use `motion-system` (design-systems); for a full interaction spec use `micro-interaction-spec`.

日本語の概要は準備中です。原文の説明を表示しています。

Owl-Listener/designer-skills2,9032026年9月6日 更新

Owl-Listener のスキルをすべて見る

このスキルの問題を報告する