インスペクション評価の限界 - 一貫性の評価
ヒューリスティック法やエキスパートレビューなどのインスペクション評価は、簡便で、ユーザを参加者として招く手間暇も必要なく、短時間のうちにインタフェースの問題点を検出できる。しかし、そのような手法を使って評価を行おうという気持ちがなければ、いくら優秀な手法であっても意味が無い。
インスペクション評価の特徴
ヒューリスティック法やエキスパートレビューなどのインスペクション評価は、簡便で、ユーザを参加者として招く手間暇も必要なく、短時間のうちにインタフェースの問題点を検出できるため、かなり頻繁にユーザビリティ評価に用いられている。もちろん、インスペクション評価には長所もあれば短所もあるのだが、もう一つの一般的な評価法であるユーザビリティテストとの間には、基本的にそれぞれの長所と短所がお互いに相補い合うという関係がある。簡単に要約してしまえば、インスペクション法が広く浅くインタフェースの問題点を探るのに向いているのに対し、ユーザビリティテストは狭く深く問題点を探るのに向いている。そのため、まずインスペクションで問題点を粗出ししておいて、その中で重要だろうと思われた問題点についてタスクシナリオを作ってユーザビリティテストを行う、という組み合わせ方があちこちで利用されている。
インスペクション法のひとつであるヒューリスティック法では、ニールセン(Nielsen, J.)のヒューリスティック原則にしたがって検査(インスペクション)をしていくこととされているが、そのヒューリスティック原則のVer.1では4番目が「一貫性を持たせる」となっていて、Ver.2でも4番目は「一貫性と標準」という項目になっている。そのこと自体は結構なことなのだが、果たしてインスペクション法でどこまで一貫性がチェックできるのか、そういうことを今回は考えてみたい。
インタフェースの一貫性
まず表面的な一貫性、つまりインタフェース外面における一貫性について考えてみると、これは用語の一貫性、操作部品の位置の一貫性、色使いの一貫性、方向の一貫性などを含んでいる。
用語の一貫性
用語の一貫性について、僕は昔コマンドラインインタフェースつまりCUI(キャラクターユーザインタフェース)の時代に苦労したことがある。まずOSのレベルに入ったり出たりするとき、そのシステムではLOGONとLOGOFFというコマンドを、入力プロンプトに対して与えることになっていた。しかし、そのOSに載っているアプリでは、そこから抜けるために、LOGOFFではなく、byeとかquitとかendとかexitとかctrl/xとか異なるコマンドを投入しなければならず、現在の状態を誤解すると他のコマンドをいれてしまったり、挙げ句の果て、間違えてプロンプトにLOGOFFと入力してしまうこともあった。また他のOSではLOGOUTというコマンドを使っているものもあった。
これらはシステム間の一貫性ということではあるが、少なくとも同一のOSに載っているソフトにおいては終了コマンドを統一して欲しいと思ったものだ。現在でも、たとえばPythonのコマンドではただのquitではなく、quit()と入れなければならない。こうした一貫性の欠如をなくすためには複数のソフト開発において連携が取られていなければならないが、そうした協定もないようで、ユーザが注意して学習するしか対策はないようである。
操作部品の位置の一貫性
操作部品の位置の一貫性については、たとえばATMの取消ボタンの位置などが以前は画面ごとに違う場所に表示されることがあったが、さすがにこういう目立った問題は最近では無くなったようだ。GUIではないけれど、エレベータの扉の開閉ボタンについては、これまで経験したエレベータのすべてで開くが左、閉じるが右となっていて、工業会の規格があるのかもしれないが、ともかくエラーを犯してしまう心配はない。
一昔前、分かりやすいボタンのシンボル(ピクト)を設計関係者が検討していたことがあって、両方向の矢印の間に人を描こう、いやそれは必要ないとか苦心していたようだが、ボタンの配置が一貫してしまえばいちいちシンボルを確認することもないためか、議論は立ち消えになってしまったようだ。いまもその当時の議論の残滓として矢印の間に縦線が描いてあったりすることがあるけれど、現在ではユーザとしてはそんなことはどうでもいい、という状態に近いだろう。
色の一貫性
色の一貫性については、交通信号に電球を使っていた時代には青が緑っぽかったり青っぽかったりすることがあり、さらに経年劣化で色が変化することもあったが、現在ではLEDランプとなり、安定した色表示が行われている。いわゆる色弱のドライバーにとっては、緑っぽい青信号は赤信号と混同しやすいので、これは良い方向に変化してきたと思う。
テレビリモコンのボタンのうち、電源のオンオフを割り付けられるボタンは右上にあり、赤色である、というのが一般的だ。しかし、ホテルなどにあるビデオ連動型リモコンでは左上にあったり、一段下の位置にあったりとバリエーションがあり、位置についてはまだ完全に統一されておらず、時々ユーザを混乱させる。
方向の一貫性
方向の一貫性は、公共インタフェース、特に地下鉄の通路やビルのエスカレータの設置においてきちんと設定されていない。人は右、車は左、という道路交通法のある日本で、歩行者間の通行方向にいつ、どのような形でルールができたのか知らないが、東京都内の駅や地下道、あるいは階段では、歩行者同士では左側通行がデフォルトのようにすら感じられるほどだ。要するに、向こうからやってくる歩行者は自分の右側を歩く、ということだ。歩道を歩いていてもそういう場合が多い。自生的に生じたものなのか、鉄道会社が誘導したものか分からないが、ともかく左側通行に完全に一貫させるならそれでもいい。
しかし問題は「ここでは右側通行」のような例外が結構あることだ。基本的にこうした場面では人の流れにのって歩くから、大きな問題は発生していないようだが、なんとかして欲しいと思っている。またエスカレータも、登りが左側の時と右側の時が混在している。これは視覚障害者にとっては危険に直結する大きな問題だろう。建築家が何を考えているのか知らないが、ちゃんと方向の一貫性についても配慮をして欲しい。
ともかく一貫性の欠如はユーザの混乱をまねき、ユーザエラーを引き起こし、時には安全にも関わってくるので、少なくともこうした外面的な一貫性については、インスペクション評価でも見つけやすい問題なのだし、厳密なルール化をはかり、違反事例をなくすようにしていくことが大切だ。
バージョン間の一貫性
さて、本稿ではこのバージョン間の一貫性の問題を強調したいのだが、特にソフトウェアの場合、バージョンアップによって一貫性が損なわれてしまうことがある。外面的な一貫性が空間的な変動に関するものであるのに対し、こちらは時間的な変動に関する一貫性の話である。もちろんハードウェアの場合も時間的な変動はあるけれど、同じハードウェア製品を立て続けに買うことはあまりないので、次の機種でインタフェースが変化してしまっても、あまり大きな問題にはならない。しかしソフトウェアの場合には、同じパソコンでソフトウェアのバージョンアップをして使い続けることは多い。したがって、そこに一貫性の欠如があると、確実にユーザを混乱させ、解決までに長い時間をロスさせることになる。
しかし、インスペクション評価で、こうしたバージョン間の一貫性の欠如を見つけようとすることは結構困難である。評価者が旧バージョンを熟知していた場合には、その変化を見つけることは比較的容易だろうが、新バージョンをいきなり提示されて、それを評価してほしいといわれても、旧バージョンを知らなければ一貫性欠如の問題を見つけることはできないし、旧バージョンとの比較を丁寧に実行している評価者がどれだけいるかという問題もある。
パソコンを利用していて、バージョン間の一貫性の欠如のために一番苦労させられるのはOSのインタフェースの場合である。特にWindowsという基本ソフトの問題である。(macOSについては筆者は利用していないので、問題の有無を知らない)。Microsoft社は、社内にちゃんとユーザビリティやUXの部署をもっており、活発に活動しているという話を聞くのだが、いったい彼らがどのような活動をしていて、彼らの提示する勧告が社内でどれほどの重要性をもって受け入れられているのかは分からない。そもそも一般のユーザが評価者としてOSのユーザビリティ評価をしても、ほとんどの場合、それは趣味的な活動になってしまう。Microsoft社でそうした一般ユーザの意見を聞いてくれる窓口がどこか分からないし、それをまともに受け入れてくれるかどうかも分からない。個別のアプリケーションの場合であれば、それを開発している企業のなかに評価部門があり、彼らの評価結果をもとにして品質向上を図ることは多いだろう。しかしMicrosoft社に向かって、その巨大なOSのユーザビリティ評価をまともにやってやろうという個人も組織もないのが現状だといえる。
仮に、そうした人がいてお金のかからないインスペクション評価をすることにしたとしよう。その場合、まず彼らを途方にくれさせるだろうことは、現在のOS(いまならWindows 10)の機能の膨大さである。これを全部やるのか、本当に?、しかもボランティアで??、ということになるのではないだろうか。
結局、問題点、特に今回問題にしているバージョン間の一貫性の欠如を発見するのは、ユーザビリティ専門家のインスペクション法によるユーザビリティ評価ではなく、「アレッ、どうなってるんだ?」という体験を一般ユーザがしてしまうタイミングである。以前のバージョンでは、こうやればできたのに、そのための操作部品が無くなってしまっている、というような体験である。それから彼らはネット検索をしたり知り合いに情報を求めたりして、問題を同定し、解決策をみつけ、ようやく利用を継続できることになる。要するに、この繰り返しなのだ。Microsoft社は、最初からそういう流れを想定して製品開発をしているのではないか、とすら思えてしまう。
事例
参考までに、僕が最近出くわした事例を二つほど報告しておきたい。一つはディスプレイの輝度設定について、もう一つはシステムの詳細設定についてである。
- 以前のバージョンではディスプレイの輝度設定はコントロールパネルのディスプレイのところにスライドバーがあって、それで調整することができた。最近、白内障のせいなのかどうか分からないがスクリーンがまぶしく感じられるようになったので、ちょっと輝度を落とそうと考えてコントロールパネルを開いたのだが、ディスプレイの項目のところにスライドバーがない。無ければ当然調整はできないので、いろいろ調べたのだが、結局無くなったことがわかった。ディスプレイが沢山の種類登場したためか、OSからの制御が困難になったらしく、輝度調整を外してしまったらしいのだ。それで仕方なく、夜間モードを使用することにした。夜間モードの設定には色温度の調整のスライドバーはついているが、輝度調整のスライドバーはない。しかもスケジュール設定のところには時間の設定という選択肢があるにも関わらず、終日夜間モードにするという選択肢がない。仕方なく、現在は8:00にオンにして7:45にオフにするという設定にしている。つまり15分間は夜間モードがオフになってしまうような設定だ。いったい設計者はユーザの利用状況というものをどのように考えているのだろうか。
- もう一つのシステムの詳細設定は、システム環境変数の設定を変えたいので、コントロールパネルあたりを捜索した。そして見つけることができなかった。しかし、こういう場合、CORTANAは全く役にたたない。仕方なくネット検索をして、WindowsキーとPauseキーの同時押しで表示させるというやり方をみつけ、なんとか事なきを得た。
さて、こうした問題は、仮にMicrosoft社の評価部隊がインスペクション法によってチェックしたとして、見つけられるものだろうか。当然彼らの大多数は旧バージョンのインタフェースを知っている筈だ。だから見つけられて当然だと思うのだが、そもそも前述のような点は評価対象にすらなっていなかったのではないか。評価対象になっていたのなら、設定変更ができないとなった場合、コントロールパネルの該当画面に「以前、ここにあったディスプレイの輝度設定はなくなりました」とか「あなたのお使いのディスプレイでは輝度設定はできません」とか「以前、ここにあったシステムの詳細設定は、場所を移動したのでWindows + Pauseで画面を起動してください」といったサービスメッセージを表示すべきだろう。それすらしていないということは、放置しておいてもユーザが何とかするだろうと考えたか、そもそも問題点に気づいていなかったかのどちらかである。
ちょっと話がWindows批判に集中してしまったが、そもそもインスペクション法のようなユーザビリティ評価法は、まず使われなければ意味が無い。それを使って評価を行おうという気持ちがなければ、いくら優秀な手法であっても意味が無い。そして、評価してやろうという気持ちがあってトライしても、特に時間的なインタフェースの変動に対しては残念ながらインスペクション法は強力ではない。
時間的なインタフェースの変動、そしてそれによって生じる一貫性の問題に対しては、設計段階で設計内容を変更しようとする設計者がきちんと記録をしておき、それをメッセージなりで表示するようにしてくれなければならない。やる気さえあれば、できないことではないはずだ。インスペクション法は、設計者がそうした努力をしても、尚残ってしまうユーザビリティの問題点を見つけるための手法なのだ。
