AppSociallyの萩原です。このブログでは、私たちの会社でUXチームの運営のベースとして使用している「UX for Lean Startups」の概要を紹介しています。非常に優れた書籍ですが、日本語版が出版されていませんので、その魅力を何回かに分けてお伝えしていければと思っています。

前回は、「UX for Lean Startups」の読者対象や読み進め方、おおまかな概要を紹介しました。前回はこちらよりご覧ください。UXデザイナーの教科書 “UX for Lean Startups” とは何か?

http://www.amazon.co.jp/UX-Lean-Startups-Experience-Research/dp/1449334911

今回は、そもそも本のタイトルにもなっているLeanUXとは何か?について書いていきます。LeanUXを構成する6つの要素を紹介します。

はじめに — Lean UXとは?

Lean UXは一過性の言葉ではありません。

デザインの改善にあたって土台になるものであり、長い間多くの人々に実践されてきた手法です。 実際、多くの人はユーザー中心設計(user-centered design)やアジャイル設計(Agile design)と混同しがちです。理由として、Lean UXの大部分がユーザー中心設計やアジャイル設計に近いためです。

しかし、Lean UXにはそれら二つにはないデザインの手法も含まれています。それでは、Lean UXを構成する要素を見ていきましょう。

1. Lean UX Is About Validating Hypotheses

Lean UXはLean Startupがそうであるように、仮設を検証していくことです。これは”ビジョン”が先行する従来のデザインと大きく異なります。

http://blog.marksweep.com/post/12770665811/double-loop-learning-and-the-lean-startup

ユーザーから学んで、仮設を立て、実装して測定する、そして仮設を立てる。この繰り返しです。

例えば、ユーザーのコメントをストアするために商品ページにコメント欄を追加しようという改善案が提案されたとします。それに従ってプロダクトマネージャーがワイヤーフレームを作り、それを元にデザイナーがデザインをし、エンジニアがコードを書いていきました。全体の期間としては2,3ヶ月かかっています。最終的に、ユーザーがコメントを残せるようになりました。しかし、それは一体なんのメリットがあるのでしょうか、それによってユーザーがお金を使うようになったのでしょうか。何のためにX社は数ヶ月かけてコメントシステムをつくったのでしょうか。

このアプローチの問題は、仮説ではなく機能から始まってしまったことです。それでは例えば、もしX ”利益を増やせる仕組みを見つけた。事前調査によると、商品ページにコメントが存在している商品のほうがユーザーが買いやすくなるようだ。これを検証してみよう”と言って始めたならばどうでしょうか。 UXデザイナーがこの仮説を検証するための方法を提案するでしょう。それは例えば、ある商品ページに手動でコメントを追加して、そのコメントつきのページが他のページと比べてより多く売れるかを確認するというものかもしれません。

上記の2つのアプローチが導く結果は同じかもしれまんせんが、仮説を立てて検証したほうが明らかにコストは抑えることができます。 Lean UXは機能を追加することではありません、顧客の課題を見つけ、それをどう解決するかを考え、それを検証していくことなのです。

2. Lean UX Is User Centered

Lean Startupは、ユーザーから学んだアイデアに基づいて成り立っているように、Lean UXにおいてもUser- Centered Design (UCD)非常に重要です。幸いなことに、多くの人がUCDを実践しているので、彼らから学ぶことができるでしょう。

3. Lean UX Is Agile

Agileでは、エンジニアとデザイナーも含んだ多機能なチームをつくります。これはLean UXも同様であり、それによって失敗したときに素早く変更を加えることができます。またAgileでは、大量のドキュメントの代わりに、ピクセル単位で整えられた全ページのモックアップを用意します。このようにしてLean UXでは、Agileのように製品のフィードバックを受けるまでの時間を短くして早いサイクルを回せるようにします。

4. Lean UX Is Data Driven

Lean UXの大切な考えのうちの一つに、新しいデザインや機能を追加したところで製品がよくなるとは限らないということがあります。すべてテストをして、その変更が主要なユーザーの振る舞いに重要な影響をあたえるのかを明らかにしていきます。

デプロイとテストのフィールドバックループをデザイナーに適用し、Design, Mesure, Learnのサイクルを回していきます。そのDesignに変更することによってどれだけのインパクトがあるのかを測定し、そこから実施するかを判定していきます。もし変更がユーザーに悪影響を及ばしたなら、どの前提が間違いを発生させ、どの仮説が検証されていなかったかを調査します。この繰り返しはデザイナーにとっても、ユーザーの本当の振る舞いを知るという意味で有用なものになります。

5. Lean UX Is Fast and Cheap (Sometimes)

Leanはよく誤解され、出来るだけ安く行うことと同義に捉えられていますが、そういうわけではありません。しかしながらLeanUXは通常のUXに比べれば、安く時間をかけずに行えることは事実です。

それはすべての工程において無駄を排除しているからです。出来るだけ小さなテストを行ってプロダクトの検証をしていきます。そのためイニシャルのコストは小さく抑えられます。ただし、プロダクトのデザインを適切にするためのツールを準備するためのコストはかけるべきでしょう。

6. Lean UX Is Iterative (Always)

”Minimum Viable Product(MVP)”はLeanUXにおいて大きな役割を担っています。MVPについての詳細は後に単一の章として紹介しますので、簡潔に言うと、仮説を検証できる最小限のプロダクトです。一度、MVPを作ったら、それを継続して検証と改善を繰り返していきます。新機能だけでなく、既存の機能も継続して検証を繰り返すべきです。この反復させるプロセスは、非常に大切なコンセプトですが多くの人が見落としがちです。

いかがだったでしょうか。LeanUXを構成するキーワードである、仮説検証/ユーザー中心設計/アジャイル/データドリブン/繰り返しについて紹介しました。

次回からは、Validationの部分について紹介していきます。

--

--

Shingo Hagiwara

サンフランシスコと東京でエンジニアをしています。SFまわりの話題について書いています。 @AppSocially / @ChatCenteriO