ドラッグで並べ替えるリストのUI設計：キーボード操作と保存状態

リストの項目を並べ替えるとき、利用者が知りたいのは「どこへ移動するか」と「その順序が保存されたか」です。4番目の作業を2番目に移すなら、指を離す前に挿入位置を示し、移動後は新しい順序を確認できるようにします。ドラッグのアニメーションが滑らかでも、保存結果が分からなければ安心して使えません。ドラッグできない人のための操作も、同じ結果につながる必要があります。

この記事では、運用チームの優先作業リストを一つの例として、移動前から保存失敗まで設計します。実装前にマウス操作、キーボード操作、確認画面を関係者に見せたい場合は、各状態の画面をPixsoのプロトタイプでつなげて検討できます。ここで設計するのは業務アプリの操作です。プロトタイプを作るだけで本番データの順序が保存される、という意味ではありません。

ドラッグハンドルを描く前に、順序の意味を決める

「請求書を確認」「仕入先に連絡」「在庫を照合」「契約を確認」「更新を公開」の5件が並ぶリストを考えます。担当者が4番目の「契約を確認」を2番目へ移すと、結果は「請求書を確認」「契約を確認」「仕入先に連絡」「在庫を照合」「更新を公開」です。まずこの結果を明文化しておくと、デザインと実装が同じ順序を目指せます。

その順序は担当者だけに適用されるのか、チーム全員に共有されるのか、それとも今開いている画面だけの一時的な並べ替えなのか。保存モデルによって表示すべき文言が変わります。項目を動かすたびに自動保存するのか、最後に「順序を保存」を押すのかも決めましょう。画面では移動済みに見えるのに、再読み込みすると元へ戻る状態を説明なしに残してはいけません。

作業名が長い場合も位置が分かるよう、短い優先リストなら番号を添える方法があります。長いバックログでは、番号よりグループ名が重要なこともあります。色の変化だけで移動を伝えず、「『契約を確認』を5件中2番目に移動」のように結果を言葉でも示します。

ドロップする前に挿入位置を見せる

ドラッグ用のハンドルは、どの行を動かすか分かる位置に一貫して置きます。チェックボックス、行メニュー、詳細を開くリンクと押し間違えない余白も必要です。「契約を確認」を持ち上げたら元の位置に目印を残し、「請求書を確認」と「仕入先に連絡」の間に挿入線を出します。「仕入先に連絡」を置き換えるように見せてはいけません。

ほかの行をまたぐときは、予想される順序を連続して示します。大きく跳ねる演出で挿入線がポインターから離れると、狙った場所が分かりにくくなります。スクロールするリストでは移動先を見失わせず、自動スクロールも止めやすい速度にします。スマートフォンでは通常のスクロールとドラッグが競合するため、明確なハンドルや意図的な開始操作が役立ちます。

先頭に固定された項目や、権限のために動かせない項目があるなら、移動可能な範囲を事前に示します。実際には置けない位置に挿入線を出し、指を離した後に初めて拒否する設計は避けます。ただし、サーバー側で最後にしか判定できない条件は、失敗時に理由と回復方法を示す必要があります。

ポインターを使わずに同じ順序へ到達できるようにする

ドラッグを唯一の方法にしないことが重要です。各行の操作メニューに「上へ移動」「下へ移動」を置き、長いリストでは「位置を指定して移動」も検討します。キーボード利用者は行へフォーカスを合わせ、メニューから移動し、操作後は予測しやすい位置へフォーカスを戻せます。先頭や末尾で使えない操作は、一貫した形で無効化または非表示にし、押しても何も起きない状態を作らないようにします。

結果は項目名と位置で伝えます。「『契約を確認』を5件中2番目に移動しました」。まだ保存していないなら、その点も続けて知らせます。DOM上の順序が変わっただけでは、読み上げを利用する人に移動結果が伝わるとは限りません。独自のリスト部品を作る場合は、役割、フォーカス移動、操作方法を定義します。W3Cのリストボックス・パターンは参考になりますが、すべての並べ替えリストにそのまま使える仕様ではありません。実際のキーボードと支援技術で確認してください。

マウスとキーボードで、最終的に保存される順序が違ってはいけません。キーボード操作だけ画面上の見た目を変えたり、見つけにくい別の確定操作を要求したりしないことです。Atlassianのアクセシビリティ指針も、ポインターだけに依存しない設計を考える際の参考になります。

移動結果を確認し、保存失敗から戻れるようにする

移動後は新しい順序を表示し、「契約を確認」またはそのハンドルへフォーカスを保ちます。自動保存なら、通信中と保存完了を分けて示します。サーバーが受け付ける前に「保存済み」と表示してはいけません。手動保存なら、未保存の表示と「順序を保存」操作を、画面を離れる前に気づけるようにします。

誤操作を取り消せることも大切です。「元に戻す」はカードを視覚的に戻すだけでなく、保存される順序も以前の状態へ戻すべきです。共有リストをほかの人が同時に編集した場合は、どちらの順序が現在のものかを説明します。競合が起きたら最新の順序を確認し、意図した移動を適用し直せるようにします。他人の変更を黙って上書きしてはいけません。

保存に失敗したときは、未保存の新しい順序を残して「再試行」「破棄」を出すか、最後に保存された順序へ戻して理由を伝えるか、どちらかの方針を明確にします。消えるだけの通知を出し、画面には未確定の順序を残すのは不親切です。見えている順序とサーバーが受け付けた順序が最終的に一致する設計にします。

アニメーションではなく状態の変化を検証する

5件のリストで4番目を2番目へ移す同じ操作を使い、成功時だけでなく途中と失敗時も確認します。

マウス、タッチ、キーボード、読み上げ、狭い画面で同じ結果を確かめます。操作方法は異なっても、移動先と保存状況を理解できることが条件です。視覚的なフィードバックはAtlassianのデザイン指針も参考になりますが、最終的な仕様は自分たちの製品でのテストに合わせます。

Pixsoで移動と回復の画面を並べて検討する

移動前、挿入位置のプレビュー、移動後・未保存、保存完了、保存失敗を一続きで描きます。キーボード用の操作メニューも、別の題材にせず同じ5件のリストに加えます。各画面で作業名と「4番目から2番目」という条件を揃えると、レビューが内容の違いに引っ張られません。

レビューでは各操作の前に「どの行がどこへ動くか」「保存は終わったか」「失敗したらどうなるか」を予想してもらいます。デザイナーの説明がなければ答えられないなら、画面上の手掛かりを強めましょう。合意した画面は実装時の判断や受け入れ確認にも使えます。

動きよりも、信頼できる結果を設計する

並べ替えで大切なのはアニメーションそのものではなく、以前の順序から意図した順序へ確実に移ることです。ドラッグ以外でも同じ位置へ到達できるようにし、移動前に挿入先を示し、移動後は「見た目が変わった」と「保存された」を区別します。操作がうまくいかなかったときにも使えるリストになります。