UIが悪い気がする？システム改善時に役立つリサーチとテストの方法まとめ

「なんかこの機能、使われてないんですよね。多分UIがよくないんだと思います」
業務システムのUI（ユーザーインターフェース）改善に関するご相談で、こういったお声をいただくことがあります。しかし、私たちはすぐに「ではUIを直しましょう」とは言いません。

なぜなら、システムが使われない原因は、UIの使い勝手だけにあるとは限らないからです。さまざまな要因を考慮して問題点を見極めたうえで、UIに課題があると明らかになった場合に、はじめて改善に取り組むべきだと考えています。
UI改善には「リサーチ → UI設計 → ユーザビリティテスト」というプロセスが重要であり、「UIを直す」という作業はそのプロセスの一部だといえます。

「UIが悪い」という声の、その奥にあるもの

“使われない機能”があったとき、多くの場合UIが疑われます。 でも実は、原因は違うところにあるケースも多々あります。
実際に「使われない機能があるからUIを見直したい」とお客様から伺ったケースで、次のような出来事がありました。

• その機能にたどり着く適切な導線がなかった（例：機能群が隠れており、ツールバーに機能がたくさんある）
• 業務上その機能が不要になっていた（例：開発当初は印刷用のPDF出力機能が必須だったが、ワークフローが変わり出力が不要になった。それでも画面上には「印刷」ボタンが残り続けている）

また反対に、UIに問題があり利用者が何度も操作につまずいていても、周囲の人がフォローしていたために“問題が表面化しなかった”というケースもあります（例：新人が操作方法に迷っていても、隣の先輩が毎回教えてくれていたため、UIの改善要望として声が上がらなかった）。

つまり、UI は“悪い結果”として見えているだけで、原因はユーザー理解の不足や業務設計の不整合にあるかもしれないということです。これは、ユーザーがどのような背景や前提で操作しているのか、どのような業務上の目的を持って行動しているのかといった体験全体——UX（ユーザー体験）に目を向けなければ、本質的な問題は見えてこないことを示しています。ここで少し専門的な言葉を使うなら、これは UX（ユーザーエクスペリエンス：ユーザー体験）の問題です。

UIはユーザーが直接目にする「見た目」の部分ですが、UXはそれに加えて、そのUIが「どのように使われるか」「業務の中でどう役立つか」といった「ユーザー自身が体験すること」が含まれています。

実際に、「UIだけ変えてほしい」とのご要望をうけて始めたプロジェクトでも、UIに起因すると思われていた問題を本質的に解決するには情報構造の見直しや導線の再設計、つまりUXを含めた再検討が必要になることが少なくありません。

UXデザインの5段階モデル

UXは、「UXデザインの5段階モデル」として整理されることがあります。
UXの5段階モデルを考案したのは、ジェシー・ジェームズ・ギャレット（Jesse James Garrett）です。彼が2002年に著書『The Elements of User Experience』の中で提唱したもので、UXデザインの考え方を「戦略」「要件」「構造」「骨格」「表層」の5段階に整理したフレームワークとして知られています。業務システムにも応用可能な設計思考の枠組みとして、このモデルを参考にしています。

図では「表層」が一番上に配置されていますが、これは“目に見える順序”としての構成です。
実際の設計の流れは、次の1〜5の順番で戦略層から積み上げていくのが、サービスを作り上げる上で自然な流れです。つまり、最後の「表層」で起きている問題も、1〜4にある「戦略」や「要件」の段階に原因があるケースが多いのです。

1. 戦略（Strategy）：ビジネス目標やユーザーの目的を定義する
2. 要件（Scope）：必要な機能やコンテンツを洗い出す
3. 構造（Structure）：情報や操作の流れを設計する
4. 骨格（Skeleton）：レイアウトや導線、UIコンポーネントを設計する
5. 表層（Surface）：色や形、タイポグラフィなどの“見た目”を整える

UIが属するのは一番上の「表層」です。ただし、厳密には構造や骨格などの層にもUI要素は関与しています。ユーザーの操作に直接かかわる部分である以上、UIは「表層」に限られたものではなく、複数の層をまたぐ存在だと捉えることが自然です。つまり、UIは全体設計の最終成果物であると同時に、その下にある“設計の積み重ね”と密接につながっており、UIだけを見直しても根本的な改善にはつながらないのです。
UI改善とは、この5層すべてに目を向けながらバランスよく設計し直すプロセスだと私たちは考えています。

UI改善はリサーチやテストとともにある

ここで、はじめに述べた、UI改善には「リサーチ → UI設計 → ユーザビリティテスト」というプロセスが重要という話題に戻ります。

リサーチというと難しく聞こえるかもしれませんが、要は「仮説と計画」を立てることです。
ユーザーがどこでつまずいていそうか、自分たちはどう改善すべきと考えているのか、それを整理する工程にすぎません。
そして、ユーザビリティテストはその仮説に対して「本当にそうだったのか？」を確かめる“振り返り”の時間です。
言葉こそ専門的ですが、実際には日頃の業務の中でも自然にやっていることと大きくは変わりません。

ただ、注意が必要なのは「テスト」という言葉が、特にエンジニアやPMの方にとっては“正しく使えるか”“エラーが起きないか”という観点で捉えられやすいという点です。
もちろんそれも大切ですが、ユーザビリティテストで見たいのは「迷わず目的を達成できるか」「使いにくさを感じていないか」というユーザー視点での“体験のスムーズさ”です。
つまり、UIの使いやすさはコードやシステムだけでは測れない“別の辛さ”に着目する必要があるということです。

UIを改善するというのは、“画面をきれいにする”ことではありません。
ユーザーが目的を達成しやすくなるように設計しなおすことです。
そのためには、以下のようなプロセスが必要です。

1. リサーチ：ユーザーや業務の実情を確認する
2. UI改善：課題に対して適切な解決策を設計する
3. ユーザビリティテスト：その解決策が意図通りに機能するかを確認する

この流れがひとつながりになって、初めて本質的な改善になります。

改善の“前後”を比較してこそ意味がある

リサーチとユーザビリティテストは、それぞれ別々の工程に見えますが、本来は改善の“前後”にセットで行うのが理想的です。
たとえば、ある画面が使いにくいという声が出ている場合：

• 改善前にインタビューや観察を通して「何が起きているのか」を把握する
• UIを改善する
• 改善後に再度同じ業務でユーザビリティテストを行い、「使いやすくなったか」を確認する

この比較をすることで、「改善が意味を持ったのかどうか」が明確になります。
実際、私たちがUI改善のプロジェクトに取り組む際は、同じ人に前後2回インタビューすることもよくあります。1回目では「ここがわかりづらかった」と話していた方が、改善後に「今回は迷わず進めました」と答える。それがまさに、改善の手応えです。

ユーザーの声がない＝リサーチ不足の可能性

本当はUIに問題があるのに、「ユーザーは問題なく使えている」と、システムの企画・開発側の人が勘違いして、問題を見落としていることもよくあります。
「ユーザーは問題なく使えている」という意見をお持ちの方に「実際にユーザーが使用している現場を“見た”ことがありますか？」と聞くと、得てして「見たことはない」とご返答を頂きます。

実際に現場を見に行くと

• マニュアルを見ながら慎重に操作している
• 入力エラーを何度もやり直している
• 他の人に声をかけながら手探りで進めている
• 紙に下書きをして、清書をPCでする

といった“見えないストレス”が存在していることはよくあります。
使えている＝使いやすい、ではありません。
多くの場合、ユーザーは「慣れ」によって問題を乗り越えてしまっているだけなのです。

リサーチとテストの代表的な手法一覧

以下は、UI改善に関するリサーチとユーザビリティテストで使われる主な手法の例です。

リサーチの方法（課題を見つける）

• ヒューリスティック評価：UIの原則に沿って、デザイナーが問題点を洗い出す。短時間で大枠を掴みたいときに向いている。
• エキスパートレビュー：業務やUXに詳しい第三者が画面をレビューして、潜在的な課題を抽出する。
• ユーザーインタビュー：現場ユーザーに話を聞いて、困りごとや価値観を深掘りする。改善前の仮説作りに有効。
• アンケート：ユーザー全体の傾向を把握するのに適しており、要望や満足度、優先度を幅広く集められる。
• 観察（フィールドワーク）：実際の業務中にどのようにUIが使われているかを観察。現場のリアルな使い方を把握できる。

ユーザビリティテストの方法（改善の効果を検証する）

• インタビュー（改善後）：改善したUIを使ってもらい、実際の使用感や効果、残る課題を聞き出す。
• 観察：改善後の業務の中で、UIがどのように使われているかを観察。リサーチと同じく“見に行く”ことが重要。
• シナリオベースの操作テスト：業務シナリオを設定し、画面操作を実際にしてもらうことで、迷いなく使えるかを確認する。

※テストとリサーチは対立するものではなく、改善の「前後で同じ手法を繰り返す」ことで、定性的な変化を把握しやすくなります。

見に行ける時も、行けない時も。リサーチの6つの方法

とはいえ、「現場に行くのが難しい」「どうやって調べればいいか分からない」といった声もあります。
そこで、私たちが実際に使っているリサーチの手法を6つご紹介します。現場に行ける時も、そうでない時も、状況に応じて選べる方法です。

1. 実際の操作をそばで観察する（同行・現場ヒアリング）
2. 操作ログやアクセスログを確認する
3. スクリーン録画や画面共有で操作を再現してもらう
4. 「この画面、どこで使いますか？」と聞く（業務マッピング）
5. 小さな困りごとを引き出すヒアリング
6. 業務のストーリーを聞く

ユーザビリティテストは小さくはじめられる

ユーザビリティテストというと、「エラーが起きないか」「仕様どおりに動くか」を確認する“機能テスト”のイメージが強いかもしれません。
しかし私たちが重視しているのは、あくまでユーザー視点での「迷わず目的を達成できるか」「使いやすいと感じられるか」という“体験の確認”です。
そのためのテスト方法としては、以下のようなものがあります：

• インタビュー（改善後）：実際に改善箇所を使ってもらい、率直な感想や迷いがなかったかを聞く
• 観察：実際の業務の流れの中でどのように新しいUIが使われているかを観察する
• シナリオベースの操作テスト：実際の業務シナリオを想定して、特定の作業をしてもらい、その様子を確認する

いずれも、改善前に実施したリサーチと“同じ観点・同じユーザー”で比較できるようにしておくことがポイントです。
つまり、リサーチとテストは本来つながっているものであり、「前後で同じ手法を使って比較する」ことが、UI改善の成果を見極めるうえでとても大切なのです。
ユーザビリティテストも「大がかりなもの」と思われがちですが、まずは以下のような方法から始められます。

1. リサーチで見つけた課題に対して仮説を立てる
2. 改善案を作成する（画面でも紙でも可）
3. 少人数のユーザーに実際に操作してもらい、反応を観察する
4. 改善前と比較して、迷いが減っているかを確認する

この比較があることで、「本当に改善されたか」が明確になります。

UI改善方法に悩んだら、プロセス全体で考える

私たちは、UXを強みとするITコンサルティング会社です。UIデザインにとどまらず、業務設計やエンジニアリングまでを視野に入れ、業務システムにおける「リサーチ → UI改善 → ユーザビリティテスト」までを一貫してご支援しています。

業務アプリケーションにおける「使いにくさ」は、UI単体の問題に見えて、実際には業務フローやシステム構造に根本原因があるケースが多くあります。
私たちはユーザーの業務実態や利用環境を踏まえ、“本当に使われる”UX／UIの実現をゴールとした支援を行っています。
「現場からUI改善の声があるが、何から着手すべきかわからない」
「ユーザーにとっての“使いやすさ”をどう定義すべきか悩んでいる」
そんな時は、まずは一緒に何ができるかを考えることから始めてみませんか？NCDCではそのようなお悩みを持った企業様への伴走支援も可能です。ご連絡をお待ちしております。