mcpField
L
layers-observed-behaviour

layers-observed-behaviour

github.com/jamiemillデザイン・UI3131.9k 回インストール22 週間前に更新
リポジトリ

layers-observed-behaviour について

調査を計画したり既存資料を統合したりする、プロダクトチーム向けのユーザーリサーチ手法集です。生の証拠、確信度の記録、調査ギャップの明示を重視します。

主な機能

  1. 01調査計画と資料統合を切り分け
  2. 02学習目標に応じて手法を選択
  3. 03具体的な行動や発言を抽出
  4. 04パターンから候補ジョブストーリーを作成
  5. 05確信度と調査ギャップを記録

活用シーン

  1. 01ユーザーインタビューや観察を計画
  2. 02サポートチケットから行動の手掛かりを発見
  3. 03既存のインタビューや分析資料を統合
  4. 04追加調査で解くべき問いを特定

インストール

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

$npx skills add https://github.com/jamiemill/layers-skills --skill layers-observed-behaviour

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

詳細

/layers-observed-behaviour

/layers-intro が読み込まれていることを前提とします。このスキルは手順書ではなく、手法のライブラリです。「これらのスキルの使い方」を参照してください。

観察された行動のレイヤーは、現実に最も近いものです。ユーザーが実際に何をするかであり、私たちがそうだと思っていることや、そうしてほしいと願うことではありません。このレイヤーより上にあるものはすべて解釈であり、このレイヤーが情報源です。

状況は2つに分かれます。どちらに該当するかを見極め、明示してください。

  • 計画 — まだ調査をしていないため、調査を設計します。
  • 統合 — 調査資料があるため、内容を整理して意味を見いだします。

調査が一部だけ進んでいる場合は、まず既存の内容を統合し、その後、足りない部分を補う計画を立てます。


このレイヤーで決めること

  • ユーザーについて、特に答えを得る必要がある具体的な問い
  • すでにあるエビデンスと、その信頼性
  • 不足している情報をどう集めるか
  • 確信を持って言えるパターンと、依然として仮説にとどまるもの

観察の誠実さを保つための原則

  • 生データに近い状態を保ちます。 観察内容は具体的で、情報源に近いものにします。ユーザーが何を言い、何をし、何を感じたかを記録し、結論に要約しないでください。
  • チームの思い込みではなく、実際に見聞きしたことを根拠にします。
  • 確信度を示します。 観察済み/推測/仮定を区別します。何かを観察済みとする場合、その裏付けとなる逐語的な引用を同じメモ内に記載できる必要があります。引用可能なエビデンスのない観察済みの主張は、実際には推測です。
  • 調査の不足を明示し、取り繕わないでください。
  • 回避策は重要なシグナルです。 工夫してでも実行するほど強い動機となるニーズは、重要なニーズです。

手法

調査を計画する
手法使用する場面
学習目標を定める常にここから始めます。「ユーザーをもっとよく理解する」を、「何が友人を紹介するきっかけになり、何がためらわせるのか」のような2〜3個の具体的な問いへ掘り下げます。
JTBD インタビューきっかけ、動機、不安を理解するときに使います。仮定の話ではなく、実際に過去に経験したことについて尋ねます。ガイド:導入(「最後に〜したときのことを教えてください」)、時系列(何がきっかけで、何を試したか)、動機(何を期待し、何を心配したか)、締めくくり。
コンテキスト調査/観察ユーザーの発言と実際の行動が異なる場合に使います。暗黙の行動を把握するため、実際の作業を観察します。
日記調査行動が長期間にわたって分散している、または頻度が低い場合に使います。ユーザー自身が出来事の発生時に記録します。
サポートチケット/レビューの分析シグナルが蓄積された既存の製品に使います。参加者を募集せずに、規模の大きな課題を把握できます。
アナリティクスのレビューユーザーが何をするかを把握します(その理由ではありません)。定性的な調査を補完しますが、置き換えるものではありません。
ユーザビリティ観察既存の製品で、人々がどこで苦労し、どこでうまくいくかを把握します。

インタビューでは、事前に統合方法も計画します。1つのメモに1つの観察内容を記録し、関連する問いのタグを付け、要約よりも生の引用を優先します。(定性的なインタビューは通常、6〜10件で飽和状態に達します。)

資料を統合する
手法使用目的
観察内容の抽出ユーザーが何を言い、何をし、何を感じたか、具体的な事実を取り出します。まだ解釈は加えません。記憶を頼りに、最も意外だったこと、繰り返し現れたこと、予想外に苦労していたことを問いかけます。
パターンのグループ化繰り返し起きる状況、共通する動機、共通する不安、回避策ごとに観察内容を分類します。
ジョブストーリーの候補[状況]のとき、[動機]を満たしたい。そうすれば、[結果]を得られる。 「状況」が具体的であること、「望むこと」が解決策ではなく動機であることを確認し、確信度を示します。
不足事項の明示観察内容からまだ答えが得られていないことを特定します。これらを、次回の計画セッションで扱います。

デザイナーとの協働

まず、インタビュー、録音、チケット、分析データなど、何があるかを確認し、モードを明示します。名詞(候補となるドメインオブジェクト)と、ユーザーが使う自然な言葉に耳を傾けます。これらはドメインレイヤーに反映されます。

目的に合った手法を提案します。Plan では学習目標に合った手法を、Synthesise では抽出 → パターン → 候補となるストーリーを使います。一連の手法をすべて行うのではなく、次に役立つことを行います。

残すのは要点だけです。重要な生の観察結果、裏付けとなる証拠を伴うパターン、自信度を付けた候補となるジョブストーリー、明示された調査ギャップを記録します。

候補となるジョブストーリーは /layers-user-needs で洗練できます。

コメント