1986年の60のガイドラインを再訪する
※ユーザビリティガイドラインの耐久性に関するJakob Nielsenのコラムへの補足記事
Sidney L. Smith と Jane N. Mosier の Guidelines for Designing User Interface Software は、アメリカ空軍の Electronic Systems Division の資金提供により、MITRE Corporation によって、1986 年に出版された。このレポートには、944 のユーザビリティガイドラインが書かれている。
古いユーザビリティガイドラインが時間を超えて有効性をどれほど保つかを見積もるため、ガイドラインの 6 つの主なセクションから 10 ずつのかたまりを抜き取り、そのサブセットの評価を行った。サンプルを選ぶには、各セクションの真中あたりを開き、ページ左上から 10 ずつを抜き出した。
下記に示すのは、私が評価を行った 60 のガイドラインを書き写したものだ。本の中のほとんどのガイドラインは、例、コメント、参考書籍がついていた。簡潔化するために、そのほとんどをここでは省略した。
また私は、今でも有効だと思うガイドラインには何もコメントしていない。あたりまえだが、もうほとんど使われていないデザイン要素に関する物であれば、たとえそれが正しくても、そのガイドラインの重要性は下がる。しかし、もしそのような要素を使っているのであれば、不適切だという注意書きがない限り、そのガイドラインを気にとめておくべきだ。
セクション 1：データ入力
このセクションには、テキスト入力、オンライン入力フォーム、データ確認など、コンピュータに情報を入力することに関係するガイドラインが書かれている。このセクションの中ほどの部分には、入力欄とそのラベルをどう関係付けるかが書かれている。このトピックは、特に 1970 年代のメインフレームインターフェイスを少しだけ改良したような、原始的なフォームに頼ることが多いウェブベースアプリケーションで、今でも重要なものだ。
1.4.12 必須・任意データ欄のマーク付け
フォーム画面をデザインするとき、必須データ欄と任意データ欄を明確に見分けられるようにすること。
1.4.13 データ内のフィールドマーカー排除
入力文字列の長さが一定でなく、入力データがフィールドマーカーを完全に置き換えない場合、残っているフィールドマーカーをコンピュータ処理で無視すること。
Jakob 2005 年の分析：
現在のシステムでは、入力欄を示すためにフィールドマーカーを使わないため、このガイドラインは無意味なものになっている。
1.4.14 不定長文字列の自動配置
入力文字列の長さが一定でない場合、配置をコンピュータ処理で自動的に調整すること。文字列を、ユーザが手動で右寄せや、左寄せする必要があってはいけない。
例
アンダースコアで入力欄を表示しているものとして、下記の例は全て同一とみなされるべき。
| Address: 40 Dalton Road_______ |
| Address: _______40 Dalton Road |
| Address: ___40 Dalton Road____ |
Jakob 2005 年の分析：
現在のほとんどのシステムでは、デザイナーが前もって各入力欄の配置調整を行っているため、ユーザは配置を調整できなくなっている。したがって、このガイドラインは無意味なものになっている。
1.4.15 データ入力欄移動時のタブキー入力
ひとつのデータ入力欄から、次のデータ入力欄に移動するとき、ユーザにしっかりとタブキーの入力をさせること。コンピュータは、このようなタブ入力を自動的に行ってはいけない。
コメント
自動タブ入力は、タイピングに長けたユーザが、画面を見ずに一連の情報入力を行い、間違えてデータ入力欄を飛ばしてしまうといった、縦続的なエラーを引き起こす原因になりうる。ここで許容できる、ひとつの解決法は、各フィールドの最後に余分な空白文字を付け加えることだ。ソフトウェアは、その空白文字にはみ出るような入力を禁止し、そのような入力が行われた場合は音でそれを知らせるようにデザインされるべきだ。こうすることによって、正確に入力欄の移動のためのタブ入力を、タッチタイプするユーザにも行なえるようになる。
Jakob 2005 年の分析：
これは、電話番号や社会保障番号を区切って、複数の小さいテキストボックスに入力させようとするウェブサイトによく見られる間違いだ。1986 年からずうっと、データ入力時に小さいテキストボックス間を自動的に移動させると、エラーが起きやすいことが分かっていたのだ。どんな場合でも、例えば電話番号などで市外局番に括弧をつけるなど、様々なフォーマットを受け入れられる、単一のテキストボックスにするほうが良い。（柔軟な入力欄は、高齢者にとっては特に重要になる。）
1.4.16 明確なラベル形態
入力欄、ラベルの付けられたコントロールオプション、説明書き、または画面に表示されているそれ以外のものが、入力欄に付けられたラベルとの見分けがはっきりと付けられるようにすること。
例
ラベルを全て大文字で書かれ、最後にコロンをつける。または、入力欄の文字を明るい色で表示し、ラベルをくすんだ色で表示するなど。
Jakob 2005 年の分析：
ラベルと入力欄の見分けをはっきりと付けられるようにすることは、今でも重要なことだが、システムがそれを自動的に行なってくれるようになっているため、デザイナーにこれを警告する必要はなくなっている。
1.4.17 一貫したラベル形態
入力欄が画面上に散らばって配置されている場合、ラベルと対になる入力欄の関係を示すための表示方法に一貫性を持たせること。
例
ラベルは常に入力欄の左側に置く。またはラベルは入力欄のすぐ上に、左端を入力欄の左端にあわせるように置く。
1.4.18 入力開始場所を示すためのラベル内句点
各入力欄のラベルの最後は、そこに入力を行なえることを示すために、特殊記号を入れること。
例
これには下に示すように、コロンの使用を推奨する。
| NAME: __ __ __ __ __ __ __ __ __ __ __ |
Jakob 2005 年の分析：
このガイドラインはほとんどの場合、特にオンラインフォームの場合は、未だに有効なものだが、いくつか例外がある。例えば、検索用文字列を入力するテキストボックスと「検索」というコロンを省いた言葉をボタンにし、対を作れば、ラベルとアクションボタンの両方の役目をまかなえる。（これはホームページのユーザビリティのガイドライン #49 になっている。）
1.4.19 理解が容易なラベル
入力欄のラベルを作成するとき、分かりやすいか、または既に標準的で、その意味が定着している言葉やコード、または略称を使うこと。気まぐれにコードを作ってしまわないこと。
1.4.20 データフォーマットを示すラベル
もし、助けになるようであれば、データフォーマットを示すラベルを付け足すこと。
例
| DATE (MM/DD/YY): __ __/__ __/__ __ |
1.4.21 データ単位を示すラベル
入力欄のデータの単位が一定である場合、その単位をユーザに入力させるのではなく、ラベルの一部として記述しておくこと。
例
| SPEED (MPH): __ __ __ |
セクション 2：データ表示
このセクションは、主にテキスト出力、データ書式や表に関して書かれているが、セクションの中ほどでは視覚的なデータ表示に的を絞っている。そのため私は、この部分を分析することにした。
2.4.3.10 周期的なデータの繰り返し表示
曲線が周期的なデータを示すならば、グラフからはみ出ている周期部分が収まるところまで、グラフの範囲を広げることを考慮してみること。
コメント
ここでの目的は、表示されている周期的なデータから肝心の部分を、曲線の最初に戻らずに探し出すことを可能にするということだ。どれほど広げるのが好ましいかは、その使い方によって違う。簡単に言えば、同時に使うデータは、同時に表示するということだ。
2.4.3.11 差の直接表示
2 つのデータセットを見比べなければいけない場合、ユーザに元の 2 つのデータを視覚的に見比べさせるのではなく、その差を独立した曲線として表示すること。
例
もし 2 つの曲線が、収入と支出を表している場合、収益（または赤字）を表すその二つの差の曲線を表示すると良いかもしれな。
2.4.3.12 面グラフ
各曲線が全体の一部を示している場合、各曲線が積み上げられ、全体量を示す部分に網がけまたは塗りつぶしを行う、面グラフを使うことを考慮してみること。
Jakob 2005 年の分析：
Microsoft Excel でこのグラフは「積み上げ面」グラフと呼ばれている。
2.4.3.13 面グラフでの順序
面グラフの中で各系列データを、一番変動する曲線を一番上に、一番変動しない曲線を一番下にするような並べ替えを行なうこと。
コメント
面チャートで下部にある曲線の不規則性は、上部にある曲線全てにその不規則性を「増殖」させてしまい、上部にある曲線の目立つ波が本物なのか、それともこの表示順序によって生じたものなのかが判断しにくくなる。
コメント
時には、系列の並びを決める固有の理由がある場合もある。もしその理由が、曲線に分かりにくい不規則性を作ってしまう場合、そのデータは別の形態のグラフにして表示したほうが良いかもしれない。
2.4.3.14 面グラフのラベル付け
画面スペースが許す限り、各系列の網がけまたは塗りつぶしの行なわれた領域内に、直接配置すること。
2.4.3.15 累計グラフ
累積した合計を示す場合、累計グラフを使うことを考慮してみること。だが各系列の変動を示す場合は、累計グラフに頼ってはいけない。
2.4.4.1 棒グラフ
1 つの同じ単位を持つ複数の系列や、異なる間隔のインターバルで採取された同一系列の比較を行う場合、棒グラフを使うことを考慮してみること。
2.4.4.2 ヒストグラム（ステップグラフ）
系列や、インターバルの回数がとても多い場合、ヒストグラム（ステップグラフ）や、間隔を開けない棒グラフを使うことを検討すること。
コメント
ヒストグラムは一般的に、例えば X 軸方向にインターバルごとの観測を記録する、周期データを示すために使われる。このような場合、ヒストグラムを使えばインターバルの隙間によって「格子柵」状に見えてしまうことを防ぐ。
2.4.4.3 棒グラフの一貫性
似通った情報を示す関連した一連の棒グラフでは、グラフの縦横の方向に一貫性を持たせること。
2.4.4.4 棒グラフ内の間隔
近接したデータの間隔を、眼球運動をしなくても視覚的な比較ができる程度に、狭くすること。
コメント
もし、大量の棒が表示されるのであれば、隙間の大きさによっては、目の錯覚で濃い棒と淡い棒の縞模様に見え、目をチカチカさせてしまうこともある。そのような場合、間隔のないヒストグラムを使用したほうが良いかもしれない。
セクション 3：シークエンスコントロール
ユーザのワークフローに対するコントロールを指し示すのに、このタイトルは多少変だが、ここではシステム上でデータの入力や参照とは対照的に、ユーザがどのように処理を行わせるかが書かれている。このセクションでは、メニュー構造、コマンド言語、そしてエラー処理といった、今でも全ての項目が有効なことについて語られている。私は他でも行ったように、中程の部分を分析に選んだ。この部分にはメインフレームのダイアログをコントロールする主な手段だった、ファンクションキーについて書かれていた。
今日のシステムでは、ファンクションキー（F1、F2、など）が使われることは希だが、コマンドキーを使ったショートカット（ Ctrl-X、Ctrl-C、Ctrl-V、など）が多く使われる。そして、そのためのガイドラインは、ここに書かれているものと同じだ。
3.1.4.8 キーコンビネーション一貫した論理関係
キーコンビネーション（コントロール / シフト）が使われる場合、シフトした機能と、シフトしていない機能の関係は、論理的な関係を一貫して保つこと。
例
論理関係のひとつの例は、シフトした機能と、シフトしていない機能を、逆の機能にすることだ。例えばあるキーがカーソルを前進させるのであれば、それをシフトしたものは、カーソルを後退させるということだ。
例
もうひとつの例は、シフトした機能とシフトしていない機能の関係を、度数の違いにすることだ。例えば、あるキーが表示されている 1 文字を消す場合、シフトした機能は 1 語消すという具合だ。
3.1.4.9 ファンクションキーの 1 機能化
各キーは、ラベルが付けされた機能を、それを 1 回押しただけで行なうこと。また、そのキーが繰り返し押されても、その機能を変えないこと。
Jakob 2005 年の分析：
もし、マウスボタンを特殊なファンクションキーとして考えるならば、このガイドラインはもう使うことができない。ダブルクリックはインタラクションのひとつとして、確実に定着しているため、それを禁止することは非現実的だ。もちろん、ダブルクリックは悪名高いユーザビリティ問題を引き起こし、多くのユーザがシングルクリックと、ダブルクリックの違いを理解せずにいる。もし Apple がこのガイドラインに従って、2 ボタンマウスを採用し、ダブルクリックを世界に広めることがなければ、もっと良かったのかも知れない。だが、現実世界でダブルクリックは、無くなることはないだろう。
3.1.4.10 ファンクションキーへの反応
もしファンクションキーを押しても、すぐにその影響が画面に現れない場合は、その処理が行なわれたことを何か別の方法で知らせること。
3.1.4.11 有効なファンクションキーの表示
もし、ファンクションキーの中で有効なものと無効なものがある場合、現在有効なものを、例えば明るい色などで、明示すること。
3.1.4.12 必要の無いファンクションキーの無効化
現在行なわれている処理の中でファンクションキーが必要ない場合、そのキーを自動で一時的に無効にすること。ユーザに、この目的のために機械的な操作を要求してはいけない。
3.1.4.13 共通機能の 1 キー化
いつでも使うことのできる機能には、ファンクションキーを 1 つ割り当てること。
Jakob 2005 年の分析：
現在のシステムでは、機能をいつでも使えるようにするために、一般的に固定されたメニューやナビゲーションバーなどの、異なるメカニズムを使用しているため、このガイドラインは有効でない。いつでも使える機能全てにファンクションキーを必要とするのは、ファンクションキーをあまり使わなくなっている現在のユーザインターフェイスでは適切ではない。また、現在のソフトウェアには、いつでも使える機能が多すぎて、キーボードにあるファンクションキーの数では足りなくなってしまう。
3.1.4.14 一貫したファンクションキー割り当て
もし、特定の機能が複数の処理過程でキーに割り当てられている場合、その機能を一貫して同じキーに割り当てること。
3.1.4.15 異なる操作モードでの一貫した機能割り当て
もし、あるファンクションキーが、異なる操作モードで異なる機能に割り当てられている場合、同等または類似した機能をそこに割り当てること。
3.1.4.16 簡単な復帰機能
もし、ユーザによってキーへの機能割り当てが変えられるようになっている場合、元どおりの基本機能に簡単な方法で戻すことができる術を提供すること。
例
コクピットデザインにおいてマルチ機能キーは、ナビゲーションや武装の操作といった複数の目的に使うことができるが、パイロットは一つの動作で基本の操縦操作機能に戻すことができるべきだ。
コメント
用途によっては、その処理の終了時、入力タイムアウト時、またはその両方によって、ユーザのマルチ機能キーの割り当てを自動で基本機能に戻したほうが、望ましい場合もある。自動タイムアウトの設定時間は、経験的に調整されなくてはいけない。
3.1.4.17 分かりやすい配置
キーボード上で使うファンクションキーの位置は、学習と使用を楽にするために、分かりやすい場所にまとめること。最も頻繁に使うファンクションキーを、最も指が届きやすい場所に配置すること。
セクション 4：ユーザガイダンス
このセクションは、システムのフィードバックや進行状況の情報など、ヘルプシステムの枠を大幅に越えた領域を説明している。
4.2.3 入力に対するフィードバック
もし、ユーザ入力に対する結果が、完全に反映するまでに時間がかかる場合、その処理経過を示すものを何かしら表示すること。
コメント
入力をコンピュータに行なった後、処理が正しく行なわれているのかどうかという、フィードバックを、ユーザは必要とする。コンピュータの反応が数秒後れただけで、その処理が普段すぐに終わるものであれば特に、ユーザに不安を与えることになる。そのような場合、その処理が実行されていることを示し、できればその処理にかかる予測時間を示す、途中経過のフィードバックが提供されるべきだ。
4.2.4 処理完了の表示
ユーザ入力による処理に時間がかかった場合、処理が終了したことを、ユーザに知らせ、次の処理を行なうための、正しいガイダンスを提供すること。
4.2.5 印刷要求へのフィードバック
ユーザが印刷出力を要求し、離れた場所にあるプリンタでその取り扱いが行なわれる場合、ユーザにその処理が行なわれていることを示す表示をすること。
4.2.6 画面 ID
各画面に固有の ID を、画面フレーム上部の固定された場所に表示すること。
Jakob 2005 年の分析：
このガイドラインは現在、当初書かれたとおりにすると、正しくない。ウェブサイトで URL が「固有の ID 」になると思うかもしれない。しかしそれ以前に、かつてメインフレーム時代に特定画面を指し示した ID で、今のユーザは画面を関連付けしていないのだ。変わりに現在のガイドラインは、各画面の目的を簡潔に要約したものを見出しまたはタイトルとして、提供することだ。
4.2.7 複数画面の表示
もし、一覧や表が 1 画面に入らない場合、複数フレームに画面がまたがって表示されていることを知らせること。
4.2.8 操作モードの表示
ユーザ（またはコンピュータ）の行ったことの結果として、操作モードの変更が行われ、それ以後のユーザ入力に影響を与える場合、現在のモードを示すものを表示し続けること。
Jakob 2005 年の分析：
モードという概念は、現在のインタラクションデザインでは嫌われている。しかしながら、もしモードを使っているのであれば、明らかにその表示は行わなければいけない。
4.2.9 オプションの表示
前回選択したオプションがまだ操作可能である場合、それを自動またはユーザ要求によって、表示すること。
Jakob 2005 年の分析：
このガイドラインは良いように見えるかもしれないが、現在のシステムが持つ、無数のオプションを前提に考えると、以前選択したものを表示し続けるのは、非現実的だ。ユーザがそれを要求した場合、それを表示するのは、間違いなくガイドラインになる。またeコマースの購入手続きの最終決済前の確認ページでも、選択したオプションを表示することが推奨される。
4.2.10 選択アイテムの表示
ユーザが、表示されているアイテムに何か操作をするために選択を行った場合、そのアイテムを画面上でハイライトする事。
Jakob 2005 年の分析：
これは今でも通用する助言だが、一般的にシステムが自動的に行ってくれるので、普通は選択アイテムの表示に関するガイドラインは必要とされない。それでもなお、Flash のユーザビリティ レポートでは、ハイライトやその他選択の表示に関して、ガイドラインを書かなくてはいけなかった。多くのユーザが、現在の Flash のデザインにおける、乏しいフィードバックによって、失敗さするからだ。
4.2.11 ユーザ割り込みに対するフィードバック
データ処理中のユーザ割り込みの後、ユーザにシステムが処理前の状況に戻ったことを示すメッセージを表示すること。
4.3.1 情報提供型エラーメッセージ
コンピュータが入力にエラーを見つけた場合、ユーザに何がおかしく、それについて何ができるかを示す、エラーメッセージを表示すること。
セクション 5：データ通信
今日の視点からこのセクションを見ると、まるで電子メールのユーザインターフェイスのことを書いているように見える。しかし多くのガイドラインは、ウィッシュリスト、画像共有アプリケーションなど、ユーザ間通信を行うシステムにも有効だ。
5.2.10 非公式な配信リスト
各個人またはグループで、局地的な利用のために、非公式な配信リストを自由に作成できるようにすること。
5.2.11 リスト内リスト
配信リストの中に、個人以外にも、他の配信リストを内包できるようにすること。
5.2.12 配信リストの変更
一度作られた配信リストに変更を加えられるよう、コンピュータ補助を提供すること。
5.2.13 部分的アドレスの自動補完
アドレス指定時に、それが固有アドレスを指定するに足りている場合、部分的な名前の入力を許可すること。
5.2.14 自動アドレス確認
アドレスの正確さ（書式やフォーマットが正しいか）をコンピュータでチェックし、メッセージを送信してしまう前に間違いを直させること。
5.2.15 返信時のアドレス挿入
ユーザが受信メッセージへの返信をするとき、自動的に正しい返信先アドレスと、元の受信メッセージの引用を挿入すること。
5.2.16 アドレスヘッダの編集
送信するために準備されているメッセージのアドレスヘッダを、ユーザが編集できるようにすること。
Jakob 2005 年の分析：
このガイドラインは未だ正しいが、今の時代、編集できないアドレス欄を作るデザイナーがいるとはとても思えない。そのようなものが存在するとは思うが、とてもまれだろう。それを考えると、たまにはこのように、過去のコンピュータシステムにどれほど柔軟性が欠けていて、不器用なものであったのかを思い出させてもらえて、良いのかもしれない。コンピュータは未だに使いにくい。だが、20 年前はもっと酷かったのだ。
5.2.17 アドレスの重複確認
宛先アドレスの中に、各アドレスが 1 度きりしか書かれていないことを確認すること。
5.2.18 順列配信
複数階層の受信者による評価が必要となるアプリケーションでは、1 人の受信者から、次の受信者にそのメッセージが転送されるよう、最初の送信者が連続した配信先を指定できるようにすること。
5.2.19 受信メッセージの再配信
アドレスヘッダを付け足すことによって、受信したメッセージを再配信することを可能にすること。
Jakob 2005 年の分析：
このガイドラインの基礎になっている目的は、未だ正しい。ユーザはメッセージを再配信できるべきだ。しかし、それをどのように実現するかという細かい提案は、有効性を失っている。この例が強く示すように、そのガイドラインがどのような原理で作成されているかを説明するべきだ。将来の読者が、細かいことは変わっても根本的な内容が有効性を失っていない場合、それを取り入れることが可能になるからだ。
セクション 6：データ保護
このセクションでは、秘密を守ることにとても気を使っているのが見られ、このガイドラインの起源が軍事にあったことを象徴している。だが民間のシステムでも、ユーザデータを保護しなくてはならない。そのため、ここに書かれているガイドラインは、現在も高い有効性を持っている。
6.1.1 簡単なログオン
ログオンとユーザ認証の手続きをできる限り簡単にし、データの不正使用を徹底して防ぐこと。
6.1.2 ログオンのプロンプト
パスワードやそれ以外のデータで、アクセスまたは変更にユーザの身分証明と認証が必要なものには、ログオン手続きを用意すること。
6.1.3 ユーザによるパスワード決定
パスワードが必要とされる場合、ユーザに自分のパスワードを決定する権利を与えること。
6.1.4 パスワードの変更
ユーザによるパスワード変更を、いつでも行なえるようにすること。
6.1.5 パスワードの非表示
パスワードがユーザによって入力される場合、パスワードが公にならないようにすること。入力されたパスワードは、表示されてはいけない。
6.1.6 ログオン失敗回数の制限
不正アクセスの繰り返し試行からシステムを守るために、ユーザに許可される間違いのマージンになる、ログオン失敗の回数と比率の上限を課すること。
6.1.7 ユーザの確実な身分証明のための補助テスト
提供されているよりも、もっと厳密にユーザ認証がシステムのセキュリティーに必要な場合、補助的なテストを行い、現実的でない記憶力をユーザに課さずに、確実な身分証明を行なわせること。
6.1.8 継続的なユーザ認証の認識
身分証明後は、そのユーザに与えられている全てのデータアクセス / 変更の権利が、そのワークセッションが終わるまで継続するようにすること。
6.2.1 データアクセス時の単一認証
データアクセスのためのユーザ認証は、ログオン時だけにすること。特定のデータにアクセスする度に、ユーザ認証を求めないこと。
6.2.2 セキュリティー区分の表示
表示されているデータが、セキュリティー目的で区分されているものであれば、各画面上に目立つセキュリティー区分の表示を行なうこと。
