スプリットビューUIの設計：一覧と詳細のつながりを保つ

スプリットビューは、項目の一覧と、選択した1件の詳細を並べて表示するUIです。問い合わせを読む、文書を確認する、レコードを次々に調べるといった作業に向いています。項目を選ぶたびに一覧の状況を把握し直す必要がないためです。選択中の行、詳細の見出し、操作ボタンが、すべて同じ対象を指していることが設計の要になります。

PixsoのUIデザイン機能で、広い画面と狭い画面の両方にこの関係を作っていきます。大切なのは画面を均等に二分することではなく、1件を扱っている間に、何を見える状態にしておくかです。

一覧と詳細を同時に見る意味がある作業を選ぶ

設計例として、サービスデスクのBeaconを考えます。担当者は受信トレイを見て、Mira Chenから届いた領収書の発行に関する問い合わせを開き、内容を読んでから返信します。一覧は、近くにある別の問い合わせ、その件名、対応状況を把握するために役立ちます。詳細ペインは、選んだ問い合わせの内容と、その問い合わせに対する操作を示します。

これは、左右の領域に別々の提案を載せるマーケティング用の分割画面とは異なります。1件のレコード内の関連セクションを切り替えるタブとも違います。Beaconでは、一覧の別の行を選ぶと、詳細ペインが表す対象そのものが変わります。

1件の処理に大きな作業領域が必要で、周囲の一覧がほとんど役立たない場合は、独立したページが適しています。少量の補足情報だけが必要なら、コンパクトな開閉領域で十分なこともあります。一覧と項目の間を繰り返し移動することに意味があり、そのために画面を共有する価値がある場合に、2つのペインが役立ちます。

選択中の対象を見失わせない

Beaconの選択中の行には、Mira Chen、領収書の発行、#1042を表示します。詳細の見出しにも、一覧との対応が分かる識別情報を載せます。同姓同名の顧客がいたり、同じ件名の問い合わせが複数あったりしても、問い合わせ番号があれば区別しやすくなります。すべての情報を一覧に並べる必要はありません。

ポインターを行から外した後も、選択中の表示は残します。選択状態とホバーを同じ見た目にしないことが重要です。また、キーボードのフォーカス枠は、今操作できる行やボタンを示します。その行の問い合わせが、すでに開いているとは限りません。

一括操作がある場合は、その選択も区別します。チェックボックスで複数の問い合わせを一括処理の対象に選び、行を開く操作では1件を詳しく見る、といった関係です。チェックされた行と詳細に表示する対象を同じ状態として扱うと、操作がどの問い合わせに適用されるのか分かりにくくなります。

何も選んでいない最初の詳細ペインにも、意図した状態が必要です。Beaconでは、最新の問い合わせを自動的に開くのではなく、一覧から選ぶように案内できます。担当者が選んでいないものを、選択済みのように見せずに済みます。一方、#1042への直接リンクから来た場合は、アクセスが許可されていれば、その問い合わせを開きます。

内容に合わせてペインの幅を決める

まず、一覧の1行を識別するために必要な情報を決めます。Beaconなら、差出人、件名、短い本文のプレビュー、対応状況が一覧の確認を助けます。本文全体は不要ですが、件名を数文字で切り詰めてしまうと、似た問い合わせを見分けにくくなります。

詳細ペインには、メッセージと返信欄を読みやすく配置できる幅を確保します。機械的に半分ずつにすると、一覧側の余白が多いのに、会話が窮屈になることがあります。同じ長さのダミー文ではなく、実際にありそうな件名と長い本文で比率を比べます。

文字を拡大した場合も試します。短い英単語なら収まる一覧幅でも、翻訳した件名や長い組織名では使いにくくなることがあります。どの内容を折り返すか、補足情報をどこへ移せるか、完全な識別情報をどこで確認できるかを決めます。

幅を調整できることが本当に役立つなら、区切りを操作できると分かる見た目にし、ドラッグ以外の方法も指定します。使えないほど細くならないよう、各ペインの最小幅も決めます。ただし、サイズ調整は必須ではありません。適切な幅の組み合わせと分かりやすい狭幅レイアウトがあれば、多くの人が使わない操作を追加するより簡潔にできます。

一覧が変わっても作業位置を保つ

担当者が#1042を読んでいる間に、新しい問い合わせが届くことがあります。新着を知らせても、詳細ペインを無断で新しい問い合わせへ切り替えないようにします。サービスデスクで起きた変化が、担当者の現在の選択を上書きしてはいけません。

項目を確認して一覧へ戻るときは、適用中のフィルターと、作業を続けやすいスクロール位置を保ちます。対応状況を変えた結果、現在のフィルターに一致しなくなる場合は、その結果を説明します。たとえば「未解決」の受信トレイで#1042を解決済みにした後は、詳細をしばらく表示したまま、現在の一覧から外れたことと、次の問い合わせへ進む方法を示せます。

この動きは、偶然の並び替えに任せず、プロダクトチームで決めます。別の業務では次の項目へ自動的に進む方がよいかもしれませんが、その場合も操作前に結果を予測できる必要があります。「解決済みにする」と「解決済みにして次を開く」は、異なる操作です。

選択中の項目が開けなくなった場合、その見出しの下に別の項目の内容を残してはいけません。開けなくなったことと、適切な戻り先を示します。可能な範囲で一覧の状況は保ちつつ、現在の利用者に閲覧権限がない情報を表示しないようにします。

狭い画面では1ペインにしても、戻る経路を保つ

狭い画面のBeaconでは、最初に受信トレイを表示します。#1042を開くと詳細画面へ進み、「受信トレイに戻る」で作業を続けやすい元の一覧へ戻れます。一覧がリセットされ、毎回先頭へ戻される構成にはしません。

Androidのアダプティブなリスト・詳細レイアウトのガイド（英語）は、十分な幅では関連するペインを並べ、狭いウィンドウではそれぞれを別の移動先として表示する考え方を示しています。WebのUIでも、この関係は参考になります。ただし、ルーティングやブラウザーの履歴は、その実装に合わせて別途決める必要があります。

ウィンドウのサイズ変更で、作業を最初からやり直させないようにします。#1042を読んでいるときに幅が狭くなったら、その詳細を開いたままにします。再び幅が広がったら、同じ選択状態の一覧を横に戻します。画面幅ごとに別々の無関係な画面として扱うと、リスト・詳細レイアウトを使う意味が失われます。

項目を切り替える前に、閲覧と編集中の状態を区別する

読むだけの問い合わせを切り替えるのと、書きかけの返信から移動するのとでは、影響が違います。Beaconでは、別の問い合わせを開く前に、下書きがどの状態にあるか分かる必要があります。

下書きを保存する製品なら、その状態を正しく示し、戻ったときに下書きを使えるようにします。入力内容が現在の編集セッションにしか残らない場合は、失う前に、編集を続けるか破棄するかを選べるようにします。画面に文字が残っているだけで「保存済み」と表示してはいけません。

この判断は、編集中の問い合わせに結び付けます。「変更が失われる可能性があります」という一般的な警告より、「Mira Chenへの未送信の返信を破棄しますか？」の方が状況を理解できます。選択中の行、下書きの宛先、確定する操作を一致させます。#1042への返信が、入力欄と一緒に別の問い合わせへ移ってしまうことは防がなければなりません。

フォーカスとスクロールをそれぞれ設計する

2つのペインを表示するときは、キーボードで一覧から詳細へ、詳細から一覧へどう移動するかを決めます。行を開いた後のフォーカス位置を予測できるようにし、フォーカス表示を見える状態に保ちます。詳細の見出しや操作も見つけやすく配置します。

狭い画面で問い合わせを開くことは、画面の移動に当たります。新しい画面の意味のある位置へフォーカスを移し、戻ったときも、前の行をすべてたどり直さずに作業を再開できる位置へ戻します。その意図をフレームのそばに記録し、実装した操作で確かめます。

ペインが別々にスクロールする場合もあります。各領域の境界を分かるようにし、選択中の問い合わせの操作へ到達できることを確認します。必要性がない限り、スクロールする詳細ペインの中に、さらに小さなスクロール領域を入れないようにします。別々の位置を保てても、どの領域を動かしているのか分からなければ使いやすくなりません。

PixsoでBeaconの閲覧経路を確認する

Pixsoで、#1042を選択した広い画面の受信トレイ、狭い画面の受信トレイ、狭い画面の詳細を作ります。Mira Chenの名前と領収書の発行という件名をそろえ、開く経路と戻る経路をつなぎます。選択状態と一覧での位置をどう保つかも、フレームのそばに置きます。

レビューでは、Miraの依頼を見つけて読み、別の問い合わせを確認してから戻ってもらいます。次に、長い件名や未送信の返信がある場合も試します。デザイナーが説明しなくても、現在の対象と次の操作が分かるかを見ます。

使いやすいスプリットビューは、繰り返し確認する作業を途切れさせません。選択、画面幅の変化、新着、戻る経路を通して、その連続性を保ちます。画面の区切りは、同じ作業を構成する2つの領域の境界にすぎません。

Pixsoで一覧と詳細がつながるUIをデザインする