リーン UX ：UXで効率性を最大化するためのヒント
近頃、リーンスタートアップ、リーン生産方式、リーンソフトウェア開発、リーンUXなど「 リーン （Lean） 」という言葉をよく耳にするようになったのではないでしょうか。これらのリーンプロセスの目的は「余計なものを取り除くこと」であり、生産性を下げたり混乱させたりするシステムやプロセスをなくします。
リーン UX の主なポイント
- 「リーン生産方式」と「アジャイル手法の原則」を取り入れた、UXデザインへの共同アプローチである。
- ２０００年代初頭に出版されたリーンソフトウェア開発に関する本から派生したものである。
- 学習の優先順位付け、成果の重視、継続的な発見など１５の原則がある。
適切なデザインツールを選択することで、UXのワークフローとプロセスの効率化につながります。UXPinは、スピード、一貫性、効率を向上させるために構築されたコラボレーションデザインツールです。１４日間の無料トライアルでぜひお試しください。
リーン UX とは
リーンUX は、連携を促し、MVP（最小実行可能プロダクト）で多くのテストや実験行う成果ベースのデザインプロセスです。
リーン UX は、成果物よりも成果を優先し、「デザインするもの」ではなく「デザインする理由」を問います。「何」を「なぜ」に置き換えることで、デザイナーは「いいと思う人がいるから何か作ろう」という曖昧なものではなく、具体的に「デザインする理由や裏付けとなるデータ」を見つけないといけません。
このように、リーンUXでのデザインは「ワークフローの概念」というよりも１つの「思考プロセス」と言えます。デザイナーは構築する前に仮説を立て、それを検証しないといけません。この思考プロセスが、MVPコンセプトのテストと実験がリーンUXでのワークフローにおいて重要な理由です。
リーン UX の歴史
リーンUX は、２００３年に出版された『Lean Software Development（リーンソフトウェア開発）』という本とアジャイル手法から派生したものです。国際的に有名なデザインとビジネスの専門家であるジャニス・フレイザー氏は、２０００年代に「リーン UX」という言葉を世界で広めました。
“Lean UX is UX practice adapted for Lean Startups…”（日本語訳：リーンUX は、リーンスタートアップのために適応された UX手法である）と言います。
そして、彼はイノベーションとシリコンバレーのスタートアップ企業数社のスケールアップに関する知識と経験を活かし、リーンのコンセプトを UXデザインに応用しました。
アジャイル UX と リーン UX
アジャイルUX と リーンUX は似たようなコンセプトですが、アジャイルUXはアジャイルを使っているチームに効果的であるのに対し、リーンUX のプロセスはどんなスタートアップや組織にも適しています。
リーン UX のプロセス
リーンUX のプロセスには、従来のUXデザイン思考のフェーズがすべて含まれており、プロトコルが違うだけであることに注意するのが重要です。
デザイン思考のプロセスには５つのステージがあります：
- 共感：ユーザーが何を必要としているかを発見する
- 確定：解決したい問題を特定する
- アイデア出し：ユーザーの問題に対する解決策を考える
- プロトタイプ：プロトタイプを作成する
- テスト：プロトタイプをユーザーやステークホルダーとテストする
一方、リーンUX はプロセスを３つのステージに分けます：
- 思案： 結果、仮定、ユーザーリサーチ、アイデア、メンタルモデル、スケッチ、ストーリーボード
- 作成：ワイヤーフレーム、プロトタイプ（MVP）、価値提案、仮説
- 確認：データと分析、ユーザビリティ・テスト、ステークホルダーとユーザーからのフィードバックの分析
ご覧のように、どちらのプロセスも同じ要素を含んでおり、方法論だけが異なっています。
リーン UX の原則
こちらの記事で、Ben Ralph氏はコアとなる リーンUX の１５原則を概説しています：
- 部門横断チーム – 同じプロジェクトに取り組む複数の部署のメンバーでチームを作る。
- 小規模、専任、同拠点 – チームを５〜９人ほどの少人数にし、ひとつの問題に集中し、同じワークスペース（リモートチームの場合は同じタイムゾーン）に置く。
- 進歩＝成果であり、アウトプットではない – ビジネス目標の達成は成果であり、機能やサービスはアウトプットである。
- 問題集中型チーム – チームは新機能のデザインではなく、問題の解決に集中しないといけない。
- 無駄を省く – ビジネス目標につながらない作業やプロセスを省く。（チームは明確な理由もなく会議に出席したり、報告書を作成したりしていないか？）
- 少人数制 – チームは一度につき１つのタスクや目的を完了することに集中しないといけない。
- 継続的な発見 – 顧客、エンドユーザー、ステークホルダーと定期的に関わる。
- GOOB（Get Out Of the Building）- 社内で仮定をごちゃごちゃ話し合うのであれば実際のユーザーとアイデアをテストする。
- 理解の共有 – チーム全体が共に学び、成長できるよう、協力し、アイデアを共有する。
- アンチパターンのロックスター、達人、忍者 – どのチームメンバーも同じように評価する。
- オープンな職場 – 自由にアイデアを共有できる環境を作る。アイデアに正誤はない！
- 分析より創造 – うまくいくかどうか議論して時間を無駄にせず、まずはやってみて、その経験から学ぶ。
- 成長よりも学習 – 最初に正しいものを作り、それから規模を拡大する。
- 失敗の許可 – 実験とリスクを取ること。マーク・ザッカーバーグ氏の“move fast and break things.” （素早く行動し、破壊せよ）という有名な言葉にあるように、完璧さよりも市場投入スピードを優先する。
- 成果物ビジネスからの脱却 – UXドキュメントは最小限に。結果に優先順位をつける。
また、このリーンUXの １５原則には、以下の２つの共通テーマがあります：
- 行動を起こす – アイデアを MVP とプロトタイプに変える。テストを繰り返す。
- チームワーク – 共有、連携、連携
リーンUX のメリット
従来のUXデザインプロセスには、監督会議、不要な文書や成果物、部署やチームのサイロ化、コミュニケーション不足など、時間をムダにしてしまう障害がありました。
リーンUX で、部門間で連携を促進させ、付加価値をもたらさないプロトコルを避けることでUXワークフローが最適化されます。
また、リーンUX の成果主義とは、UXデザイナーが、CTA（Call to Action） ボタンの色を議論するためにミーティングするのではなく、ユーザーの問題を解決し、アイデアのテストに集中するということです。
複数の部門から代表者を集めた部門横断チームを構築することで、デザイナーは多様なアイデア、経験、視点を活用することができます。この豊富な知識により、チームはより良いMVPを作り、より多くのアイデアをより早くテストすることができるのです。
リーンUX の利点は以下の５つにまとめられます：
- 無駄を省く
- 連携を促進
- 速い
- 効率的
- ユーザー中心
リーンUX の手法
リーンUX 手法の中心となる主な原則は以下の３つです：
- 仮定
- 仮説
- MVP（最小実行可能製品）
仮定
仮定は単なるアイデアですが、メリットとしては、間違っていても許されることです。これは「実験とリスクを取る」という リーンUX の哲学を補完するものですね。
仮説を立てるには、 思考 の段階で得た研究知識と問題提起が必要です。これらの知識があれば、次のような仮説を立てることができます：
- ビジネスの成果 – うまくいく成果とは？
- ユーザー – サポートしようとしている人（ユーザー・ペルソナ）について具体的にする
- ユーザーの成果 – ユーザーのペインポイントは何であり、製品がそれをどのように解決できるか？
- 製品の特徴 – 問題の解決に必要な製品の改善点
一連の仮定を強みに、問題解決のための仮説を立て始めることができます。
仮説
UXの仮説とは、以下の３つの変数を持つ検証可能な仮定です：
- しようとしていること
- （ユーザーのための）問題解決
- 望む結果の達成
仮説は次のように書くことができます： ［このユーザー］のために［これをする］ことで［この結果］が達成されると思われる。
理論は検証されるべきものであって、議論されるべきものではありません。なのでチームメンバーは、仮説がどうなるかについての意見をめぐって議論になることは避けないといけません。次に何をすべきかは、テスト結果に任せましょう！
MVP（最小利用可能製品）
製品全体をデザインする代わりに、チームは仮説を検証するための MVP（最小利用可能製品）を作ります。
仮説がうまくいけば、それを発展させるための小さな機能的製品を手に入れることができ、仮説が正しくない場合は、そのアイデアを捨てて、無駄な時間を最小限に抑えて次に進むことができます。
デザイナーは、ワイヤーフレーム、モックアップ、プロトタイプを使ってMVPを作り、あらゆるものをテストすることができます。チームは、より時間のかかるデジタルのデザインプロセスに取り組む前に、多くのアイデアをサッと洗い出すために、初期のテスト中に紙のMVPを作成することもあります。
MVP は仮説を検証できるものでないといけません。例えば、ボタンのインタラクションをテストしたい場合、紙のプロトタイプでは有意義な結果は得られませんよね。なので、デジタル製品のコンテクストの中でインタラクションをテストするには、色とコンテンツを備えた忠実度の高いプロトタイプを使用する方がいいでしょう。
それに対し、登録フォームをテストするために、何時間も何日もかけて完全に機能する忠実度の高い製品プロトタイプを作る必要はなく、シンプルなワイヤーフレームがあれば、より早く仕事を終わらせることができます。
UXPin における MVP
UXPin にあるデザインライブラリを使えば、デザイナーはコンポーネントをドラッグ＆ドロップして、MVP をサッと構築できます。高度なインタラクションを追加することもできるので、プロトタイプは最終製品のように見え、感じられるのです。
テストの精度を上げるために、より忠実なテストが必要ですか？
デザインと開発のギャップを埋めるテクノロジーである UXPin Merge を使って、MVP を次のレベルに引き上げましょう。UXPinのデザインエディタをリポジトリ（GitおよびStorybookとの統合が可能）を介して社内のデザインシステムに同期することで、デザイナーは完全に機能するコードコンポーネントを使用してプロトタイプを構築できます。
UXPin Mergeを活用してリーンUX のプロセスを最適化した使用事例として、PayPalが行った検証があります。あるデザイナーが１ページのプロトタイプ（またはMVP）を2つ作成しました。１つ目はイメージベースのツールで、２つ目はUXPin Mergeを使用しました。イメージベースのデザインツールを使用した場合では、デザイナーは MVP の作成に１時間強かかり、UXPin Mergeを使用した場合だと８分で作成できることがわかりました。その上、Mergeで作成したプロトタイプの方がより忠実で機能的でした。
UXPin Mergeについての詳細や、洗練されたコードベースのデザイン技術で DesignOpsの課題を解決する方法については、ぜひこちらをお読みください。
デザイナーが MVPを作り終えたら、次はテストです！
テスト
最後に、チームは仮説と MVP をテストします。プロトタイプのテストでアイデアの検証をできるだけでなく、リサーチャーがユーザーの行動やプロトタイプとのインタラクションを観察することで、貴重なインサイトを集めることができます。
また、ユーザビリティテストによってユーザビリティの問題やビジネスチャンスも明らかになり、デザイナーはそれを次の反復に追加することができます。
テスト結果を元に、リーンデザインチームは新たなインサイトを得ることができ、思考 の段階に戻ってプロセスを再開することができます。
まとめ
リーンUX のプロセスは、ワークフローを最適化し、連携を強化するために、従来のデザインプロセスを再構成します。チームは新しいスキルを学ぶ必要はありませんが、製品をデザインする新しい方法論へのマインドセットシフトが必要なのです。
この記事で説明してきたように、UXPinを使うことで リーンUX の考え方とワークフローが実現できます。また、コメント機能を使うことで、チームはコミュニケーションをとったり、タスクの割り当て、完了後は［解決済み］にしてタスク管理を円滑で明確に行うことができます。
さらに、デザインライブラリがあれば、デザイナーは低忠実度のプロトタイプを省略でき、ユーザビリティテスト参加者やステークホルダーから実用的なフィードバックを得られる、高忠実度の MVPにすぐに移ることができます。
そして何よりも、UXPinのドキュメンテーション機能によって作業を最小限に抑えることができます。デザイナーはデザインのハンドオフ時に、デベロッパーのために UIに注釈を付けたり、指示などの説明を作成したりすることができます。 世界最先端のコードベースデザインツールの使いやすさをぜひご体験ください。１４日間の無料トライアルはこちら。
