メインコンテンツへスキップ
レッスン一覧に戻る

atom.nocode-builder.run-user-testing-cycles

利用テストで改善する

利用テストで改善する 料理を作ったあと、自分だけで味見をするのではなく、食べてくれる人に「どう?」と聞いてみると、初めて本当の味がわかりますよね。塩が足りないとか、思ったより辛いとか、自分では気づけないことがたくさ...

run-user-test-cyclerun-user-test-cycle「run user test cycle」に関するスキルがこのレッスンで身につきます。
想定時間未設定公開状態: draft
学習メモ

成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。

種類: markdown_doc検証: basic_manual_check_v1

証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。

screenshot

メディアメディアレッスン内に出てくる図や動画のスロットです。実際の画面やイメージで理解を補助します。

diagramscreen_capture

レッスン本文

利用テストで改善する

料理を作ったあと、自分だけで味見をするのではなく、食べてくれる人に「どう?」と聞いてみると、初めて本当の味がわかりますよね。塩が足りないとか、思ったより辛いとか、自分では気づけないことがたくさんあります。

あなたが作ったツールやアプリも同じです。自分では使いやすいと思っていても、実際に使う人に触ってもらわないと「ここが分かりにくい」「このボタンの意味が伝わらない」といった問題は見えてきません。

このレッスンでは、利用テスト(=作ったものを実際のユーザーに使ってもらい、意見を聞くこと) を1周回す方法を学びます。AIツールを活用して、テスト準備から結果の整理まで効率よく進めましょう。

利用テストの流れ

前提を確認する

このレッスンを進める前に、以下を用意してください。

  • あなたがすでに作った、誰かに使ってもらいたいもの(画面のプロトタイプでも、実際に動くものでもOK)
  • テストに協力してくれる人(同僚、友人、家族など 1〜3人)
  • AIチャットツール(ChatGPT、Claude など。無料プランで十分です)

プログラミングの知識は一切不要です。

テストの目的を決める

まずは「何を確認したいか」を1つに絞ります。目的が曖昧だと、テスト後に「結局どうだったの?」となってしまいます。

良い例:

  • 「問い合わせフォームが最後まで入力できるか確認する」
  • 「トップページから目的のボタンにたどり着けるか確認する」

悪い例:

  • 「使いやすさを全部チェックする」(広すぎて結果がぼやけます)
  • 「デザインの感想を聞く」(具体的な操作を見ないと改善につながりません)

目的は1文で書けるくらいシンプルにしましょう。迷ったら、AIに相談するのもおすすめです。

AIへのプロンプト例: 「私は社内向けの備品管理ツールを作りました。初めて使う人がつまずきそうなポイントを3つ挙げて、それぞれの確認方法を1文で教えてください。」

テストでやることを3つにまとめる

利用テストは次の3ステップで進めます。

  1. お願いする − テスト協力者に「〇〇をやってみてください」とお願いする
  2. 見守る − 横で黙って見る。手助けしない
  3. 聞き取る − 終わったあと「どこで困ったか」を聞く

ここで大切なのは、途中で教えないことです。「ここ押してください」と言いたくなりますが、ぐっと我慢して相手の動きを観察しましょう。教えてしまうと、本当に分かりにくい部分が見つけられなくなります。

良い例:

  • 「この画面から、資料をダウンロードしてみてください」とだけ伝える

悪い例:

  • 「まず右上のボタンを押して、次にここを押して…」と全部教えてしまう

お願い文をAIで作る

テスト協力者にお願いする文章をAIツールで作ると、丁寧で過不足ない依頼文がすぐに用意できます。

AIへのプロンプト例: 「以下の条件で、利用テストのお願い文を作ってください。

  • ツール:社内の備品管理アプリ
  • テストの目的:新しい備品を登録できるか確認する
  • 相手:同じ部署の同僚
  • 文の長さ:1分以内に読める量
  • トーン:敬語で親しみやすく」

生成された文章をそのまま、または少し直して使いましょう。

AIでお願い文を生成する画面例

テストを実施する

準備ができたら、実際にやってもらいましょう。

  1. お願い文を読み上げる(またはチャットで送る)
  2. 相手が画面を操作する様子を静かに見る
  3. つまずいた瞬間をメモする(「どこで止まったか」「何を探していたか」「戸惑った表情をしたか」)

メモの取り方のコツは「事実をそのまま書く」ことです。

良い例:

  • 「送信ボタンの前で5秒止まった」
  • 「画面を上下にスクロールして何かを探していた」

悪い例:

  • 「UIが悪い」(解釈が入っていて、何を直せばいいか分かりません)

結果をAIで整理して改善案を出す

テストが終わったら、メモをAIに渡して整理してもらいましょう。

AIへのプロンプト例: 「以下は利用テストで取ったメモです。つまずきポイント・推測される原因・改善案を表形式にまとめてください。改善案は実現しやすさの順に並べてください。

メモ:

  • 送信ボタンの前で5秒止まった
  • 入力欄のラベルを読んで首をかしげていた
  • 完了画面のあと、次に何をすればいいか分からず固まった」

AIが整理してくれた表は、たとえば次のようになります。

つまずきポイント原因(推測)改善案
送信ボタンの前で5秒止まったボタンの色が背景と似ていて目立たないボタンの色を目立つ色に変える
入力欄のラベルが分かりにくい専門用語を使っている日常的な言葉に書き換える
完了後に次の操作が分からない完了画面に案内がない「次は〇〇してください」と表示を追加する

改善案は1回のテストで最大3つまでに絞ります。一度に直しすぎると、何が効いたか分からなくなります。

良い例:

  • 「ボタンの色を変える」「完了画面に案内を追加する」の2つを直す

悪い例:

  • 10個の改善案を全部一度に直す

改善できたか確認する

直したら、もう一度同じ人か別の人にテストをお願いします。

確認するのは次の2点です。

  • 前回つまずいた部分が解消されたか
  • 新しく別の問題が出ていないか

この「テスト → 改善 → またテスト」の繰り返しが、利用テストサイクルです。1回で完璧にならなくて大丈夫。繰り返すたびに、あなたのツールは確実に使いやすくなります。

つまずきポイントを知っておく

よくあるつまずき対処法
テスト相手が見つからない家族や友人でもOK。まずは1人から始めましょう
相手が遠慮して本音を言わない「厳しい意見ほど助かります」と最初に伝える
メモを取り忘れるスマホのボイスメモで録音する(相手の許可を取ってください)
改善案が多すぎて迷うAIに「この中で最もインパクトが大きいものを1つ選んで理由を教えて」と聞く
直したのに改善されない原因の推測が違っていた可能性。もう一度観察メモを見直す

このレッスンで作るもの

以下の4項目をまとめたテスト記録メモ(Markdown形式の文書)を完成させてください。

  1. テストの目的(1文)
  2. テスト参加者と実施日
  3. 観察メモ(つまずきポイント)とAIで整理した改善案テーブル
  4. 改善後の再テスト結果(1〜2行でOK)

AIへのプロンプト例(テンプレート作成): 「利用テストの記録テンプレートをMarkdown形式で作ってください。項目は、テスト目的、参加者、実施日、観察メモ、改善案テーブル(つまずき/原因/改善案の3列)、再テスト結果です。」

完了を確認する

次のチェックリストをすべて満たしたら、このレッスンは完了です。

  • テストの目的を1文で書けた
  • 1人以上に実際にテストしてもらった
  • つまずきポイントを3つ以内に整理できた
  • 改善案を少なくとも1つ実行した
  • テスト記録メモを完成させた
  • 完成したメモのスクリーンショットを撮った

完成したら、スクリーンショットを撮って完了です!

成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。

種類: markdown_doc

検証: basic_manual_check_v1

証跡とメディア

証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。

screenshot

メディア

diagramscreen_capture
前提 atom

必須

なし

あると楽

なし

学習完了