データを操作するアプリケーションのデザイン・開発しやすさと使いやすさを実現する71のポイント
こんにちは、SOMPO Digital LabデザインチームのUIデザイナー・プロダクトデザイナーの金（https://twitter.com/seikei_kin ）です。
管理画面、SaaS、業務システムからto Cアプリにいたるまで、ウェブサイトやアプリケーションの中には、ただ情報を閲覧するだけではなく、数値や情報などのデータを表示したり登録したり操作したりする役割のものがあります、というよりそちらの方がむしろ多いかもしれません。
そのようなアプリケーションをデザインする場合、なんとなく見た目的にはそれっぽくデザインできても、いざ開発しようとするといろいろ考慮が足りなかったり、実際に使うユーザーの観点から振り返ると過不足があったり……、といった経験をしたことがあるデザイナーは少なくないのではないでしょうか。
今回のnoteではそのようなウェブサイトやアプリをデザインする上で、データの構造や特性、あるいは実際のユースケースを鑑みた上で、気を付けるべきポイントや抜け漏れがちな注意点・検討事項などを、データの入力・選択・登録・保存・表示・検索・読み込みなど、機能ごとにまとめる形で整理してみました。ぜひご一読ください。
※見やすい配色や使いやすいボタンサイズやレイアウト、といったスタイリング・グラフィック方面での注意事項は、今回の趣旨から外れるのであまり掲載していません。ご了承ください。
データの入力・選択について
入力文字数に制限はあるか？
お問い合わせ・メモ・備考欄など、文字数を多く入力するテキストフィールドにおいては、システムとの兼ね合いで文字数制限がある場合もあります。確認しておきましょう。
選択肢の順番は使いやすいように考えられているか？
例えば生年月日を選択する場合、選択肢が1920年からスタートするのはあまり現実的ではありません。より多くの人が選びやすいような選択肢をデフォルトとして設定しましょう。
データの構造を配慮した入力形式になっているか？
氏名（姓名）・電話番号・日付・住所など、テキストフィールドの分割の方法や個数はシステムとの整合性はとれているか、確認しておきましょう。
要素を追加できる場合、制限は設けているか？
あるデータに別のデータを紐付けられる場合（商品に対するブランドや人に対する所属部署や建物に対する地域など）、システムとの兼ね合いで追加できる数に制限がある場合もあります。確認しておきましょう。
要素を追加できる場合、削除できるようになっているか？
追加はできるが削除はできない・元に戻せないということがないように、やり直し・削除の導線は用意されているか検討しましょう。
操作しやすい順番になっているか？
例えば自動入力作業と選択作業など、違う操作が交互に続くと操作に疲れます。作業の順番は操作しやすさの観点からも考慮しましょう。
入力した値をクリアできるか？その必要はあるか？
テキストフィールドなどにおいて、入力した値はクリアできるようにしておくとやり直しの際に便利です。
数値や期間の上限・下限を入力する場合、エラーとなる条件は考慮されているか？
値段・日時・サイズなど、数字の上限・下限や時間軸などを入力する場合は、入力値に矛盾が起きないようエラーとなる条件を明らかにしておきましょう。
プルダウンは選択しやすくなっているか？
プルダウンの選択肢の量は使いやすさに影響しています。選択肢の数が少ないのであればラジオボタンにする、逆に多いのであれば検索窓をつける、オートコンプリート処理を導入するなどの処理を考えましょう。
人間がやらなくていい処理をシステムがやるようになっているか？
機械的な紐付け作業・計算式などはユーザーに行わせず自動算出するようにしましょう。
カレンダーUI（デイトピッカー）とプルダウン適切に使い分けされているか？
便利なデイトピッカーではありますが、年を跨ぐ移動にはやや煩わしく不向きという弱点もあります。時と場合によってはプルダウン形式と使い分けましょう。
自由入力と選択両方を可能にしておく必要はあるか？
直接値を入力することもできるし、カレンダー形式やプルダウン形式で値を選択することも可能にするUIです。ユーザー自身が入力方式を選択することができます。
容量・形式は考慮されているか？
画像のアップロードなど、データ容量やファイル形式に制限がある場合もあります。予め確認しておきましょう。
よく使う項目を選択しやすくなっているか？
選択肢の中でもよく使う値は選択しやすい位置に配置しておく（出現するようにしておく）と便利です。
テキストフィールドの横幅は適切か？
ユーザーが操作に戸惑わないよう、フォーム幅は入力するデータを予想しやすい長さ・幅に設定しましょう。
ラジオボタンの初期値は明確になっているか？
単一選択の場合、デフォルトで選択している値を決めておきましょう。
画面上で直接編集できたほうがよいか？
画面として詳細・編集を分けてしまうより、詳細画面を直接操作する形で編集できるUIも最近ではよくあります。ページ遷移する手間を省けて便利ですので、ユースケースに応じて検討してみましょう。
入力必須項目は明確になっているか？もしくはそもそも入力をしなくて済むような配慮はされているか？
原則、入力必須項目はそれがわかるようにバッジなどで明示する必要がありますが、そもそも入力を必ずしなくてはいけない箇所（エラーが発生する度合い）を減らすことで、ユーザーの負荷・ストレスを軽減することができます。
一括処理は必要か？
ステータスの変更など、ユースケースによっては複数のデータに対して同時一括処理できると便利な場合もあります。
自由記述欄に書式設定は必要か？
リッチな機能ですが、テキストフィールドに書式設定が使えると便利です。
データの登録・保存について
登録・保存後はどの画面に遷移するか明示しているか？
データを登録・保存後はどの画面に遷移するか、決めておきましょう。
保存しなかった場合、データはどうなるか考えられているか？
入力後、決定せずに画面遷移した場合、入力内容は自動保持されるか？復元機能を設けるか？ユーザーに選択させるのか？検討しておきましょう。
決定・送信ボタンをデフォルトで非活性にしていないか？
条件を入力して決定・保存・送信するボタンについて、必須項目を入力するまで非活性にしておく処理がありますが、ユーザーからするとそのボタンを押すことができない理由を推察するのが難しい、という理由で不親切な設計ともいえます。導入は慎重に検討しましょう。
参考：サブミット (送信) ボタンをデフォルトで無効化しない _ Accessible & Usable
どの値を決定とするかシステムが迷わないように考慮されているか？
一つの値を設定・選択するための手段が同画面に複数ある場合、どの経路での操作を採用するか、明確にしておきましょう。
登録・保存前にプレビューは必要か？
失敗を防ぐため、登録・保存前に登録後の画面をプレビューできると便利な場合もあります。
データの表示について
項目の優先順位は考えられているか？
視線の流れを考慮し、一覧画面の項目は優先順位・ユーザーニーズに応じて左から並べるようにしましょう。
必要な情報は十分に表示されているか？
例えば名簿一覧において、同姓同名が2人いる場合、名前だけでは両者を判別できませんが、備考欄や誕生日や登録日などの情報があれば判断の材料となります。データを識別するための情報・材料は十分に提示できているか、確認しましょう。
データ項目の区分は適切か？カテゴライズされているか？
詳細画面において、項目数が多い場合は見出しを配置しチャンク化する（カテゴライズする）と見やすくなる場合があります。
文字量は全部表示されるか、省略されるか？省略される場合は全量はどこで確認できるか？
データにどんな文字量が入っていても適切に表示・処理できるようにしましょう。特に一覧画面において、文字がエリア幅（列幅）に対して多くなった場合、改行して全量出すか、画面が長くなりすぎるのであれば三点リーダーで省略するのか、ツールチップで補足するのかといった処理が考えられます。
０or何も入ってないときはどう表示されるか？
何も値が入力されていない場合、その欄はどうなるのかについても予め考えておきましょう。そのまま空欄にするか、空欄にしないのであれば未設定・未入力・入力なしなどの値をいれる、などの処理が考えられます。
表示したい項目を選択できる必要はあるか？
一覧画面において、項目を全て表示するのではなく任意の値を選択して表示できる機能です。データを特定の項目だけで見比べたい時に便利です。
詳細画面において一覧に戻る導線・前後のページに遷移できる導線は確保されているか？
詳細画面に遷移したが一覧画面に戻れず行き止まりになっている場合があります。戻るための導線を確保しておきましょう。また、前後の詳細ページへの遷移の導線も用意しておくと、いちいち一覧画面に戻る必要がなく便利です。
項目の詳細は確認・プレビューできるようになっているか？
一覧画面から詳細画面にページ遷移する前に、内容をプレビューで確認できると無駄な遷移の手間が防げて便利な場合があります。
メタデータの表示は配慮されているか？
メタデータとはデータの中身ではなく、そのデータ周辺の属性（更新者・更新日・履歴など）を指します。情報を表示する際にそういったデータも記載されていた方が都合がいいか、ユースケースを振り返ってみましょう。
一覧のそれぞれの幅はデータの桁数を考慮した幅になっているか？
一覧画面において、それぞれの列はそこに入るデータの桁数や量に応じて適切なサイズに設定しましょう。また、画面幅に応じて可変する列・固定されている列を決めておいてもよいでしょう。
並び替え機能について検討されているか？
一覧画面について、並び替え（ソート）機能は、一覧の列だけなど一部の項目だけ並び替える機能と、データ全体を並び替える機能の2つがあります。両方について検討しておきましょう。
並び替え方は考慮されているか？
一覧画面の各列を並び替える場合、並び替え方のルールを明確にしておきましょう。時間や値段などの数値であれば並び替え方は降順昇順で明確ですが、値の種類によっては並び替え方が曖昧なものもあります。
列の一部を固定表示させる必要はあるか？
一覧画面において、任意の列だけ画面を横にスクロールしないように固定表示しておくと、画面内を有効活用できて便利です。
自動算出できる情報について検討しているか？
生年月日→年齢、入社時期・退社時期→在籍期間など、データから自動算出される情報でユーザーにとって有益なものがあれば掲載を検討しましょう。
一括操作ボタンは選択後活性化する挙動になっているか？
複数のデータを選択後、一括で削除や実行などの操作を行うという場合、対象の値がないのにボタンを操作・実行できてしまわないようにしましょう。
ユーザーの権限によって切り替える必要はあるか？
ユーザーの権限や立場によっては利用できる機能に制限を設ける必要があるかもしれません。権限切り替え機能を設けたり、あるいは権限に応じて入り口を別にするなどの処理を検討しましょう。
一度設定した表示内容の順番や条件はどこまで保持されるか？
特にスマートフォンアプリにおいて、一度並び変えた順番や設定した表示条件はどこまで保持されるのか、ページの遷移や切り替えを行ってもそのままなのか、確認・決定しておきましょう。
データの削除について
削除後の遷移は考えられているか？
データを削除後はどの画面に遷移するか、決めておきましょう。
削除の導線は適切か？
削除したいニーズ・頻度・重要性はサービスによってさまざまです。誤操作とのトレードオフも踏まえて、削除する機能はどこの画面におくのがよいか検討しましょう。
削除してはいけない値に対する考慮はされているか？
削除することで不具合を引き起こす場合があるデータもあります。そういった場合は削除ボタンは非活性にする・予め削除対象から外す・削除できない理由を記載するなどの配慮を行いましょう。
操作しようとしていたデータが削除されてしまった時の処理は考えられているか？
そのデータが操作中に削除されてしまう可能性もあります。その場合はその旨をモーダルウインドウなどのアラートで伝えるのか、どこかにリダイレクトさせるか、処理を決めておく必要があります。
データの検索について
検索対象となる値とその範囲は決まっているか？
フリーワードで検索できる場合、部分一致・前方一致なのか、もしくは検索対象とする項目は何か、決めておきましょう。
検索結果の表示順は決まっているか？
更新日順・価格順・人気順・日付順・新着順など、検索結果の表示順番は明確になっているか、確認しておきましょう。
検索候補はサジェストされるか？あるいは過去の検索履歴は表示されるか？
検索したい用語を記憶する手間・労力を省くため、候補値や過去の履歴は表示・提案できるようにしておきましょう。
検索条件は確認できるようになっているか？
現在どういう条件で検索しているか、画面上からすぐ確認できるようにしましょう。
検索結果として返す値の最大件数は決まっているか？検索結果が多数ある場合は無限スクロール？ページネーション？
検索結果として返す値はページ内に無制限で読み込むのか、それとも一ページあたり数を決めてページネーションで分割表示するのか、事前の想定を決めておきましょう。
検索結果の値の詳細を確認できるか？
サービスの種類によっては検索結果の値の詳細をその場で確認したい場合があります。そのような導線は必要かを検討してみましょう。
検索結果の値をその場で登録・編集する必要はあるか？
サービスの種類によっては検索結果の値の詳細をその場で確認したり、内容を登録・編集したいニーズがある場合があります。そのような導線は必要かも検討してみましょう。
検索対象はページ読み込み時に全量表示させるか？
検索後対象の値は最初から全量表示させるか・検索後表示させるか2通りあります。前者の場合はいちいち検索候補を入力する手間が防げますが、一方で検索候補が多すぎる場合は最初から表示されていても選ぶのに労力がかかります。システムの負荷やユースケースを踏まえて総合的に検討しましょう。
検索条件はクリアできるようになっているか？
やり直しがしやすくなるよう、検索条件クリアボタンを配置しましょう。
基本検索条件・追加検索条件は分けられているか？
検索条件が多い場合は、画面スペースの有効活用のため、よく使用する検索条件とそれ以外の条件を分けて表示するも一つの方法です。
検索ヒット数が大きくなりすぎた場合の処理は考えられているか
検索に引っかかった件数を全部返すようにするとパフォーマンスが低下する場合があります。ヒットさせる検索件数に上限を設定する必要があるか検討してみましょう。
検索ワードを削除できるようになっているか？
検索フィールドに入れたテキストを削除できるようにしておくと、やり直しの際に便利です。
お気に入り機能は不要か？
おなじみのお気に入り機能・保存機能ですが、データそのものだけでなく、検索条件なども対象になります。ユースケースを考慮した上で検討してみましょう。
データの読み込みについて
ローディングの出現場所は考えられているか？
読み込み処理に時間がかかる場合、どのページのどの箇所にローディングを出すかについても、事前に検討しておきましょう。
スケルトンスクリーンの導入は検討したか？
スケルトンスクリーンとは読み込み中にモーションを交えながらグレーの枠・骨組みでコンテンツを擬似的に表現するUIのこと。コンテンツを読み込む様子をビジュアライズできます。
ページャーの件数は変更できなくて良いか？
一度に表示できる件数をカスタマイズできる機能です。ユースケースによってはあると便利です。
読み込み処理は表示されているデータに対して行うのか、もしくはデータ全量に対して行うのか決まっているか？
ソートなどの処理は画面上に見えているデータに対して行うのか、もしくはデータ全量に対して行うのか決まっているかで負荷が変わってきます。フィージビリティ含めエンジニアと協議・相談しておきましょう。
その他
複製機能は不要か？
データを登録する場合、既存のものをコピーする形で作成できると作業が捗る場合もあります。ユースケースを踏まえて検討してみましょう。
差し替えと追加はどちらか？
テンプレート機能など、データを呼び出して再利用できる場合、既存のデータに追加されるのか・上書きされるのかの2パターンあります。どちらにするのか、あるいはどちらか選択できるのか、決めておきましょう。
確認ダイアログは適切に設定されているか？
タスクとして見落としがちですが、データを削除する前などは確認アラートやウインドウを表示するようにしましょう。ただし、いちいちアラートを出すと煩わしい場合もありますので、その辺は使いやすさ・やり直しやすさとの兼ね合いでバランスをとる必要があります。
出力機能は必要か？
PCのアプリケーションの場合、データを印刷して確認する場合もあるかもしれません。検討してみましょう。
通知機能は適切に設定されているか？
プッシュ通知機能はユーザーに気づきを与え行動のきっかけとなる重要な機能です。通知対象・トリガーとなるアクションは網羅されているか検討しておきましょう。
ページを切り替えた時データは保持されるのか？
アプリの場合、ページを切り替えたりウインドウを閉じたりすると設定した条件はリセットされるのか引き継ぐのか、確認しておきましょう。
CSV機能は必要か？
一括してデータをインポート・エクスポートしたい場合、CSV機能があると便利です。ユースケースを振り帰り検討しておきましょう。
エンプティステートは考えられているか？
エンプティステートとは何も入っていない・0の状態のこと。例えば検索結果が0件だった場合はどういう情報を表示するのかなど、事前に検討しておきましょう。
まとめ
以上、データを扱うアプリケーション・ウェブサイトをデザインする上で抜け漏れがちな要件をまとめてみました。
最後に、本記事はチェックリスト形式という体裁ではありますが、いついかなるときもこうすべし、というマニュアルではありません。身も蓋もない言い方ですが、詰まるところ開発しやすく使いやすいデザインを実現するには、まずはユースケースや業務フローやユーザーの行動、あるいは現システムとの整合性などをその都度意識する必要があります。デザインの理想を追いつつ、一方でビジネスニーズ・システムのフィージビリティなどともバランスを取りながら最適解を見つけていく。そういったバランス感覚がプロダクトデザインの現場では求められるでしょう。
またもう一つ別の観点として、全て最初から完璧に物事を見通せるスーパーデザイナーなどまずいません。それを前提において、不完全さを許容し、トライアンドエラーを繰り返し、会話や共創で品質をあげていくような制作・開発体制を構築することも重要でしょう。足りてなければやり直せばいいし、分からなければ聞けばいい、そういった関係の中でデザインは磨かれていきます。
この記事がそういった活動の気づき・きっかけとなれば幸いです！
追記：記事の作成方法
今回の記事の作成方法ですが、すこしユニークな手法をとったので最後に紹介しておきます。こちらの内容は、ただ自分が思い付いたものを挙げたのではなく、チームメンバーみんなでサンプルのデザインを見ながらフィードバックしたものまとめるという形をとりました。
具体的にはまずは自分がFigmaでサンプルとなる画面をデザインします。それをメンバーに共有し、気になるところ・おかしなところ・疑問点などをコメントしてもらった上で、みんなで内容を発表・共有します。
普段はあまり聞くことのないような、自分だったらこうする、ここの挙動がちょっとよくわからない、この辺突っ込まれがちだよね……みたいなそれぞれの考え方・理念なども飛び交い、大変刺激的な試みでした。
そうして集まったフィードバックを集約・整理する形で本記事は作成しました。
サンプルとしてデザインした画面
フィードバックが集まった状態
また、レビューにはデザイナーはもちろんエンジニアにも参加いただいたので、開発者目線やデザイナーに気をつけてほしい観点みたいな要件も盛り込むことができ、その点も大変有意義だったかなと思います。
このようにリアルなデザインがあるとあれこれツッコミ甲斐もあり、議論が充実するなと実感した次第です。みなさんもぜひチーム内でやってみるとよいアウトプットになるのではないでしょうか。