データ品質がユーザーエクスペリエンスに与える影響

ウェブとは、つまるところコンテンツである。そのコンテンツにエラーがあったらどうだろう？ほとんどのナビゲーションがコンテンツに頼っていて、特に検索ではその傾向が強いわけだから、場合によってはユーザはサイトを利用できなくなる可能性もある。実例を挙げよう。

• musicboulevard.comでは、Madonnaの録音リストにEvitaのサントラ盤が入っていない。ほとんどのユーザはこう考えるだろう。「Madonnaで検索した。彼女のCDリストが出てきた。私の欲しいCDが載っていない。当然、この店には置いていないということだろう。このCDを手に入れるには他の店に行くしかない」
• 私の友人がある人にHeather has Two Mommiesという本を推薦した。その人はAmazon.comに捜しにいった。彼女はまず「Heather Mommies」で検索してみたが、だめだった（検索方式に関するユーザビリティ問題である）。次にこの本のフルネームを入力してみた。それでもだめだった。
  このかわいそうなユーザから私の友人のところに電話がかかってきた。著者の名前（これは永続性がある）を教えてほしいと言うのだ。そこでこの友人が、自分自身で検索してみた。「Heather, Mommies」（コンマに注意）とやったら、その本が出てきた。結局、このデータベースにはHeather has 2 Mommiesで登録されていたことがわかった。
• 別の友人が、サーベイ調査の設計にとても役に立つといって、Priscilla SalantとDon Dillmanの共著How to Conduct Your Own Surveyを薦めてくれた。Amazon.comでSalant（1人目の著者）を検索してみた。出てきた書籍リストを見ると、その本は絶版と書かれていた。私は、もうその本は手に入らないものと、ほとんどあきらめかけたのだが、そこでハイパーテキストが救いの手を差し伸べてくれた。この絶版本のページでは、2人目の著者の名前が、彼の著書一覧へのハイパーテキスト・リンクになっていたのだ。簡単なことなので、このリンクをクリックしてDillmanが他に何か面白い本を書いていないか見てみることにした。驚いたことに、そうして出てきたリストには例のサーベイ本への別のリンクが入っていた（なぜ別の本とわかったかと言うと、リンクの色が未訪問リンクの色になっていたからだ）。このリンクを追いかけたところ、求めていた本にたどり着くことができた（第二版）。
• 新しく手に入れた400MHzのマシンが起動しないので、Compaqの技術サポートに連絡した。保証内容に従って、修理技術者を派遣してくれると言う約束だったのだが、誰も来なかった。この件を検証していく過程で、問題が起こった。Compaqのシステムでのトラブル・チケットの発行日が、私が障害を報告した日の翌日になっていたのだ。理由：私が最初のアクションを起こしたのは、カリフォルニア時間で午後11時。だが、彼らのシステムはテキサスのどこかにあって、そこではすでに翌日の午前1時だったのだ。解決策：日時その他のユーザに関連したデータは、ユーザの状況に合わせて表示すること。自社システムの内部的記録に合わせてはいけない。
• リンク切れはユーザの悩みの種になり、リンク先のサイトから得られたはずの価値を無にしてしまう。

ここに挙げたどの例でも、データ品質における小さなエラーのおかげで、サイトそのものがユーザにとってほとんど役に立たないものになっている。それなりのやり方で試してみた結果が失敗だった場合、大部分のユーザはそこであきらめてしまう。だが、パワーユーザなら、品質に問題があっても迂回策を考え出せることは珍しくないだろう。ただし、ユーザの大部分をパワーユーザと想定するわけにはいかない。たとえ、あなた自身はそうであってもだ。

エラーの防止

データ問題に関する最善の策は、それらがサイトに公開される前に排除することである。メインフレームへのデータ入力の時代からあるガイドラインは以下のようなものだ。

• データを絶対に再入力させない。可能な限り、信頼できる情報源からのデータをそのままコピーしてくること。さらにいいのは、データベース内で情報の各部を保存するのは一度だけにして、それ以外のところで利用する場合は、元データを参照するようにしておくことだ。情報の変更や訂正が必要な際には、1箇所だけ直せばそれですむ。
• 合理的な変数に照らし合わせて、入力されたデータを検証すること。例えば、意味のある日付だけを受け付けるとか、その製品の価格が、サイト内の他の製品の2倍以上、あるいは半分以下になっている場合は警告フラッグを出すといったことが考えられる。書籍データベースに著者の氏名を入力する場合は、すでにその氏名がデータベースに入っているかどうかチェックすること。その結果がイエスなら、スペルは正しい可能性が高い。ノーなら、スペルを確認して、可能性のある選択肢をデータ入力係員に提示すること。
• あらゆる入力データを2回、違った人2人に入力してもらって、作業を二重化する。双方の入力が一致している場合、通常、それは正しい。

安上がりな品質管理

完璧なデータ入力が実行できないのなら、最重要の情報だけは二重チェックするようにしよう。例えば、ベストセラー作品だけは、別の人物が記録内容を検査するわけだ。オンラインではあまり売れていなくても、ウェブ以外でベストセラーなら、その記録内容は二重チェックの対象となる。

エラーの訂正

何100万人ものウェブユーザに、品質管理部になってもらおう。そのために、あなたのサイトで見つけたエラーをユーザが報告しやすいようにしておくことだ。1分以内で埋められる程度の簡単なフォームを用意しよう。あくまでもユーザの好意に頼っているのだということは、忘れないように。全ページに控えめなフッタを設け、クリックするだけでそのページのエラーを報告できるようにしているサイトもある。

各エラーを最初に報告してくれたユーザに、ささやかな報酬を進呈しよう。あるいはもっと大規模な懸賞を常時行ってもよい。ユーザのコンタクト情報は受賞者に連絡するために用いるのが主で、よほど必要がない限り、そこへ連絡してエラー報告の内容に関して追加の質問をしたりはしないことはエラーフォームに明記しておくべきだ。

エラーがあっても機能すること

あらかじめどんなによく計画しておいても、サイトでのデータ・エラーはなかなかなくならないものだ。だから、ユーザ・インターフェイスにはエラー耐性を持たせておくべきで、エラー結果にユーザが左右されないよう守ってやる必要がある。

Almost no search engines do spelling checks, but Barnes & Noble’s does. So they pull up my books even if a user spells my name Jacob Nielson (or if the user spells correctly but their database is in error).

検索エンジンでスペル・チェックをしてくれるところは皆無に等しいが、Barnes & Nobleではやっている。このため、ユーザが私の名前を間違ってJacob Nielsonと入力しても（あるいはユーザは正しいスペルで入力したのにデータベースの方が間違っている場合でも）、私の著書が出てくるようになっている。

1998年7月12日