ウェブアプリケーションの UI を設計、実装するに当たり、常日頃注意している事等をまとめてみました。
ボタンは消さない。非活性化する
操作不可能なボタンを画面から消してしまうのは好ましくないと思ってます。ユーザーは完全に操作を理解してアプリケーションを利用しているとは限りません。たとえ自分のアクションが原因で後続の操作ができなかったとしても、いつもある位置にボタンが無い事をすぐに認識できない場合があります。「あのボタンはどこだっけ？」と画面内を探し回る事になり、余計なストレスを与えてしまいます。
解決策
利用できないボタンは消すのではなく淡色表示や暗転させて利用できない事をアピールします。ツールチップ（吹き出し）等で操作できない理由を明示してあげるとより親切かも知れません。
アクションの送信を認識させる
重たい操作を実行する時等、操作が完了するまで画面に何も変化が発生しないのは好ましくありません。ユーザーは自分がボタンクリックを失敗したのかと思い、何度も同じ操作を繰り返してしまう場合があります。
解決策
ユーザーのアクションを受領した事を、視覚的に表現します。表現方法としては、例えばボタンを非活性化させる、プログレスバーを表示する、ウェイトカーソルに変更する等があります。重たい操作を実行する前に、確認ダイアログボックスを表示するのも有効です。
「戻るボタン」は常に利用可能にする
ウェブブラウズにおいてユーザーがもっとも利用するボタンは「戻るボタン」であると言われています。スマホにおいてもスワイプによってバックする操作はよく利用されるでしょう。「戻るボタン」やスワイプ等、一般的な「戻る」のアクションでいつでも前の画面に戻れる事は、ユーザーを安心させます。
解決策
非 SPA アプリケーションにおいては、POST メソッドが実行された直後の画面は一旦リダイレクトを行う事で「戻るボタン」は有効に作用します。大抵はフレームワークのサポートがあるので昨今ではあまり考えなくても良いかも知れません。SPA では実装が難しい局面もありますが、各画面において戻るボタンが意図に反するような動作になっていないか、注意しましょう。
戻った時はスクロール位置を元に戻す
従来的ウェブサイトにおいては、「戻るボタン」を押してひとつ前の画面に戻った時はスクロール位置も保たれているのが基本です。SPA においては実装が難しい事もあり、戻った時にスクロール位置がリセットされてしまうアプリケーションが少なくありません。一覧画面から進む、戻るを繰り返してブラウズするケースはよくあります。このような時にスクロール位置がリセットされてしまうとストレスが溜まります。
解決策
これは実際難しい場合も多いと思います。特に最下部までスクロールさせた時に追加のコンテンツを読み込むようなページでは、状況によっては実装が難しいと思います。別タブを開く等の対応は暫定的な解決策としては有効かも知れません。なお、ページトップに戻った方が良い場合もあるので使い分けが必要です。
エラーメッセージは簡潔に2つの文で書く
エラーメッセージで重要な事は「何が失敗したのか」「どうすれば良いのか」の2つを伝える事です。特に「どうすれば良いのか」が重要です。また「何が失敗したのか」もユーザー目線で伝えるようにしましょう。
解決策
例示した方が分かりやすいと思います。
| 悪い例 | 悪い理由 | 良い例 |
|---|---|---|
| 制約違反が発生しました | 開発者の言葉で説明している。どうすれば良いか書いていない | 商品名が重複しているので商品を追加できませんでした。別の商品名を利用して下さい。 |
| エラーです。管理者に連絡して下さい | このエラーによって何ができなかったのかが書いていない | システム障害により商品を追加できませんでした。管理者に連絡して下さい。 |
| バックトレースをそのまま表示 | 言うまでもなく、処理系のエラーをそのまま表示というのは駄目です。バックトレースが欲しいのならログに記録しましょう |
それぞれの情報に URL を持たせる
ある情報を表示している時に、その情報に紐づく URL を用意しましょう。これは JavaScript を利用しないような古典的なサイトではむしろ当たり前でした。高度化した昨今のページにおいては、表示されている情報に URL が紐づいていないケースが昔より増えているような気がします。例えば一覧画面の各項目をクリックした時にポップアップして詳細を表示するようなアプリケーションでは、表示中の詳細情報に紐づく URL が存在しないケースを見かけます。URL が無いとメール等で誰かに情報の所在を通知する時に不便になります。
解決策
各フレームワークのルーティング機能等を利用して、それぞれの情報に対して一意な URL を紐づけるようにすると良いと思います。
スマホに傾向しすぎない
レスポンシブデザインが当たり前の昨今ではスマホやタブレットで出来ない事はやらないというのがひとつの考え方ではありますが、その事が PC ユーザーにストレスを与えていないか考慮してみる必要があります。外出先ではスマホやタブレットで操作しつつ、オフィスでは PC で効率良く作業したいというケースも少なくありません。
解決策
大量の情報を一画面に表示した方が効率が上がる場合は、レスポンシブデザインをあきらめた方が良い場合もあります。
見せながら作る
昨今の高度化した UI はいくら仕様書で説明しても、操作した時の感覚も含めて理解してもらうのは大変難しいです。設計者自身が理解できない場合も多いです。ユーザーに見せながら作る事でこの問題は大きく緩和できます。アジャイル開発の現場においては「何を当たり前の事を」と言われると思いますが、契約上の問題等でウォーターフォール開発の体を外せない開発においても重要です。
解決策
ウォーターフォール開発においては、要件定義フェーズにプロトタイプ開発の期間を設けておきましょう。
UI は視覚言語であるという意識でデザインする
UI とはユーザーのやりたい事をコンピューターに伝えるための言語であると言えます。言語は整然としており、憶えた知識を元に新しい事を表現しようとした時に、意図通りに表現できる事が重要であると思います。これこそが「直感的な操作」であると、個人的には常々思っています。
解決策
同じ機能、似た機能のボタンは、同じような色、形、位置にするべきだと思います。例えばユーザー詳細画面のユーザー削除ボタンが画面右上にあるとしたら、商品詳細画面の商品削除ボタンも画面右上に配置しましょう。
かつてソフトウェアは、マニュアルを熟読し十分理解した上で利用する事が当たり前でした。昨今では覚えながら使ってもらうのが当たり前ですし、利用者の増加に伴い、平均的なリテラシーも下がってきています。熟練者を満足させつつ初心者を迷わせない UI は実際なかなか難しいと思いますが、頑張って取り組んでいきたいですね。