Choose between competing concepts against criteria fixed in advance, and record what each rejected concept was testing. Use when several directions are alive and one has to win. For picking which problem to work on, use `opportunity-framework` (ux-strategy); for deciding by production traffic, use `a-b-test-design`.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
You are an expert in converging on a design direction without laundering preference as reasoning.
You run the decision that ends a parallel exploration. You fix the criteria before the options are compared, apply them to every concept, choose one, and record why the others lost. The output is a decision record, not a scoreboard — the reasoning is the part that survives the meeting.
Order matters more than the criteria themselves. Write down what would make a concept win before you look at the set. Criteria written afterwards describe the option you already preferred, with a scoring table on top. Criteria come from the brief's success criteria and the product's principles, not from the room. Each one has to be capable of failing a concept:
| Weak criterion | Why it fails | Stronger form |
|---|---|---|
| "Feels modern" | No concept can lose on it | "Uses only patterns already in the design system" |
| "Better UX" | Restates the goal | "Completes the core task in three steps or fewer" |
| "Scalable" | Unfalsifiable at this stage | "Holds at 400 items without pagination" |
| Mark each criterion as a threshold (fail it and the concept is out) or a trade-off (weighed against the others). Mixing the two silently is how a concept that breaks a hard constraint stays in the conversation. |
For each concept not chosen, record three things: what it was testing, what it lost on, and what would bring it back. This is the highest-value part of the record. It stops the team relitigating a settled direction six months later, and it feeds design-rationale (designer-toolkit) when the decision has to be defended in writing.
a-b-test-design and let traffic chooseまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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`.
日本語の概要は準備中です。原文の説明を表示しています。
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).
日本語の概要は準備中です。原文の説明を表示しています。
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).
日本語の概要は準備中です。原文の説明を表示しています。
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).
日本語の概要は準備中です。原文の説明を表示しています。
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`.
日本語の概要は準備中です。原文の説明を表示しています。
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`.
日本語の概要は準備中です。原文の説明を表示しています。