【読書ログ】やたらとユーザーをダイアログ（対話）に引き込まない方がいい【About Face】
はじめに
「About Face -インタラクションデザインの本質-」という本を読んでいます。
特にモバイルアプリに携わるものとして、UIデザインに関してはAppleのHIG以外では、トレンドに左右されない貴重なレファレンスとして機能しそうな印象で、とても良いです。
たくさんの観点が含まれる「About Face」ですが、特に気になったものがあったのでまとめます。
エッジケースどうする問題
アプリを実際にリリースして運営していると、さまざまなお問い合わせが発生します。その中には「エッジケース」「レアケース」と言われるような滅多に起こらない事象も含まれています。
エッジケースは、必ずしもバグではありません。通常利用の中で稀に発生するものも中にはあります。そういう場合に、そのレアな想定をどこまでUIに反映するかは結構悩みどころだったりします。なんといっても、99%以上のユーザーには起こっていないケースなのですから。
フロー状態
製品を使うユーザーの生産性・効率性・魅力を高めることが私たちの目的であるなら、ユーザーが正しい精神状態を保てるようにしなくてはならない…ユーザーの集中力を維持するにはどうしたら良いかを考える。-[About Face]
ゲームなら、体験に没頭できるのが基本的には良いはずです。アプリならば道具として、コスト効率よく達成したいことが達成できればそのプロダクトは使われ続けるだろうと思います。
したがって、ユーザーのフローを妨げないことはUIUXデザインにおいて重要な観点と言えます。作業が中断したり、やりたい操作に制限がかかると、なんか使いずらいなという印象を与えてしまうことは、想像に難くないでしょう。
ユーザーのフローを妨げない
要するに、エッジケースではあるものの、想定できるのであればUIUXの観点から対応はしておきたい。しかし同時に、そのエッジケースに引っ張られる形でその他大勢のユーザーのフローを妨げないようにしたいわけです。
原則: 確率の高いものに合わせてデザインせよ、ただし可能性に備えよ
バスに轢かれる可能性もあるが、今朝はなんとか無事に職場に辿り着けるだろう。殺人バスを恐れて家に閉じ篭もることはない。… 「起こるかもしれない」ことがあるからといって、UIで「ほぼ確実に起こること」への対処方法が影響を受けないようにしなければならない。-[About Face]
- 起こる可能性が低いものについて、その他大勢が影響を受けるべきではない
- ただし、想定できている悪影響をほっておけということでもない
- 悪い影響（フローの阻害）を軽減した上で、可能性に備えられれば○
では、どうすればフローの阻害を防止できるでしょうか。
原則: どんなに格好よくても、インターフェースは少ない方が良い
世の中のほとんどのことは、少ないよりは多い方がいい。しかし、インタラクションデザインの世界では、その逆である… 画面がウィジェットの寄せ集めになってしまったり、めったに使われないコントロールが産卵したりすることなく、製品のパワーを調整し、コントロールしなければならない。-[About Face]
当然ですが、ごちゃごちゃと詰め込まれたUIでは集中できません。フローを意識するのであればインターフェースはクリーンでシンプルが好まれるはずです。
例えばGoogle検索のトップ画面は、ミニマルなデザインの象徴でしょう。
ただし、シンプルさを追求することで行き過ぎてしまう可能性もあります。ユーザーのメンタルモデルを正しく理解し、バランスを調整する必要はあります。
シンプルすぎて認知しにくいケースでもなお、Less is More
About Face では「初期のiPod」がシンプルすぎて認識が難しい例として挙げられていました。自分も世代? であり、確かに初見であのインターフェース（クリックホイール）の操作方法には戸惑った実体験があります。
しかし、簡単に覚えられるシンプルなものであれば「少ないほどよい」原則からは外れない、とのことです。あえて分かりづらいUIにする必要は当然ありませんが、「わかりやすさ / シンプルさ」のトレードオフであれば、シンプルさを取る勇気をもつことも大事かもしれません。（そして多くの場合その意思決定を行うことは難しい...）
原則: 議論するよりも、ユーザーに指示をさせる
ユーザーから見れば、役割が逆転しているのだ。本来なら何かを求めるのは人間で、要求に答えるのはソフトウェアの方であるべきなのだ。-[About Face]
理想的なUIは、ユーザーと機械の対話（ダイアログ）ではない。基本的にダイアログは「モーダル」なコミュニケーションです。モーダルは「モードが存在する状態」を指し、ユーザが特定のタスクに集中することを強制します。反対の意味を持つ言葉として「モードレス」があります。
その最たる例として、モーダルダイアログが出ることは、ユーザーに読むことを強要することであり、つまりはフローを阻害する可能性がある、ということです。
※ すべての UI をモードレスにすべきだと述べているわけではありません。
※ 全てのモーダルがフローを阻害すると述べているわけではありません。
タスク指向UI vs オブジェクト指向UI
モーダルとモードレスで個人的に思い出すのは、タスク指向UI/オブジェクト指向UIです。
| 設計順序 | 例 | 傾向 | |
|---|---|---|---|
| タスク指向UI | 動詞 → 名詞 | 入金する → 口座Aに | モーダル |
| オブジェクト指向UI | 名詞 → 動詞 | 口座Bに → 入金する | モードレス |
※どちらが優れている、という話ではありません。
タスク指向UIの場合「入金する」ことをUI上で指示してから「どの口座に入金するか」を選ぶことになります。必ずしもそうではないかもしれませんが、口座の選択はモーダルな操作になる可能性が高くなります。
一方でオブジェクト指向UIの場合は、まず「口座を選択」しその口座に対して行えるアクションがUI上に並んでいることが想像できます。（入金する, 送金する ...etc）「入金する」ために口座を選ぶ必要はなく、その後のフローは比較的スムーズになることが予想できます。
原則: 許可ではなく、追認を求めよ
- 許可を求めるモーダルな例:
- ダイアログ『保存します。よろしいですか？』
- モードレスなら:
- トースト『保存しました (取消)』
アプリケーションの性質にもよりますが、基本的には書いたものを保存しないで破棄したいと思うケースは少ないでしょう。毎回ダイアログ（対話）をユーザーに仕掛けるのではなく、追認を求めるモードレスなコミュニケーションの方が、ユーザーのフローを継続する観点からは優れていそうです。
まとめ
- エッジケースへの対応は、その他大勢のフローを妨げないよう工夫したい
- フローの継続のためには、モードレスなコミュニケーションが求められる
- 何でもかんでもダイアログ（対話）で解決しようとしない
Discussion