ユーザの声を聞きながらプロダクトを開発する時、2段階のフィードバックがあると最近思うようになった。一つ目はユーザにとって何が一番重要かどうかのフィードバックで、二つ目がユーザビリティのフィードバック。

この二つは重なる部分もあるのだけど、最近は頭の中でしっかり分けて考えるようになってきた。製品を作っていると、無数に実装したい機能があって、どれを優先するかは常にぐるぐる頭の中で回っていると思う。

そして、ユーザのフィードバックを聞いたり、観察したりしていると、ユーザごとに最適な優先順位が違うので一見混乱しがちであります。たくさんある選択肢の中で、どの機能の実装を優先させるかのタイミングを何度も自問自答していると、頭の中で整理されてきたのでその事について書いてみる。

始めに、ユーザにとって一番重要な部分はどこかのフィードバック。これが最も大切で、使う人にとって重要な問題を解決してないと、いくらユーザビリティを高めて、初心者がつまずかない体験を頑張って洗練させても使われない。

例えば、僕はスワヒリ語を習おうと思ってないので、素晴らしいユーザビリティと、最初の導入が神懸かり的に分かりやすいスワヒリ語学習アプリがあっても使わないはずだ。逆に、電車の乗換を調べたりする必要性はよくあるので、UIがしょぼい乗換案内でも必要だからよく使う。もっといい乗換案内ができたら速攻で落とすと思う。

というわけで、初期段階は一番最初から興味を持ってくれて、多少の細かい部分は目をつぶって使い続けてくれるユーザを探して、その人を優先して作るのが間違いないと思われる。

というのも、細かいユーザビリティを高めるのも、バグを潰すのも、ユーザを拡大させるための拡張機能やマーケティング、どれも時間がかかる。今使い続けてくれる人にとって何が重要な部分かを何度も考えまくって、優先順位を考えるのが大事だと自分に言い聞かせるように毎日お経を唱えています。自分が最初のペルソナなのでかなり有利だけど。

Lisgoの場合だと、iPodのような基本的操作性であったり、テキストのハイライトやオートスクロールだったり、オフライン機能。また、イライラするバグとか、こういうもの。

逆に、ユーザの層を拡大させようとすると、読み上げ音声の質、記事をどう取ってくるか、多言語に対応するとか。現時点で絶賛して使ってくれている少数の方々以外は、こういう部分がクリアされないと使わないだろう。

500StartupsのDaveが言うように、一般ユーザに広める質に達してない段階でバイラルマーケとか、拡大を狙うなというのは理にかなっている。「お前の製品はまだクソなんだから、クソなのに気にかけてくれるユーザに集中しろ。クソな段階で広めるな。」と、こんな事を言っていた気がする。

クソな段階で拡大を狙い、初期ユーザにどうでもいい機能つけて使いにくくなり、一時的な獲得できた新規ユーザも使ってすぐ離れられるという悲惨な事態だけは避けたい。もちろん、ずっと特定のユーザにこだわる必要はないのだけど。

またまた具体的にLisgoの例で話すと、だいたい4段階に分かれている。1段階目が最初のユーザにとって重要な基本機能。2段階目が記事の取得方法。3段階目が多言語対応。4段階目が能動的に記事なんて読まない層でも開いてすぐ使えるような初期体験とか。(FlipboardやPulseの最初のカテゴリみたいな）。

その先は高難度の根本的な音質向上やテキスト表現向上など。全体に関わって重要だけど、難度が高いから後回しにしているもの。ちなみに、Lisgoは第一段階がだいぶ進んできたので、もうすぐ第二段階に進めそう。グーグルリーダー対応かTwitterのお気に入りした記事リンクを取り込むようにする予定。

ちょっと前に気づいた事は、バグ修正でも優先度をつけたほうがいいという事だった。これは自分でも、バグ修正は優先度高いんだという錯覚に陥ってた。なぜならバグだから。

でも、37Signalsの記事で、取るに足らないものだけど修正がすぐにできないバグなら後回しにしてもよいと書いていて、知らず知らずのうちに陥っていた常識に気づいた。実は無意識に致命的じゃないバグは後回しにしてたけど、バグだから早く治さないとなという意識は常にあったからだ。

ここまで書いててすっかり忘れていたけど、2つ目のユーザビリティのフィードバックについて書きたい。これについては、自分の製品のドンピシャのターゲットの人が使うのを観察させてもらうのが理想ではある。でも、そこまで厳密に絞らなくても、ユーザビリティに関しては周りの人に普通にさわってもらうだけでも学べる事がいっぱいある。

自分の場合は、友達に自分のアプリを触ってみてもらい、出来る限り説明をしないで横から観察させてもらう。そうすると、どこで詰まるか、自分の予想した導線を最初に進んでいるか、それぞれの機能に気づいてくれるかなどがよくわかる。

ちょっと前までは初めて使ってもらう人を横から見れる絶好のチャンスがあっても、わざわざ操作方法を説明してしまってた。なんというもったいない事をしていたのだろうか。一度でも説明してしまうと、初めてのユーザがどこで詰まるかという貴重な情報が分かるチャンスを逃してしまう。アホだった。

あと、なかなか難しいけれど、出来る限りユーザが操作している時に何を考えているかを話してもらえると参考になる。外国人で開発者の友達にやってもらった時なんかは、あちらも理解があって詳しく話してもらいながら観察させてもらったので、自分でもびっくりするほどの発見があった。

やはり、フィードバックを得るというのは、自分の無知に気づくための過程だと思う。ダニエル・カーネマンも、人間は自分の無知な部分にたいして無知であると言ってるし。

さて、この時に気をつけているのは、ユーザビリティ向上のアップグレードも優先度を常に考えるということ。つまり、先ほど話したステップの段階で、自分の製品のステージがどの段階にいるかを考えて、初心者に優しい仕掛け作りに費やす時間を考えている。

製品がまだアーリーアダプター向けに基本機能を洗練させている段階なら、多少の説明不足の部分は目をつぶって、一番重要な部分に時間をかけたほうが合理的だ。もちろん、どんな人が使っても使いにくいユーザビリティは常に気をつけないといけないけど、最初のユーザー体験で絶対につまずかないような細かい手順の説明とかは後回しでいい。

つまり、携帯電話がまだ珍しかった時代だったとしたら、その時点で高齢者でも使えるような携帯電話を目指して、最初のユーザーエキスペリエンス向上に時間をかけるのは得策ではないということであります。

その時々のターゲットユーザによって最適なユーザビリティも変化するというのは、ゼロベースの石橋さんに去年説明してもらった。これは自分にとって凄く大きなアドバイスだった。それまでは、とにかく誰にでも分かりやすいのが正義だと盲目的に思ってたからだ。

プロダクトを作ってると、ユーザビリティと機能のトレードオフは常に考えないといけない。機能としては絶対あったほうが使いやすいけど、初めてのユーザには分かりにくいというような時、捨てるか残すかはその時のターゲットユーザの範囲で決めるしかない。

iPhoneのReederというアプリは、非常に競争率が高いRSSリーダアプリの中で一番人気だと思うけど、初心者への配慮はほとんどないに等しい。自分も最初戸惑った。もうちょい使い方が分かりやすくなる仕掛けを入れた方がいいのではないかとも思う。

でも、使い方さえわかればこれほどいいアプリはない。RSSリーダ使うようなITリレラシ高い人達には、Flipboardのような万人向けのものより、機能面で尖らせたアプリのほうが向いている。

簡単にまとめると、その人にとって重要な価値をもたらすかと、使いやすいかの二つのフィードバック。この二つを常に整理していると軸がぶれないのではないかと思いました。顧客開発とユーザビリティのフィードバックとも言い換えられるけど、知らず知らずのうちにごっちゃになりやすいと思う。

※参考リンク
Paul Buchheit at Startup School 08
Janice Fraser CEO LUXr Advice to future entrepreneurs