メーリングリストのユーザビリティ
メーリングリストのコンテンツは、極力短くするべきだ。登録、登録解除にはそれぞれ別個のEメールアドレスを用意し、メーリングリストで配信されるあらゆるメッセージに、登録解除方法に関する情報を入れておこう。ユーザビリティが向上したおかげで、登録者が128％も増加したという事例もある。
Eメールリストは、Eマーケターの夢だ。メーリングリストなら、ごく絞られたターゲットに向けて情報を発信できる。Eメールなら、顧客がサイトに来てくれるまでじっと待っている必要もない。
メーリングリストを利用すれば、ウェブサイトの影響範囲を拡大することができる。（ブラウザではなく、ユーザの受信箱のスペースを占有するという）文字通りの意味でそうなのだ。もっと興味あるたとえを使うならば、こちらからユーザに手を伸ばし、タイミングが重要な意味を持つ情報を提供することができれば、より多くのサービスが可能になることだろう。
プッシュ機能の大失敗を思い起こしてみよう。ユーザの時間をたくさん奪い取るのがゴールではない。有用性からみて十分といえる程度にユーザを刺激するのはいいが、Eメールが重荷になってしまっては元も子もない。「情報過多」などという以前に、ユーザは登録解除してしまうだろう。
ニュースレターまるまる1回分に匹敵するかなり長文のEメールを送信する会社もある。私は、Eメールはごく短いものにとどめておく方がいいと思う。見出しと要約、それにウェブサイトに置かれたよりくわしいコンテンツへのリンクに限定するのだ。理由は2つある。
- 受信箱を処理しているときのユーザは、驚くほどのストレスを感じている。上司、顧客、配偶者からの緊急のメッセージはないか、探し出さなくてはならないのだ。このため、あまり時間をかけて読んでいられないのが普通である。短くしろ、というのがウェブコンテンツの法則だった。ごく短くしろ、というのがEメールの法則だ。
- Eメールに望むのは、リンクをたどってウェブサイトに来てもらうことだ。そこでなら、もっと豊かなユーザ体験を提供でき、Eメールではまかないきれない、よりくわしい知識を望むユーザの期待にこたえることができるからだ。
メーリングリストのコマンド
伝統的なlistservで採用されているユーザインターフェイス技術は、1950年代のものだ。すなわちバッチ処理なのである。ユーザは、一連のコマンドをEメールの本文に書いて、サーバに送信する。かつてメインフレーム機を司る高僧にパンチカードの束を渡していたのと同じように。
ひどいユーザビリティだ。対話がない。間違いの元が山ほどある。
すべてがうまくいけば、ユーザの手元にはメーリングリストシステムの使い方を書いた説明書が届くだろう。説明書を読むユーザなんているかい？さらにまずいのは、必要が生じるその日まで、この説明書を大事に保存しておくユーザがいるかどうか？まずいないだろう。だからこそ、この手の古いリストシステムには、「どうしたら登録解除できるの？」というメールが山のように送られてくるのだ。
Eメールシステムそのものを、ユーザインターフェイスとしても活用できるようにしておくのがいいだろう。登録、登録解除、ディスカッショングループへの投稿などの主なコマンドには、専用のEメールアドレスを用意しておくのだ。リストを短めにしておけば、それだけユーザにわかってもらえる確率も高くなる。
これ以上に複雑なコマンドは、ウェブベースのインターフェイスにまかせよう。もっとも高度なメーリングリストシステムでも、ボタン何個かと入力用フィールドを備えたウェブのフォームがあれば説明できるはずだ。
登録者を募る
ユーザは、Eメールニュースレターの配信を受けるにあたって、オプトイン（自主的に加入）してこなければならない。ユーザ登録画面に「値打ちあるマーケティングプロモーションの送信を希望します」という一文があって、その前の小さなボックスにはデフォルトでチェックが入っているという仕掛けを採用するサイトも多いようだ。これはよくない。
確かに、このボックスに気が付かないで、チェックを外すのを忘れるユーザもいるだろう。だからといって、彼らがニュースレターを喜んで受け取るとは限らない。反対に、スパムを送ってきたということで、あなたの会社は毛嫌いされるようになるだろう。悪くすると、小さなボックスに気が付かなかったこれらユーザは、あなたのサイトを信用しなくなるだろう。このサイトは、人をひっかけようとするサイトだと思われてしまうからだ。
ボックスはチェックしないでおき、ぜひ必要だと思う人だけを集めた方がよっぽどいい。
信頼をぶち壊しにするようなデザインのうちで、私が知るかぎり最悪のものはBoo.comが採用していたものだ。標準的な小さいチェックボックスがあるのだが、そこには小さな文字でこう書いてある。メールを送って欲しくない人はここをチェック。皆さんよくご存知の通り、この手の指示を注意深く読む人はいない。そこで、平均的ユーザは、ニュースレターを断ったつもりで、このボックスのチェックを外したままにしておく。にも関わらずメールが届き始めるので、ユーザは自分の要望が無視されたと思い、怒り心頭というわけだ。Booは、大っぴらにユーザビリティを無視したために倒産してしまったので、幸いにも、この「逆を行くデザイン」で傷つくユーザはそれほど増えずに済んだ。
登録するユーザの数を増やしたければ、単に「お値打ち品」の話をするだけでは不十分だ。そのかわりに、以下の点について、はっきりした情報を開示しよう。
- メーリングリストで送られてくるのは、どんな種類の情報や特価品なのか
- 発行間隔はどれくらいか（頻度がニーズに合っていれば、それだけ登録率は高まる – 市場セグメントに合わせて、発行間隔に違いのある出版物を何種類か用意しておくという手も一考に値する）
- 登録前に、ニュースレターの見本誌を閲覧する方法 – どんなものが送られてくるのかわかっていれば、それだけサインアップの確率は高くなる
Eコマースのチェックアウト段階では、できるかぎり迅速に取引を終了するというのがデザイン面でのゴールだ。ニュースレターについての情報なんかで、気をそらしてしまうのは避けたい。ニュースレターの話は、プロセス完了後に表示される確認ページまで待つのがベストだ。顧客からお金を取った後で、初めて他のモノの売り込みにかかれるわけだ。皮肉抜きにいうと、ウェブで顧客のロイヤリティを向上させたければ、単に注文を取って、製品を送るのが一番だ。ウェブでは、何を買うのも非常に難しいので、本当にみんなが買いたいと思うものを提供できるサイトなら、長期にわたってロイヤリティを獲得できるだろう。納品できるかどうかに比べれば、その他のマーケティング上のトリックなど、みな色あせて見える。
ディスカッショングループ
ディスカッショングループでは、ダイジェスト機能が使えるようにしておこう。そうすれば、ユーザは、1日分のメッセージをひとまとめにして受け取ることができる。新規ユーザはこの形式がデフォルトになるようにしておくべきだ。これはメッセージ量に圧倒されて、彼らがおじけづいてしまわないためにも必要なことだ。
リアルタイムでディスカッションをフォローしたいユーザのためには、各投稿を単独メッセージとして受け取れる機能を提供しておくといいだろう。
ディスカッショングループには、モデレータ（議長）を置くのが望ましい。リストにスパムが流れるのを防止し、最低限の基準を守らせてリストを望ましい形で運営するためだ。残念ながら、管理はかなり労力の要る仕事だ。モデレータ代行サービスというのは、なかなかいいビジネス案だ。賃金の安い国からモデレータを見つけてくるのだ。
スパムはやめよう
言うまでもないことだが、Eメールは、メーリングリストにオプトインしてきた人だけに送信すべきだ。だが、たとえ倫理的にメーリングリストを運営していても、時にはスパム呼ばわりされることも以下のようにあるだろう。
- メーリングリスト加入を希望する際に、Eメールアドレスを間違って入力してしまうユーザがよくいる。たまたまそれが有効なアドレスだったりすると、そのアドレスの持ち主が間違ってメーリングリストに登録されてしまう。これを避けるためには2つの手法が用いられるが、いずれもユーザビリティ上の問題を抱えている。
- 登録にウェブのフォームを使わない。そのかわり、mailtoリンクを使って、ユーザに、メーリングリストサービス宛てのEメールを送信させるようにする。問題は2つある。ひとつには、mailtoリンクは、クリックすれば新しいページが表示されるというウェブの基本的前提に反するものであること。違うアプリケーションが現れて、ユーザを驚かせ困惑させてしまう。ふたつめは、Eメールプログラムが挿入するfromアドレスが、必ずしもユーザがメールを受け取りたいと思うアドレスと一致するとは限らないということだ。
- ユーザに確認メッセージを送り、それに対して積極的な返信が返ってこない限りは登録を有効にしない。余計なステップは明らかに悩みの種だ。確認メッセージに書かれた指示を理解できないユーザもいるだろう。この文面は、十分ユーザビリティテストをしておくように。その通り。プレインテキストといえども、ユーザインターフェイスたりうるのだ。
- ユーザが転職して、古いEメールアドレスが新しい従業員に引き継がれた場合。この人は頼んだ覚えのないメールを受け取ることになる。
- 善意のユーザが、内部配布用のリストで登録してしまった場合。ある部署にいる人全員がメッセージを受け取れるようにとの配慮だが、当然ながら、その中には、頼んだわけでもないメールを送りつけられて閉口する人もいるはずだ。残念ながら、この問題には対処のしようがない。あるEメールアドレスが、個人ユーザのものなのか、配布用リストなのかは判断できないからだ。
最後の2つの問題に対して、私の納得できる解決策は、メッセージの送信先Eメールアドレスを各メッセージのフッタに入れておくというものだ。こうすれば、受取人は、なぜそのメールが自分のところに届いたかがわかるので、適切なアドレスで登録解除手続きができるようになる。
登録解除を簡単に
ユーザに対するスパムという苦情を避けるためにも、登録解除は簡単にできるようにし、そのやり方を、すべてのEメールメッセージのフッタに書いておくこと。
そんなことをしたら、ユーザに、リストをやめるように薦めるようなものじゃないか、という人もいる。だが、あなたのEメールに飽きてしまった人は、いずれにせよ、もはやたいした顧客ではなくなっている公算が高い。その人をうるさがらせれば、それだけ彼らの気持ちは離れていく。簡単にやめられるようにしておけば、いつか帰ってきてくれるかもしれない。
最も重要なのは、パーミッションマーケティングというコンセプトに少しでも共感するところがあるのなら、あなたがユーザの「パーミッション」を得ているといえるのは、ユーザが積極的にあなたの話を聞きたがる時に限られるということを知るべきだ。「いったんユーザに取り入って彼／彼女のEメールを教えてもらったら、あとは何をやろうと思いのまま」というのがパーミッションだなどと、勘違いはしないこと。
登録解除のデザインとしては好ましいのは、各ユーザごとに専用のEメールアドレスを作っておくというものだ。そのアドレス宛てに何かEメールが届けば、そのユーザはメーリングリストから除名される。このパーソナライズされた登録解除用Eメールを、リスト上に流れるすべてのメッセージの最後に書いておくといい。
ユーザが登録解除するときは、リストから除名されることを確認してもらうための承認メッセージを送るべきだ。このメッセージには、登録の方法も書いておこう。
- そのユーザは単に新しいアドレスに変更したいだけなのかもしれない。このプロセスで彼らを失わないようにしよう
- そのユーザは、大きな締切りの間近だとか、そういった理由によって、一時的に登録解除したいだけかもしれない
- そのユーザは、価値ある情報を受け取れなくなったことを後悔し、後ほど再度登録したいと思うかもしれない
フッタの登録情報
各メッセージのフッタには、登録方法を書いておこう。あなたのニュースレターが良いものなら、受取人の中で、他のユーザ宛てに転送してくれる人も多いだろう。こうして転送された人は、自分自身で登録する方法を知りたいはずだ。
ケーススタディ：Alertbox告知リスト
Alertboxの読者数は約20万人。そのうちで告知メーリングリストに登録している人は2万8000人だ。ほとんどの人がすでに膨大な数のEメールを受け取っており、受信箱に関してはたいへん防衛的になっている。よって、読者の86％は、新しい記事が出るとすぐにEメールで知らせてもらうよりも、自分のペースでコラムをチェックした方がいいと感じている。
数ヶ月前、私は、Alertbox告知リストのメーリングリストプロバイダを変更した。その結果は、ユーザビリティが登録数の成長に与える影響をみる上では、よいサンプルといえる。
- 古いリストサービスでは、週あたりの新規登録者数が218
- 新しいリストサービスでは、週あたりの新規登録者数が497
ユーザビリティを改善したことで登録数は128％も向上した。このように大きな効果が現れることは、特に驚くに値しない。ユーザビリティでウェブ機能の利用者が倍増するというのは、実にありふれた出来事だ。
古いリストサーバは特にだめだった。私がそれを利用していたのも、単に (a) 無料で (b) メンテナンスを他人に任せられるというだけの理由だった。それは昔流のバッチ処理コマンドモデルを採用していて、ユーザは、Eメールメッセージの本文にコマンドを正確に入力しなくてはならなかった。なお悪いことに、登録成功の確認メッセージは、alertbox-errorsというアドレスから送信されていた。やれやれ。ユーザが怖気づくのも無理はない。しかも、登録を有効にするには、ユーザはこのメッセージに対して返信しなくてはならない。subject行を編集し、承認の意思を示すのだ。ここで挫折した人は数多い。
現在、Alertbox告知リストはSparkLISTで運営されている。ハイエンドメーリングリストに特化したASPだ。私は彼らのサービスがとても気に入っている。リスト管理者（すなわち、私）のためのインターフェイスは、ユーザビリティ面でずいぶん改善の余地はある。だが、登録者用のインターフェイスは、よくできている。
反応時間
プロ向けのメーリングリストサービスを利用するメリットのひとつに、配信スピードがある。SparkLISTでは、私の2万8000のEメールを配信するのも、通常数分もあれば済む。以前のプロバイダでは、メーリングリスト全員に行き渡るまでに丸1日かかっていた。Eメールを希望したのは、一刻も早く知らせて欲しいからなのに、と苦情を言うユーザが多かったが、確かにもっともな言い分だ。
Eメールに要求される反応時間は、ウェブページに要求されるそれとかなり異なっている。何度も言ったように、基本的なヒューマンファクター要件を満足させるためには、ウェブページは10秒以内にダウンロードできなくてはいけない（そして、理想的ユーザビリティとしては1秒でありたい）。Eメールにはナビゲーションは関係ないし、ユーザはひとつひとつのメッセージをただ座って待っているわけでもない。だから、Eメールが届くまでの時間が数分であろうと、1時間であろうと、ほとんどの場合、ユーザビリティ上の問題になることはない。
1時間以上遅れるようになると、ユーザはディスカッションから疎外されたように感じる。あるいは、届いた頃には、そのニュースはもう古いと思われるかもしれない。ニュース主体のリストが増えるにつれ、速さはますます重要になるはずだ。
唯一の例外は、ユーザ行動の直接の結果として送信されるEメールだ。例えば、確認メッセージは1分以内に送信するべきだ。さもないと、ユーザはシステムが落ちているのではないかとか、何か自分が間違いをしでかしたのではないかと不安になってくる。
メーリングリストの未来
うまくいけば、メーリングリストは、それほど先ゆきが長くないだろう。長期的には、個人的なやり取りという性質を欠いたものは、すべてEメールから除外すべきだ。ユーザは、まったくタイプの異なった情報であふれかえる受信箱に、窒息しそうになっている。
現在メーリングリストとして提供されているサービスは、コミュニケーションコントロールパネルに表示するべきだ。これは、ユーザが興味を持っているあらゆる事象をモニターするもので、ホットなエリア、ニュースのあるエリアがハイライトになり、ユーザのコンピュータに搭載されたエージェントが情報源に優先順位をつけ、その重要度を面積の大小で表現する。確かにコミュニケーションコントロールパネルは議論の流れを壊し、単一のオブジェクトに分解してしまうだろう。だが、その活動をより役に立つ形で視覚化してくれるのだ。数百の議論の流れが受信箱に散乱しているよはましだろう。
補足情報
WilsonのWeb Marketing Info Centerには、Eメールニュースレターに関する長大な参考文献リストが用意されている。リンクや要約も完備している。
2000年8月20日