ソフトウェアの設計プロセスではプロダクトの欠陥が見つからず、ユーザーが使う段階になって欠陥が明らかになりユーザー体験を損ねてしまうことがあります。
この記事では、そういった事態に陥らないようにチェックしておくべき事項をリストアップしました。ここで挙げるチェックポイントは一般的なものであり多くのプロダクトに適用可能ですが、例外もあることをご理解ください。
インタラクションデザイン
01 - 頻繁に発生する操作が簡単にできるか
チェックをする理由：同じ情報を繰り返し入力することは面倒であり、ユーザーの生産性向上に寄与しません。面倒な操作が多ければ、ユーザーはより生産性の高い競合プロダクトへの乗り換えを検討するでしょう。
チェック方法：プロダクトのフローを分析し、ユーザーの行動を観察しましょう。何度も行う操作が存在する場合、より簡単にする方法を検討します。たとえば、ユーザーが過去に入力した情報を再入力できる機能などです。
02 - エラーから容易に復旧できるか
チェックをする理由：やり直し機能があれば、誤操作や意図した結果とならない場合でもフラストレーションなく作業を再開できます。
チェック方法：まず、ナビゲーションにやり直し機能があるか、あれば実際に動作するかを確認します。続いて、ユーザビリティテストでユーザーが陥りやすい誤操作シナリオを作成し、容易にやり直しができるかを確認します。
03 - ユーザーの知識レベルに合わせた機能が提供されているか
チェックをする理由：初心者ユーザーに対してはスムーズに使い方を学べる機能、使い慣れたユーザーに対してはより操作を簡単にする機能を提供することが必要です。ユーザーのレベルに合わせたサポートを提供することによりユーザビリティが向上し、結果としてユーザーが定着してくれることに繋がります。例として、使い慣れたユーザー向けのショートカットや初心者向けのヒントツールなどが挙げられます。
チェック方法：まず、初心者と使い慣れたユーザー向けのツールがあるか確認します。次に、これらのツールが適切に使用されているかを確認するユーザービリティテストを実施します。
04 – 作業を阻害せず、ヘルプ機能へアクセスできるか
チェックをする理由：ユーザーは作業に行き詰まった場合、ヘルプ機能を参照します。ヘルプ機能はオンラインでもオフラインでも現在のウインドウではなく、新たなウインドウで開くようにし、ユーザーが中断した場所から簡単に再開できるようにする必要があります。
チェック方法：ユーザーがヘルプ機能を使用するテストシナリオを作成し、ヘルプ機能が作業の進行を中断していないかを確認します。
ビジュアルデザイン
05 – 原色の使用は３色以下に抑えられているか
チェックをする理由：場合によっては３色以上の原色を使用してもかまいません。しかし、３つの色を組み合わせることは難しいので、基本的には３色以上の使用は避けるべきでしょう。
チェック方法：設計の際、カラーパレットに原色が３色以下になっていることを確認してください。
06 – 色のみでコンテンツや機能を表現していないか
チェックをする理由：アクセシビリティを考慮した設計は、あれば良いものではなく必須要素です。コンテンツや機能を色のみで表現すると、色覚障がい者はプロダクトを使うことができなってしまいます。これは、潜在的ユーザーを失うことになります。
チェック方法：colorfilter.wickline.orgではカラーフィルター機能があり、色覚障がいの症状別にプロダクトがどのように見えるかを確認することができます。また、プロダクトをスクリーンキャプチャしグレースケールに変換することで、視覚障がい者がプロダクトの色を簡単に識別できるかを確認することもできます。
07 – ビジュアルヒエラルキーはユーザーが使いやすく設計されているか
チェックをする理由：ユーザーはプロダクトを使用する上で、プロダクトのビジュアルヒエラルキーを手掛かりにしているので、ユーザーを適切にガイドできるようにヒエラルキーの設計をする必要があります。
チェック方法：プロダクトがどのように動作するかを把握し、その操作を実行するためにビジュアルヒエラルキーが正しく設計されているかを確認する。
08 - 重要アイテムがビジュアルヒエラルキーにおいて適切に表現されているか
チェックをする理由：ユーザーはビジュアルヒエラルキーを見て、コンテンツの優先順位を判断します。そのため、ビジュアルヒエラルキーの上位アイテムは、ビジネスにおいてもっとも重要であり、ユーザーがもっとも興味を持つ内容にする必要があります。
チェック方法：プロダクトをスクリーンキャプチャし、５ピクセル程度のガウシアンぼかしを適用すると、ビジュアルヒエラルキーのどこが目立つのかが分かります。ビジネスとユーザーにとって重要な項目がハイライトされているかを確認してください。
09 – プライマリーアクションとセカンダリーアクションは視覚的に区別されているか
チェックをする理由：プライマリーアクションとセカンダリーアクションを明確に区別することにより、ユーザーが誤操作をしたりや混乱したりすることを避けることができます。たとえば、「送信」と「キャンセル」は、視覚的に区別する必要があります。
チェック方法：ユーザービリティテストを実施して、ユーザーに起因するエラーではなく動作の区別が不明確であることに起因する共通のエラーを見つけます。 また、デザインを見直す際は、アクションによって色、サイズ、配置などの要素を区別するようにします。
10 - インタラクティブな要素を認識しやすいか
チェックをする理由：新しいプロダクトを使用する場合、ユーザーは過去に使用したほかのプロダクトで得た経験から、「ある機能に関するボタンの形状はこうあるべき」、「こう動作すべき」といった期待感を持っています。あらかじめ、このような期待を踏まえた設計をすることにより、ユーザーに不快感を与えずに済みます。
チェック方法：プロダクトの中で共通のパターンが使用されていない部分を探します。たとえば、一目でリンクとわからないリンクがあれば改善が必要です。
11 - フォーム送信が成功したかをユーザーが確認できる仕組みになっているか
チェックをする理由：アクションが正常に実行されたかどうかをユーザーに伝えることは非常に重要です。たとえば、フォームを送信したあとに確認メッセージを表示することで、ユーザーは次のタスクに進むことができます。
チェック方法：ユーザーが情報を入力するすべての項目を調べます。そして、ユーザーが入力を完了したことをトリガーにして、その操作の完了確認ができるようにしましょう。あわせて、操作結果に関してフィードバックが明確であることも確認してください。
12 - アラートメッセージに一貫性があるか
なにをチェックするか：すべてのアラートメッセージが同じ形式、方法、場所に表示されるように設計されているか。
チェックをする理由：すべてのアラートメッセージが同じように表示されるのであれば、ユーザーはすぐに注意すべき事項を確認できます。アラートに一貫性がなければ、新しいアラートが表示されるたびにユーザーに不要な認知的な負荷を与えることになります。
チェック方法：すべてのアラートメッセージが同じ形式であり、同じ配置になっているかを確認します。
13 - アラートメッセージが視覚的に区別されているか
チェックをする理由：アラートメッセージをほかの要素と区別することにより、ユーザーはアラートを認識し、対応することができます。
チェック方法：アラートメッセージが視覚的に区別されていることを確認したあと、ユーザービリティテストでアラートメッセージに対してユーザがどのように反応するかを確認します。
情報アーキテクチャ
14 - ナビゲーションが一貫しているか
チェックをする理由：適切なナビゲーションによって、プロダクトのどのページからでもユーザーは目的を達成できるようになります。
チェック方法：プロダクトの情報アーキテクチャについて書かれたドキュメントを確認し、すべてのページからナビゲーションにアクセスできるかとリンク切れになっていないかをチェックします。ビジュアルデザインに取り掛かる前に、カードソーティングやテストツリーなどの手法を使って、情報アーキテクチャの経路が直感的に設計されているかを確認してください。
15 – 機能やコンテンツを拡張する余地は十分にあるか
チェックをする理由：新しい機能やコンテンツが登場する度に、プロダクトのナビゲーションと情報システムを再設計することは困難です。ナビゲーションメニューと全体のレイアウトは、多くのカテゴリやトピックを途切れなく行き来できるようにする必要があります。拡張の余地がある設計とは、インタフェースが容易に調整できることを意味します。
チェック方法：すべてのステークホルダーに、今後どのようにプロダクトを拡張していくか確認します。たとえば、静的なコンテンツやビデオコンテンツのサポートの必要性などの意見を聞き、拡張の余地を検討します。
タイポグラフィ
16 – ２種類以上のまったく異なるフォントが使用されていないか
チェックをする理由：２つ以上のフォントを使用することがあってもかまいませんが、一般的に２つ以上のまったく異なるフォントを調和させることは容易ではないと言われています。ユーザビリティとビジュアルの観点から、このルールに従いタイポグラフィをシンプルにし、理解しやすくしましょう。
チェック方法：２つ以上のフォントが混合していないかを確認します。また、選んだフォントがデザインに調和しているかも確認します（詳細はこちらを参照してください）。
17 - テキストのフォントは12ピクセル以上となっているか
チェックをする理由：目的によって小さなフォントサイズを使用することもありますが、一般的には12ピクセル以下のフォントサイズは読みにくいと言われます。
チェック方法：すべてのテキストコンテンツのフォントが12ピクセル以上であることを確認します。
18 – ラベル、ヘッダー以外で大文字を多用していないか（英字のみ）
チェックをする理由：大文字を多用すると、文章が理解しにくいものになってしまいます。大文字を減らすことにより、視覚的に重くなく、ユーザーが理解しやすいものになります。大文字は、特に強調したい場合や頭文字語（編注：各語の頭文字語を組み合わせた言葉。UI、CTAなど。）などルール上必要な場合のみに使用します。
チェック方法：ヘッダー、ラベル、頭文語字のみに大文字が使用されていることを確認します。
19 - コンテンツとインタラクティブな要素を区別しているか
チェックをする理由：コンテンツとインタラクティブな要素には明確な区別が必要です。これは、サイズや色、位置、フォントスタイルなどによって区別することができます。異なるフォントスタイルによって、ユーザーは混乱することなくインタラクティブな要素を見分けることができます。
チェック方法：インタラクティブな要素をコンテンツと区別できるように目立たせます。ユーザービリティテストのなかでユーザーがインタラクティブな要素を使いにくいと感じていないかを確認します。
20 - コンテンツによってフォントサイズや太さを変えているか
チェックをする理由：フォントの違いは文章の読みやすさに大きく影響します。見出しや小見出し、文節に明確な区別をつけることで、文章は格段に読みやすくなり、見た目も良くなります。
チェック方法：コンテンツをレビューする際、見出しや小見出し、文節が異なるフォントサイズと太さで表記されているかを確認してください。
ユーザーインターフェース
21 – 機能や内容が近いものをグループ化しているか
チェックをする理由：ユーザーは、機能や内容が近いものをグループ化したがるものです。ナビゲーションバーが良い例です。このように関連しているアイテムをグループ化することにより、ユーザーはインターフェースを理解しやすくなります。
チェック方法：機能が似ているアイテムを探し、グループ化されているかどうかを確認します。
22 – 複数のステップを含む作業においてプログレスバーが設置されているか
チェックをする理由：複数のステップを含む作業では、ユーザーは終了するまでにどれだけ時間を費やすものか不安に感じたりします。プログレスバーを設置していれば、進捗状況を確認できるだけでなくユーザーが達成感を感じ途中で作業を止めないようにすることができます。
チェック方法：プロダクトに複数のステップを含む作業がある場合、プログレスバーで進捗状況が示されているかを確認します。
23 – コンテンツと背景は容易に区別できるようになっているか
チェックをする理由：コンテンツと背景が容易に区別できれば、ユーザーの理解力が高まります。明確に区別されることによってナビゲーションが使いやすくなり、ユーザーがボタンに注目してくれるようになります。その結果、ユーザビリティが改善されるでしょう。
チェック方法：プロダクトをスクリーンキャプチャし、３～５ピクセル程度のガウスぼかしを適用し、コンテンツと背景の表示を認識できるかを確認します。
・・・
すべてのチェック項目を達成しましたか？ しかし、これで終わりではありません。常にテストを続けユーザーからのフィードバックを収集し、改善を継続することが大事です。
