[&] Lean UX - ustwo

Lean UX 濱田雅史 (ustwo)
http://connpass.com/event/3964/

@Surface & Architecture (http://www.surface-arch.com/

今週、スウェーデンから日本に来ているのですが、
はしゃぎすぎた結果、のどがつぶれています（笑

会場の参加者は、
デザインやっている人、半分くらい。
デベロッパーが半分くらい。

UXって何？というのをお話しさせて頂きたいと思います。
岡村さんに紹介いただきましたが、usTwo (http://ustwo.com/) から来ました。
２人のファウンダーが立ち上げた会社なので us Two ですが、
今は 100人、150人くらいいます。
デザイナーがありがちな夢を描くだけでなく、DO（実行）する部分もやらなければいけない
というのがモットーです。

ロンドンで２人が立ち上げ、大きくなって、2007年に JOin して、
2008年にスウェーデンにオフィスをかまえました。
ソニーエリクソンの関係です。ルンドという都市にオフィスがあって
一緒に仕事をするためにオフィスを立ち上げました。
2012年 NY に立ち上げました。
今は、スウェーデンに居ますが、
楽しい雰囲気の場所で、楽しい人が楽しい仕事をするのがモットーで、
それで良い仕事ができるという自身があります。

我々どういう仕事をしているかというと、
1/4 がサービスデザイン、UXデザイン。
プロダクトによっては自社でアプリの開発もやるので、
UX Designer が 39人
デベロッパーが 46人
Visual Designer が 39人
いろいろな　 SONY, SAMSUNG, BBC, H&M, Google などと仕事しています。

2007年、まではソニーエリクソンで仕事していて、
辞めた後に、絵画の勉強をして、us Two
MASA AND PEACE というサービスを立ち上げています。
こっそり立ち上げて、今、社長です（笑）社員 2人ですけど。

LEAN というトヨタの方式とか、無駄を無くそうというのは解るのですが、
工場の中で無駄を省こう、無くそうというものですが、
実際はバリューが無いと意味が無い。
お客さんが喜んでもらえるものを作らないと意味が無い。

UX とは何なの？
人によって理解が違ったりして難しいところがありますが、
定義としては、ユーザーエクスペリエンス。
プロダクトやサービスを使うことによって、得られる感情や、
行動、考え方の変化など、
ポジティブな変化や、そういったものを UXとしてとらえる。
使う前や、使う後、プロダクトのライフサイクルに対して
インパクトがあり、ユーザーに対しての理解を深めないといけない。

無駄を無くして、よりよいものをより効
率よく作ろう
Lean UX = Design thinking + Agile + Lean Startup" (Jeff Gothelf)

Lean UX: Building a shared understanding to get out of the deliverables business from Jeff Gothelf

個人的にはちょっと違うのではないかと思っていて、
Lean UX はLean Startup が UX デザイナーにうまく翻訳され、
細かいところまで落とし込まれたものだと考えている。

Jeff の2日くらいのワークショップをベースに紹介します。
A CASE STUDY
とりあえず、一つ銅がをお見せしたいと思います。

これは、NYのデパートのデザインチームがやった
実験的なプロジェクトで、何をやったかというと、
小さなチームを作り、ビジュアルデザイナー、インタラクションデザイナー
マネージャー、企画など、彼らが実際にデパートに行って、
その場にお客様の様子を見ながらポストイットで貼っていく。
そこで仕事をし始める。



お客様が普通に買い物しているところを観察し、
発見した内容をまとめ、その場でデザイナーがワイヤーフレームを書いたり、
実際にそこで、そのソリューションが良い悪いはディスカッションするのではなく、
どの場でデベロッパーがすぐ実装し、すぐに動くものができ、
動くものが出来たら、メガネ屋さんのところに持っていって、
お客さんに使ってもらい、フィードバックをもらって、
その状況に飛び込んでフィードバックをもらった上で、
プロトタイプをアップデートして、その後
持ち帰って検討する。
それが Lean UXのどういう部分なのかというのをお話しできればと思います。

Are we building the right thing?
そもそも、私たちは正しいものを作っているのか？

いままでは、作れるのか？というのが問いであったが、
何が作れるか？ではなく、何を作る必要があるのか？
というのが Lean UX の考え。
解りやすく言うと、
人々が欲しく無いものを作っても意味がない。
無駄な時間をかけても意味がない。

プロダクトやサービスがうまくいかなかったとか、
半年一年かけて作っても、誰が使っているのかわからなかったり。
そう考えると Lean UXの考えが当てはまるのでは無いかと。

入門編なので、少しだけ。

1. Hypotheses
2. Minimal Viable Product
3. Validated learning

●仮説 Hypotheses

プロジェクトを始めるときは何かしらやりたいことがあって、
企画だったり、エンジニアだったりがアイデアを持ってやろうとうことですが、
スタート地点はアイデアですが、
やりたいことをやろうというわけではなく、
それをやる必要があるのか？期待する結果が得られるのか？という
質問をする必要がある。

まず、キックオフミーティングしようと考えるが、
ミーティング終わった時に、往々としてありうるのが、
個人個人で考え方が違い、誤解があり、
三人いたら、三者三様になり、
違うものをイメージしたままプロジェクトが始まってしまう。
一ヶ月二ヶ月たった後に、誤解が生じた上に、
自分たちが誤解していたことに初めて気づく。
無駄なので、そういうことが無いようにしよう。

Step 1. Build a small & cross functional team
小さな違う役割を果たすメンバーをバランスよく含んだチームを作る
違う観点で物事を見たり、知識がかたよっていないので、
見落とすことなく、進めることができる。

Step 2. Externalise assumptions and expectations
想定と、プロジェクトに期待するものを
正しく理解する必要がある。
乱暴に言うと、我々が思っている全てのことは「想定」でしかない。
ユーザーがこう思っていて... と考えるが、
そのユーザーがターゲットでなかったり、する場合もある。
見える形でシェアして、仮説を確かめていく。

- Desired outcomes
- Users
- Features
- Success criteria
- etc, etc

顧客満足度をパーセントにしたいとか、
サインナップのコンバージョンレートをいくつにしたいとか。
プロダクトをもっと売りたいという人もいれば、
顧客満足度をあげたいという人もいる。
どれが一番大事で、どういう順番でやっていくのか？
考える必要があり、
大事なところにフォーカスした製品が作れる。
自問する必要がある。

状況に応じて、想定外の人が使い始めるかもしれないし、
違う使い方をするかもしれないし、
違う機能でより幸せになるかもしれないし、
誰がどこで使うのかまで考えないと。
あれもできるし、これもできるしと考えると、
直感で考えても意味が無いので、
ユーザーがこういう風にこういう目的で使っているので...
と、彼らの生活パターン、使い方、問題、
隠れたニーズを理解する必要がある。

仕様書がふってきた場合、誤解も生じますから、
機能の確認の必要のうえ、プライオリティをシェアした上で
大事なものを考えたうえで次のステップに進む。
何をもって成功と見なすのかも大事。
技術的制限とか、いろんなことがありますが....
自分たちの頭の中にあることをシェアして共通理解を進める。

3. Assemble hypotheses
いろんな情報がバラバラになっているとテストがしづらいので、
仮説を作ろう。

We beleve that
- [ doing this feature ]
- for [ users ]
- will achieve [ this outcome ].

We'll know this is true when we see
- [ success criteria ] .

このアプローチに沿って考えると、
ペルソナに沿って考えると、
Amazon のように 1クリック購買できるとすると？....
ユーザーの何％が1クリック購買するのか仮説をたて、
仮説が証明されるかどうか。

スタートアップだと、いろいろな仮説があって、
Plannning Lean , ビジネスモデルキャンバスを Lean 用に作ったもの。

[写真]

Q. 仮説をたてるのは解るが、革新的なものは生まれないのでは？
A. 革新的なものこそ、仮説とテストが意味がある。
例えば、Google Glass のプロトタイプを作って試してもらえば、
目が疲れるという意見があれば、そのプロダクトそのものを辞めるのではなく、
目が疲れない方法を色々考えることができる。

●Minimum Viable Products

いろいろな人が集まって、自分たちの想定を吐き出した上で、
仮定をたて、次のステップに進む。
ミーティングルームで話すのではなく、まずは作ってみる。
作ってみないと解らない。実際に作るところ。

MVP: The smallest thing you can make
to test your hypothesis.
仮説を試すために最低限の機能は何なのか？

今までの考え方は、
時間がたてばたつほど、リスクが高くなる。
例えば、スタートアップとして、40インチの持ち運べるタブレットを作るとすると、
ディスカッションだけして、話しをしていけばいくほど、時間も経ち、
時間が費やした分だけ、失敗する可能性もある。
時間をかけても、商品がリリースされていないばあい、
失敗したら、費やした時間が無駄になってしまう。

Lean の考えからすると、仮説をたてるのに時間をかけ、
実際にモノを作ってみて、改善のための学習をする。
失敗するリスクが減る。一週間考えたものがダメになって
次のステップに進む。リスクが少なく次のステップに進む。
新しいものを作るほど、リスクを少なくして薦められる。

一週間で作りきれればいいのですが、
作りだしてしまうと、何ヶ月もかかるものを
Kickstarter でとりあえずビデオを作って、
説明した上で、公開すると、
ユーザーが見た時に、おもしろいと思うと、
お金を出してくれる人が増える。
彼らがお金を出したくなるほどのコンセプトが
出せるのであれば、その良さが確認できる。

ビジョンを見せた時に誰もお金を払ってくれないのであれば、
何かが違うことがわかる。
一つの例です。
じゃっかん落とし穴的なのは、周りの人に聞く場合、
どうしてもポジティブなアイデアばかりが帰ってくる。
フェアなジャッジがしにくいので、
できるだけターゲットとするユーザーにきく、
金を出すといってくれれば、成功する。
使ってみないとわからないという場合もあるときは、
動くプロトタイプを作ってしまう。

いままでであったら、社内でプロジェクトを告知して、
デザイナーも入ってきて、かっこいいアプリケーションを
二ヶ月三ヶ月かけたけれども、誰も使ってもらえなければ
完全に無断になる。
けれども多少見た目がきたなくても、一〜二週間で作ってしまえば、
革新をもった上で次のステップに進める。
リスクを回避しながら前進することができる。

●確認した学習 Validated Learning
作っただけではしょうがない。作ったものを評価してそこから学ぼう。
どうやってやるの？
Validate Qualitatively 質的な評価。
具体的には、usTwo が作った Honk というツール

https://play.google.com/store/apps/details?id=com.ustwo.honk&hl=ja

まずは外に持っていく。外に居る人に使ってもらう。
建物を出て、お客さんに合って、フィードバックをもらう。
コンテキスト、シチュエーションが大きく影響する。

なんでいいのか、なんで悪いのを学ぶ。
想定をテストすることができる。
100人200人というテストはできないので、
量的な評価。
Rando というアプリケーションを作りました。
写真をシェアするアプリケーションなのですが、
COHORT Analysis というのがあり、
サインナップした人が、その日から何枚シェアしているのか？
良くみると、二週間くらいで、限りなくゼロになったしている。
http://rando.ustwo.se/

全体で見ると利用数がうなぎ上りに見えるが、
ほとんどのユーザーは二週間以内に使うのを辞めてしまっている。
長期的に使ってくれないと、ビジネスとしては難しい。
エンゲージメントを改善していかないと難しいことが解る。

Pivot or Persevere?
仮説が正しかったか？正しかったら次のフェーズに進めばいいし、
正しくなかったら、別の仮説に作り替えて、次に進む。

仮説／MVP／確認された学習