← 実践記事

OTSUMU KNOWLEDGE

操作を説明しないユーザーテストで、画面の問題を見つける

試作画面を紹介して感想を聞くだけでは、利用者が一人で使えるか分かりません。ユーザーテストでは、実際の目的に近い課題を渡し、どこで迷い、何を手掛かりに判断するかを観察します。

画面名を教えない課題を作る

「検索ボタンを押してください」ではなく、「来週使える会議室を探してください」と目的を伝えます。操作方法を指定すると、その画面の分かりにくさが隠れてしまいます。対象者は、想定する業務や状況に近い人を選びます。

助けた場面も記録する

進行役はすぐ説明せず、どこを見ているか、何を期待しているかを尋ねます。途中で支援した場合は、どの説明が必要だったかを残します。参加者の能力を評価する場ではなく、製品側の問題を調べる場であることも伝えます。

問題を影響で並べる

好みの違い、時間がかかる問題、仕事を完了できない問題を分けます。一人が強く希望した機能を即座に追加するより、複数の場面で詰まる原因を優先します。少数のテスト結果を市場全体の利用率として扱わないでください。

修正後も同じ目的で確認する

問題、仮説、修正、再確認の結果を記録します。ボタンの色だけでなく、用語や業務の流れそのものが原因の場合もあります。操作の改善と、顧客が対価を払うかの検証は別に進めます。

参考資料と編集について

新規事業.com の関連ナレッジ ↗をもとに、Otsumuが検証・実装・運用の観点から再編集しました。制度・仕様・サービスの現況は、各提供元の最新情報をご確認ください。

編集:Otsumu株式会社 / 編集日 2026.09.19

あわせて読む

次の一手を、一緒に。

事業の検証から開発・運用まで、現在の段階に合わせて支援します。

事業について相談する ↗
FROM KNOWLEDGE TO ACTION

知識を、次の一手へ。

30分の無料診断で、次の一手を整理する ↗