「予約できました」、でも画面は下書きのまま。画面試作で見つける使いにくさ

たとえば「保存を押したので、予約できました」。本人はそう話しているのに、画面の状態は下書きのまま。新しい備品予約ポータルで考えます（想定例）。画面への感想に加えて、目的を達成するまでの操作を確かめる必要があります。

短い画面試作を使い、「登録する・探して変更する・間違いを取り消す」の行動を記録すると、迷った箇所と修正する理由を具体的に話せます。

対象は、開発前から画面設計中の業務システムです。試作での操作の観察と、実装後に行う性能・連携・権限の試験や納品物の検収は、別の段階として扱います。

試作v0.1を2026年9月15日に試すと仮定し、観察記録の書き方を見ていきます。実際に試して得た結果は、記入票の空欄版へ書き込んでください。

課題文、開始状態、観察記録、修正・再確認の見本と空欄版は、画面試作・利用者テストの記入票（Excel）から利用できます。

「保存」の先に、何が起きたかを見せる

同じ10月6日の備品P-01の予約でも、次の文言では利用者に伝わる意味が変わります。下書きを残す操作と、予約を確定する操作を分けた表示案です。

画面に表示するもの	迷いが残る表示	下書き保存後の表示案	予約確定後の表示案
見出し	保存しました	下書きを保存しました	予約が確定しました
対象	P-01／10月6日	P-01／10月6日	P-01／10月6日
現在の状態	画面の下に「下書き」	まだ予約されていません	予約済み
次の操作	ホームへ戻る	予約を確定する	自分の予約を見る

PCでは状態とボタンが同時に見えても、幅390pxのスマホでは縦に並び、状態が画面の下へ押し出されるかもしれません。表示案では結果と状態を近くに置きます。スマホで文字を拡大したときも、「まだ予約されていない」と分かるかを試します。この表示案も、実際の利用者が操作して予約の状態を判断できるか、これから試します。

試す利用場面を選ぶ

最初に「誰が、どこで、何を済ませる画面か」を決めます。初回利用なら入口や言葉の意味、毎日の操作なら探し直しや繰り返し入力、間違えた場面なら取消ややり直しが焦点です。「社員向け」だけでは、スマホで初めて入力する人と、PCで毎日確認する人のどちらを優先するか判断できません。

参加者は、設計内容を知る担当者だけでなく、実際の利用者に近い人から選びます。業務経験、画面への習熟、入力方法を分けて考え、対象に含まれる人の利用条件を落とさないようにします。役職や年齢だけで「この人が全員の代表」と決めないことも必要です。

例の備品予約ポータルには、説明用に作ったデータを使います。実案件でも、本番データを持ち込まずに試せる範囲を用意します。ただし、現場の本物の書類でなければ分からない難しさは別途確認します。GOV.UKの利用者テスト資料は、実際または想定される利用者の参加と、架空データでは把握できない場合があることを説明しています。

試作の深さを決める

試作（プロトタイプ）は、完成品を作る前に画面や操作の仮説を確かめるものです。確かめたい用事に合わせて紙、静止画、クリック可能な試作、HTML等で動く試作を選び、必要な部分だけ組み合わせます。

表1　同じ予約業務でも、試作の深さで試せる範囲が変わる

試作の種類	確かめること	この段階で残ること
紙の試作	項目の意味、情報の順番、どこを押したいか。進行役が紙を差し替える。	実端末での文字入力、スクロール、読み上げは確かめられない。
静止画	文言や表示の優先度、実寸での見え方。	入力から完了までの移動や、入力ミスからの復帰は試せない。
クリック可能な試作	作った経路の中で、登録・変更・取消へ進めるか。	入力欄、エラー、戻る操作が未再現なら、その挙動は試せない。
HTML等で動く試作	実装した範囲で、入力・キーボード・支援技術との操作を試す。	本番の性能・連携・権限・保存の正しさは、実装後に試す。

「登録」なら入力から確定表示まで、「変更」なら既存データを探して直すところまで、「取消」なら取り消す対象と残す対象を見分けるところまで用意します。成功画面だけでなく、戻る画面や入力エラーも対象です。作っていない経路で止まった場合は、利用者の迷いと混同せず「試作未実装」と記録します。

本物らしい完成画面の静止画でも、本人が入力し、間違いを直して完了できるかは分かりません。キーボードや読み上げの挙動が問いなら、画像の切替に加えて、必要な部分を動く形にします。GOV.UKの試作資料でも、試作のコードと本番のコードでは品質条件が異なり、そのまま本番へコピーしないよう案内しています。

利用者に操作してもらう

始める前に、「あなたの能力ではなく、画面を確かめます。途中でやめても構いません」と伝えます。記録や録画をする場合は、目的・閲覧者・保管期限を説明して同意を得ます。試作に外部への送信や本当の予約がないことも事前に確認します。

課題では、操作手順ではなく目的を渡します。たとえば「予約一覧の右上を押してください」では、入口を見つけられるか分かりません。「自分の予約日を変更し、変更後の日付を確かめてください」と頼み、進行役は操作を先回りして教えないようにします。

Excelの「課題設定」シートには、そのまま読める課題文と開始状態を用意しています。3課題は、それぞれ必要なデータを最初から準備します。登録に失敗したために変更・取消も試せない、という連鎖を避けるためです。次の表では、説明前の行動と、その後の支援を分けて記録しています。

三つとも説明用の想定で、OS・ブラウザの版、ほかの利用者での結果、修正による改善効果は未確認です。実際に試す際はこれらを記入し、各表の「未確認」欄に挙げた操作も確かめます。

表2　登録する：説明前の行動と修正案

記録項目	記入例
利用者と端末	初回利用の社員A。スマホ縦向き、表示幅390 CSS pxを想定。
達成する用事	10月6日のP-01を予約し、予約できたかを見る。
迷った箇所（説明前）	「保存」を押す→ホームへ戻る→予約が終わったと話す。試作上は下書きのまま。
誤操作と支援	下書きと確定を混同。進行役が状態欄を示した後に確定。結果区分は「支援あり達成」。
修正後の再確認	保存を「下書き保存」と明記。確定表示を分け、説明なしで対象と状態を判断できるかを試す。再確認は未実施。
根拠	GOV.UK：観察方法／W3C：表示・入力の基準。
未確認	実際の保存、通信断後の記録の保持。

表3　探して変更する：説明前の行動と修正案

記録項目	記入例
利用者と端末	日常業務を知る社員B。ノートPC、表示幅1280 CSS px、マウス操作を想定。
達成する用事	自分のR-102を探し、10月8日から9日に変更する。
迷った箇所（説明前）	全体検索で予約番号を入力→見つからずホームへ戻る→「自分の予約」で対象を探し直す。
誤操作と支援	全体検索はお知らせのみが対象。助言なしで見つけて変更。結果区分は「自力達成」。迷いは残る。
修正後の再確認	検索対象を明記し、自分の予約への入口を見直す。重複登録せず既存予約を変更できるかを試す。再確認は未実施。
根拠	GOV.UK：観察方法。
未確認	大量データでの検索速度、検索権限。

表4　間違いを取り消す：説明前の行動と修正案

記録項目	記入例
利用者と端末	キーボードで操作する社員C。PC、表示幅1280 CSS px、HTML試作を想定。
達成する用事	重複分R-103だけを取り消し、R-102を残す。
迷った箇所（説明前）	取消確認を開く→Tabを押す→画面の背後へ移動し、確定ボタンに到達できず止まる。
誤操作と支援	誤取消は未発生。マウスへの変更を求めず終了。結果区分は「未達成」。
修正後の再確認	確認画面のフォーカス移動を直す。キーボードでR-103だけを取り消し、R-102が残る表示まで試す。再確認は未実施。
根拠	W3C：2.1.1・2.4.7／GOV.UK：観察方法。
未確認	読み上げとの連動、取消の実処理・権限・履歴。

「分かりにくそうだった」という感想より、「検索して戻った」「下書きを完了と話した」のように行動を残します。原因の推測や修正案は、その記録と分けます。困っている人を放置する必要はありません。助けたら、いつ何を伝えたかと、助言後の結果を別に記録します。

記入票では、結果を「自力達成・支援あり達成・未達成・試作未実装・未実施」に分けます。普段使う読み上げや入力支援は通常の利用条件です。進行役が正解の場所を教える支援は、別に記録します。話しながらの操作時間を、本番の処理速度や改善率に読み替えることもしません。

環境と操作条件をそろえる

端末名だけでなく、OS・ブラウザの版、画面の表示幅、文字の拡大設定、入力方法、通信状態、使う場所を記録します。実施した条件が不明なら、結果を別の環境へ広げられません。表の390・1280 CSS pxは説明用の表示幅です。対応端末や合格の基準は、自社の利用条件に合わせて決めます。

現場でスマホを使うなら、縦向き表示、文字拡大、入力中に画面が隠れる範囲を見ます。屋外利用があるなら、安全な場所で日差しや反射も試します。PCの画面幅だけを狭めても、実機の入力感や屋外の見え方を確認したことにはなりません。条件は発注者の現場担当者と実際の利用者に聞き、端末の設定画面や社内の対応環境一覧で確かめます。

アクセシビリティを調べるには、W3C「WCAG 2.2」を参照できます。たとえば、文字のコントラスト（1.4.3）、文字拡大（1.4.4）、狭い表示幅での折返し（1.4.10）、キーボード操作（2.1.1）とフォーカス表示（2.4.7）、エラーの説明（3.3.1）や入力のラベル（3.3.2）です。これらは確認の入口です。適合を判断するときは、各基準の適用条件と必要な全項目を確かめます。

たとえば、マウスで完了できた取消画面でも、表4のようにキーボードでは進めないなら、同じ「使える」とは判定できません。画面読み上げが必要なのに試作が対応していない場合も、未確認として残し、動く試作や実装後の環境で確認を計画します。

基準に合っているかと、対象の人が用事を済ませられるかは、両方を試します。W3C WAIの利用者評価資料も、利用者による評価と基準への適合評価を組み合わせること、少人数の結果を全利用者へ一般化しないことを示しています。

「予約できた」を、申請と承認の二地点で確かめる

事前予約する共用機器の操作例で、「今日13:00〜14:00に撮影用カメラを使いたい」という課題を試せます。2026年10月26日、使う班を「確認用の班」として申請すると、R912が「申請中」になりました。承認すると「承認済み」へ進み、さらに「渡した」の操作が残っています。申請・承認・現物の受渡しが別の状態です。

利用者に試してもらうときは、先に「予約ボタンを押してください」と教えず、上の用事だけを伝えます。「できた」と話した時点で、何を見てそう思ったかを聞き、表示された状態と対応させます。

観察票へ残すもの	記入の仕方
利用者の発言	「申請を出せた」と「利用が確定した」を、本人の言葉のまま記録
画面の状態	申請中、承認済み、貸出中のどれだったか
課題の達成	今回の課題が申請までか、承認確認までかに照らして判定
次に直す箇所	状態の見落とし、次の行動の迷いなど、観察した理由を添える

状態を分ける学習教材（ZIP）の prototype でも、申請中・承認済み・貸出中の違いを比べられます。今回のブラウザ操作は執筆者による確認で、利用者テストの参加人数や成功率を測ったものではありません。自社の端末と利用者では、説明する前の操作を別に観察してください。

修正の優先順位を決める

まず、目的を達成できない、誤った完了判断をする、必要なデータを誤って消す問題を優先します。次に、回復はできても迷いや入力し直しが生じる問題を扱います。色の好みなどは、操作への影響があるのかを分けて相談します。重大度は業務への影響と回復方法に応じて調整します。

この例では、予約できたと思い込む問題と、キーボードで取消できない問題が先です。予約変更の課題で見つかった検索の迷いも、続けて直します。ただし、別人の予約を変更する危険が見つかれば、優先順位を上げます。「何人が困ったか」だけで、影響の大きい問題を後回しにしないためです。

修正票には、行動の記録、修正する理由、担当、対象版、再確認の条件を残します。改善後は問題の箇所だけでなく、前後の操作も含めて同じ用事を試します。同じ参加者が正解を覚えている可能性もあるため、初見の分かりやすさが問いなら別の人や同難度の課題で補います。

最初の打ち合わせには、試す利用者と端末、3つの用事、説明前の行動を記録する人をそろえます。画面に賛成してもらうことより、予約したつもりで帰ってしまう人を開発前に見つけることが、この試作の目的です。

実装後の受入確認はシステムの受入テスト・検収で確かめること、試作から本番へ進む判断は試作・PoC・MVPから本番へ進む条件と見送る条件で整理しています。導入後の運用は使われないシステムを直す｜改善要望の選び方をご覧ください。

募集者と応募者をつなぐサービスなら、画面の使いやすさに加え、手作業で成立するかを開発前に試せます（マッチングサービス開発前に手作業で試すこと）。

画面や動く見本の制作を依頼する場合は、試作・最小版開発の内容と費用で紹介しています。発注者は利用場面・参加者・業務上の完了条件を整理し、開発側は試作範囲・修正内容・技術上の未確認点を示す、という分担から始められます。誰が修正を決め、費用や日程に影響する変更をどの場で相談するかも確認します。

参考出典

• W3C「WCAG 2.2」2024年12月12日勧告版、1.4.3・1.4.4・1.4.10・2.1.1・2.4.7・3.3.1・3.3.2
• GOV.UK「Using moderated usability testing」課題設計、観察、架空データ、支援技術
• GOV.UK「Making prototypes」試作の選択と本番コードとの違い
• W3C WAI「Involving Users in Evaluating Web Accessibility」利用者評価と基準評価、小規模評価の限界