起業家に告ぐ、ユーザビリティテストを使え

SPONSORED LINK

Pocket

Top

ちと出遅れましたが、こちらに乗っかってみようかな、と。書き始めたらかなりの長文&文字ばっかりになってしまったのでお時間のあるときにどうぞ。

さて、スタートアップブームですね。

この界隈に知り合いが多いのでよく話したりもしますが、今のスタートアップシーンに圧倒的に足りていないのは「ユーザビリティテスト」ではないかな・・・と(個人的に)思っています。

サービスリリース前には絶っっ対に!やった方がいいです(ユーザビリティテストしていないサービスはリリースしちゃだめ、という法律つくってもいいぐらい・・・というのは言い過ぎか)。

もちろんやっているところもあるのですが、あまりにも「え、ユーザビリティテストやっていないの・・・?」と驚くことが多くなってきたので、ちょいとその手順なんかを説明してみますよ・・・(ユーザビリティテストをやっているところにとっては以下、当たり前の説明が続きますのでスルーでお願いいたします・・・)。

作業としてはそれほど難しいものではありません。

この一手間をかけるかかけないかでぐっとサービスの完成度が高まるので激しくおすすめします。またせっかくなのでドットインストールを例に出しながら説明してみますかね・・・。

■ ユーザビリティテスト前のドットインストール

まぁ、すごく恥ずかしいわけですが、ドットインストールのユーザビリティテスト前はこんな感じでした。

Old home

↑ いまどきっぽい機能満載でした。

画面を見るとわかりますが、「友達フォローみたいな機能もつけて、アクティビティフィードがあって、ポイント制でゲーミフィケーション、これからはソーシャルラーニングじゃね?」という感じでノリノリで開発していました。

そしてある程度出来たところで向かったのは市ヶ谷のbeBit社

ユーザビリティコンサルティングといえばbeBit社なので、リリース前にちょっとアドバイスもらおうかな、という軽いノリで遠藤社長とランチをすることに。

「わりとすごい機能をたくさん作っちゃったから驚かれちゃうかな〜」なんて思いながらサイトのプレゼンを始めたのですが・・・結果はひどいものでした。

「これ、どういう人が使うんですか?」
「なるほど、じゃ、そういう操作をしてサイトに来ますよね。でも、この画面じゃ何があるかわからないですよ」
「このページでユーザーに何をさせたいんですか?」
「ポイントって何ですか?」
「ホーム画面のアクティビティって何ですか?アクティビティってみんなが理解する言葉ですか?」
「学習させたいんですか?友達とつなげたいんですか?どこをクリックしてもらいたいのですか?何がしたいんですか?」

矢継ぎ早に質問されて気付いたのは「まったくユーザーのことを考えていなかった」ということでした。このサイトに来る人がどういう人で、どういうシチュエーションでアクセスしてくれて、また、そのページに来るまでにどういう心理が働いているのか、といったことがすっぽり抜けていたのです。

まったく恥ずかしい話なのですが、「いまどきのサービスだったらフォロー機能は当たり前」「モチベーション維持にはゲーミフィケーション」といった「なんとなく流行っているもの」に流されまくっていました。そうした機能の実装をすることですっかり充実した活動をしていると思い込んでいたのですが(実に4ヶ月もね!)、まったくの勘違いだったのです。

最後に遠藤社長に言われた言葉はいまでも心に強く残っています。

「成果を出すサイトを作りましょうよ。ぼんやりとしたサイトを作ってもしょうがないですよ。田口さんがプログラミング学習を広めたいなら、ちゃんと勉強してもらえるサイトにしましょうよ。要らない機能は削ってシャープに行きましょう、シャープに。」

■ 市ヶ谷のスタバにて

「ユーザー中心」という視点がごっそり抜けていたことに愕然として、僕と@fkojiはそのあと市ヶ谷のスタバでミーティングをします。そこで今あるサイトはとりあえずおいておいて、「どういう人に使ってもらいたいのか?」「どういうシナリオで使ってもらえるのか?」を議論しました。

すると今まで見えなかったことが霧が晴れるように見えてきました。今まで「なんとなく(かっこいいから)つけていた機能」がまったく要らない機能だとわかり、逆に「このシナリオだったらこの機能は絶対必要だよね」というものがクリアにわかるようになりました。

具体的にドットインストールの例で説明しましょう。

まずはターゲットの設定です。ドットインストールの場合は「IT業界にいる人で、プログラミングになんとなく興味がある非エンジニアの人(ディレクターさんとかデザイナーさんとか営業さんとか)」を想定することにしました。よりイメージしやすくするために「俺たちのまわりにいる人だと○○さんとかだよね」といった具体的な人名をあげるといいかと思います(そしてその人にユーザビリティテストしてもらった)。

そのあとは考えられるシナリオを羅列していきます。これは複数あるかと思いますが、5〜6個でいいと思います。たとえばドットインストールの場合は次のようなシナリオが考えられました。

「Aさんは検索エンジンで『プログラミング 学習』を検索してドットインストールにアクセス。すぐに学習したいのでどんなレッスンがあるかさっと把握したい。無料か有料かもすごく気にしている。」
「Bさんはツイッター経由で来た人。プログラミングで話題になっているサイトがあるらしい。昔からプログラミングに興味があったのでどんなものか見てみたい。話題になっているRailsとかツイッターボットとかが作れるかが知りたい」
「CさんはIDEA*IDEA経由で。いつも見ているブログの人がサービスを立ち上げたから見てみたい。プログラミングに挫折経験あり。今までにありがちだった学習サイトとどう違うのかをすぐに知りたい。」

こうしたシナリオが出来たらそれに優先順位をつけていきます。ドットインストールの場合、この時点でシナリオを絞ってシャープなサイトを作りたかったので最初は招待制にすることに決めました。

そうなるといろいろなことが見えてきます。招待制ということは、このサービスを知るのはツイッターやFacebook経由がほとんどのはず。そのときにどんなつぶやきとともに紹介されるのか、そしてURLをクリックしたときに見えるべき項目や文字は何か、といったことを精査していきます。

「トップページにアクセスするよね、そのときにサイトの特徴を知ってもらわないといけない。だから『3分動画』という文字は大きくあるべきだよ。そしてこのページでは登録してもらうのが目的だから他のこの機能とかは邪魔だよね・・・」

そうしたシナリオを詰めていくと、それぞれのページについて以下のことがはっきりしてきます。

  • そのページに来る人はどういう人か?(具体的であればあるほどいいです)
  • そのページにアクセスした時点でその人は何を考えているか?(何を期待しているか?)
  • そのページでユーザーに何をしてもらいたいか?
  • そのために何の文字が必要か?どの機能が必要か?

そして導き出された「必要な文字」「必要な機能」が要件となります。それをファーストビューに押し込む作業がいわゆる情報設計です。それらの設計を丹念にやっていくと、最初に作ったサイトとは似ても似つかないものが出来上がりました(泣)。

なお、開発者的には「テキストなんか最初はダミーでいれておいてリリース前に一気に書けばいいよね」と思いがちですが、日本語というか文字というか言い回しはとてつもなく重要な「機能要件」です。テキストを変えるだけでまったくクリックされなかったものがクリックされるようになったりしますので、他の機能と同等の重要度でもって真剣に考えるべきです。

それからシナリオを精査して徹底的にユーザー視点で見ていくと、実は使う人がいないんじゃないか?と思い至ることもよくあります(=使うようなシナリオを思い浮かばない)。

スマホで使える便利なアプリがあったとしても実際にそれを起動するシナリオがかなり苦しいものだったり、一回はノリで使うけど、次にログインする理由がまったく思い浮かばなかったり、なんて現実にここで気付くことになったりするので、一度はやってみることをおすすめします・・・。

さて、そうしたシナリオの精査が終わったら、実際のユーザビリティテストに移ります。

■ 恐怖(?)のユーザビリティテスト

ユーザビリティテストはとりあえず4〜5名やれば十分です。ターゲットになりそうな人にアポをとって以下の手順で進めていきます。

  • シナリオをなるべくその人の生活にそったカタチで、具体的に説明していきます(仕事中にツイッターでこういうつぶやきが出てきました。ちょっと時間が空いていたのでアクセスしてみることにしました、などなど)。
  • そこでサイトを見せて、実際に操作をしてもらいます。操作してもらう前に「もうここで使わない、となったら終わりにしていただいてかまいません」と言っておきます(やめどきがわからなくなる人もいるので)。
  • 操作をしてもらうときにとても大事なのは「思っていることをリアルタイムでしゃべってもらうこと」です。操作をしながら「うわ、暗いサイトだな」「ボタンは・・・ああここか」といった具合に口に出してもらいます。これは人によっては不得意なこともあるので、その場合は「思っていることをしゃべってもらえますか?」と促す必要があります。
  • なお、ユーザーが操作中は観察するのに徹し、変に誘導しないように気をつけましょう。「ここはどうすればいいですか?」と聞いてくるユーザーもいますが「いつも家で操作しているようにやってみてください」と言うにとどめておきましょう。
  • ユーザーが操作するのを見ながら、想定していたのと違う操作をした場合にメモしておきます。また操作がちょっと止まって「あ、なにか悩んでいるな」と感じたところがあればそれもメモしておきます。
  • 操作がすべて終わったらメモしておいた「こちらの想定とは違う操作」「ちょっと操作がとまったところ」について「そのとき何を感じていましたか?」と質問します。

これを数名繰り返すことで、びっくりするぐらい有益な情報が得られます。せっかく作った機能やらがまったく使われなくて涙目になったりしますが(いや、ほんとに・・・)、「実際に使われるのは何か?」がわかるようになります。

なお、途中でアドバイスを始めるユーザーもいますが、そうしたものは(ほとんどの場合)スルーしましょう。「こういう機能があるといいなぁ」といっているユーザーはアドバイザー視点であって、ユーザー視点ではありません。こういう機能があるといいなぁ、と言っている人に限って実際に使わなかったりしますよね・・・。

それからもし可能だったらユーザビリティテストには実際にコードを書いている人に同行してもらうといいかと思います。

もしユーザビリティテストを僕一人がやって、実際にほとんどのコードを書いてくれている@fkojiに来てもらっていなかったら、そのあとで「やっぱりこの機能削ってくれる?」と言うのはかなり苦しかったはずです(しかもその機能をリクエストしたのは僕だったという・・・)。ユーザーの行動を目の当たりにすることにより、「あ、やっぱり削りますか・・・これ・・・」と二人で納得することが出来たのは開発進行上、とても大事なことでした。

■ 改善、改善、改善

ユーザビリティテストをするとさまざまな改善点が見えてくるのでガシガシと改善していきます。ドットインストールだとユーザビリティテストで次のような声を拾うことができました。

「プログラミングを友達と学習するって・・・ちょっと意味がわからない。できれば一人で勉強したい。」
「フォローするとどんな良いことがあるの?」
「ホーム画面で必要なのは今まで何を勉強して次に何を勉強したらいいか教えてくれることじゃない?」
「レッスン一覧で言語別に分けられていても、そもそもそれらの意味がわからない。」

こうした声をもとに要らない機能はけずり、わかりにくいところはテキストを直し、クリックされないボタンには説明を加えるなどの作業をしていきます。

結果として「動画を見てもらって、どこまで何を見たかが管理できるだけのサイト」になりましたが、変な機能をつけてユーザーを混乱させるよりはすっきりと「シャープなサイト」が出来上がったと思っています(まだまだ改善すべき点がありますが)。

先日の一般公開に際しても、シナリオをいくつか設定して、実際にユーザビリティテストしてもらうことで、直前にいくつかの効果的な改善を行うことができました。最初は面倒だったり、実際に目の前でユーザーの声を聞くのは怖かったりしますが、「使ってもらえるサイト」を作るためには必須かと思いますよ・・・。

■ 最後に

スタートアップは同時進行的にいろいろなことをしなくてはいけないので当然のことながらファイナンスやPRなんかも軽んじてはいけないのですが、「成果を出すサイト」を作るにはやはりユーザー中心の視点を貫くのが大事かな、と個人的に思います。

ユーザーが欲しいモノを見つけるには、彼ら(彼女ら)の意見を聞くのではなくて、実際の行動を見ることが一番の近道です。ユーザビリティテストはどのスタートアップにとっても必ずやるべき作業ではないかな、と思います。

なお、「ユーザー中心の設計」については、beBit社の次の本がおすすめです(ステマじゃないよ!)。

4797333529

» ユーザ中心ウェブサイト戦略 仮説検証アプローチによるユーザビリティサイエンスの実践

あと、beBitの遠藤社長いわく、こちらもおすすめとのこと(IDEOの行動観察手法についての本です)。

415208426X

» 発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法

ドットインストールがうまくいっているのか?という点についてはまだ何も言えませんが、ユーザビリティテスト実施の一例として参考にしていただければと思います。

ツイッターもやっています!

SPONSORED LINK

  • Trackback are closed
  • Comments (2)
    • Keijiroh
    • January 10th, 2012

    さらに、このユーザビリティテストを繰り返し行う事が大切だと考えます。タンジブルな製品と違って、ウェブサイトは繰り返しテストとパブリッシュを簡単に行えるので、何度も何度も素早くイイデザインをすると、もっといいと思います。

    • taguchi
    • January 31st, 2012

    テストコメント