あるデザイナがユーザインターフェースで「モード」を避けるたったひとつの理由

スマートフォンのアプリやウェブアプリ（ウェブ上で使うアプリケーション）の画面を作るときの話です。結果として同じ機能を提供する場合でも、ユーザインターフェースの善し悪しで、ユーザがそのプロダクトから受ける体験の善し悪しが変わります。

そのため、ユーザインターフェースデザインでは、よりわかりやすく使いやすいものを考えるのですが、これがなかなか難しいプロセスであるため、世間には分かり難かったり、使いにくいインターフェースがたくさん存在します。

当社でも、多くのサービスを開発＆運用し、新しいサービスも作っていますので、毎日のようにインターフェースが設計されています。そして、良く考えて作っているつもりでも、意図せずに良くないインターフェースが入ってしまう場合があります。そのため、細かくレビューを行い、注意して取り組むようにしています。

今回その中でも、特に注意が必要なパターンである「モード」と呼ばれるものを取り上げて解説したいと思います。

「モード」について

インターフェースの議論で「モード」というのは、ソフトウェアが状態を持ち、その状態によって、ユーザが可能な行動やソフトウェアとのインタラクションに何らかの制約がかかるような場合を言います。

具体的な例としては、ペイントソフト（ラスタ系）を使っているときの「消しゴムモード」（通常、線を書くのに対して消したい場合に導入されるモード）などが挙げられます。

モードにも時間的な長短や、かかる制約の種類や大小があり、時間や制約の範囲が限定的である場合には、モードとして認識されないものもあります。したがって、ここでの検討は、モードに入ることでそのソフトウェアの動作に大きな変化があり、時間的にも一定の長さを持つものに限ります。

例えば画面サイズなどの制約があり、同じペインの中に複数の役割を持たせたい場合や、複数の画面を跨いで使わないと、ある処理に必要な一連のデータが揃わない場合、一連のデータが揃うまでソフトウェアの状態を固定したい場合、といったように、画面制約の不自由を解消する目的でモードが活用されることが多いです。

しかし、そのような活用方法/メリットがあることを理解していながら、モードをできるだけ避けたほうが良いと考えるデザイナは多く、使わない方が良いとする方もいます。ではモードの何がそんなに厄介なのでしょうか？

「モード」の厄介なところ

モードを利用した時に起こるユーザーインターフェースの不具合で、深刻なのが「モードスリップ」です。これは現在はモードに入っているのだというコンテキストをユーザとソフトウェアの間で正しく共有できていない場合に起こる不具合で、ユーザに戸惑いや混乱をもたらします。

ペイントソフトの例で続けましょう。多くのペイントソフトでは基本的な状態ではペンを操作して、描画領域に線を書くことができるようになっています。そして、描いた線を消すためには「消しゴムツールを選択する」などの操作をして消しゴムモードに入ります。

このような場合に、ユーザが現在のコンテキスト（消しゴムモードであるということ）を完全に把握していると良いですが、そもそも消しゴムモードに入ったことを知らなかったり、途中で忘れたりした場合に「さて、線を書き足すぞ！」と操作すると、書いた線が消えてびっくりします。

ここでさらに悪循環が起こります。モードスリップが発生したということは、ユーザはそのモードを解消したいはずです。しかし、そもそもコンテキストが共有できていないからモードスリップが起こっているので、当然モードを解消することにも苦労し、結果としてUXが大変悪くなるのです。

モードスリップの対策？

そのため多くのソフトでは、このようなモードスリップを回避するための工夫がされています。例えば、消しゴムのモードに入るには、ツールパレットから消しゴムツールを選択します。するとマウスカーソルが消しゴムを模したアイコンに変わります。

マウスカーソルというのはユーザインタフェースにおいてユーザの意図の化身です。そして、まさにこれからカーソルを使って、消す箇所をポインティングしていくわけですから、画面全体におけるサイズは小さくてもユーザがこのカーソルの変化を見落とすことはありません。

さらに「消しゴムを使う」という現実の体験と、インタフェースで行われる操作はアナロジカルに一致しますので、「消しゴムモード」というコンテキストは自然に共有されます。

この例の示すように、モードがうまく働くためには事前に次の2つの要件が大切だと考えられます。

1. モードに入っていることやその影響範囲をインターフェースが表現する
2. モードのコンテキストが正しく共有される

また、これらはモードスリップを起こさないための要件ですので、そもそもモードを導入しなければ考慮しなくて良いものになります。

ここまで、消しゴムモードの例では、マウスカーソルというオブジェクトの存在や、ツールを持ち替えて使うというメタファーがうまく利用できるためこれらの要件が自然に満たされていました。

しかし、ハードウェアやソフトウェアの制約による要件でモードを導入する場合の多くでは、これらの要件をうまく満たせることが少ないです。このことがユーザインターフェースの設計においてモードを忌避する理由です。

アップルのエピソード

最後に、世界のユーザインタフェースデザインを牽引する立場にあるApple社のモードに関するエピソードをご紹介したいと思います。

日本ではスマートフォンの普及率がまだ30%を切っていた2010年ごろの話です。iPhoneでは写真を撮影するとき、側面にあるボリュームボタンをシャッターとして使うことができませんでした。

しかし、写真を撮るときに「画面タップではなく、物理ボタンを使いたい！」と考えるユーザやアプリディベロッパーは多くおり、ボリュームボタンで写真を撮れるようにしたカメラアプリが開発されました。

iPhoneにアプリを配布するにはAppleの審査が必要です。しかし、ボリュームボタンでシャッターを切れるようにしたカメラアプリは審査に合格しませんでした。このことはディベロッパーの間で話題になり「便利なのに！なんで許可しないんだ！Appleは本当にユーザのことを考えているのか？」という批判的な意見も多かったと思います。

Appleがそのアプリを拒否した理由は「ユーザはボリュームボタンは音量を上げ下げするものと考えており、ボリューム操作でシャッターが切れるとユーザが混乱するから」というものだったそうです。

つまり、カメラを使っているときはボタンがシャッターになり、そうでないときはボリュームに戻るというモードをiPhoneに導入することを嫌ったと考えられます。iOSの動作にモードが設定されないように一貫性を持ってコントロールされていて、Appleのこだわりが感じられます。