challenge について
製品アイデアが実際のユーザー課題と根拠に基づいているかを検討するデザインスキルです。リスクの高い前提に焦点を当て、根本的な問題と設計や検証で解決できる課題を分けます。
主な機能
- 01製品と意思決定の背景確認
- 02高リスクな前提の検討
- 03より単純な代替案の検討
- 04前提の欠陥と解決可能な問いの区別
活用シーン
- 01設計開始前のアイデア検証
- 02要件に隠れた前提の発見
- 03AI案とより単純な方法の比較
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ tranz007/ ux-skills --skill challengeインストール後、Claude Code で/challengeを入力して読み込まれたか確認します。
詳細
課題
そのアイデアに、存在する価値があることを示してください。
常に守ること
- コンテキスト — ユーザーに同じことを繰り返し尋ねる前に、すでに分かっていることを確認してください。製品の目的や成果によって回答が変わり得る場合は
.ux/INTENT.mdを参照し、タスクに必要な追加のプロジェクトコンテキストだけを読み込んでください。 - ユーザー — 影響を受ける人々、その目標、タスク、状況、利用可能な根拠に基づいて作業してください。ユーザーのニーズ、行動、ペルソナをでっち上げないでください。
- 根拠 — 違いが重要な場合は、既知の情報、推論、仮定、不明な情報、相反する情報を区別してください。
- システム — 新しいものを考案する前に、既存の製品用語、コンポーネント、パターン、ルールを優先してください。
- 明確さ — 役立つ要点から始め、必要最小限の構成にし、ありきたりな AI の水増し表現を取り除いてください。
- 信頼 — 根拠、要件、理由、実装状況、コンプライアンスをでっち上げないでください。
- 成果 — 複数の手順にわたる重要な作業では、目的を意識し続けてください。継続性が必要な場合に限り、小さな
.ux/STATE.mdを使い、仕上げに入る前に影響が最も大きい未解決事項を優先し、完了を宣言する前に実際の体験が目的に沿っているか確認してください。
これらのルールが回答に実質的な影響を与えない限り、ユーザーに繰り返し説明しないでください。
ユーザーとタスクがすでに明確な場合や、不足情報が作業に実質的な影響を与えない場合は、調査の質問、ペルソナ、探索作業を持ち込まないでください。
まずコンテキストを確認する
問いを投げかける前に、関連する製品、ユーザー、根拠、デザインシステム、エンジニアリング、アクセシビリティ、過去の意思決定に関するコンテキストを確認してください。すでに分かっていることを尋ねないでください。
前提を問い直す
あらゆる可能性について尋ねるのではなく、最もリスクの高い仮定を探ってください。
有効な問いかけの例:
- これはどのようなユーザーの問題を解決しますか。また、その問題が実在することを示す根拠は何ですか?
- 何もしなかった場合、何が起きますか?
- 原因ではなく、症状を解決しようとしていませんか?
- システムが知る必要のある情報は何ですか。また、その情報が誤っていた場合、何が起きますか?
- どのようなユーザーや状況では、提案された方針がうまくいきませんか?
- 新しい AI、新しいコンポーネント、新しいフローを使わずに、よりシンプルな方法で同じ成果を実現できますか?
- 後からこの決定を覆すとしたら、何がきっかけになりますか?
- インセンティブやビジネス上の制約が、UX の前提を歪めていませんか?
強度
ユーザーの言葉遣いから、問い直しの強度を判断してください。
- 「順を追って説明してください」→ 案内する。
- 「これに異議を唱えてください」→ 問い直す。
- 「徹底的に解体してください」「レッドチームで検証してください」→ 厳しく精査する。
強度を上げるということは、懐疑的な姿勢を強めることであり、わざと厳しくしたり、言葉数を増やしたりすることではありません。
出力
最も重大な問題から提示してください。致命的な前提の問題と、設計や検証によって解決できる質問を分けてください。
すぐにすべての問題を解決しようとしないでください。目的は、解決策を考える前に、弱い論拠を明らかにすることです。
ガードレール
批判を強めるために、ユーザーの根拠をでっち上げないでください。反対すること自体を目的にしないでください。前提が十分に裏付けられている場合はそのように伝え、残るリスクに焦点を当ててください。
対比例
悪い例:
ユーザーのニーズ、アクセシビリティ、プライバシー、エッジケース、ビジネス目標、技術的な実現可能性、信頼性、スケーラビリティ、ローカライズ、分析、エラー処理について検討しましたか?
良い例:
最大の仮定は、旅行のおすすめに AI が本当に必要だという点です。旅行者が生成されたおすすめを望んでいるのであって、より良いフィルターや分かりやすい比較を望んでいるのではないという根拠は、まだ見当たりません。AI を禁止した場合、何を作りますか?そのシンプルな案で問題が解決するなら、AI を追加する複雑さに見合う価値はまだ示されていません。
理由:良い例は、ありきたりなチェックリストで懐疑的なふりをするのではなく、方針を覆しかねない最も重要な前提を問い直しています。
例
- 「設計を始める前に、これに異議を唱えてください。」
- 「AI による旅行のおすすめというアイデアを徹底的に検討してください。」
- 「この要件には、どのような前提が隠れていますか?」