Entries

スマホのUI考2 〜 フィードバックについて

UIについて徒然と考える自分用メモ、2回目はフィードバック。ユーザーに「何かがおきたよ!」と如何に明解に知らせるか?1回目はこちら
随時増えたり減ったりするよ。自分の主観だから間違ってることもチラホラあるかもよ。


振り返ってみてTiltShiftGenでは、遷移系のフィードバックは少なめにして、情報系のフィードバックを多めに調整してたんだなぁとシミジミ。多分、ブラーの処理が重かったからだと思う。隙をみてバージョンアップしたい。

一般論
・フィードバックとは? ユーザーの操作に対して、結果を返すこと。操作の実感。
・フィードバックのないアプリは痛覚の無い人間。
・物理的なフィードバックもソフトウェア的フィードバックもなければ、ユーザーは何がおきているか知覚できない。
・何かが起きたら必ずユーザーに通知する。
・適切なフィードバックが行われるとユーザーは快感を感じる。
・新雪に足跡をつけたり、プチプチを潰したり、水たまりをバシャバシャした記憶を思い出しながらやる。
・最小の責務は「ボタンを押す」「ボタンを離す」の通知。
・ボタンはTouchDownしたら凹むべき
・ボタンはTouchUpしたら戻りつつ、光ったりするべき。
・押した時に音を出すのもアリ。
・トグル系のボタンは、自分の現在の状態を明示的に表現する。
・スクロールできる場所も、本来ならば押した瞬間になにかリアクションがあるべき(凹んだりして、スクロールモードに移行する等)。
・全体的に物理メタファー、現実社会メタファーを用いるとユーザーが直感的に理解できやすい。

アニメーション
・アニメーションは飾りや演出ではない。
・アニメは「状態Aから状態Bに変化した」ということをユーザに明示的に宣言する為のもの。
・アニメは「特定の処理を実行中」ということをユーザに明示的に宣言する為のもの。
・プログラマさんは、「必要なアニメを省略するのは、公開するライブラリで型宣言省略して変数や関数をバリバリ書くようなレベル」と意識するといいかも。
・パッと一瞬で画面を切り替えると、ユーザーは迷子になる。
・遷移したことがしっかり伝えられれば、それ以上は過剰。基本的には最小限に停める。
・理想は0.1秒以下、最悪でも0.3秒ほどまでに停める。
・例外的には「時間のかかるバックグラウンド処理」が終わるまでの時間稼ぎをする為に、派手なアニメーションを入れる場合がある。
・遷移入りのアニメーションの体感待ち時間は、フィードバックなしの待ちに比べて激減。心理レベルでの高速化。

画面遷移のフィードバック
・上下左右への全画面並行移動のスライドアニメは、基本的にページ構造を深く/浅く移動したことの明示的な宣言。
・ズームイン、ズームアウトも同様。データを深く潜ることの明示的な宣言。
・画面が裏に反転するアニメ、ページがチラっと半分めくれて裏が見えるアニメは、データの持つプロパティや属性などを違う切り口にから見せていることを暗示。
・画面が裏に反転するアニメは、モードの切り替え等を示唆する場合もある。(iBookのライブラリ→ストアの遷移)。
・画面全体のフェードアウトやモザイク、ディゾルブは、データAからデータBにノンリニアに移動した場合を暗示(テレポート的な移動)。
・基本的には、遷移が深い方向に潜ったか、浅い方向に浮かんだかが明示するのが最重要。
・連続するアクションでは「現在位置を示す」というのも重要なフィードバック。NavigationBarの中央と左ボタンはその為のもの。

データの編集のフィードバック
・画面内のデータがアップデートされた場合、どの場所がアップデートされたかを明示的に宣言する。
・定番としては編集箇所が点滅したり色が変わる。ユーザーの操作と関係なく更新された場合は、変更箇所をユーザーが画面に触るまで明示的に示し続ける。
・ユーザーの明示的なアクションで領域が編集された場合、色が変わったあとに通常色までフェードで戻す等も可。
・ボタンやテーブルセルが画面にダイナミックに追加される場合、出現アニメーションをいれることで、「その位置に何かが追加された」ということが明示的に表現できる。
・気持ちいいアニメー、キャッチーなアニメーはその先の高等スキルなので、アニメーション得意な人と相談しながらやる。

バックグラウンドプロセスのフィードバック
・「何か作業が行われていますよ」を明示的に宣言。
・別名ActivityIndicator。グルグル回るリング。プログレスバー。
・ロード中、通信中などを明示的に表現する為に使われる。
・スピナーがあることで、ユーザーはバックグラウンドで処理が行われていることを知覚できる。
・逆をいえば知覚する必要のない裏処理では、スピナーは必要ない。
・スピナーを使う場所は主に以下の4カ所。
・1:画面上ステータスバーにて、ネットとの通信を明示化する為に使う。
・2:画面中央にて、保存やアップロードなどの画面のロックされる重要な通信処理を明示化する為に使う。
・3:画面がロックされない画像のロード等にて、画像の上に配置して使う。
・4:画面がロックされないボタンの実行等にて、ボタンをスピナーに差し替えてボタンのみをロックする為に使う。
・スピナーはプログレス(ロードの進行状況等)までは表現することができない。
・待ち時間が非常に長い場合には、スピナーよりプログレスバーを使う方がよい。
・他の表現としては4コマアニメループや、明滅などが使われる。
・画面がロックされる場合は派手に真ん中を占有する、画面がロックされない場合は地味にやる。
・バックグランド処理の終了を「ユーザーに通知しなければならない」場合は派手に通知する。そうでなければ地味に消す。

エラーのフィードバック
・ユーザーの間違った処理を指摘。
・このフィードバックが不適切だと、ユーザーはとても不快になる。
・ダメなフィードバックは以下のようなモノ。
・1:全ての項目を入力して更新ボタンを押してからエラーを出す。エラーは項目入力時に随時フィードバックする。
・2:複数の選択肢がある時、選択可能な組み合わせでありながら実際に選択するとエラーを出す。あらかじめ選択できないようにする。
・3:直さなければいけないことはわかるが、何を直せばいいのかわからない。
・4:「全角/半角で入力してください、ハイフンを入れて/外してください。」入力のバラツキはシステムで吸収すべき。
・5:エラー前の入力等が全部消える。消す必要性がない。
・6:「エラーコード550」等。ユーザーは理解できない。エラーコードを出すならFAQかカスタマーヘルプに誘導する。
・ちょっと文言直すだけでとっても親切に。
・1:「ネットワーク接続ができません」 → 「ネットワーク圏外の可能性があります。電波を確認してもう一度お試しください」 
・2:「WIFI通信ができません」 → 「この機能にはWIFI環境が必要です。WIFIネットワークをご確認うえもう一度お試し下さい」この語WIFIの説明にも誘導できれば理想。
・「ユーザーがどうすれば問題を解決できるか?」を明示的にする。


・長い作業は終了通知を、音やバイブでお知らせするのもアリ。
・そうすると画面を見続けたり、なんども確認しなくて済む。
・視覚的なフィードバックよりも音はよりプッシュ
・全体的に「ピ」とか「ポン」とかアタック音(立ち上がり)が短い音がよい。「ォォォオン」とか立ち上がりの遅い音は、フィードバックと認識されない。
・音は画面を見ていなくても、携帯からある程度離れていても通知できる。
・スマホの持ち主以外にも伝わるため、よりソーシャルでもある。
・アップロードやセーブ等「待ち時間のある重要な操作」には音を入れるようにしたほうがいいかも。
・高音系はすぎると神経に触る。低温系はすぎると埋もれる。
・フィードバックが音だけだと、電車など屋外では埋もれる。
・職場や病院など音をオフにしたい場所も多い。

振動
・最も強いフィードバック。
・長い処理でユーザーがアプリを閉じたり、注意が他に以降した場合に、強制的に引き戻せる。
・多用しない(ボタン程度に使うとウザイ)。

応用
・たとえば「データ保存」や「通信」が一瞬でできる場合、ユーザーは本当に保存できたか知覚できない。
・この場合、わざと嘘の待ち時間を0.3秒ほどの与えて「保存中」を表示するのも有効。
・速すぎる処理は、結果が視覚的にダイナミックでない限り、ユーザーは知覚できない。
・結果をダイナミックにするか、過程をダイナミックにする。


参考図書
ごちゃ混ぜになってるけど、たぶんこの辺が色々な考えのソース。あとAppleのHuman Interface Guideline。

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

理解の秘密―マジカル・インストラクション (BOOKS IN・FORM Special)

クロフォードのインタラクティブデザイン論

発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法

考えなしの行動?

ヤコブ・ニールセンのAlertbox -そのデザイン、間違ってます- (RD Books)