はじめに

この記事では、筆者が普段WebアプリケーションのUIを検討している際に、独自に「破壊的な変更が実行されるUI」と呼んでいるUIについて解説します（以下、「破壊的なUI」と呼びます）。破壊的なUIは、利用者へ強い不安やストレスを与える可能性を含んだUIです。ですので、この種のUI検討には、その特徴への十分な理解と事前の対応が必要になってきます。

特に、UIデザイン作成が先行して実施されて、そのUIを元にして実装がされるような直進的なフローが採用されている場面では、UI検討時の考慮不足が発見されないまま実装完了まで進んでしまうことが多々あります。そうなると、発生した不安やストレスがダイレクトに利用者へ負担されてしまうことになるため、UI検討の段階でストレスの発生源を把握しつつ、ストレスなどへの予防策の実施が求められます。

また、次節で解説しますが、破壊的なUIは、画面から完全に取り除くことはできません。そのため、破壊的なUIへの対応は回避よりも予防が重要になり、破壊的なUIは存在しつつも、不安やストレスの発生をなるべく抑制した状態を目指すのが、UI検討のポイントになってきます。

破壊的なUIとは？

筆者が考える「破壊的なUI」とは、実行結果が不可逆であるという性質を持っています。

これはUI自体の見た目や動作が不可逆なのではなく、サーバーやクライアントのメモリに保持されているデータが不可逆な状態であることを指しています。ですので、UIの見かけには特徴が現れません。利用者によりボタンなどが操作された結果、データの更新または削除が実行され、不可逆な形で値が変更されるという状態です。たとえば、テキストの上書き保存や、項目の追加、保存済み項目の削除などがこれにあたります。

項目の追加などは、追加後に削除すれば良いだけなのだから、可逆なのではないかと思われるかもしれません。しかし、実際には削除がなかったことになって元に戻っているのではなく、利用者の記憶にある内容と一致する状態にするために、「追加」のあとに「削除」という操作が手動で行われたに過ぎません。つまり、操作が逆進したのではなく、ひとつ追加されて前進しています。

内容をたまたま元に戻せたのは、利用者が変更前の状態を記憶していたことと、さらに、元に戻すのに必要な機能が備わっていたからです。もし、そのWebアプリケーションが削除機能を備えていなかったとしたら、たとえ利用者が内容を記憶していたとしても、データ的には追加前の状態にすることは実現しません。

このように、破壊的なUIはWebアプリケーションではありふれた挙動ですので、破壊的だからといって「排除しましょう」ということはできず、画面から完全に破壊的なUIを取り除くことはできません。それだけに、いかに上手に共存するかがポイントです。

破壊的なUIの性質は不可逆であると述べました。ですが、読者のみなさんの中には「そうは言うけど、テキストの上書き保存や項目の追加って、そんなにストレス与えるかな？」と違和感がある方もいるかもしれません。その違和感はまさに正解で、破壊的なUIのすべてに注意が必要なわけではありません。破壊的なUIにも程度の強弱がありますので、その特徴をよく知ることで、対応のさじ加減をコントロールできるようになります。

破壊的なUIのなかでも、大きなストレスを利用者へ与えかねないUIは、不可逆である性質に加えて、次のような負の特徴を持っています。

• 対象が集合である
• 操作結果が予測困難
• 注意喚起が不十分
• 誤操作への対策が不十分

今回は、この4つの破壊的なUIの特徴をつかみ、対応のコントロールの足がかりにしましょう。

対象が集合である

機能実行のトリガーが1つのボタンだったとしても、実行対象がつねに1つとは限りません。機能の実行対象の数はさまざまで、少ないものもあれば多いものもあります。そして、さまざまある対象のなかでも、それが集合を意味するものだった場合には注意が必要になってきます。

実行対象の数がどんなものか概要をつかむために、初めに少ないほうを紹介します。もっとも数が少ないものは、ワンペアの機能です。機能実行のトリガーが1つで、対象が1つの状態です。具体的な例を挙げるとすると、通知のON/OFFを切り替えるトグルボタン付きの機能でしょうか。トリガーがトグルボタンで、対象が通知の可否の切り替えのみを対象とした、とてもシンプルな状態です。

このような状態であれば機能把握は難しくありませんし、もし誤操作をしたとしても、元の設定へ状態を進める操作が容易に実施できるため、不安やストレスの発生を低減するための対策は不要と言えます。

次に対象が集合である場合です。機能実行のトリガーが1つで、対象が複数ある状態の機能を指します。具体例としては「グループ削除」や「一括削除」が顕著でしょう。これは、グループや一括という言葉が示す通り、何かしらの複数要素をまとめた集合に対して、一挙に削除を実行しようとするものです。トリガーとなるのは「削除ボタン」1つですが、対象はグループが内包している複数の子要素となります。

言葉はとても便利なもので、複数の要素がまとまった何かを、特定の概念でもって集合として命名することができます。

たとえば、「チーム」や「プロジェクト」、「リポジトリ」なども集合ですね。言葉としては1つのワードとして表現できていますが、実際には、とてつもない量の情報を内包している可能性があります。そして、あなたがもしチームやプロジェクト、リポジトリの情報を、誤操作によってごっそり削除してしまったととしたら……。どうやら、集合を取り扱うUIへは、対応や対策が必要になってくることが、見えてきたのではないでしょうか。

操作結果が予測困難

人間、誰しも未知な事象には不安や恐怖がつきまといます。たとえば、中が見えない状態の箱へ自らの手を差し入れるのは、やはり怖いですし躊躇しますよね。意を決して手を差し入れる決断をするとなれば、それなりの覚悟と心の準備が必要になってきます。それと同様のことがUIにも起こり得ます。何かのボタンがあったとして、それを実行した結果が予測困難だったとしたら、そこにはやはり、それなりの決断と心の準備が必要になってきてしまいます。

そして、不安を抱えたままでの決断は相応のストレスを伴います。決断自体に負荷がかかっていることに利用者は無自覚なことが多いので、このような箇所が増え、ストレスの発生頻度が増えてしまうと、利用者は、知らぬ間に決断疲れを起こしてしまいます。決断疲れは、決断の質を下げてしまいますし、物事を実行する気力を奪いかねません。

たとえば次の図のようなUIは、操作結果が予測困難な状態です。

リストの下部に削除というボタンが設置されています。しかしながら、このUIには次のような問題があります。

• 視覚的に判断できる装飾によって、削除の対象範囲が区別されていない
• 削除ボタンの対象範囲が文字要素として明確に指示されていない

結果として、このボタンを実行すると見た感じ何かしらの削除が実行されるであろうことは読み取れますが、何が削除されるかは明確ではありません。リストのすべてが削除されるかもしれませんし、リストの末端1件だけが削除されるかもしれず、操作結果の予測が困難な状態です。

注意喚起が不十分

不注意や誤操作、理解不足による操作によって大きなストレスを利用者へ与えかねないUIは、UI自身がその可能性を発信していなければなりません。よくある例としては「赤色のボタン」です。赤色で目立たせることで、その他のボタンとの差別化を図っています。また、日本において赤色は「注意」や「危険」の意味合いを十分に含んでいるため、一定の注意喚起の効果を期待できます。そのため、一般的なUIとして頻繁に見かけます。

もし、このような注意喚起が不十分だったらどうでしょう。次の図に注意喚起が不十分な状態を挙げています。特に色が付いていない同じ見かけのボタンが4つ並んでいます。ボタンの意味を理解するには、テキストをじっくり読む必要があります。ご想像の通りで、これをパッと見て注意が必要であることを区別することは難しそうです。

前の例を見ると、注意喚起が不十分な状態には、改善の余地があるということがわかります。

ただし、安易にすべてを赤いボタンにすれば良いというわけではありません。赤色にすることに固執してしまうと、思わぬ落とし穴にはまってしまう場合があります。注意喚起の本質は赤色にすることではありません。重要なのは周囲との差別化で、それによって利用者の理解を助ける部分にあります。

人間は物事に「慣れる」ことのできる生き物です。もし画面に赤いボタンが大量にある状態だったり、注意が必要ではないボタンにまで赤色が採用されていたりすると、赤いボタンであることに慣れてしまい、本当に注意が必要なボタンへの警戒心が弱まってしまいます。そうなると、注意喚起を強めるための対応が逆効果となり、結果的に、注意喚起が不十分といった状態になることがあります。

誤操作への対策が不十分

前でも述べましたが、人間は「慣れる」ことのできる生き物です。慣れてしまえば、それまでの記憶や体験を基にして効率的に判断を進めることができます。慣れは、人間が何かを効率的に実行するためにとても重要な要素で、それはWebアプリケーションの操作においても同様です。

ただ、Webアプリケーションのように、利用者からコンピュータへの意思決定の伝達手段がボタンに集約されるような場合は、慣れがあることによる副作用で誤操作を誘発する場面もあります。

通常、Webアプリケーションでボタンのデザインをする場合は、まず抽象度の高い状態で見かけを作り、その後、実用の段階で「保存」や「削除」のように具体的な意味が付与されますが、このときにボタンの見かけは共通利用をするために維持されることが基本です。これはパッと見たときの見た目がほぼ同じになることを示しています。そうすると、人間の慣れるという現象によって汎用性の高いボタンが同じものに見えてしまい、これが、利用者の誤操作を誘発します。

慣れが誤操作を誘発すると書きましたが、慣れだけが誤操作の原因となるわけではありません。仮にマウスのような微細な位置操作を必要とするデバイスを利用している場合は、純粋に押す箇所を間違ってしまうこともあるでしょう。もしかしたら画面の前を猫が横切り、キーボードやマウスにぶつかってしまい、運悪く操作が実行されてしまう不運もあるかもしれません。

その原因が利用者が意図した操作なのか、そとれも不運によるものなのかは予測できませんが、いずれが原因にしても「誤操作というものは必ず発生する」というスタンスでいることが重要です。必ず発生すると思っていれば、危険度の高い操作への対策実施が自然の流れとなります。

まとめ

今回は、破壊的なUIの性質と特徴を解説しました。不可逆である性質と4つの特徴を解説しましたが、これを意識することで利用者へ大きなストレスを与えかねないUIを見つけやすくなります。

破壊的なUIの発見が可能になったので、次は対応です。次回は、破壊的なUIの回避と負の特徴を打ち消すための対応について解説します。