ウェブでヒトの心を掴むには。 - 青空を探す、旅の記録。

今までスタンドアロンのアプリケーションでやっていたことが、今や次々とウェブ上で出来るようになってきた。
ネットワーク上にないと意味をなさないアプリケーションと違って、そう言ったスタンドアロンアプリケーションの代替となるタイプのアプリケーションをウェブに乗せるのは、次のような利点があるのは既によく知られてるとおり。

ブラウザだけですぐ使える
- いちいちダウンロードしなくていい
アカウント情報さえ持ち歩けば、どのマシンからでも同じドキュメントを扱える

この中で、後者は今回は置いておく。前者のメリットについて考えてみよう。
アプリケーションをより広く使ってもらうためには、その使い始めのバリアが低ければ低いほどいい。いくら便利そうなものでも、深い、分かりづらいダウンロードリンクを叩いてダウンロードして解凍して、ランタイムをかき集めてきてインストールして、本体までやっと入ったと思ったら今度はシリアルナンバーをもらって……なんて手間がかかるようだと途中でイヤになるのがユーザ心理。このご時世、実行ファイルがそのまま置いてあるっていうのは非常にヤバイ匂いがぷんぷんするから、ダウンロード型だと最短コースはこんな感じでしょう。

ダウンロードリンクが見やすい位置に書いてあって、それを叩く
確認ダイアログでOKを押す
解凍する
アプリケーション本体をダブルクリック

これでも短いんだけど、アーカイバが入ってなかったら解凍しようとしたところでこけるしそもそも解凍って何よ？という場面もないわけじゃない。
この使い始めのステップ、ウェブアプリならもっと短くできる。一番簡単のだと、アプリケーション起動というか、利用画面へのリンクを書いておけばそれを叩くだけで即利用可能に出来る。
なんだけど、ここでよく考えて組まないとこの利点がスポイルされるので注意。
アプリケーションのタイプによってはユーザ登録が必要になるのが多い。サーバ側でドキュメントを蓄えるなら、それを誰が作ったのか記録しておかないとダメだったりする。この場合、良くある設計としてはまずサインアップしてもらって、その後ユーザページを生成する。だから、初回起動までのステップとしては次のようになる。

サインアップのリンクを叩く
ユーザ情報を入力してsubmitする
ユーザページが開かれるので、アプリケーションの利用を開始する

ここで、ユーザ情報のフォームが長ければ長いほど利用開始までのバリアが高くなる。詳細な個人情報なんか要らない、ってことならOpenIDなどの外部認証を使うべきで、そうすることによってバリアは小さくなるけどゼロにはならない。OpenID URLの入力は省けないので。カケラの樹も新規利用開始のフローはこの形で、ログインフォームからOpenIDを入力してログインボタンをクリックして、初めてエディタが使えるようになる。

この動線をもっと短くするには、こんな方法はどうだろうか。
まず、ゲストユーザに対しては「文書を作ってみる」リンクを見せておく。それを叩くとエディタが起動、文書の作成が行える状態になる。
この時点では誰が書いているのかシステムは理解していないので、仮の扱いで保存しておく。仮なのでブラウザを閉じたら消えるようにしておいてもいいし、同一セッション内に限って編集を継続できるようにしてもいい。この文書は、その後OpenIDが入力された段階で正式にユーザアカウントに保存する。
つまり、ゲスト扱いですぐに機能を使えるようにしておき、サインアップは事後に行う。これなら初回の利用開始までの動線がさらに短縮できる。
似たような手として、実際に動くけど保存は出来ないデモ画面を置いておく手法がある。カケラの樹もそうなってる。使い勝手を見てもらうためならそれでいいんじゃないか、という考え方もあるんだけど、ユーザからすると実は、このデモ画面はあまり使う気にならない。
理由はごく単純で、書き込んだ内容は保存されないから。入力内容が失われると分かっていたら、本格的に使い込んでみようとは思わないでしょう。せいぜいちょっと触って無意味な文字をたたたっと書き込んでみるくらいが関の山なので、そこで心を掴めればそれでいいがじっくりと試してはもらえない。
本格的に試してもらおうとするなら、後からサインアップすれば保存できる形の方がよいでしょう。

「使ってみなければわからない」のであれば、とにかくユーザが触ってみる気になるように、利用開始までの動線を短くするのはとても有効。
何か新しい物を作るときは、この「初回の動線の短縮」って考え方を心の片隅に置いておくと、いいんじゃないかな。