🎨

現場で使えるモードレスUIの具体例と実践テクニック

2024/06/15に公開

はじめに

先日「Modal、Dialog、Drawer の違い」について解説した記事を書きました。

https://zenn.dev/miravy/articles/33b97d94bb7ea7

この記事の中で「モードレス」について軽く触れましたが、
「そもそもモードレスってなに?」
「モードレスな UI ってどんなものがあるの?」
と疑問をもった方が多いかと思います。

本記事ではモードレスにフォーカスを当て詳しく解説します。また、記事の後半では厳選した具体例 5 選を紹介します。
この記事を読み終えれば、現場で使えるためのエッセンスが身についているはずです。

モードレスとは

モードレスは言い換えると「モードがない」「モードを持たない」となります。
ユーザが特定のタスクを強制されることなく、任意の UI オブジェクトを操作できる状態を指します。

モードレスな UI は自由に操作できるため、ユーザビリティを向上させます。
アクセシビリティの観点でも短期記憶に負荷をかけないため、ユーザにとって使いやすい UI と言えます。

そのため一般には、後述する「モーダル」より「モードレス」が推奨されます。

対比される概念:モーダル

モードレスの反対の概念としてモーダルがあります。

モーダルは「モードが存在する状態」を指し、ユーザが特定のタスクに集中することを強制します。
モーダルでは、ユーザは特定のタスクを完了するまで他のタスクを行うことができません。

代表的な例としては「モーダルダイアログ」(画像参照)があります。

Cloaked の例

Cloakedのフォーム入力ダイアログ

この例では、「ユーザはフォームの入力を完了して送信する」か「Cancel ボタンを押してダイアログを閉じる」以外の操作を行うことができません。

UI をモードレスにするには

ところで、モードレスな UI を考えるのはそう簡単ではありません。
特に意識せずにデザインを進めるとモーダルな UI を多用することになるでしょう。

UI をモードレスにするためには、以下のポイントを意識することが重要です。

1. 小さな操作で目的を達成できる

ユーザが簡単な操作でタスクを完了できる場合は、モードレスにすることが望ましいです。

例えば確認ダイアログなど、選択肢が Yes/No の 2 つのみであるケースは、モードレスにすることができるでしょう。
モードレスな確認ダイアログについては、後ほど具体例を示します。

モーダル内の UI が複雑である場合は、タスクやアクションを分解するところから始めましょう。UI が複雑な原因は、複数のタスクやアクションが混在していることが多いです。

タスク指向で UI をデザインするとどうしてもモーダルになりがちです。後述するオブジェクト指向も活用しながらオブジェクトベースでタスクを整理しましょう。

タスクやアクションの分解ができない場合は、情報設計が間違っている可能性もあるので、根本的に見直すことも検討しましょう。

2. 非同期処理の活用

時間のかかる処理はバックグラウンドで実行し、ユーザーの操作を中断させないようにします。

例えば、画像やファイルのアップロードはバックグラウンドで行い、その進捗状況をステータスバーなどで表示します。

また、フォームやメッセージなどの送信リクエストに時間がかかる場合には、楽観的な更新を行い、ユーザが操作を続けられるようにすることも有効です。

非楽観的な更新 楽観的な更新
非楽観的な更新 楽観的な更新

引用

非楽観的な更新では「更新中」というモードに入るのに対し、楽観的な更新ではモードに入らずに続けてメッセージを送信できます。

3. 画面の大きさを最大限に活用する

デスクトップ幅の画面は広いため、モードレスな UI を実現しやすいです。

左右からスライドする Drawer を活用して画面の半分に別のコンテンツを表示したり、チャットボットを画面下部に配置してユーザが他の操作を続けながらチャットできるようにするなど、画面の大きさを最大限に活用することでモードレスな UI を実現できます。

一方で、モバイルは画面が小さいため、デスクトップと同様の機能を提供するためには情報設計を工夫する必要があります。

4. オブジェクト指向 UI を意識する

オブジェクト指向 UI(OOUI)は、オブジェクトを中心に設計する UI パターンです。
「まずオブジェクトを選び、次にそのオブジェクトに対するアクションを選ぶ」という流れで UI を設計します。

オブジェクト指向 UI で最も重要なことは、「名詞 -> 動詞」の順に設計することです。
対比される概念として「タスク志向 UI」がありますが、タスク志向 UI は「動詞 -> 名詞」の順に設計します。

サービス開発の多くは「ユーザの課題」が発端です。
その課題を解決するために多くの人がとる UI 設計の手法は、アプリケーションの中でユーザが行うこと = タスクを想定し、そのタスクに対応した UI をを考えることです。

タスク志向で進めると「動詞 = タスク(動詞形) -> 名詞」の順に設計された UI となり、モーダルな UI になる傾向があります。
そのため、オブジェクト指向 UI を意識することで、モードレスな UI を実現しやすくなります。

詳しい内容については、こちらの「OOUI 本」を読んでみてください。

https://www.sociomedia.co.jp/10046

モードレスではなくモーダルを使うべきケース

一方で、すべての UI をモードレスにすべきだと述べているわけではありません。
最も大切なことは、「モーダルとモードレスを適切に使い分けること」だと考えています。

ここでは、モーダルを使うべきケースをいくつか挙げてみます。

1. 必ずユーザに確認して欲しいコンテンツを表示する

デスクトップの画面ではさまざまな情報が表示されるため、ユーザが重要な情報を見逃す可能性があります。

そのため、ユーザフローの中で必ずユーザに確認して欲しい情報をモーダルで表示します。
例えば、お知らせや広告などが該当します。

ただし、この目的でモーダルを多用すると UX が悪化する可能性があるため、過度な使用は避けるべきです。

2. ユーザに確認を求める

ユーザに確認を求める場合は、モーダル(ダイアログ)を使うことが一般的です。
例えば、モーダル確認ダイアログが該当します。

ここで先ほどの「1. 小さな操作で目的を達成できる」で述べた

例えば確認ダイアログなど、選択肢が Yes/No の 2 つのみであるケースは、モードレスにすることができるでしょう。

と矛盾すると思った方もいると思います。
これについては、「操作の重要度」を考慮する必要があります ↓

  • モーダルにするべきケース
    • ユーザに重要な操作(取り消せない操作など)の確認を求める場合
  • モードレスにするべきケース
    • ユーザにとって重要でない操作(通知の許可など)後から取り消せる操作(ゴミ箱に移動など)

ユーザにとって重要な操作はモーダルに、そうでない操作はモードレスにすることが望ましいでしょう。

3. 必須のステップをユーザに促す

特定のステップを踏まないと先に進めない場合は、モーダルを使うことが適しています。

例えば、新規登録時の利用規約同意や、パスワードの変更時の確認ダイアログが該当します。

このようなケースでは、モーダルを使わないとユーザがステップを見落とす可能性があるため、モーダルを使う必要があります。

4. ユーザをタスクに集中させる

ユーザに特定のタスクに集中してもらいたい場合は、モーダルを使うことが一般的です。

例えば商品の一覧ページにおいて、絞り込みの項目が多い場合はモーダルを採用します。ユーザが「絞り込みのモード」に移行することで、絞り込みに集中でき、自身にとって適切な絞り込みを行うことができます。

また、一連の操作の中で独立した操作を行う場合も、モーダルを使うことでユーザに集中してもらうことができるでしょう。

モードレス UI の具体事例 5 選

最後に、モードレスな UI の具体例を 5 つ紹介します。
これらの事例を参考にしながら、モードレスな UI を実現するためのヒントを探してみてください。

1. メール作成ダイアログ| Gmail

1 つ目はデスクトップ版 Gmail のメール作成ダイアログです。

右下にメール作成ダイアログが表示されていますが、このダイアログはモードレスダイアログです。
ユーザは新規メールの作成中に他のメールを閲覧したり、検索を行ったりすることができます。

もしこのダイアログがモーダルだった場合、ユーザはメールの作成中に他の操作を行うことができなくなります。

Gmailのメール作成ダイアログ

2. トーストメッセージ| Zenn

続いては、今みなさんが見ている Zenn のトーストメッセージです。

トースト(Toast)は、ユーザが何かしらの操作を完了した際に一時的に表示されるメッセージです。
トーストは「ポップオーバー(Popover)」の一種で、ポップオーバー API - MDN Web Docsで言及されています。

ポップオーバーとは

ポップオーバーは、他のコンテンツの上に表示するコンテンツです。
ユーザはポップオーバー内のコンテンツを確認しながら、他のコンテンツを操作することができます。

Zenn の事例では、アカウント設定画面 で操作をすると自動で保存され、「更新しました」のトーストメッセージが表示されます。
このメッセージが表示されている間も他の操作を行うことができるのが、トーストとポップオーバーの特徴です。

Zennのトーストメッセージ

3. BottomSheet | Google Maps

次に、Google Maps の BottomSheet です。

BottomSheet は画面下部からスライドしてくる UI コンポーネントです。
過去に投稿した「これで迷わない!Modal、Dialog、Drawer の違い」では、BottomSheet は Drawer の一種として紹介しました。

ここで紹介するのは、モードレスな BottomSheet です。
Google Maps では、BottomSheet が表示されている間も地図を操作することができます。

ユーザは、アプリのメインコンテンツであるマップに紐づいた詳細な情報を知りたいときに BottomSheet を表示し、他の操作を続けながら情報を確認することができます。

Google MapsのBottomSheet

4. 左右スワイプ| iPhone 通知センター

次に、iPhone の通知センターの左右スワイプです。

これは、UI をモードレスにするにはの「1. 小さな操作で目的を達成できる」で言及した「モードレスな確認ダイアログ」の例です。

通知を削除する際に、モーダル確認ダイアログを表示するのではなく、スライドによって削除させることができます。
このような UI にすることで、ユーザはモードに移行することなく、通知の内容を確認しながら削除の操作を行うことができます。

iPhone 通知センターの左右スワイプ

5. モードレスエディット| Wantedly

最後に、モードレスエディットについて紹介します。

モードレスエディットは、常に編集可能になっており変更内容は自動保存される UI です。
ユーザは編集というモードに移行することなく、常に閲覧・編集を行うことができます。

このモードレスエディットは、OOUI 本でも紹介されており、「名詞 -> 動詞」の順に設計された UI の代表例の 1 つです。

Wantedlyのモードレスエディット

引用

モーダルエディット

モードレスエディットとの違いを理解するために、モーダルエディットの例も挙げておきます。
こちらも Wantedly の例です。

この例では、職歴の編集をモーダルで行う UI になっています。ユーザがモーダル内の編集のみに集中できるようになっています。
このケースではユーザが、職歴に関する詳細な情報を思い出すことに集中できるため、モーダルが適しているといえます。

Wantedlyのモーダルエディット
引用

おわりに

モードレスについて理解が深まったでしょうか?
モードレスはユーザビリティを向上させるために非常に重要な概念です。モーダルとの違いを理解し、適切に使い分けていきましょう。

最後に注意点ですが、モードレスな UI が出来上がると、ユーザだけでなく開発者自身もモードを意識できなくなります。すると、運用の過程で不要なモーダルな UI が生まれることがあります。

モードレスな UI を維持していくためには、常にユーザの視点で UI を簡潔に保つことが重要です。
また、チームメンバーにもモードレス UI の意義を共有し、意識を高めることも必要です。

もしモーダルな UI が増えてきたなと感じたら、またこの記事を読み返してモードレスな UI にするためのヒントを探してみてください。


最後までお読みいただきありがとうございました!
よければぜひ X(Twitter) のフォローをお願いします!

https://x.com/yu_3in

参考

https://zenn.dev/miravy/articles/33b97d94bb7ea7

https://www.sociomedia.co.jp/10046

GitHubで編集を提案

Discussion