Sociomedia
ヒューマンインターフェース ガイドライン

ひとつのボタンでオンとオフを切り替える場合、ラベルが現在の状態を表すのか押した後の状態を表すのかわかりづらいことをフリップフロップ問題という。状態表現とラベルを分離してこの問題を回避する。

システムの都合による入力書式の制約をできるだけ減らす。半角と全角、ひらがなとカタカナ、ハイフンの有無など、入力書式の揺れをシステム側でできるだけ吸収し、内部で自動的に整形／補完する。ユーザーに機械的な厳密さを求めない。

タイピングは負荷が大きく、ユーザーは自分で入力するよりも選択肢から選ぶことを好む。途中まで入力したところで「入力しようとしていたこと」や「価値のある入力値」を選択肢として提示して、ユーザーの行為を効果的に支援する。

縦に長い画面をユーザーにスクロールして見てもらいたい場合、スクリーンの下端にちょうどコンテンツの切れ目があるとスクロールできるように見えない。コンテンツの切れ目の位置を調整するなど、続きがありそうに見せる。

オブジェクトのスタイル変更やツールの選択時に、その結果として得られる状態のプレビューを選択肢として提示する。プロパティを適用する前にその結果を見ることができれば、ユーザーの試行錯誤の効率が高まる。

馬鹿でも間違えない（フールプルーフ）ようにするより、間違ったとしても大丈夫（フェールセーフ）なようにする方が重要。もし全ての操作が取り消し可能であれば、実質的に誤操作は存在しなくなり、全てが目的に繋がる試行錯誤の一環となる。

エラー発生時にはわかりやすいメッセージによってユーザーの理解と行動を手助けする。何が起きたのか的確に知らせ、そこからどうすればよいのかを示す。プログラマー向けのエラー番号は一般ユーザーには役に立たない。過剰な表現は避ける。

滅多にない事を考慮しすぎて通常の利用を面倒にしてはいけない。プログラマーはエッジケースを重視するがデザイナーはメインケースを重視すべき。メインケース用の機能とエッジケース用の機能を並列に扱うと、インターフェースは複雑になり、普通の使い方が阻害されてしまう。

ユーザーがやろうとしたことにいちいち確認をとったり、処理が正常に完了したことを報告したりしない。操作の状況と処理の結果はダイアログではなく画面の変化でモードレスにフィードバックする。不可逆的かつデータ消失の恐れがある場合にのみ実行前の意思確認をする。

デザイン上の要求をすべて満たそうとすると形にならない。デザインには仕様を割り切るためのガッツが必要。ユーザーの誤解やクレームを恐れて網羅性や論理性や厳密さを優先しすぎると、情報やオプションが多くなってむしろ基本的なデザイン趣旨がわかりにくくなる。

情報空間の中でユーザーが迷子にならないように道しるべを与える。今どこにいるのか、どこへ行けるのか、近くに何があるのか、どうすれば戻れるのか、など。一貫したナビゲーションスキーム（誘導体系）を用いてシステムの全体像を把握できるようにする。

いつでもすぐに最初の場所に戻れるよう避難口を用意する。ホーム画面を起点にしたナビゲーションや、特定のモードに入って作業をする場面などにおいて、迷子になったり作業を中断したくなったユーザーが簡単に基本の画面へ戻れるようにしておく。

ユーザーが製品を使い始めて数秒以内に成功体験を得られるようにする。最も基本的な作業画面や対象物リストをできるだけ早い段階で表示し、ユーザーがすぐに作業を開始できるようにする。そして作業が正当に進んでいることを感じさせる。

はじめからユーザーにすべての意思決定を求めず、必要最小限のもの以外は回答を先送りできるようにする。アカウントが無くてもある程度利用できる、属性情報をすべて埋めなくてもレコードを作成できる、など。入力フォームでは必要性が明らかな項目だけを必須にする。

画面の広い範囲を変化させる際には、トランジションのアニメーションをつけて、状態遷移の連続性をユーザーが把握できるようにする。変化前の状態と変化後の状態の中間過程を0.1〜0.5秒程度で段階的に示す。

画面の状態Aから状態Bへの変化にトランジションのアニメーションをつける際は、その逆方向の動きを状態Bから状態Aに戻る変化にもつける。このような展開と方向の対応によりユーザーは情報空間の概念的構造を正しくイメージできる。

ユーザーの操作に対しできるだけ短い時間で反応を返す。システムの反応が瞬時に行われていると感じる限界は0.1秒と言われている。反応が遅れても考えの流れが妨げられない限界は1秒。待つことに集中できる時間は10秒。それ以上時間がかかる処理には進捗率や残り時間の表示が必要。

ユーザーの操作に応じてシステムの状態変化を示す時には、ユーザーが注目している場所の近くでフィードバックする。選択したオブジェクトに対するアクションであればそのオブジェクト自体の変化で。単独のボタンであればそのボタンの近くで示す。

初級者が簡単に使い始められるように最初は高度な機能を隠しておき、それが必要になった時あるいは扱えるようになった時にUIを追加表示することをプログレッシブ・ディスクロージャ（進展的な開示）という。これにより段階的な学習が可能になる。

アイコンには記号的な表現を用いるのが普通だが、特定の文化圏でのみ使われるサインや言語依存の慣用表現などを元にした記号は国際的なサービスの中で使わないように注意する。

言語によって単語の平均文字数は異なる。一般にドイツ語は長いので（平均で英語の1.4倍）レイアウトを簡易的にテストするのに用いるとよい。逆に漢字やハングルはラベルが短くなるのでボタン等が押しにくくならないよう工夫する。

日本では ◯ と ✕ を「良い」と「悪い」の意味で使うが、これらの記号が持つ肯定／否定のニュアンスは文化圏によって異なるので、国際的なインターフェースで用いると意味が伝わらない恐れがある。例えば ✕ はチェックと同じ意味で肯定的なニュアンスで用いられることもある。

UIは直観的であるのが良いと言われるが、多くの人が言う「直観的」は「慣用的」の意味である。ダブルクリックでファイルを開くのもピンチで写真を拡大するのも、初めは教わらなければできない。大事なのは人々がすでに知っているイディオム（操作の慣用表現）にすることと、もし新しい操作方法を提案するならユーザーがそれを自然に学習できやがて慣用的に使えるようなものにすること。

ダイアログにおける肯定／否定ボタンの並び順は、アプリ内の論理よりもユーザーの習慣を優先してプラットフォームごとのルールに従う。明確なルールがない場合は「左が戻るで右が進む」という一般的な感覚に従って右を肯定ボタンにする。