問い合わせボタンを見つけやすくしても、送信後に何が起きるか分からなければ、不安は残ります。入力画面が整っていても、返答で困り事が解決しなければ、利用者の目的は達成されていません。
UI/UXの改善では、画面をきれいにすることに加えて、誰が、どの状況で、何をできるようにしたいかを決めます。このガイドは、用語、調査、設計、評価をつなぎ、課題に応じて詳しい記事へ進むための入口です。
30秒で要点
- 利用者の目標と、事業側の目標をそれぞれ書きます。両方を満たせる設計かを確認します。
- 利用前・操作中・利用後のどこで困っているかを調べ、試作で確かめる問いを絞ります。
- 指標は目標から選び、対象・分母・期間を固定します。操作の成功、内容の理解、解決は同じ到達点ではありません。
どこから読むか — 自分の状況から選ぶ
この記事はUI/UXを利用者の目的から組み立てる考え方を扱います。個別の手法・基準・心理の論点はそれぞれ別の記事にあります。
言葉の整理から入りたい。 違いの基本はUI/UXとは？、デザインの定義そのものは「意図された変化」としてのデザイン、調べ方の入口はUXリサーチ入門。
アクセシビリティに対応したい。 実践の手順はWebアクセシビリティの実践ガイド、用語から確認するならアクセシビリティとは？、どの基準に準拠するかはWCAG 2.2とJISどちらに準拠か、動きの配慮はprefers-reduced-motionは「全停止」ではない。
心理の知見を設計に使いたい。 全体像はデジタルインターフェースの心理学、数字の見せ方はアンカリング効果とは？、残数や期限の表示は希少性の心理学、レビューや導入数は社会的証明とは？、監修・認証の扱いは権威の心理学。
やりすぎの線引きで迷う。 境界の考え方はダークパターンと正当な訴求、解約動線の判断はサブスク解約を「わかりにくく」してよいのか、小さな選択の設計はコミットメントと一貫性とは？。
使われ続ける設計にしたい。 やる気より文脈という見方は「やる気」より「文脈」ではないか、細部の質はマイクロインタラクションデザインガイド、数字から直すならデータドリブンUX改善ガイド。
UI、UX、使いやすさの関係
表が収まらない場合は、横にスクロールできます
| 観点 | 主に見るもの | 問い合わせの例 |
|---|---|---|
| UI：ユーザーインターフェース | 画面、入力、操作、システムの応答などの接点 | 項目のラベルを読めるか。エラー後に修正できるか |
| 使いやすさ | 特定の利用者が、ある状況で目的を達成しやすいか | 自分に必要な窓口を見つけ、無理なく送れるか |
| UX：ユーザー体験 | サービスとの関わり全体で生じる経験や受け止め方 | 対応範囲を理解して依頼し、返答を受け、困り事が解決するか |
UIは視覚的な装飾だけではありません。キーボードの操作、読み上げへ伝わる情報、処理中や完了時の応答も接点に含まれます。また、UXには必要な内容が提供されるか、運用が約束を果たすかも関係します。NormanとNielsenは、UIとサービス全体の体験を区別し、操作がよくても必要な内容がなければUXは良くならない例を示しています。著者によるUXの定義
基本語を確認したい場合はUI/UXの入門、設計の目的から考えたい場合はデザインの基本へ進んでください。
利用者の目標を、画面より広く捉える
「問い合わせを増やす」は事業側の目標です。利用者側には「相談してよい内容か確認したい」「返答の時期を知りたい」「問題を解決したい」などの目標があります。数を増やすだけでなく、双方の目標が重なる条件を探します。
次の図は仮想の問い合わせサービスです。同じ100人を追い、受付完了と、利用者が解決を確認した状態を分けています。数字は測定方法を説明するための例で、改善効果や一般的な水準ではありません。
図の受付率は80÷100で80%、解決率は72÷100で72%です。受付済みの人だけを分母にすると解決割合は72÷80で90%になります。いずれも計算は正しくても、答える問いが違います。実際には未回答・追跡中・途中離脱も記録し、確認できなかった人を都合よく分母から外さないようにします。
利用者がフォームを使わず案内文だけで解決した場合には、それも別の成功経路です。送信数の減少だけを失敗と見なさず、必要な到達点をサービスに合わせて定義します。
調査から改善まで、五つの判断をつなぐ
1. 対象と状況を決める
新規利用者か、繰り返し使う人か。スマートフォンか、業務用端末か。どこまで知識を持っているか。誰についての問題かが曖昧なままでは、改善案を比べにくくなります。
対象を狭めることは、他の人を無視することではありません。まず調べる範囲を明示し、異なる状況での問題を別に記録します。支援技術を使う人や、操作に不慣れな人も計画へ含めます。
2. 観測と解釈を分ける
アクセス解析では、離脱や戻り操作が起きた場所を調べられます。ただしログだけでは、その人が何をしたかったか、なぜやめたかは分からない場合があります。
操作観察やインタビューでは「何に困ったか」の説明候補を探します。「項目の前で止まった」は観測、「意味が分からなかった」は確認が必要な解釈です。利用者の発言、操作、担当者の推測を分けて残します。UXリサーチの基本とデータから改善を考える方法が役立ちます。
3. 情報と操作の仮説を作る
例えば「添付が必要か分からず送れない」という観測なら、必要条件を事前に示す案、添付せず後から追加できる案、別窓口へ案内する案を比べます。文言を短くするだけでよいとは限りません。
画面のまとまり、ラベル、選択肢の比較、エラー後の修正経路を設計します。心理学は仮説を考える材料になりますが、研究で観測された効果をそのまま自社の成果率へ置き換えないでください。インターフェースの心理学と行動経済学をWebへ応用する際の考え方へ接続できます。
4. 試作で、利用者ができるかを確認する
試作は完成画面でなくても構いません。確認したい動作ができる程度の画面を用意し、実際の利用者または利用しそうな人に、現実的な課題を依頼します。「このボタンを押してください」ではなく「予定を変更したいので、必要な手続きをしてください」のように目的を伝えます。
GOV.UKの方法ガイドも、答えを示唆しない課題、観察、必要に応じた質問を勧めています。操作を試す対象はサービスであり、参加者の能力を採点する場ではありません。モデレート型ユーザビリティテストの公式ガイド
5. 比較する変更の単位を決める
一つの文言を比較することも、複数箇所をまとめた新しいフローを比較することもできます。まとめて変えた場合に分かるのは、その変更案全体の違いです。個々の要素の寄与を知りたいなら、要素を分けた比較や実験計画が必要になります。
前後の数字だけでは、季節、広告、利用者構成の変化が混ざります。因果的な効果を知りたい場合は、割り付けや対象数を含む比較設計を行います。A/Bテストの統計へ。入力後の運用も問題なら、業務プロセスの改善まで検討範囲を広げます。
指標は「測れる数字」からではなく「目標」から選ぶ
Googleの研究者によるHEARTは、満足などの主観的評価、関与の深さ、新しい利用、継続利用、課題の達成という五つの観点で指標を整理します。全てを採用する必要はなく、目標→達成を示す兆候→測定する指標の順に選びます。これは同社の実践から提案された枠組みで、導入による成果保証ではありません。HEART原論文
表が収まらない場合は、横にスクロールできます
| 目標の例 | 確認したい兆候 | 指標と条件の例 |
|---|---|---|
| 必要な窓口へ依頼できる | 適切な分類で受付が完了する | 定義した開始者に占める、追跡期間内の適切な受付完了者の割合 |
| 不備から立て直せる | エラー後も修正して手続きできる | エラー発生者に占める修正完了者の割合。件数と重症度も確認 |
| 返答が役立つ | 利用者が解決したと回答する | 対象全員に対する解決確認者の割合と、未回答者の数 |
PV（ページ閲覧数）や滞在時間が増える理由には、関心の高まりだけでなく、迷いもあります。短時間で必要な答えが得られるサービスでは、短い利用が望ましい場合もあります。申込み率を重視する場合も、誤申込みや取り消しの負担を併せて見ます。CVR改善のガイドを使い、事業目標だけに評価が偏っていないか確かめます。
集計前には、対象、数える単位、人の重複、分子・分母、期間、完了の定義、計測漏れを決めます。率が上がっていても、達成しにくい人が集計から抜けていれば評価は変わります。
アクセシビリティを後付けの確認にしない
アクセシビリティは、障害のある人が内容を知覚し、理解し、操作できることに関わります。W3Cは、支援技術と動作するコードの要件と、分かりやすい案内などの使いやすさの要件が重なることを説明しています。一般的なユーザーテストだけでも、基準のチェックだけでも、全ての問題を捉えられるとは限りません。W3Cのアクセシビリティ・使いやすさの整理
設計初期から、キーボードで辿れる順序、ラベル、色だけに頼らない状態表示、拡大した画面での情報の見え方などを確認します。具体的な要件を学ぶ場合はアクセシビリティ入門へ。対象者の参加と技術的な確認を組み合わせ、この簡易確認だけで適合を宣言しないでください。
最小の検証：一つの課題を、最初から最後まで確かめる
- 「問い合わせを送り、次の対応を理解する」など、利用者の達成を一文で書きます。
- 課題、対象者、利用端末、成功とみなす状態を決め、試作を用意します。
- 操作を誘導せずに観察し、止まった箇所、誤り、修正、完了後の理解を記録します。個人情報を不要に集めないため、使うデータも事前に決めます。
- 分からなかった理由を確認し、観測と推測を分けて、一つの改善仮説にまとめます。
- 修正後も同じ課題と成功条件で確認します。少人数で見つけた問題と、全利用者にどれほど起きるかという推定は分けます。
一回で全体のUXを測ったことにはなりません。まず不明だった条件を減らし、残った問いに応じて調査や比較を追加します。チーム内の思い込みも点検したい場合は意思決定バイアスの点検ガイドへ進めてください。
参考資料・引用元
本記事は2026年10月8日に以下の一次資料を再読し、記述を確認しています。
UI、UX、アクセシビリティ、観察、標準検査、定量指標はそれぞれ別のものとして扱います。フレームワークや少人数のテストを、利用者全体の満足や収益の保証として扱うことはできません。