usability-testing について
コンセプト検証から実際のプロダクトの使いにくさの発見まで、ユーザビリティテストの計画を支援するスキルです。テストの忠実度、参加者やシナリオの設計、観察、結果の反復への活用を扱います。
主な機能
- 01テスト目標の明確化
- 02適切なテスト忠実度の選択
- 03参加者募集とシナリオの計画
- 04自己申告より行動観察を重視
- 05結果を反復開発に反映
活用シーン
- 01開発前のコンセプト検証
- 02ユーザーフローのつまずきの発見
- 03複数のデザイン案の比較
- 04テスト結果をチームで活用する計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/usability-testingを入力して読み込まれたか確認します。
同梱ファイルreferences/guest-insights.md
詳細
ユーザビリティテスト
11 人のプロダクトリーダーのフレームワークと知見を活用して、効果的なユーザビリティテストを実施できるようユーザーを支援します。
支援の方法
ユーザーがユーザビリティテストについて支援を求めた場合：
- 目標を明確にする - コンセプトの検証、摩擦点の発見、コンバージョンの最適化のどれを目指しているかを確認します
- 適切な忠実度を選ぶ - Wizard of Oz テスト、フェイクドア、プロトタイプ、本番環境でのテストから選べるよう支援します
- テストを設計する - ユーザーの募集、シナリオの作成、観察する内容について案内します
- 反復の計画を立てる - テスト結果をプロダクト開発プロセスにどう反映するかを話し合います
基本原則
作る前に、まずは模擬する
Itamar Gilad：「最初は模擬します。フェイクドアテスト、スモークテスト、Wizard of Oz テストなどです。タブ式の受信トレイが動作するところを人々に見せましたが、実際は Gmail ではなく、単なる見せかけでした。」本番コードを書く前に、人間が裏側で自動化タスクを実行する模擬版を使って、核となる価値提案を検証します。
少人数のサンプルから、大きな摩擦が見つかる
Melanie Perkins：「インターネット上で無作為に選んだ 10 人に聞くだけで、大勢の人に当てはまるような、非常に的確なフィードバックが得られることに驚きます。」わずか 10 人の無作為な参加者でテストを行い、プロダクトの根本的な問題を特定します。
ユーザーに尋ねるだけでなく、観察する
Uri Levine：「ユーザーをただ観察して、何をしているかを見るのです。予想と違う行動をしていたら、理由を尋ねます。」直接観察することで、アンケートでは見落とされる行動やニーズが明らかになります。ユーザーが想定した経路から外れたときは、「なぜ」と尋ねます。
1 つではなく、複数の選択肢をテストする
Kristen Berman：「1 つだけを見せる UX 調査は、決して行いません。必ず複数の選択肢を提示し、どれが意図した行動を最も促すかを比較します。」単一デザインのテストでは、ユーザーの行動を効果的に予測できません。
作り手のバイアスを克服する
Guillermo Rauch：「自分のプロダクトがどれほどよく機能するかを、実際以上に高く評価しがちです。別の人にプロダクトを使ってもらい、操作する様子を観察することがとても大切です。」ユーザーを直接観察することで、自分のプロダクトは実際より直感的に使えると思い込む傾向を克服できます。
ミクロなテストが、数百万の成果をもたらす
Judd Antin：「ボタンが怖く感じられるとわかったことで、7 文字を変更し、Airbnb は数百万ドルの成果を得ました。」ユーザビリティテストを初歩的な仕事だと軽視してはいけません。恐怖感や混乱を招く CTA を見つけることが、コンバージョンに大きな影響を与える場合があります。
テストの段階を順に進める
Itamar Gilad：「中間段階のテストでは、ラフなバージョンを作ります。早期採用者プログラム、アルファ版、長期的なユーザー調査、そしてフィッシュフード（自分のチームでのテスト）などです。」まずフィッシュフーディングから始め、ドッグフーディング、アルファ版へと段階を進め、確信度を高めていきます。
チーム全体で取り組む
Noah Weiss：「PM、エンジニア、デザイナー、ユーザーリサーチャーが、全員で 1 つの Slack スレッドに参加し、ユーザビリティセッションにリアルタイムで反応していました。」部門横断のチームが共有チャットスレッドでセッションにリアルタイムで反応することで、参加を促します。
ユーザーを支援するための質問
- 「観察または検証しようとしている具体的な行動は何ですか？」
- 「コンセプトの検証が必要ですか（フェイクドアを使いますか）、それとも実行方法の最適化が必要ですか（実際のプロダクトを使いますか）？」
- 「率直なフィードバックを得るために、利害関係のないユーザーをどのように募集しますか？」
- 「1 つの選択肢をテストしますか、それとも複数の選択肢を比較しますか？」
- 「テスト結果をどう活用しますか。開発にどのように反映しますか？」
- 「チームの誰にセッションを観察してもらうべきですか？」
よくある注意点
- 1 つのデザインだけをテストする - 相対的なパフォーマンスを測定するために、複数の選択肢を提示します
- 検証前に作り始める - 本番コードを書く前に、オズの魔法使いテストやフェイクドアテストを行います
- 社内の直感に頼る - 社員は製品に詳しすぎるため、実際にユーザーが感じる使いにくさを見つけられません
- 細部の問題を無視する - ちょっとしたコピーの変更やボタンのラベルが、ビジネスに大きな影響を与えることがあります
- 単独でテストする - エンジニアやデザイナーにもセッションに参加してもらい、共通認識を深めます
詳細
11 人のゲストから得られた 14 の知見すべてについては、references/guest-insights.md をご覧ください
関連スキル
- 顧客調査
- PRD の作成
- 製品のリリース
- グロースループの設計