mcpField
U
ux-research

ux-research

github.com/rampstackcoデザイン・UI1.0k270 回インストール2 週間前に更新
リポジトリ

ux-research について

生成的なUXリサーチを計画・実施し、発見を意思決定につなげる、ツールに依存しないスキルです。研究課題の設定、手法選定、参加者募集、分析、結果共有を扱います。

主な機能

  1. 01研究課題の設定
  2. 02目的に応じた手法選定
  3. 03参加者募集の指針
  4. 04観察結果の分析と洞察検証
  5. 05調査結果の共有形式

活用シーン

  1. 01新製品のユーザーニーズを探る
  2. 02原因が不明な製品課題を調査する
  3. 03投資前に戦略方針を検証する
  4. 04チームでユーザーニーズへの理解を深める

インストール

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

$npx skills add https://github.com/rampstackco/claude-skills --skill ux-research

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

同梱ファイルREADME.mdreferences/interview-guide-template.md

詳細

UX リサーチ

資料を作るだけでなく、意思決定につながるユーザーリサーチを計画・実施します。技術スタックやツールを問いません。

このスキルは、仮説生成型および探索型のリサーチ向けです。既存のデザインをテストする場合は、usability-testingを使用してください。顧客体験全体をマッピングする場合は、journey-mappingを使用してください。


使用する場面

  • ユーザーへの理解が十分でないまま、新しい製品や主要機能に着手するとき
  • 明確なデータ上の兆候がない状態で、うまくいっていない理由を診断するとき
  • 新しい機会仮説を生み出すとき
  • 大きな投資を行う前に、戦略の方向性を検証するとき
  • ユーザーから離れてしまったチームの共感を育むとき
  • 「ユーザーと話すべきだ」という意図を、実際の計画に落とし込むとき

使用しない場面

  • 特定のデザインやプロトタイプをテストするとき(usability-testingを使用)
  • 既存の体験における全体的なジャーニーをマッピングするとき(journey-mappingを使用)
  • 定量的な測定を行うとき(analytics-strategyを使用)
  • コンバージョンテストを行うとき(cro-optimizationを使用)

必要な入力

  • リサーチの質問(複数可)—何を明らかにする必要があるか
  • ステークホルダーの賛同(誰が調査結果を必要とし、どの意思決定がその結果にかかっているか)
  • ユーザーへのアクセス(既存顧客、見込み顧客、離脱したユーザー、対象セグメント)
  • スケジュールと予算
  • 活用できる過去のリサーチ

フレームワーク:6つのフェーズ

1. 質問を設定する

質問が悪ければ、リサーチの結果も悪くなります。質問の設定には、十分な時間をかけてください。

良いリサーチの質問:

  • 具体的である(「ユーザーは製品についてどう感じていますか?」ではない)
  • オープンエンドである(「ユーザーは機能Xを気に入っていますか?」ではない)
  • 意思決定に関係する(回答によって、何を作るかが変わる)
  • 調査可能である(分析だけでなく、ユーザーとの接触を通じて回答できる)

例:

良くない質問より良い質問
「ユーザーはオンボーディングを気に入っていますか?」「オンボーディングのどの段階で、新規ユーザーは続行すべきか迷いますか?」
「どの機能を作るべきですか?」「現在のユーザーは、[具体的な作業]において、どのような未充足のニーズを抱えていますか?」
「なぜコンバージョン率が低いのですか?」「ユーザーが価格ページにたどり着いたとき、どのようなメンタルモデルを持っていて、それは意図とどこで食い違っていますか?」
2. 手法を選ぶ

質問に応じて手法を選びます。

仮説生成型の手法(実際には何が起きているか?):

  • 詳細インタビュー。 60分、参加者5〜15人。背景、動機、メンタルモデルの理解に最適です。
  • コンテクスチュアル・インクワイアリー。 ユーザーが実際の環境で仕事をする様子を観察します。ワークフローの理解に最適です。
  • 日誌調査。 参加者が数日から数週間にわたって体験を記録します。1回のセッションでは現れない行動の把握に最適です。
  • フィールドリサーチ。 ユーザーが生活・仕事をしている場所で時間を過ごします。文化的・文脈的な理解に最適です。
  • アンケート(自由回答中心)。 自由回答を通じて幅広い傾向を把握する必要がある場合に使用します。

検証手法(この仮説は正しいか?):

  • コンセプトテスト。 説明、モックアップ、またはプロトタイプを見せて、反応を得ます。
  • カードソート。 情報アーキテクチャを検証します。
  • ツリーテスト。 ビジュアルデザインの影響を受けずに、情報の見つけやすさを検証します。

(動作するデザインのユーザビリティテストについては、usability-testingを参照してください。)

3. 参加者を募集する

参加者の募集は、リサーチの成否を左右します。

募集基準:

  • リサーチの対象者に合致する(「参加したい人なら誰でも」ではない)
  • 行動に幅を持たせる(アクティブユーザー、離脱したユーザー、未利用者)
  • 関連する場合は、属性にも幅を持たせる
  • 友人、家族、従業員は除外する(偏りがあるため)
  • 可能であれば、リサーチ参加を職業とする人は除外する(対象とする母集団が異なるため)

募集チャネル:

  • 製品内での募集(現在のユーザーに参加を呼びかける)
  • ユーザーセグメントへのメール連絡
  • 募集プラットフォーム(UserInterviews、Respondentなど)
  • カスタマーサポートチームからの紹介
  • 対面での現地募集

謝礼: 参加者には謝礼を支払います。標準的な料金は60分あたり50〜150ドルで、経営幹部や専門職の場合はさらに高くなります。

募集人数: 20〜30%が欠席することを見込んでください。7人を募集し、5人のセッションを設定します。

4. 実施する

インタビューまたはセッションそのものです。

インタビュー前:

  • 24時間前と1時間前に確認の連絡を送ります
  • 録音環境をテストします(音質は妥協できません)
  • インタビューガイドを準備します(テンプレートを参照)
  • 可能であれば記録係を用意します(インタビュアーが集中できます)

インタビュー中:

  • (同意を得たうえで)映像と音声を記録します
  • 調査の質問から始めず、関係づくりから始めます
  • 自由回答形式の質問をします(「前回のことについて教えてください……」)
  • 沈黙を活用します(参加者が話し始めるのを待ち、次の質問へ急ぎません)
  • 「なぜ」と尋ねますが、連続して何度も尋ねないようにします(尋問のようになります)
  • 具体的な内容や例を尋ねます(「何をしたのか、順を追って説明してもらえますか?」)
  • 矛盾点には穏やかに問いかけます(「先ほどはXとおっしゃいましたが、今はYとおっしゃっています。理解を深めるために教えてください」)
  • 感情が表れる瞬間に注目します(重要なことの兆候である場合が多いです)
  • 売り込んだり説得したりしません。これは話を聞く場であり、売り込む場ではありません

アンチパターン:

  • 誘導的な質問(「これを分かりにくいと感じませんか?」)
  • 仮定の質問(「もし……という機能があったら使いますか?」)―行動の予測にはあまり役立ちません
  • 一度に複数の質問をすること
  • 話を遮ること
  • 沈黙を埋めること
  • 仮説に沿ったインタビュー(すでに考えていることを裏付ける質問だけをすること)
5. 統合する

メモが自動的にインサイトになるわけではありません。

統合のプロセス:

  1. 観察事項を記録します。 録音、メモ、書き起こしからまとめます。各観察事項は、引用、行動、感情、瞬間など、単一のデータポイントです。
  2. 親和図法で整理します。 観察事項をテーマごとにまとめます。付箋やデジタルツールを使います。
  3. パターンを見つけます。 複数の参加者に共通して現れるテーマは有力な手がかりです。一度だけ見られた観察事項も興味深いものですが、確度は低くなります。
  4. インサイトを特定します。 インサイトは単なるテーマではありません。「なぜ」を説明したり、「それが何を意味するのか」を示唆したりする、意外性のある発見です。
  5. データに照らしてインサイトを検証します。 一部のインタビューにしか当てはまらない場合、それはインサイトではなく仮説です。
  6. シグナルとノイズを見分けます。 8人中1人だけが持つ信念はノイズかもしれません。8人中6人が持つ信念はシグナルです。

優れたインサイトの判断基準:

  • チームにとって意外性がある(すでに知っていたことはインサイトではありません)
  • チームが推測していた「なぜ」を説明します
  • 具体的な行動につながります(それが何を意味するのか?)
  • 複数のデータポイントに照らしても成り立ちます
  • 1、2文で表現できます
6. 共有する

調査結果はスライド資料の中で埋もれてしまいます。共有方法を計画しましょう。

効果的な成果物:

  • 主要インサイトの文書。 5〜10件のインサイトを、裏付けとなる引用とともに明確に記載します。
  • ハイライト動画。 参加者の重要な場面を編集した5〜10分の動画です。どのような文書よりも説得力があります。
  • 対面ワークショップ。 ステークホルダー自身に、統合した内容をたどってもらいます。参加することで内容が身につきます。
  • ステークホルダー別の概要資料。 対象者によって必要な切り口は異なります。CEOは戦略的な示唆を求め、デザイナーは課題点を求め、エンジニアはユースケースを求めます。

効果のない成果物:

  • 斜め読みされる80枚のスライド資料
  • エグゼクティブサマリー以降は誰も読まないレポート
  • 冗長な説明文
  • 誰も見返さない文書に埋もれるインサイト

ワークフロー

  1. 調査の問いを定めます。 ステークホルダーとともに、何度も見直します。
  2. 手法を選びます。 問いに合ったものを選びます。
  3. 実施計画を立てます。 スケジュール、予算、参加者募集、ツール、チームを決めます。
  4. 参加者を募集します。 早めに始めましょう。募集の遅れはすべてを遅らせます。
  5. パイロットを実施します。 本番の前に1〜2回のセッションを行い、ガイドを改善します。
  6. 実施します。 ガイドに沿って進めつつ、予想外の発見にも心を開きます。
  7. 統合します。 すべてのセッションが終わるまで待たず、途中から始めましょう。
  8. 共有します。 複数の形式で、複数の対象者に伝えます。
  9. 影響を追跡します。 調査によって意思決定は変わりましたか? 変わらなかった場合、質にかかわらず調査は失敗です。

失敗パターン

  • 意思決定につながらない調査。 調査結果が活用されません。労力が無駄になります。
  • 曖昧な調査の質問。 質の悪い質問からは、解釈できない回答が得られます。
  • 「協力してくれる人なら誰でも」採用する。 サンプルが対象者層に合っていません。
  • プロの参加者を過剰に採用する。 得られるのはパターンに沿った回答であり、実際のユーザーの声ではありません。
  • ガイド内の誘導的な質問。 調査結果に反映されるのはユーザーではなく、調査者です。
  • 統合を省略する。 メモだけではインサイトになりません。
  • チームがすでに抱いている考えを裏付けるインサイト。 特に疑ってかかりましょう。
  • リリースされない調査結果。 プロダクトの意思決定を変えない調査結果は、飾りにすぎません。
  • 何年分もの意思決定を単一の調査プロジェクトで支える。 調査結果には有効期限があります。更新しましょう。
  • 調査を一度きりのプロジェクトとして扱う。 継続的なディスカバリーは、断続的な調査に勝ります。

出力形式

デフォルトの出力:

  1. 調査計画(調査開始前) - research-plan-[topic].md
  2. インタビューガイド - interview-guide-[topic].md
  3. 調査結果ドキュメント(統合後) - research-findings-[topic].md
  4. ハイライトリール(動画、別途制作)

調査結果ドキュメントの構成:

# [Topic] research findings

## Question we set out to answer
[Specific question]

## Method
[Approach, sample size, dates]

## Top insights
1. [Insight, stated in one sentence]
   - Supporting evidence: [Quotes, behaviors, or state the gap per the data-availability rule]
   - Implication: [What this means for product/strategy]
2. [Insight 2]
   ...

## Themes (less prominent than top insights, still worth noting)
[List]

## Outliers worth investigating
[Single-participant observations that may be signal in disguise]

## Recommended next steps
[Specific actions]

必要なデータが利用できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、認められる出力は、その不足を明示した成果物です。何が必要だったのか、実際に何を取得または検証できたのか、そして出力のどの部分に影響するのかを記載してください。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足を明示すれば、それで回答として完結しています。


参考ファイル

コメント