[&] 9 Principles of Lean UX / Janice Fraser

9 Principles of Lean UX / Janice Fraser
シリコンバレー流UXアプローチ
----------------------

Ux for lean startups london

View more presentations from Janice Fraser

Tokyo 1 day (日本語)

View more presentations from Janice Fraser

デザインを通して、スタートアップを良くしていこう。

Lean StartUp という概念を聞いたことある人は？
2008年頃。投資家のアドバイザーをしていて、
スタートアップを要請するプログラムを作ってくれと言われた。
Max Mama という 19歳のスタンフォードの学生と会って、
Lean Start Up というのはヤバいよ！と伝えて。
本当に Design Thinking と共通の考えで素晴らしいもの。

Janice Fraser
@clevergirl

1. Design +Prod . Mg. + development = 1 product team

2. Externalize!

3. FLOW: think/make/check

4. Repeatable and routinized

5. Solve the right problem

6. Goal -driven and outcome-focused

7. Generate many options

8. Decide quickly and hold decisions lightly

9. Recognize hypotheses & validate them

10. Reaserch with users is the best source of information (&inspiration)

オライリーで本を書くことになっている。
9つのプリンシパル。

■ 1. Design +Prod . Mg. + development = 1 product team

初期段階のスタートアップのプロダクトマネジメントチームを作るべきか？

デザイナーとプロダクトマネージャーと開発者が一緒になって働く。
アジャイル開発は Lean Startup においても大切な要素。
ひとつの場所に集まって皆で開発するのが重要。

●ウォータフォール式

開発チームが居るところと、マーケティングの人の間に
「プロダクトオーナー（マネージャ）」がいる。
この人は Un Happy な人。
プロダクトマネージャーはみんなのニーズを把握しなければいけない。
ステークフォルダーは何を提供すべきなのか？
開発チームに何を作らせるのか？
悲惨なプロダクトマネジメントは、「ウォーターフォール」式。
長い時間かかって、仕様を作って、開発する。
ユーザーからのフィードバックも開発側からのフィードバックも無しに作る
悲惨な形。

●これからスタートアップをやる人はこういう形式で

デザイナーとプロダクトマネージャーと開発者がひとつのチームとして働く。
この体制というのは、Tim McCoy が名付けたのだが、Product Stewardship という。
それぞれが責任を持って開発を行う。
UXの人は、ユーザーと共感することが役割。その人は作ったものを
ユーザーにプロダクトを見せたり、ユーザのニーズをうまく把握したり、
ニーズや課題に共感し、開発者に伝えるのが仕事。

今まではプロダクトマネジャーの要望を開発すれば良かったが、
本来は開発者がどういう技術を使ってどういうモノを作るのか？
どう課題を解決するのか。開発者がイノベーションを起こすべき。
天井を高くする役割がある（J.D. サリンジャー）

Bis. の人は、難しい判断をする人。
ユーザの要求を聞きすぎるとビジネスにとって良くないという場合は、
Bis. の人が判断する。
作らなければいけないものが 6つ以上あった時、優先順位をつけるのが役目。

この体制はバランスを追求した体制。
組織が大きくなっていくと、１つのチームにするのは難しいので、
LeadUX, LeadDev, LeadBis それぞれの代表が１つのチームで運用する。
ひとつのチームでフラットで、誰が偉いとか無く、フラットな状況。



■ 2. Externalize !

実物化して外にだす。
いろんなアイデアがあって、いろんなスケッチを書いたりするのがデザイナーだが、
シリコンバレーのUIデザイナーは
すぐにスケッチして、壁に張って、すぐに共有する。
コミュニケーションが活発になってより良いものが産まれる。

デベロッパーがするべきことは一緒で、
開発チームには大きなディスプレイがあって、開発の進行状況が
詳しく表示されて、状況がわかるようになっている。
おたがいどこが課題なのかがわかって、
よりコラボレーションが産まれる。

■ 3. FLOW: think/make/check


The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

「FLOW: 流れ」流れを作ることが重要。
エリックリース（Eric Ries）の本が出版された。日本でも4月くらいに翻訳が出る予定。
作って、計って、学ぶ　という流れが重要。
特にスタートアップで錯覚するのは、機能をいっぱいつくったから進んでいると錯覚する。
たくさんコードを書いたということで進んでいると錯覚する。
コードの行数ではなく、どれだけユーザのことを学んだかということが重要。
ものを作って計って学ぶということを繰り返してサービスを作っていくのが需要。

デザイナーも同じサイクルを作っていて、think/make/check を考えていて、とても合っている。
このサイクルをいかに何回も回せるのか？
学ぶことをどれだけできるのかが、会社の進展になる。
いろんなアイデアを持っているが、
アイデアが必要なのかどうかを証明して、
もっと良くして、証明して、もっと良くして　というサイクルを繰り返す。
アイデアを検証した後に、作りにはいる。

■ 4. Repeatable and routinized

繰り返し繰り返しできるルーチンを作るのが重要。
デザイナーのアイデアがあって、デベロッパーの状況が把握できて、
作って学ぶというフローができていて、
その次は、会社としてルーチンを作るのが重要。
今日何をするのか？ではなく、
課題を見つけたら、課題を検証して、作って計るという流れるルーチンを
作るのが重要。それでチームの効率があがっていく。
ルーチンを作る目的は、会社が大きくなってくると、新しい人が入ってくる。
決まりの無い方法を教えるのは難しいが、新しい人をすぐに会社のフローに
入ってもらえる。日本の企業はうまいはず。
シリコンバレーはプロセスを作れと言っているが、日本では自然にルーチンができるだろう。

■ 5. Solve the right problem

正しい課題を解決すること。
正しいことに集中して、正しい問題を解決すること。
ユーザビリティーテストを通して、サービスを使っていて困っていることや
課題意識を持っていることに集中して解決策を提供する。
今まではプロダクトロードマップみたいのがあって、それに向かって作業しているのだが、
作って試して学ぶことによって新しい課題が産まれてくる。
そのサイクルを繰り返してどんどん新しい課題を解決していくサイクルを作るのが大切。

■ 6. Goal -driven and outcome-focused

最もコードをリリースする時に重要なのは、目標をたてることと、
数字がとれる状況にすること。
ユーザーの課題を解決するための機能を追加し、
その追加した機能をちゃんと検証するための方法を入れておく。
新機能を使う人が 60%と計画をたてて、もし 60%の人が使わなかったら、
違うアプローチで課題を解決するようにする。
これが限られたリソースで正しい解決をする方法。

■7. Generate many options

サイクルをまわしている時に、課題をどう解決するかという
ブレインストーミングのフェーズがある。
課題を解決するオプションをたくさん生み出すのが大切。
プロダクトマネージャと開発者と UX担当がそれぞれ 10分間でトータル 18のアイデアを出す。
開発者の視点でどう解決するのかを技術の視点で 6つのアイデアを出す。
UXの視点で 6つ出す。ビジネスの視点で6つだす。
全体を見ると、ものすごい良い解決策が出てきたりする。

■8. Decide quickly and hold decisions lightly

3人で解決策を出すのが重要。
3人で議論して1つを決める。決めたあと意識するのは「失敗しても良い」
一番重要なのはユーザーについて学ぶことが需要。
試してうまくいかなければ、次のことを試せば良い。
ユーザーのことを学ぶのが重要。このプロセスに間違いは無い。
間違ったアイデアを選択しても大丈夫。

■9. Recognize hypotheses & validate them

Lean Startup で重要なプロセスは色々試すこと。
アイデアを試し、アイデアがうまくいっているのか検証し、
ユーザーのことを学び、次につなげる。
どの過程を検証するのかが一番難しくてスキルが必要。
このプロセスを繰り返すことによって、どのアイデアを試すべきかが分かってくる。

■10. Reaserch with users is the best source of information (&inspiration)

ものを検証する時に真っ先に行くべきのはお客さん。
Analytics を使うのも良いが、実際に話して、実際にユーザーが使うところを見て、
うまくいっているのかを検証するのが重要。
これは新しいインスピレーションを得ることができる。
ユーザーとの距離を縮めることが重要。

Q: 誰がユーザーなのか？誰が課題を持っているのかのリサーチの例をいくつか教えてください。
　最初のアーリーアダプターはどうみつければ良いのか？
A: 人のバックグラウンドを考えて、目標をたてる。2週間以内に50人と会話するとか。。。
　そうするとどのユーザーがアーリアダプターになってくれるのかが分かる。
　UXの本はたくさんでているが、ありがちなのは、カスタマーとの会話の仕方が載っている。
　その中には、自分が何のプロダクトを作っているのかを知らせてはいけない。
　最初にストーリーを語らせるのが重要。課題についてたくさん語ってもらうのが重要。
　気分や、思っていること、次なにしたいのか？を聞く。
　解決しようという課題を知ることが重要。

Q: 作って／計って／学ぶ　のサイクルをまわして、微妙な解決が見えている時はどうすれば良いのか？
A: ABテストをするといい。微妙な時は同時進行でテストしてどちらの方が良いのか検証した方が良い。

Q: サイクルの中でどうしたらチェックできるのか？
A: ユーザテストや、Google Analytics とかあるが、本当にうまくいったかどうか判断するのは難しい。
　10週間ぐらいアドバイザーしていた会社、ホームページのコンバージョン率をあげたいという課題。
　いろいろ試したけどあがらなかった。もともとやっていることが違うのか？　課題が違うのか？
　いろいろメトリックスをみて判断が難しいのはユーザビリティテストをするのが良く、
　Steve Krug "Rocket Surgery Made Easy" がおすすめ。

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems (Voices That Matter)

ウェブユーザビリティの法則 改訂第2版

Q: 良いデザイナーとプログラマーにデザイナーに出会うこつ
A: meetup, meetup, meetup, meetup, meetup!
　今（大学生のうちに）たくさん友達を作っておくのがおすすめ。
　Facebook も PayPal もそう。社会人になっていしまうと真に打ち解けるのは難しい。

おすすめ書籍リスト
http://luxr.co/lean-ux/booklist/