表組のスクロール｜UIデザインポリシー整理
リーガルテックAI SaaSスタートアップ、MNTSQのプロダクトデザイナーのクボスケです。
私たちは、レバレッジの効くデザインの仕組みづくりを目指しています。この記事は、MNTSQとしてのUIデザインの基準や方針を決めていく「UIデザインポリシー整理」というプロジェクトのなかで行なわれたディスカッションをもとにまとめたものです。
このプロジェクトの主旨や運営については、初回の記事でも述べていますので、ぜひご覧ください。
それでは、今回のトピックは「表組のスクロール」です。
表組のスクロール
大量のデータを扱うシステムでは、表組の形式でデータを管理するUIがよく採用されます。ただし、多機能で汎用的なスプレッドシートの再現をUI上で目指す必要はありません。その場面での最適な体験のために優先順位を明確にしてデザインすることが重要です。
ここで「表組」とは、データベースの用語としての「テーブル」と区別するために使用しています。
表組はPCのように十分な表示領域が確保できる環境に適しています。スマートフォンなどの小さい画面では、列数が多い場合にスムーズな体験が難しくなることがあります。情報要素を減らせるか、表形式がそもそも妥当なのか、リスト形式・カード形式に再編できるかなど、ユースケースと目的に応じてよく検討します。
今回は、スクロールに焦点を当てて整理します。
表組と付随する要素を大きく以下のように分けます。表組本体以外の要素は、必要に応じて設けます。
表組本体
表示のコントロール
データの操作
データ全体を取り扱うアクション・ナビゲーション
データに注目している最中のユーザーの視界はなるべくデータ自体の表示のために広く確保します。そのため、限られた領域をスクロールに追従して占有する要素は最小限にします。ヘッダー行は、データと同時に見えていないとユーザーの認知的な負担が増してしまうため、スクロール時に上辺に吸着するようにフロートします。それ以外の要素は、データと同時に視界に提示されている意義がないためスクロールアウトします。
スクロールの負担がユーザーにとって過大だと感じられる場合は、セル内の改行などでデータ行ごとの高さが大きくなりすぎていないか見直したり、1画面あたりの表示件数を調整します。
以下はやりとりの内容を一部抜粋したものです。
kassy：表組は高さが大きくなるケースもあるため、表組に付随する操作部分のUIが表組と一緒にスクロールアウトしてしまうと、何かしたいときにスクロールして戻る手間がけっこうかかってしまうという話が社内でありました
ナカシマ：これは表組に限らずデータリストの形式でもそうなのですが、スクロール固定の箇所がウィンドウ内にあちこちあると、多重にスクロールが発生してしまうことがあります
クボスケ：横方向のスクロールに対して表組みの列を固定するケースもありますよね
kassy：そもそも、表組の1行の高さがやたらに大きくなってしまっているケースは、セル内のデータをなりゆきで折り返してすべて表示しているなど、適切な省略がされていないからだったり
クボスケ：列についても、その画面での用途において本当に表示が必要なのか、持っているデータの中からユーザーの体験に意味のあるものを選別して、表組全体が無駄に大きなものとならないように、まずきちんと検討するべきですよね
ナカシマ：とくに横方向に大きな表組はスマートフォンのような小さなスクリーンのデバイスでは扱いが難しいですよね。スクロールの有無を明示して横スクロールを許容するほか、データのレイアウトを表組ではなくカード型に組み替えたり
クボスケ：場合によるのでしょうが、そもそもスマートフォンで大量データを一覧性高く表示したい、というユースケースが少ないと思います。もしそうなるようなら、ユーザー体験のところから見直したほうがいいのでは
kassy：モバイルファーストなUIの考え方だと、そもそも表組は使わないですね。PC主体の業務システムにおける大量データの表示を前提に整理しましょう
クボスケ：表組周辺に置かれる要素にもいくつか種類がありそうです
絞り込みや並び順、列の表示／非表示の切り替えなどといった表示のコントロール
データ行の新規追加や、データ行の複数選択と一括操作など、データの操作
データのダウンロードや、ページ表示を切り替えるページネーションなど、データ全体を取り扱うアクションやナビゲーション
スクロールするときに、表組と一緒にスクロールアウトしてしまってかまわないか、データ自体とは独立して固定で常に視界にあったほうがいいかは、要素や操作の性質・目的によるのではないでしょうか
ナカシマ：表示中のページ内に限らない、データ全体でページを跨いだフィルタリングなど、横断的な操作もあるのでは
kassy：データの検索結果一覧を見ながら条件を変えていきたいもの、絞り込みなどは、移動距離が短いと操作性がよいですね。必ずしもスクロールに対して固定しなくても、［上部へ戻る］ボタンを固定配置しておく、といった解決もできるかもしれませんが
ナカシマ：列に昇順／後順ソートのコントロールがあると、ページをまたいだ並び替えについて、ユーザーの混乱があるかもしれません。Excelなどページの概念がないスプレッドシートでは問題ないですが、ページのある表組では注意が必要です
クボスケ：スクロールに対して固定部分を設けるときに、主役である「データ」の表示領域が狭くなってしまわないように気をつけたいですね
ナカシマ：表組のヘッダー行には各列のデータ名があるので、スクロールに対して固定で見えていてほしいです。たとえば「作成日」「最終更新日」のように形式が同じ「日付」だったりするデータは、スクロールで消えてしまうとどちらがどちらか判りにくくなってしまいます
kassy：なるべくたくさんのデータを閲覧できるように、固定する要素はデータと同時に提示されることに意義がある、最小限のものにしましょう
クボスケ：無いとユーザーの認知的な負担が増してしまうもの、という観点では、固定するのは基本的にヘッダー行のみということになりそうですね