4 ポイント 投稿者 GN⁺ 2024-01-11 | 1件のコメント | WhatsAppで共有
  • Ben Shneidermanの8つのインターフェースデザイン原則は、ほとんどの対話型システムに適用できる実用的な基準だが、設計領域ごとに検証と調整が必要
  • 一貫した用語と動作、普遍的なユーザビリティ、情報的なフィードバックは、ユーザーが状態変化を予測し理解するための基本条件
  • 作業フローは開始・中間・終了のある単位にまとめ、完了時点では明確な確認を提供することで、ユーザーが次の行動に移りやすくなる
  • エラーは予防が優先であり、発生した場合は具体的な復旧案内と容易な取り消しによってユーザーの不安を減らすべき
  • 制御感と低い記憶負荷を中心に据えることで、モバイル、デスクトップ、Webインターフェースで生産性と習熟感を高められる

原則の性格と適用範囲

  • Ben Shneidermanは膨大なユーザーインターフェース設計の知識をいくつかのGolden Rulesに圧縮し、ほとんどの対話型システムに適用できる指針として整理した
  • これらの原則は経験から生まれ、30年以上にわたって磨かれてきたが、特定の設計領域では別途検証と調整が必要
  • 1985年の初期リストも学生やデザイナーに有用な指針として受け入れられ、Jakob Nielsen、Jeff Johnsonらが変形と拡張を加えた
  • このバージョンはDesigning the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Editionの3.3.4節に掲載された内容

8つのインターフェースデザイン黄金律

  • 一貫性を追求する

    • 似た状況では一貫した行動順序が必要
    • プロンプト、メニュー、ヘルプ画面では同じ用語を使うべき
    • 色、レイアウト、大文字の使い方、フォントも全体として一貫しているべき
    • 削除コマンドの確認や、パスワード入力時に表示しないといった例外は、理解可能で限定的であるべき
  • 普遍的なユーザビリティを追求する

    • 多様なユーザーの要求を認識し、コンテンツ変換を容易にする柔軟な設計が必要
    • 初心者と熟練者の違い、年齢層、障害、国際的な差異、技術の多様性が要求範囲を広げる
    • 初心者向けの説明、熟練者向けのショートカットや高速な進行機能は、インターフェース品質の認識を高める
  • 情報的なフィードバックを提供する

    • あらゆるユーザー行動にはインターフェースのフィードバックが伴うべき
    • 頻繁に発生する些細な行動には簡潔な反応で十分だが、まれで重要な行動にはより実質的な反応が必要
    • 注目対象を視覚的に提示すれば、変更点を明確に示しやすい
  • 完結感を与える対話フローを設計する

    • 作業手順は開始・中間・終了のあるグループとして構成すべき
    • 1つの作業グループが終わったときの情報的フィードバックは、達成感、安心感、次の作業への準備信号を与える
    • 電子商取引サイトでは、商品選択から決済へ進み、明確な確認ページで取引を締めくくる流れがその例
  • エラーを予防する

    • 可能な限り、ユーザーが重大なエラーを起こせないようにインターフェースを設計すべき
    • 不適切なメニュー項目を無効化したり、数値入力欄でアルファベット文字を受け付けない方式が例となる
    • エラーが発生した場合は、シンプルで建設的かつ具体的な復旧指示を提供すべき
    • 郵便番号の1つの誤りのために氏名・住所フォーム全体を再入力させるのではなく、誤った部分だけを修正するよう案内すべき
    • 誤った行動はインターフェースの状態を変えないようにするか、状態を復元する方法を併せて提供すべき
  • 容易な取り消しを許容する

    • 可能な限り行動は取り消せるべき
    • 取り消しは、ユーザーにエラーをキャンセルできるという確信を与えて不安を減らし、見慣れない選択肢も探索できるようにする
    • 取り消しの単位は、単一の行動、データ入力作業、氏名・住所ブロックのような作業グループになりうる
  • ユーザーに制御権を持たせ続ける

    • 熟練ユーザーは、自分がインターフェースを制御しており、インターフェースが自分の行動に反応していると強く感じたがる
    • 予期しない変化、慣れた動作の変更、退屈なデータ入力、必要な情報取得の難しさ、望む結果を作れない状況はユーザーを不快にする
  • 短期記憶の負荷を減らす

    • 人間の短期記憶の情報処理能力には限界があり、経験則では「7±2 chunks」程度を記憶できる
    • ユーザーがある画面の情報を記憶して別の画面で使わなければならないインターフェースは避けるべき
    • 携帯電話は電話番号の再入力を要求すべきではなく、Webサイトの現在位置は継続して表示されるべきであり、長いフォームは1画面に収まるよう圧縮されるべき

設計者が得る実務基準

  • これらの原則は各環境に合わせて解釈・精緻化・拡張されるべき
  • 限界はあるが、モバイル、デスクトップ、Webデザイナーにとって良い出発点になる
  • 単純化されたデータ入力、理解しやすい表示、迅速で情報的なフィードバックは、ユーザーの生産性向上に焦点を当てる
  • 優れたインターフェースは、ユーザーがシステムに対して有能さ・習熟感・制御感を感じられるよう支援すべき

1件のコメント

 
GN⁺ 2024-01-11
Hacker News のコメント
  • UI の「デザイン」に必ずしも含まれないと思われがちだが、パフォーマンスもしばしば見落とされる
    パフォーマンスの悪い UI は、こうしたデザイン規則をすべて破っているようなものだ。私の Sony Android スマート TV は見た目は素晴らしいが、UI が遅すぎて実質的に使えないほどだ
    絶えず変わる不安定な UI も、ほとんどの原則に反している。スマート TV はこの点でも特にひどく、ホーム画面のレイアウトやアプリアイコンの位置が、たいした理由もなく頻繁に変わる
    ついでに、個人的にますます不満が募っているのがラベルのないアイコンだ。ツールチップすらないことも多く、ボタン名を知るためにドキュメントをググらなければならないなら、その UI デザインは悪い

    • Snapchat が大流行して以降、悪い UI は Gen Z 向けの機能なのだと思うようになった
      使いにくいインターフェースに若年層が集まり、その難解さが親世代を排除する内輪向け機能のように働く
    • パフォーマンスはデザインの一部
      優れたデザイナーは、自分の提案する UI がパフォーマンスにどう影響するかを開発者と議論し、エンジニアリングがユーザーの目に触れる技術的判断を下す際にトレードオフを助ける
    • ラベルのないアイコンという点で、私が使った中で最悪のソフトウェアは CATIA V5 だった
      UI に小さなアイコンが何百個もあっただけでなく、ドキュメントでもそのアイコンがそのまま使われていた。マニュアルが「まず [] をクリックし、次に [] を押し、最後に [] に移動して [] を行う」といった具合だった
      V5 のかなり初期のバージョンの話なので昔のことだし、今は改善されていることを願う
    • UI デザイン失敗の最大の原因は、ユーザーと要件から孤立することだ
      それ以外はすべてコーディングに近い
    • Spotify もホーム画面のレイアウトやアプリアイコンの位置を頻繁に変える
      毎朝同じニュースポッドキャストを 2 つ聴いているのだが、アプリのおすすめ項目が毎朝理由もなくシャッフルされる
      さらにいらだつのは、アプリ起動時に昨日のレイアウトを一瞬表示し、読み込みのために 1 秒ほど固まったあと、項目を並べ替えることだ。その瞬間に動いた項目を毎回誤タップしてしまい、ひどくストレスがたまる
  • 数年前に一緒に働いたデザイナーが、一貫性がなぜ重要なのかを見事に説明してくれた
    限られたカラーパレットや、誰も気づかないようなフォント選びの問題ではない。細かなルールを追いかけると、ひどいソフトウェアになる。UI の多様性が減るほど一貫性が高まると勘違いしている人もいる
    核心は、ユーザーがそのソフトウェアの熟達者になれるようにすること
    そのデザイナーは Microsoft Office を例に挙げた。人々は Microsoft Office を「知っている」ことに誇りを持ち、「Office」の慣性を体感しているため、複数のアプリ間を自然に行き来できる。Vim でも同じ感覚がある。何かがどう動作すべきかをただ知っていて、よく作られた新しいプラグインはたいていそのパターンを尊重する
    Office と (Neo)Vim が優れた UI の例というわけではないが、際立って安定している

    • デザイナーではないが、私がいつも強調しているのは、ユーザーがすでに他の場所で身につけた UI 要素や概念を活用して熟練度をブートストラップする力は大きいという点だ
      たとえば 4 つの選択肢を見せるとき、ブランドテーマをまとった [Insert UI Library] の検索可能なチェック項目コンボボックスを使うこともできるし、単にラベル付きの普通のラジオボタンやチェックボックスを表示することもできる。後者のほうがあらゆる面で優れている
      ユーザーは丸と四角を見ただけで 1 つだけ選ぶのか複数選ぶのか分かり、4 つの選択肢をすべて見られ、モバイルキーボードが「検索」のためにせり上がって小さな画面をさらに覆う問題もなく、アクセシビリティも常に 100% に近い
      しかしこの選択肢は「自分たちのデザインシステムとかわいく馴染む」という項目で不合格になるので、デザイナーはたいてい前者を選び、さらに悪いことにその方式を標準化して、通常のウィジェットの使用を「バグ」にしてしまう
      結局、あまりにも多くの「UX デザイナー」が美学とブランディングを崇拝し、他のすべてを犠牲にしている。UI ウィジェットはブランドや創造性を示す場所ではない。すべての文字をロゴの形に強制する独自フォントを作ってはいけないのと同じだ。顧客はブランドよりも、自分の作業を終えられるかどうかを重視する
    • Microsoft が、もっともそれらしい選択肢だけを見せて「助けよう」とする適応型リボンを導入したとき、多くの人が怒った理由の 1 つかもしれない
      必要な機能を見つける能力を大きく損なった
    • ユーザーがソフトウェアの熟達者になれるようにする、という表現は本当に素晴らしい
      自分を技術に詳しいと思っていない人が Excel でものすごく素早く操作するのを見るのは、いつも特別なものがある
      Microsoft の UI デザイン規則はかなり見事だ。長年の一貫性のおかげで、人々は 1〜2 年ごとにアップグレードしてもソフトウェアを使い続けられる。Microsoft のファンだから言っているわけではない
      アップグレードの要点は、UX を改善する漸進的な変化だ。ただし Win 95 が「どこでも右クリックすればプロパティや、より深い設定/詳細情報」という概念を導入したとき、なぜデザインチームが拒否しなかったのかは理解できない。右クリックできるかどうかをユーザーに示さない、見えない機能だったからだ。Win 95 を最初に数回使う間、誰も右クリックを理解していなかったように思う
    • プログラミング言語のデザイナーなので、こうした問題を毎日考えている
      熟練度が関係していることには同意するが、一貫性がなぜ熟練度につながるのかについては、もう少しつながりの説明が必要に見える
      一貫性とは、ユーザーがシステムについてすでに知っていることを、システムの別の部分へ複利のように拡張することだ。システムに一貫性があれば、X と Y を学ぶために費やした努力によって Z と W も分かるようになる。同じように動作するはずだからだ。一貫性のないシステムでは、既存の学習投資から得られる価値はずっと小さくなる
    • 一貫性の重要性には同意するが、「Office と (Neo)Vim は優れた UI ではないが、際立って安定している」という言い方には同意しない
      Office は少なくとも長期的には安定していない。悪名高いリボンは、安定していて効率的だった Word UI からの悲しい逸脱であり、Windows プラットフォーム全体における Microsoft の理解しがたい後退が問題をさらに大きくした。たとえばアプリケーションからメニューバーをなくしたこと。いったいなぜそんなことをしたのか分からない
  • もう一つ加えてほしい「ルール」は、概念モデルをユーザーに見せること。
    製品の概念モデルを理解していないと、アイコンにどれだけ適切なラベルが付いていても常に混乱する。たとえば「New Configuration」というコマンドがある製品を想像すると、そもそも「Configuration」が何なのかが曖昧だ。別のオブジェクトを定義できるようにするテンプレートなのか? 複数のオプションのまとまりを素早く切り替える方法なのか? フォルダのようなコンテナなのか?
    UIは、ユーザーがインターフェースを探索するだけで概念モデルを推測できるように設計されるべきだ。これは必ずしも簡単ではない。

    • 良いインターフェースの目的は、実装の詳細を隠しながらユーザーを目標へ導くことだ。
  • 「たとえばユーザーが間違った郵便番号を入力したとき、名前・住所フォーム全体を再入力させるのではなく、間違った部分だけを直せるよう案内すべきだ」という部分が最大の不満点で、いまだによく見かける。
    複数ページにわたるフォームでも、前後に移動するときにこの原則が守られるべきだ。
    「誤った操作はインターフェースの状態を変えるべきではなく、変わってしまったなら元の状態に戻す方法を案内すべきだ」も重要だ。
    携帯電話や腕時計のような小さな画面では、スペースを節約しようとするデザイナーがますますアイコンに依存している。しかし多くのアイコンは見慣れないか解釈しにくく、場合によっては押してみないと分からない。そうしたアイコンには、間違えたときに元の状態へ戻る方法が必ず必要だ。

    • その通り。「Corvallis」と入力したら「Oregonですか、Montanaですか?」と尋ねて、「97330」と入力したなら残りはそのままスキップすればいい。
    • 本当にイライラする。
      メールアドレスとパスワードでログインしようとするときにすでに問題ではあるが、「パスワードをお忘れですか」を押したなら、さっき入力したそのメールアドレスをもう一度入力させるフォームに飛ばさないでほしい。
  • 「適切でないメニュー項目はグレーアウトせよ」という話には条件がある。
    グレーアウトされている理由が明確でないなら、そうすべきではない。コマンドは有効にしておき、クリックしたときに現在使えないなら、なぜ使えないのかをエラーメッセージで説明すべきだ。なぜコマンドが無効になっているのかをユーザーに突き止めさせるのはストレスになる。
    例外は、ユーザーが最後まで進んで多くの時間を無駄にした後でようやく使えないと告げられる可能性が高い場合だ。
    関連してさらに読む記事: https://medium.com/@vedranio/james-bond-and-the-design-of-di...

    • メニュー項目をグレーアウトしつつ、クリックしたら同じように説明メッセージを表示するのではだめだろうか?
      それなら両方の利点を取る方法に見える。
    • それでも、ユーザーがクリックする前にその操作が無効であることを示す一貫した視覚的手がかりは必要だ。
    • 例外が一つある: 有料のプレミアム機能
      あるToDoアプリがこうしている。プレミアムのコマンドが無料のコマンドと視覚的に区別されていないため、つい頻繁にクリックしてしまい、そのたびに全体の流れを中断する加入促進ダイアログが出る。
      私の基準では深刻なUIの誤りだ。
    • ボタンはグレーアウトしつつ、マウスオーバーするとクリックできない理由を教えてくれるツールチップを付けるのはどうだろう。
    • 同意しない。現在の文脈で不可能な操作を無効化するのは役に立つ。ただし、なぜそうなのかを説明しなければならない。
      理由を示さず特定の操作だけを無効化するUIにはいつも腹が立つ。
  • Nielsenのユーザビリティ10ヒューリスティックスは、良い北極星の役割を果たす。

    1. システム状態の可視性
    2. システムと現実世界の一致
    3. ユーザーの制御と自由
    4. 一貫性と標準
    5. エラーの予防
    6. 記憶より認識
    7. 使用の柔軟性と効率性
    8. 美的でミニマルなデザイン
    9. エラーの認識、診断、回復
    10. ヘルプとドキュメント
      https://www.nngroup.com/articles/ten-usability-heuristics/
    • このNielsen-Normanのページと元ページの違いははっきりしている。
      NNのページのほうが情報をはるかに吸収しやすく、より簡潔で、ページレイアウトもはるかに良い。
      どちらの記事にも耳を傾けるべき情報と方向性が含まれているが、元ページがNNページの捨てた昔ながらの同一フォントサイズと段落の慣習を採用している点は皮肉だ。
      Hacker Newsもこうした情報の一部に従っていないのがもどかしい。既存の投稿を編集するとき、「update」ボタンを押した後のフィードバックが十分に明確ではない。おそらく画面を再描画しているのだと思う。
  • まさに選ぼうとしていた位置に別のものを割り込ませて、誤タップさせるUIはやめるべきだ。
    前述のルールのいくつかに違反しているのかもしれないし、緩和できる問題なのかもしれないが、個人的には本当に気が狂いそうになる要素で、特に重大なミスだと思う。

    • Jiraでストーリーの担当者を変えようとすると出てくるUnassigned/Automatic選択が特に思い浮かぶ。
  • 抜けている重要なルールが一つある。かつてはあまりに当然に思えたことだが、静的な情報と操作要素を区別しなければならない。
    また、適用できない操作要素を隠すのではなくグレーアウトすべきだ。そうすれば、ユーザーはその機能が存在すること、どこにあるのか、使うにはどんな条件を満たす必要があるのかを学べる。
    関連して、ユーザーがたまたまカーソルを乗せたときだけ何かが現れるような、かくれんぼUIに絶対に依存してはいけない。こちらは仕事を終わらせたいのであって、Advent calendarを探索したいわけではない。

  • 私が学んだ黄金律の一つは、インターフェースが描画された後に要素が予期せず動いてはいけないということだ。
    Googleは、親指を持ち上げてから画面を押すまでの間にボタンが動くケースが特にひどいが、Googleだけの問題ではない。

    • これはOSレベルで処理してほしい。
      対象がタッチされる約0.25秒以内に新しく現れたものなら、タッチイベントを生成すべきではない。人間の反応速度からして、そのくらい速くボタンを狙って押すことはできないからだ。
  • これは明らかにユートピア的な黄金律である
    ほとんどの人はこうしたルールに反対しないだろう
    それでも、ほとんどの開発者はこうしたルールを頻繁に破るインターフェースを扱ったことがあるはずだ。理解していなかったり、望んでいなかったりしたからではなく、その時点でのコストが大きすぎたからだ
    たとえば 取り消し可能であること は非常に難しく、アプリケーションの下にあるデータ構造が最初からそれを念頭に置いて作られていて初めて可能になる。エラー防止も同様で、何がエラーなのかを正確に把握すること自体が難しくコストがかかり、ユーザーの言葉で完璧なフィードバックを提供することはさらに複雑である