書評「LEAN UX」

3年くらい前に話題になっていた本ですが、今更ながら読んでみました。

どんな本?

帯の言葉を借りると「最適なデザインに、最短で到達する」ための開発手法、チームビルディングの話。

気になったところ

原則:進捗=結果(アウトプット)ではなく、成果(アウトカム)
機能やサービスを開発することは、結果です。これらの機能やサービスで達成を目指すビジネスゴールは、成果です。LeanUXでは、明示的に定義されたビジネスの成果を基準にして進捗を測ります。

目的あっての機能開発のはずが、関係者が増えると責任の所在もぼやけてきて、いつの間にか機能をリリースすることがゴールになりがちなので気をつけたいですね。

その辺りがなあなあになってしまわないよう、施策のissueを立てる際に、目標数字と期間を必ず決めるようにしました。

成果重視型の仕事を進めるための重要なツール「仮説ステートメント」
* 前提
* 仮説
* 成果
* ペルソナ
* 機能

施策を検討する際のテンプレートとして良さそう。

一番大事なのが前提。ここが間違っていればこれ以降のステップは全て意味が無い。 仮説は、前提を踏まえた上で検証したい内容。成果は仮説検証の指標。ペルソナは仮説の対象者。機能は仮説検証のために作るもの。

デザインの意思決定を測定可能な要因に還元してしまうことで、製品の利用を通じて感じられる喜びや細やかな間隔がとらえにくくなってしまうというものです。だからこそ、成功基準には定性的なフィードバックを含めることが重要だと考えています。

数字だけ見ていると気づけないこともありそう。

例えば、グループチャットのサービスにおいて、数字を見る限りではグループ参加まではたどり着いているので、問題はその先にあると思いきや、実はそれまでの工程が長すぎて参加した時点で離脱してしまっているとか。

MVPの計画では、まず「何を学ぼうとしているか」を検討すべきです。その際、以下の3つの基本的な質問について考えると効果的です。
1.デザインの対象となっている解決策には、そもそもニーズがあるか?
2.提供しようとしている解決策と機能には、価値があるか?
3.この解決策は、使いやすいか?

ついつい自分の仮説を過信してしまって施策案が膨らみがちなので、段階的に進めるということを意識して、毎回必ずMVPから始めることにより、チームとしても数字を見て検証しようという文化も育まれていきそう。

スタッガード・スプリント
開発の1スプリント前に先行してデザイン活動を行うプロセス。「デザイン・スプリント」の間にデザインと妥当性の確認を行い、それを開発スプリントの間にに実行される開発のストリームに渡します。(中略)チーム全体が同時に同じことに取り組んでいない状況を、簡単に生み出してしまう

今やろうとしていたのはまさにこのスタイルかも。施策案をストックしておいて、デザイン検討をちゃんと終えたものから開発に回していくような。 たしかに、しっかり検討し尽くしたつもりでも、なんらかの問題は出てきてしまうものなので、最善の形ではないかも。

ヒーローは不要
組織がLean UXを成功させるためには、デザイナーと非デザイナーを含む、あらゆるタイプの貢献者の幅広いコラボレーションが必要なのです。

デザイナーとしてリーダーシップを発揮するというよりかは、チームのデザインファシリテーターとして活動するのが良いのかも。

実践したいこと

「つくる」ではなく「当てる」に拘る

  • 施策に必ず目標数字と期間を設定する

「MVP」で始める

  • 自分の仮説を過信しない。必要最小限で始める。

コメントを残す

メールアドレスが公開されることはありません。