ON THE TRIP流　UX的負債の避け方、負い方、返し方

ON THE TRIPゼロから構築するUXのプロセスと方法論(後編)
2 018.01.11
ON THE TRIP流 UX的負債の避け方、負い方、返し方

Proﬁle
森上航平
もりかみこうへい
2013 - 2015
株式会社 EAST OWL 代表取締役
2015 - 現在
meuron 株式会社 CPO / エンジニア / デザイナー
2017 - 現在
株式会社 ON THE TRIP UI/UX エンジニア
略歴
illustrator / Photoshop / Sketch / UI/UX 設計
Ruby on Rails / Swift / html / css / js (angularJS/jQuery)

INDEXON THE TRIP流 UX的負債の避け方、負い方、返し方
01 UX的負債とは？
02 UX的負債の避け方
03 UX的負債の負い方
04 UX的負債の返し方
05 ゼロからのサービス立ち上げ

UX的負債とは？
ABOUT
01
ON THE TRIPは実現したいことやメッセージ、
世界観がしっかりと存在していて、
やりたいこと・やるべきことが沢山ある。

ABOUT
01
新規サービス立ち上げの流れ
リサーチ&インタビュー
プロトタイプの作成
テストの実施
リリース

ABOUT
01
→ 技術だけでなくデザインやUX設計にも負債が生まれる
1.プロジェクト開始時点ですべての要求をあつめることは出来ない
2.集めたところで要求はどれも必ずと言っていいほど変わる
3.やるべきことはいつだって与えられた時間と資金よりも多い
“
”
開発に置ける３つの真実

ABOUT
01
UX的負債は絶対悪であり、必ず滅ぼすべきなのか？
→無いに越したことはないが、必要悪である

ABOUT
01
「あらゆる旅先を博物館化する」というロマンを掲げて、
世界観の濃いオーディオガイドを作るようなサービスは
前例がなくわからないことだらけなので、
負債を上手に負いながら素早く立ち上げて検証・改善を行う方針に。

ABOUT
01
1.プロジェクト開始時点ですべての要求をあつめることは出来ない
UX設計、体験設計の領域では特に
3.やるべきことはいつだって与えられた時間と資金よりも多い
→ サービスインして、実際にユーザーのデータを取るまで見えないものが必ずある
2.集めたところで要求はどれも必ずと言っていいほど変わる
→ 成長過程でターゲットが広くなったり、要求される体験そのものが変化する
→ 新規立ち上げには常に時間もお金も人手も足りない

ABOUT
01
新規サービスの立ち上げで大事なのは、
・無駄な負債を負わない
・勇気を持って負債を負う
・負った負債はきちんと返す
という、負債の適切な取り扱い

UX的負債の避け方
プロダクト・ステートメント
02
UX的負債を避けるときにもっとも重要なのは、
「やらないこと」を決めること

02
新規サービスを立ち上げるときは
みんなが色々なアイディアに溢れる

02
色々なアイディアを盛り込んだ意図の明確でないサービスは、
使われない上に体験設計を複雑にして沢山の負債を抱えることに...
もしあなたが四次元ポケットを持っていたなら、
ハサミが欲しい時に、10徳ナイフは取り出さない

02
取捨選択の基準を明確にブレないようにして、
立ち上げ時に集中するべきUXをしっかり定めて見える化する
UX的負債を避けるには...
GOALSTART
funcA
funcB
funcC
funcD
funcE
funcF

02
旅の体験を膨らませる
成瀬/志賀/訪日観光客
観光地・旅先に行った現地で
・旅の体験を膨らませないもの
・観光地や旅先に行ったときに関係のないもの
・成瀬/志賀/訪日観光客が欲しいと思わないもの
ローンチ時にやらないこと
THE GUILDの深津さんが公開している
ステートメントシートを利用

02
利用前
利用時
利用後
累積
観光地に行った時にその場(付近)でON THE TRIPに出会って面白そうだと思い
どのガイドよりもその場所での旅の体験が膨らむコンテンツに触れて深く楽しみ
その場所のことを思い出して誰かと話したくなったり、次の旅先に想いを巡らせて
ON THE TRIPで次の旅先を探したり、旅先でON THE TRIPがないか探す

02
利用前
利用時
利用後
累積
観光地に行った時にその場(付近)でON THE TRIPに出会って面白そうだと思い
どのガイドよりもその場所での旅の体験が膨らむコンテンツに触れて深く楽しみ
その場所のことを思い出して誰かと話したくなったり、次の旅先に想いを巡らせて
ON THE TRIPで次の旅先を探したり、旅先でON THE TRIPがないか探す
FOCUS
BizDev

02
「あったほうがいい機能」を作るのを我慢して、
提供したい価値体験に紐づくものを最短距離で作ってみる
→ UX的負債を最小限に抑える
シ
ェ
ア
機
能レコメンド機能

UX的負債の負い方
フェーズと戦略
03
とても勇気の必要な「UX的負債を負う」というのは、
言ってしまえば、もはやただの「えいや！」の世界

03
利用時のUIにおいてはわかりやすいのが一番で、
迷わず悩まず誤操作せず使えるのが大前提

03
それでもON THE TRIPがリリース時に選んだのは、
独特の操作感・空気感を持ったUI

03
理由は３つ
・UIのグランドデザインがある程度出来ていた
・旅好きペルソナの美意識に合った
・「新しいことをしていそう」なことが一目で伝わった

03
ON THE TRIPはローンチ時に沢山のユーザーが入るタイプではなく、
スポット数に紐づいてユーザーの流入やLTVが変わるアプリ
→「早くリリースすること・営業時に目を引くこと」の方が、
ローンチ時にUIを最適な形にしておくよりも重要度が高いと判断

03
思い切ってユーザビリティの低い状態でリリースして、
リリース前から改善の準備を進めることに
→ある程度のUX的負債を負うことを腹決め

03
リリース前からざっくりと改善のスケジュールと改善案を考案し、
リリース後のデータを追いながら優先度を調整
優先度A
□
□
□
□
優先度B
□
□
□
□

03
早くリリースして提携スポットを増やし、
スポットを増やしている間に改善を進め、
グロース期に備えて最適なUXの形を模索する

03

UX的負債の返し方
改善
04
UX的負債を返す = サービスの改善を行う

改善
04
昨今、改善の手法や知見は調べれば山ほどあり、
サンプルパターンも多く、
新規立ち上げに関わる人間は知識として持っていることが多い

改善
04
それゆえに、関係者がそれぞれの視点と知識でそれぞれに
「正しいと思うこと」をぶつけ合い、
意外と改善の議論が空中戦になりやすい

改善
04
どれだけデータを見て提案しても、
メンバーが優秀であればあるほど空中戦になりやすく、
空中戦になると「声の大きいメンバー」の意見が通ってしまう
→ これでは適切な改善が行えない...

改善
04
なぜ空中戦になるのか？
→サービス開発において「絶対的な正解」というものが少なく、
ある立場の人にとっては、あるユーザーにとっては、
ある期間においては…みたいな条件がつくと、
だいたいどれもそれなりに正しそうになってしまう

改善
04
A君「機能Aを改善したい！」
B君「機能Aってそんな重要じゃなくない？それより、
　　この画面迷うから機能Bを改善する方がいい気がする。」
A君「気持ちはわかるけど、機能Bって別に迷わなくない…？」
B君「いや、でも実際の画面の録画見るとほら、迷ってるんだよ。」
A君「たしかに...なるほど...」
C君「そんなことよりもクレームが来てたこともあったし、
　　機能Cを追加しない…?」
A君,B君「たしかに…うーん...」

改善
04
なにが空中戦たらしめているのか？
→前提の欠落

改善
04
A君「(ペルソナAのために)機能Aを改善したい！」
B君「(ペルソナBからすると)機能Aってそんな重要じゃなくない？
それより、(ペルソナBが)この画面迷うから機能Bを改善する
方がいい気がする。」
A君「気持ちはわかるけど、(ユースケースAから流れてくると)機能B
って別に迷わなくない…？」
B君「いや、でも実際の(ユースケースBの)画面の録画見るとほら、
迷ってるんだよ。」
A君「たしかに...なるほど...」
C君「そんなことよりも(ペルソナCから)クレームが来てたことも
あったし、機能Cを追加しない…?」
A君,B君「たしかに…うーん...」

改善
04
メンバーが知らず知らずのうちに色々なペルソナの、
色々なユースケースについて話しているので、どれも正解になってしまう
→ これを解決するフレームワークを作成

改善
04
P(ペルソナ)がU(ユースケース)の時R(理由)なのでS(解決策)する。
PURSを意識して話す

改善
04
実は議論している時にもっとも散らかりやすいのは、
「ペルソナ」と「ユースケース」なので、
ここを明確にしてあげると、議論がとてもシンプルになる

改善
04
リソースには限りがあるので、
ステートメントシートで決めたペルソナやユースケースに
当てはまらないものは、ローンチ前や直後に関しては捨てる

改善
04
・そもそもペルソナ不在のサービス改善を防げる
・話しているペルソナがずれているとすぐにわかる
・ほとんど存在しないユースケースの話かそうでないかに気づける
・実はやりたいだけでペルソナやユースケースとは関係ない機能追加や
改善を避けられる
Merit

改善
04
A君「ペルソナAがUの時にRだから、機能Aを改善したい！」
B君「ペルソナAってすでにLTVがかなり高いから、
ペルソナB見た方がよくない？」
A君「確かに」
B君「ペルソナBはUの時に迷っているみたいだから、機能Bを改善すると
LTVが伸びそう。」
A君「そこ結構刺さるはずの機能だし、機能B周り改善しようか」
C君「ペルソナCがUの時にクレーム出してきたこともあったし、
機能Cを追加しない…?」
A君「そもそもUの時って多い感じ？」
B君「ヒアリングしたりログ見る感じではペルソナCにそういうUは
あんまりなさそうだけど」
C君「あ、そうなんだ、じゃあいっか。」

改善
04
「Pが成瀬・志賀・訪日観光客ではない」
「Uが観光地に行った時ではない」
ON THE TRIPでは、
ような改善施策は今の所、後回しにして捨てて、
「Pが成瀬・志賀・訪日観光客で」
「Uが観光地に行った時にまつわることで発生率が高い」
ような改善施策に集中して取り組む

改善
04
こうすることで、今ある自分たちのリソースで、
価値検証したいことに対して最速・最短で到達&修正を行う
ことができる

改善
04
提供したい人に、提供したい価値を届けるための、
できるだけ強い幹を最初に作るために負債を返すことが肝心
GOALSTART funcA
funcB
funcC
funcD
funcE
funcF

ゼロからのサービス立ち上げ
新しい価値を作ること
05
今世の中にないものを作る
→ 「沢山の失敗を重ねながら進む」のが前提

05
最初のバージョンを世に出した時に恥ずかしいと思わなければ、
そのローンチのタイミングは遅すぎたということだ。
"If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late"
by Reid Hoffman

05
失敗を小さく・早くしながら、
一緒に働いているメンバーをワクワクさせることが大事
その中でプロジェクトを引っ張る人間は、

05
「あらゆる旅先を博物館化する」
「旅の体験を膨らませる」
「あらゆる場所に根付いた物語を掘り起こす」
ON THE TRIP はプロダクト・アウト型の組織

05
「僕たちが信じていること」を実現しながら、
人や時代に求められる形にフィットさせるのが、
UXを担当する人間としての役割

ON THE TRIP流 UX的負債の避け方、負い方、返し方

More Related Content

More from loftwork