サイロごとには先進的
なのに会社全体では絶望的
リーンにプロジェクトを進める
最後にはデザイナーの分厚い資料のプレゼン
失敗
責任は？
おしゃれなデザイン会社
エンジニア
経営幹部
システム全体にある
サイロを壊す
ユーザーが喜ぶことを原点にまとまる
—-
なぜリーンUXか？
需要があるか
それは事実か
わからない
仮説検証サイクルで進むしかない
フィードバック・ループ
（真っ暗で何が置いてあるかわからない部屋から脱出）
健全なプロダクト開発
マラソン
459回やれば失敗する可能性は1%
「早く失敗して成功を早める」
—-
リーンスタートアップ
「最大の価値を持つアイデアに最大のリソースを投じるための手法」
リーンUX
アジャイル開発しながらデザインニーズにも応える
ピクセル単位の仕様書
拍手喝采
日の目を見ない
未完成や醜い状態で見せる恐怖
克服する
大切なのはコラボレーション
学習とイテレーションの継続
—-
【Lean UXへのイントロダクションと基本原則】
人間中心デザイン
UX
デザイン思考
「人間を直接観察することを原動力とする」
アジャイル
プロセスやツールより対話を
ドキュメントより動くソフトウェアを
交渉よりユーザーとの協調を
計画に従うよりも変化への対応
リーンスタートアップ
構築、計測、学習
MVP
Lean UXの原則
チームビルディングの原則
部門横断的チーム
エンジニア、PM、デザイン、マーケ、QA
小規模同一場所のチーム
10人以下
コミュニケーション、集中、連帯感
自己充足的で権限持つチーム
外部との依存関係なし
ユーザーや顧客と直接関われる
課題焦点型のチーム
機能実装ではない
課題解決が目的
当事者意識の芽生え
独自の解決策
チームや組織文化となる原則
疑問から確信へ
全ては推測や仮定
機能ではなくユーザー行動の変化を重視する
無駄を取り除く
フォーカスする
共通理解を生み出す
集団的な知識
ユニコーン、エバンジェリスト、ヒーローは不要
チームワークの方が大事
失敗を許容する
実験は失敗がつきもの
創造性が高まる
陶器の例
自転車の例
プロセスの指針となる原則
バッチサイズを小さくしてリスクを減らす
継続的に発見する
使い方、なぜかをチームで定期的に調査する
GOOB : 新たなユーザー中心思考を使う
Getting out the building
建物から出る
購入するのはユーザー
仕事を外面化する
付箋など
分析よりも形にする
何かをつくって建物を出る
中間生成物中心から脱却
ドキュメントでなくプロトタイプ
【Lean UXのプロセス】
機能でなくユーザー行動の変化
機能でなく検証の継続
仮説とTDD
前提仮説
デザインと開発
MVP構築
実施と学習
機能でなく仮説から
課題にフォーカスするようになる
会社全体のKPI
マーブルチョコで投票
海賊指標
獲得
活性
継続
紹介
収益
「ユーザーが特定の機能を欲していることは滅多にない」
バナナスライサーの例
デザインシステムをつくる
Wikiベースでもよい
スプレッドシートでアイデア出し
一列目は名前
8人でやった
2枚目でテーマ分け
レトロスペクティブ
週末の集まり
MVP
一つ目の考え
学習を主目的とする
マーケットに価値を提供ではなく
マーケットが何を求めているか明らかにする
もう一つ
できるだけ早く価値を提供する
小さなバージョンを作る
ニュースレターを出すべき？という例
ニュースレターを読みたい人がいるか
MVPとしてまずはフォームを作る
どれだけの人が求めているか
求められていることがわかる
内容のMVP
仮説
その仮説で最初に学ぶべきものは何か
最小限の労力でそれを学ぶ方法は何か
リーン
MVP構築手順
核となるベネフィットと提示方法を考える
明確なCTAを使う
優先順位付けを重視する
アイデアに固執しない
学習をすばやく繰り返す
ゼロから作ろうとしない
行動を測定する
ユーザーと話す
なぜ？を特定する
MVPの難しさ
フォーカスは容易でない
機能と課題を混ぜてしまう
学習目標を明確にする
小さく進める
コードがいらない場合もある
学習曲線を意識する
MVPの例
まずLPだけをつくる
どこにも繋がらないボタン
Flickrのスクリーンセーバーとして使うボタン
オズの魔法使い
Amazonエコーの例
体験のプロトタイプ
ペーパープロトタイプ
ワイヤーフレームモックアップ
中から高忠実度のモックアップ
コーデッドプロトタイプ
「仮説の妥当性を学習するために用意する実用最小限の製品」
MVPのポイントは学習である
顧客開発は継続的
リサーチャーはファシリテーター
フィールドワーク
インタビュー
最後に他に有益なフィードバックを提供してくれそうな人を紹介してもらう
ターゲットかどうか確認
仮説確認
インタビュー後にモックアップを触ってもらう
3-12-1
3人のユーザー
12時
週に1度
パターンを探る
カスタマーサポートと連携する
【Lean UXの実践】
アジャイル開発のUXへの適用
スクラム
時間区切りのサイクル
ユーザーストーリー
ベネフィット
バックログ
ユーザーストーリーのリストと優先順位
スプリント
動くソフトウェアをつくる
スクラムでは2週間
スタンドアップ
日次定例
自分が何をしているか
どういう壁に直面しているか
レトロスペクティブ
スプリントの最後の定例
良かった点
問題点
チームとして改善すべきこと
プロセスの最適化
イテレーション・プランニング・ミーティング
バックログの優先度を決定
プロダクト・ディスカバリ
学習活動
何を提供するか
スプリント・ゼロ
プロダクト・ディスカバリの時間
デザイン・スプリント
アイデアからプロトタイプへ
デュアルトラック・アジャイル
2つのバックログ
ディスカバリ
デリバリー
デュアルトラックアジャイル
プロダクト・ディスカバリ
仮説アイデアをつくっていく
ディスカバリ・バックログにまとめる
デリバリー
検証されたアイデアを開発していく
デリバリー・バックログにまとめる
ディスカバリとデリバリーを分けてはいけない
小さなウォーターフォールになる
あくまでチーム
顧客開発にできるだけ同席
ドキュメントで即共有
Google form
スプレッドシート
デリバリーで得た検証結果
ディスカバリ・バックログにフィードバックする
段階で分かれているわけではない
最初はデザインスプリント
1日から1週間
IPM
デザインスプリントを成果物を使う
ユーザーストーリーをつくり優先順位をつける
1日
実験計画をたてておく
仮説
検証方法
担当者とコスト
ユーザーフィードバックを計画しておく
5営業日に１回
スプリント開始
全員が参加する
エンジニアだけではない
「デザインはチームスポーツである」
ビジョンの共有
仕事の質を高める
重要な機能は何か
何を最初にすべきか
ビジョンの共有の不足の現れ
「これが起きたらどうする？」
私は正しくあなたは間違っている
から
課題をどう解決するかに変える
社内ステークホルダーとうまくやるために
イシューに対するロードマップを管理する
事前に連絡する
彼らに知らせる
進捗
実験と学んだこと
次の実験
リスクと対処方法
成果にフォーカスしてコミュニケーションする
影響がありそうな変更を伝える
対処する時間を十分に取れるようにする
LeanUXとはマインドセットである
スピードが第一、美しさはその次
システムの主要機能
使い方によって分かってくる
Twitterのハッシュタグ
デザイナーをファシリテーターにする
全員が同じレベルでコラボレーションする
ピザ2枚分のチーム
ヒーローは不要
美しいデザインがもたらすバイアス
デザインヒーローはいらない
PayPalの例
チームビルディング
PM、デザイナー、エンジニア
「ピカソを台無しにする」のは避けたい
ピクセル単位のデザイン
実装可不可を答えるだけ