「Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES) 」読書メモ

本書「Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン (THE LEAN SERIES) 」は、顧客開発とリーン・スタートアップのテクニックをUXに適用して、低コストで迅速に開発を進める方法と、良い体験を構築するための方法を教えてくれる1冊です。

本書に書かれている方法に、目新しい方法はありませんが、素早くサービス開発を回転させていくためのサイクルは、端的にまとまっていると思います。個人的には、リサーチする前にペルソナを作り、ペルソナの答え合わせとしてリサーチを活用したほうが、迅速に判断できるという指摘は、そのとおりだと思いましたし、今後の仕事の参考にしていこうと思います。

僕が気になった所を、メモとしてまとめてみました。

Lean UXの基盤

デザイン思考

  • 人々を直接的に観察することを原動力とするイノベーション
  • 人々が日々の暮らしの中で何を求め、何を必要としているか、特定の製品の製造やパッケージング、マーケティング、販売、サポート
  • どの方法を、好んでいるかそうでないかを観察する

アジャイルソフトウェア開発

  • プロセスやツールよりも、個人と相互作用
  • 詳細で分厚い文書よりも、機能するソフトウェア
  • 契約交渉よりも顧客とのコラボレーション
  • 契約の順守よりも、変化への対応

リーンスタートアップの手法

  • 構築(build)
  • 計測(measure)
  • 学習(learn)

部門/領域横断的なチーム

ソフトウェア・エンジニアリング、製品マネジメント、インタラクション・デザイン、ビジュアル・デザイン、コンテンツ戦略、マーケティング、品質保証などもすべて、Lean UXのチームに含まれるべき

Lean UXの原則

小規模、専任、同一場所

チームは小規模にし、中心メンバーは10人以下。小さなチームにすることで「コミュニケーション」「集中」「連帯感」を保つことが出来る。

進捗=結果(アウトプット)ではなく、成果(アウトカム)

機能やサービスを開発することは、結果(アウトプット)。これらの機能やサービスで達成を目指すビジネスゴールは、成果(アウトカム)

課題焦点型のチーム

機能を実装することではなく、ビジネス上の課題を解決することを目標とするチーム

無駄を取り除く

最終目的の達成につながらないものを出来るだけ排除する。

バッチサイズは小さく

チームを前進させるために必要なデザインのみを開発し、テストや実装をしていないデザインのアイディアの「在庫」を減らす。バッチサイズが大きいと、大きな成果物が形になるのをまたなっくてはならない。

継続的な発見

ユーザーが製品をどのように使っているか、その理由は何かを理解する。そのために、調査を計画に従い、定期的かつ頻繁に実施。調査はチーム全体が関与。

GOOB(getting out of the building)

ユーザーのニーズは何かということについて、会社の会議室で議論をしても、有意義な結論は導けない。答えは、会社の外の、市場のなかにある。

仕事の外面化

仕事を頭やコンピューターの外側に出し、他者の視点に晒すことを意味する。

分析するよりも形にする

分析をすることよりも、実際にアイディアを形にすることを評価する

成長よりも学習

開発すべきアイディアの妥当性を、規模を拡大する前に確認する。大規模な機能の実装に内在するリスクを低減できる

失敗を許容する

ビジネス上の課題への最善のソリューションを見出すために、アイディアを実験してみる必要がある。アイディアのほとんどは失敗に終わる。成功するためには、安心して失敗できる環境が必要。

中間成果物中心の仕事の進め方からの脱却

開発対象物についての文書ではなく、達成しようとしている成果にデザインプロセスの重点をシフト

ビジョン、フレーミング、成果

  • 前提:真だとみなしていることの概要を示す定義
  • 仮説:前提を詳しく述べたもの。実験できるように、製品/ワークフローの特定エリアに対象を絞る
  • 成果:仮説の妥当性の有無を評価するために、チームが市場から得ようとするシグナル
  • ペルソナ:チームの解決対象の課題を抱えていると想定される対象ユーザーのモデル
  • 機能:望ましい成果の実現を促すと思われる、製品への変更や改善

前提の宣言

  • 準備すべき重要な点
  • 現行製品がどのように利用されているかを示す分析レポート
  • 製品の利用時における顧客の特定の行動を説明するユーザビリティレポート
  • 過去の課題解決への試みとその成否に関する情報
  • 当該の課題の解決が会社のパフォーマンスに及ぼす影響についての、ビジネス・ステークホルダーによる分析
  • 同じ課題に取り組む競合の同行を示す、競合分析

課題ステートメント

  • 製品/システムの現行の目標
  • ビジネス・ステークホルダーが解決を求めている課題
  • 特定の解決策が指定されていない、明示的な改善要求

仮説ステートメント

市場からの以下のフィードバックを得た時に、自分たちが正しいか、間違っているか、判断できる。

  1. 定性的なフィードバック
  2. 定量的なフィードバック
  3. 主要業績指標の変化

成果

実現しようとする成果を、出来る限り明確にしておく

ペルソナ

  • 前提を明確にし、前提を実証するためにリサーチを行う(通常はリサーチの後にペルソナを制作するので、順序が逆)
  • 最初の推測の精度とターゲット・オーディエンスを調整すべき度合いによって迅速に判断できるようになり、設計にも反映できる

ペルソナで考えるのは以下の4点

  • 名前
  • 行動に結びつく顧客層情報
  • ニーズとペイン(不満点)
  • 潜在的なソリューション
  • 機能

成果リストの作成と、対象のユーザー・グループの絞り込みを終えたら、これらの望ましい成果を実現するために求められる戦術、機能、製品、サービスについての検討を始める
機能のリストを作り、これまで準備してきたものを基に、デザインの制作を始める

コラボレーティブデザイン

一般的なコラボレーティブ・デザイン・セッションでは、チームはまず全員でスケッチを行う。デザインのアイディアに対し、意見を述べて議論する。
これらのセッションの結果を構成するのは、ラフのスケッチのワイヤーフレームです。

デザインスタジオは、以下の手順にしたがって行う。

  • 課題の定義と制約の明確化
  • 個別のアイディアの創出
  • プレゼンテーションと批評
  • イテレーションと洗練
  • チーム全体でのアイディアの創出

良いスタイルガイドの特徴

スタイルガイドとは、コラボレーティブ・デザインを容易にするツール。ヘッダー、フッター。マトリックス、フォーム、ラベル、ボタンロジック、及び製品のユーザー・エクスペリエンスに含まれるすべての要素もスタイルガイドに入る。

  • アクセスしやすい
  • 見つけやすい
  • 配布しやすい
  • 検索しやすい
  • 使いやすい
  • 継続的に改善されている
  • 実用的である

スタイルガイドを作成するには

  • 目次を作成する
  • コンテンツを追加する

実用最小限の製品(MVP)

MVPは前提の評価に役立つと同時に、証明されていないアイディアに投じる労力を最小限に抑えられる

MVPの作成

  • デザインの対象となっている解決策には、そもそもニーズがあるか
  • 提供しようとしている解決策と機能には、価値があるか
  • この解決策は使いやすいか

MVP作成にあたってのガイドライン

  • 明確かつ完結であること
  • 優先順位付けを重視する
  • アジャイルを維持する
  • 行動を測定する
  • CTA(コール・トゥー・アクション)を使用する
  • 機能的である
  • 既存の分析との統合
  • アプリケーションの他の部分との一貫性の維持

プロトタイプ作成ツール

プロトタイプ作成ツールは、以下を基準にして選択する

  • プロトタイプとインタラクションをするのは誰か
  • 何を学習したいのか
  • 作成の期間はどれくらいあるか

ラフなプロトタイプ:ペーパー

  • 速ければ1時間程度で作成できる
  • 配置とその変更が可能
  • 低コスト
  • オフィスに有る材料を使って組み立てられる
  • 短期間での反復と複製に時間がかかる
  • シュミレーションが極めて人工的

クリック可能なワイヤーフレーム

  • ワークフローの長さを再現しやすくなる
  • 大きな生涯を明らかにしやすい
  • 未完成の製品をイメージ出来るだけの人でないと、テストが成立しない

高度なプロトタイプ

ワイヤーフレームベースのプロトタイプよりも格段にディテールを細かく作り、デザインの実証と評価を行う。

  • ビジュアルデザインとブランド要素を評価出来る
  • ワークフローとインタラクションを評価できる
  • ネイティブプロトと比べると、双方向性が限定されている
  • ユーザーは通常、実データを使えないため、シュミレーション出来る製品内のインタラクションには限りがある
  • ツールによっては、プロトタイプの作成とメンテナンスには時間がかかる。プロトタイプをメンテナンスし、実製品に対して同期させるためには、しばしば作業の重複が生じてしまう

コーデッド・プロトタイプ

  • 本番環境のコードとして再利用出来る場合がある
  • 最もリアルなシュミレーションを実現
  • 既存のコード資産からの生成が可能
  • 実動作するコードを作成しなければならないため、時間がかかる
  • コードを完璧なものにしたいという誘惑にかられやすい

フィードバックとリサーチ

コーボレーティブ・ディスカバリ

チームとしてアイディアを市場で評価すること
チーム全体がオフィスのあるビルの外に出て、顧客に会い、そこから学習するというリサーチ手法
この活動は外注しない。情報がフィルタリングされ、価値が下がってしまう

  • チームとして、質問、前提、仮説、MVPをレビューします。チームとして何を学ぶ必要があるかを決定する
  • チーム全体で競技し、学習目標の達成のために、誰に話をすべきかを決定する
  • 会話の指針となるインタビューガイドを作成する
  • チームをインタビュー用のペアに分ける
  • 各チームは、顧客/ユーザーと会うために外に出かけます
  • 1人がインタビューを担当し、もう1人がメモをとるようにする
  • 質問を開始し、対話と観察を行う
  • セッションの後半でMVPを実演し、顧客にそれを使ってもらう
  • 顧客のフィードバックをメモする
  • メモ担当者にもフォローアップの質問をするチャンスを与える

リサーチ結果から意味のある情報を得る

  • パターンを見つける
  • 異常値は保留する
  • 他のソースを使って検証する
  • どのような状態でも評価する
  • カスタマー・サービスからも情報を得る

オンサイトのチェックポイント

  • 検索ログ
  • サイト利用時の分析
  • A/Bテスト

関連商品