8月27日（土）に「Open Network Lab」が主催する
「実践的User Experience ワークショップ」に参加してきました。
Ajaxの生みの親でもあり、デザインコンサルティングファームの
「Adaptive Path社」の初代CEOで、
UXデザイナーとして活躍した「Janice Fraser」さんが、
スタートアップの中でUXを実践していく方法を、
実践的なワークショップにてレクチャーしていただきました。
実践的User Experience ワークショップ
■日時：2011年8月27日（土） 9:00（8:30より受付開始） – 21:00
■場所：〒150-0022 渋谷区恵比寿南3-5-7 代官山DGビル 9F
■アジェンダ
(1) Lean UXについて（9:00 – 10:30）
グループワークと個別質問会を通じ、
「リーンスタートアップメソッド」を使用した実用的なUXテクニックの紹介や、
プロダクトマネジメント、UXとプロダクト開発の接点について説明します。
(2) 顧客育成のためのインタビューと生成調査(11:00 – 12:30)
生成調査と評価調査の違いを説明し、正しいインタビューの練習や指導を行います。
昼食(13:30 – 14:30)
(3) プロダクトとインターフェイスの開発(14:30 – 15:30)
インタビューや調査を通じて得た情報をプロダクトやインターフェイスの開発に
活用するための技術指導（プロトタイプのスケッチや絵コンテ）を行います。
(4) 定量分析と定性分析(16:00 – 17:00)
正しい調査方法で、質問や仮説、未知の部分を解決する手法を学びます。
定量分析や定性分析についてより深く堀り下げたディスカッション、Q&A、
ケーススタディーや調査ツールを通じて、定量分析と定性分析に関する理解度を深めます。
受付
前日は西麻布泊だったため
ホテルの最寄り駅の広尾駅から、恵比寿の会場へ。
受付をすませて、
レシーバーを受け取り、
セミナールームへ。
午前中は、座学からスタート。 ※座学の内容メモは長いので後ろに。
開場は満員御礼で、
逐次通訳はあるものの、
基本英語のセミナーなのに、みんな英語がわかるらしい・・・
ワークショップ
まずは「クロスピンマン」という、
人のイラストの書き方を習いつつ、
個人個人で、ペルソナを作成
（プロダクトもペルソナも仮説でOK）
グループでどのペルソナがいいか検討し、
そのペルソナにインタビューする内容のヒントを「Topic Map」として、作成しておく。
ここからお昼だったけど、
「Topic Map」にどのようなヒントを書いておけばいいかはっきりしなかったので、
講師のJaniceを呼んで、内容を確認してもらう。
※「まずはクローズクエスチョン（こんな体験ありませんでした？）を聞いて、
その後にオープンクエスチョンでストーリーを聞く」とのこと。
お昼ご飯
いっしょに参加していた#hcdvalueのメンバーと一緒に準備されていたお弁当をいただく、
食後にイトマキさんのマッサージ大会。
これがなければ死んでいたかもぐらいに、
この時点でいろんなダメージが蓄積していて、本気で帰ろうかと・・・
午後
午後はワークショップの続きから。
作成したペルソナを検証するために、
ペルソナの属性に近い人がペルソナになりきり、
午前中に作成した「Topic Map」を元にインタビューを受ける。
【DUMP】そのインタビューのメモを元に、
ポイントやアイデアをポストイットに書きだす
【SORT】書き出せたら、その付箋をグルーピングし
クラスタ分けをして、そのクラスタにラベルを付ける
そのクラスタやメモを元に、
ペルソナに加筆・修正を実施。
【6User】ペルソナの検証ができたら、
「6User」というメソッドを使い、
シーンを６個書く。
全員のシーンの中から、
投票で、ソフトウェア化したいシーンを選び出して
ワークショップは終了。
※青いテープを１人２票を投票して、一番多かったもの。
懇親会
懇親会は同じ会場でケータリングを利用して。
感想
今回のセミナーはUXと名前が付いているものの、
ビジネス向けのセミナーで、
自分が想像していたセミナーとは違うものでした。
特にもやもやしたのが、
「ペルソナの作成」の時でしょうか・・・
「想像で作ったペルソナを、想像のユーザーで検証している」
もしかしたら、
このワークショップのために、
割愛している部分があったのかもしれませんが、
「実際のユーザーの経験」
には触れていないんですよね・・・・
仮説・検証を早く行って、
仮説を徐々に現実に近づけていくのはわかるんですが、
あまりにも見えているところしか拾い上げてない方法の、
ワークショップだったのでお昼の段階で帰りたくなったのかもしれません。
それであれば、大学院生が研究している、
「思い出ワークショップ」の方が、
数十倍「ユーザーの経験」に触れているし・・・
「時間もコストもかかるから」は、
言い訳にしか聞こえないような気がします。
もしかしたら僕の理解不足があるのかもしれませんが、
僕はもっと人の体験に潜り込むようなデザインをしていきたいと思います。
※10/3追記
実際にLeanを実践している方がいました。
「リーンスタートアップを実践してのこれまでとこれから」
講義資料＋講義メモ
当日の講義資料が日本語化されてますが、
訳が微妙な箇所が所々ありますね・・・
英語版の資料 Tokyo 1 day (日本語)
■LeanUXについて 09:00 – 10:30
トヨタの看板方式がLeanのスタート地点
▼Crushing the Boulder 大きな岩を砕く
大きな岩を一生懸命上に上げるが、あがらないで岩が落ちてくる、
それの繰り返し。
ビジネスの現場で必要とされているのは、
ユーザーのことを知りたい、知る事。
※映画ゾンビランドの写真。
このような写真のように、大きな岩を砕いてほしい、
大きな岩を小さくして、それを上に上げていく、
それがLeanUX。
岩を砕く事が大事。
▼Janice Fraser 自己紹介
adaptive pathでCEOを勤めた。
LeanUXを実践している。
何がうまくいくのか、いかないのかのノウハウがある。
Janice Fraser
@clevergirl
@luxrco
#LeanUX
■Part 1: Lean UX Fundamentals
▼What is Lean Startup?
Eric Ries → LeanUXの考え方を取り得れた。
スタンフォード大学のSteve Blankから影響を受けた。
「スタートアップは予測可能なステップ」
・Customer Discovery:「顧客を発見する」
まずはユーザーの生活を調査する
・Customer Validation 顧客の評価
対価を払うのに適しているのか？
※問題解決のフィット
・Customer Creation 顧客を創出する。
・Company Building 組織を構築
※Get out of the building!
まずは外に出よう！
▼Brand Cooper and Patrick Vlaskovitz
「Customer development」でGoogle検索すると172万件
?アイデアを思いつく。
４つの質問を考えながら進めていかないといけない。
・どのようにフィットさせていくのか
まずどのように進めていくのか考える、
仮説を立てる。
ソリューションではない。
※常に自分に「何が大切なのか」と問い合わせながら進める。
?Befor Fit
フィットすることを検証。
顧客がお金を払ってもいいか検証する。
※プロダクトマーケとフィットを検証する方法
「この商品がなくなったら悲しい」
▼顧客開発=UX!!?
人を理解する
スケッチしてプロトタイプをつくる
新しいユーザーエクスペリエンス
※人間中心デザインの手法がビジネスの中で実践されはじめている。
デザインの枠にとどまらず、ビジネスと協力していかなければならない。
▼2008年09月13日にLeanStartUPという言葉が
Eric Riesのブログにアップされた。
http://www.startuplessonslearned.com/2008/09/lean-startup.html
▼参考
LEAN THINKING reduce waste
※この３つの要素をまとめるとLean Startupが生まれた。
IDEAS
↓
BUILD
↓
PRODUCT
↓
MEASURE
↓
DATA
↓
LEARN
※この繰り返し
※検証して学ぶ
▼UX Cycles
THINK
MAKE
CHECK
▼What is UX?
Design > UI
USERS
NEEDS
USES
FEATURES
USER STORIES/THEMED RELEASES
※UIはUXの一部でしかない。
アランクーパー曰く
テーブルを椅子に変えることはできない。
奇麗なテーブルをデザインしても顧客の満足はあがらない。
スタートアップで重要なことは決定をすること
（議論は永遠に及ぶので）
User Experienceは10年の経験があるので、
スタートアップのパートナーであってほしい。
ユーザーリサーチの参考書はいっぱい出ている。
勉強するクラスもたくさんある。
※フォーカスインタビューはやらないほうがいい。
▼Lean UXの新しいところは？
Lean User Experienceには指針がある。
チームの儀式、習慣のようなもの
▼Lean UXの9つの原則リスト
1.Design + Prod.Mg + development = 1product team
Design と ビジネスと開発は１つのプロダクトチーム
プロダクトオーナーは責任範囲が広すぎる
デザイナーにも、開発にもアカウントを与える。
2.Externalize!
外部化する。
３〜４人で一つのものを作り、議論する。
3.Goal-Driven and Outcome-Focused
目標成果型/測定
成果にフォーカスすることで意思決定が早くできる。
未達のときはやり直しができる。
4.Repeatable and routinized
リピート可能でありルーティン化
最初は３〜４人のチーム
それをどうFacebook化するか。
ルーティン化する必要がある。
（毎回同じことをはなさなくてすむように）
5.Flow: Think/make/check
Think-Make-Checkのフロー
6.Focus on solving the right problem
正しい問題を解く事に集中
7.Generate many options and decide quickly which to pursue.
多くのオプションを考えるが、固執してはダメ。
迅速に意思決定する方法を考える。
8.Recognize hypotheses & validate them.
仮説を検証する。
デザイナーに共通することは、自分のアイデアに自身がありすぎる、
あくまでも仮説
9.Research with users is the best source of information (& inspiration)
アイデアが欲しければ、お客様の声を聞く、
▼RITUALS OF LEAN UX（Lean UXの習慣）
1.Write the test first
必ずテストを書く
2. User quote/nees as sprint name
ユーザー視点の名前をつける
3. Wireframe check
ワイヤーフレームを検証する。
4.Desiger / developer pairing
デザイナー・開発者でペアを組む。
5.UX & Products Mgt participate in startup meetings daily
毎回MTGだとパンクするので、密に共有する。
6 Validation step
ステップを検証することも必要。
7. Retrospective periodically
定期的に回想。
■In Practivce: Write the test first
これはあるショップから持ってきた例。
■In Practice: Wireframe Check
ワイヤーフレームの4つのチェック方法
1.Is this an accurate reflection of the system?
2.What here is hard?
3.What alternatives are there?
4.Is it worth the effort?
★質問タイム
Q.プロダクトを検証する場合に２つ考えれる
「仮説を立てる」「顧客に聞く」のどちらがいい？
A.顧客との距離によるので、仮説を立てることが多い。
Q.ワイヤーフレームのチェックにて、
デザイン完成の段階でのミスをなくすためには、
A.開発者とデザイナーのパートナーシップが重要。
Q.スタートアップをやっているが、次にやることが難しい
A.優先度をつけることが必要。
■Part2: Customer Development Interviews 11:00 – 12:30
顧客育成のためのインタビューと生成調査
▼User Research
QUANT
QUAL
GENERATIVE
EVALUATIVE
これを埋めていく。
QUANT * EVALUATIVE
まずはABテスト（ソフトを２バージョン作成する。）
テーブルが必要なのか、椅子が必要なのかここでチェックする。
KPIを確認する。
※図の三角形
リサーチには３段階ある。
まずは小さく行う。
QUAL * EVALUATIVE
・Usability
何が原因かチェックする。
定量的/定性的
・Hallway usability
誰でも良いので、15分程度でチェックしてもらう。
・remote
リモートテストのサービス
QUANT * GENERATIVE
surveys
→サーベイはスタートアップではさけた方がいい。
サーベイは設計によって適切な情報がとれないことがある。
QUAL * GENERATIVE
Contextual Inquiry(Byer & Holzblatt)
Mental Models(Indi Young)
→Contextual Inquiryの簡易版
Interviews
Starbucks
▼Mint.comというスタートアップがあった。
お金を理解することができるサイト
Indiが８週間の調査をしてチャートを作った。
ミントはそれを元に、ユーザーのもっとも大事なことをサービスとした。
※米Intuit
ミントを買収した。
リサーチャーがお客様の家に行き、
どのように会計の計算をしているかを観察した。
リサーチャーは深い洞察を得る事ができる。
▼Interviews
適切な人を選ぶ必要がある。
Before the Interviws
誰と話したいか
topic map
prompts.
大きな視点で質問して、ストーリーを話してもらう。
▼Conversion Pronpt
まずはクローズクエスチョン（こんな体験ありませんでした？）
その後にオープンクエスチョンでストーリーを聞く
▼Topic Map
６つの雲をかく。
質問のヒントになるようなもの。
■Part3:プロダクトとインターフェイスの開発 13:30 – 15:00
※良いインタビューはインタビュアーの発言は10%以下。
※誘導するような質問はNG。
▼6users
デザインリサーチの方法
■Part4:定量分析と定性分析 15:30 – 17:00
▼チェック方法／評価
「何を学びたいかに依存する。」
「これを使ってもらえるか？」
Will people use it
Why won”t people use it?
What”s wrong with this?
※モバイルのアプリケーションの場合は難しいかも。
「なぜそんなことをするのか？」
「長く使ってもらえるのか？」
デザインは間違える
テスト駆動型開発（TDD）はデザイナーにとってとても興味深い
▼User Resurch
・a/b testing
最初から３つは捨てることと考えてプロトタイプを作る。
例：すばらしいフォトグラファーは、すばらしい写真を撮る
（無駄な写真を捨てているから）
・analytics
解析手法をデザインに反映するには時間もコストもかかる。
・usability
ユーザービリティテスティングをしていないプロダクトは、
必ず失敗する。
ユーザービリティテストを肝臓に例えた（毒を解毒する。）
肝臓通さないと身体こわすよ。
何をテストすればいいのか、２つにまとめられる。
・Behavior
Do people use it?
Which is better?
Did we do the right thing?
Are these results good?
Are we making progress?
CLOSED – ENDED QUESTIONS
・Ability
How Should I design the new one?
Why won”t people use it?
Wha”ts wrong with this?
How could I make this better?
why do people do that?
What do people love about it?
How can I improve conversion?
Whuy is there drop off?
What do they think this should do?
OPEN – ENDED QUESTIONS
■事例
taskrabbit
→コンバージョンを倍にしたい。
5％→9.75%にした。
Vanity
Metrics for Pirates
■Research Tools
・Analytics
Conversion testing
Unmoderaed Tests with Video
Heat Mappinng
コメント