mcpField
U
ux-design-thinking

ux-design-thinking

github.com/asgard-ai-platformデザイン・UI243111 回インストール21 週間前に更新
リポジトリ

ux-design-thinking について

人に関わる製品、サービス、プロセスなどの課題に取り組むチーム向けの、人間中心のデザイン思考スキルです。ユーザー調査からテストまでの5段階を反復し、問題や解決策を考える前にユーザーを理解することを重視します。

主な機能

  1. 01共感からテストまでの反復的な5段階
  2. 02ユーザー観察とインタビューのガイド
  3. 03視点ステートメントによる課題設定
  4. 04アイデア発想とコンセプト選定の手法
  5. 05検証内容に応じたプロトタイプの精度

活用シーン

  1. 01機能を計画する前のユーザーニーズ調査
  2. 02ユーザーの洞察に基づくサービス課題の再設定
  3. 03簡易プロトタイプによるコンセプト検証
  4. 04反復的なデザイン思考スプリントの実施

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/asgard-ai-platform/skills --skill ux-design-thinking

インストール後、Claude Code で/ux-design-thinkingを入力して読み込まれたか確認します。

同梱ファイルexamples/sample_scenario.mdreferences/dt-exercises.md

詳細

デザイン思考

概要

デザイン思考は、ユーザーのニーズ、技術的な実現可能性、ビジネスとしての成立性を統合する、人間中心のイノベーションアプローチです。5つの段階は直線的ではなく、反復的に進みます。理解が深まるにつれて、前の段階に戻ることを想定してください。

フレームワーク

IRON LAW: Empathize BEFORE Define, Define BEFORE Ideate

Jumping to solutions (Ideate) without understanding the problem (Define)
wastes effort solving the wrong problem. Defining the problem without
empathizing with users produces internally-focused problem statements.

The sequence matters: understand the human first, then frame the problem,
then generate solutions.
5つの段階

1. 共感する — ユーザーの世界を理解する

  • ユーザーの状況を観察し、インタビューし、その場に身を置きます
  • 目標:ニーズ、課題、動機を理解します(ユーザーが言うことだけでなく、行動や感じていることも理解します)

2. 定義する — 適切な問題を設定する

  • 共感によって得られた知見を統合し、視点(POV)を示す文にまとめます: [ユーザー]は[ニーズ]を必要としています。なぜなら[洞察]だからです
  • 適切に定義された問題は、半分解決したも同然です。必要に応じて捉え直します。

3. アイデアを出す — 多くの解決策を生み出す

  • 発散:質より量を重視します。判断は後回しにします。
  • 手法:ブレインストーミング、「どうすれば〜できるか」という問い、SCAMPER、考え得る最悪のアイデア
  • その後、収束させます。投票し、グループ分けし、プロトタイプを作るコンセプトを2~3個選びます。

4. プロトタイプを作る — アイデアを形にする

  • 学びを得るために、すばやく、低コストで、使い捨てのプロトタイプを作ります
  • 精度は検証する問いに合わせます。フローには紙のスケッチ、インタラクションにはクリック可能なモック、技術的な実現可能性にはコードを使います
  • 目標は仮説を検証することであり、関係者に感銘を与えることではありません

5. テストする — 実際のユーザーから学ぶ

  • 実際のユーザーにプロトタイプを試してもらいます
  • 意見を聞くだけでなく、行動を観察します
  • うまくいったことは何ですか?うまくいかなかったことは何ですか?意外だったことは何ですか?
  • 中核となる仮説が誤っていた場合は、「共感する」または「定義する」に戻ります

出力形式

# Design Thinking Sprint: {Challenge}

## Empathize
- User: {who}
- Key insights from research: ...
- Surprises: ...

## Define
- POV: [User] needs to [need] because [insight]
- How Might We: {3-5 HMW questions}

## Ideate
- Ideas generated: {count}
- Top 3 concepts: ...

## Prototype
- Prototype type: {paper / digital / physical}
- What it tests: {specific assumption}

## Test
- User feedback: ...
- Validated: {what was confirmed}
- Invalidated: {what was wrong}
- Next iteration: {what to change}

例

適切な適用例

**シナリオ:**病院の待合室での体験を再設計する

  • 共感する:患者を3日間観察しました。重要な洞察:不安が高まるのは待ち時間そのものではなく、待ち時間がどれくらいになるか分からないことです。
  • 定義する:「患者は待ち状況を把握していると感じる必要があります。なぜなら、不確実さは実際の待ち時間によるもの以上に不安を強めるからです。」
  • アイデアを出す:40件以上のアイデアから上位3件を選定:リアルタイムの待ち順表示、SMSによる順番のお知らせ、所要時間の推定表示キオスク
  • プロトタイプを作る:SMS通知フローの紙のプロトタイプを作成(5分で完成)
  • テストする:患者8人がテストし、そのうち6人が、実際の待ち時間は変わらなかったにもかかわらず、「不安が大幅に減った」と回答 ✓
不適切な適用例
  • 「新しいアプリ機能が必要だ」と考え、「共感する」を飛ばして開始 → 問題を理解せずに解決策を考えています。鉄則に反します。

注意点

  • 「素早く失敗する」には心理的安全性が必要です:失敗が罰せられるなら、チームは実験しません。プロトタイプは失敗するためのものだと共有しましょう。それが学びにつながります。
  • HMWの問いが解決策の範囲を決めます:「どうすれば待ち時間を減らせるか?」と「どうすれば待ち時間中の不安を減らせるか?」では、異なる解決策につながります。問いを慎重に設定しましょう。
  • プロトタイプ ≠ MVP:プロトタイプは仮説を低コストで検証するものです。MVPは実用可能な製品です。プロトタイプを作り込みすぎないようにしましょう。
  • デザイン思考はデザイナーだけのものではありません:サービス、プロセス、ポリシー、ビジネスモデルなど、人間のニーズに関わるあらゆる問題に適用できます。
  • 反復は必須です:5つの段階を一度ずつ進み、前の段階に戻らなかったなら、それは付箋を使ったウォーターフォールであり、デザイン思考ではありません。

参考資料

  • 各段階のファシリテーション演習については、references/dt-exercises.mdを参照してください

コメント