アジャイルUXとリーンUXは、コラボレーション、反復作業、ユーザー中心のエビデンスに基づくリサーチをシステムの中心に据えています。
どうしてですか？
もし、デジタル製品の設計や開発を、ひとつの仮説や計画、アイデアをもとに一気に進めるとしたら、どうなるでしょうか。完成品になるまでに、失敗する可能性があまりにも多いのです。
考えてみてください。1つのルールと観察で、性能とユーザーニーズのあらゆる側面を明らかにすることができるでしょうか？
例えば、テクノロジーの進歩は驚くほど速いので、必要なタスクを新しい方法で実行するためのより良い方法が登場するまでに、それほど長い時間はかからない可能性が高い。また、人は常に進化し、変化するものですから、昨日の問題は、1～2週間後に発見した問題ほど重要ではないかもしれません。また、あなたが最新の問題に対する解決策を考えている間に、競合他社が何か優れたものを発表し、あなたの現在のプロジェクトが少し物足りない、時代遅れ、あるいは単に不必要と思われるかもしれません。
そのような場合、一発勝負の企画で、一度の制作フェーズで、必要のないものを開発するのは、コスト高になる可能性が高いです。
アジャイルUXは、その特定の問題群を解決しました。
アジャイルUXがソフトウェア開発に登場したとき、その仕事は、そうした視野の狭い開発体制を過去のものにすることでした。
異なるセクション、ステージ、または機能を、より短いステップで、より小さな塊に分割して管理し、通常2〜3週間かけてレビューする方法を導入しました。設計・構築・テスト・発売のサイクルを、設計・構築・テスト・レビューのサイクルに格上げし、発売する価値のある製品が完成するまで、必要なだけ反復するようにしました。
どれも素敵な話でしょう？価値ある解決策です。
しかし、時間とお金の両方のリソースが要求されるようになり、より速く、より手頃な価格で市場に参入する方法を求める新興企業が増えるにつれ、リーンUXのアプローチは、時間とお金の予算が制限された新規事業にとって最も魅力的なものとなっていきました。
リーンUXとは？
項を追加した場合 リーン？ このような合理化は、時間の節約であれ、お金の節約であれ、手抜きだと思われるかもしれません。しかし、そうではありません。
リーンUXデザイナーは、レーシングドライバーだと考えてください。彼らは手抜きをするのではなく、最も効率的な方法を最高速度で見つけるのです。
リーンUXの手法は、最初のバージョンは決してベストではないという前提に大きく依存しており、実際、機能しないことも想定されています。このような考え方からすると、プロトタイプの何が問題なのかを発見するために、必要以上にプロトタイプを作る必要があるのでしょうか？そこで、MVPがプロセスにとって非常に重要になるのです。
リーンUXの仮定をテストするための最小実行可能プロダクトの使用
アジャイルUXと同様に、リーンUXは共同作業で、ユーザー中心で、一口大のセクションで構築されます。しかし、機能、セクション、またはプロセスを分けるのではなく、イテレーションは通常、前のプロトタイプで問題があると判断した点を基に作られた新しいまたは改訂されたMVPである。
この工程は、いわゆる 仮定法・仮説法.
それぞれの試作品が間違っていて、改善が必要だと仮定すれば、一連の仮定を導くことができる問題文が導き出されます。そのためにはどうすればいいのでしょうか？通常、チーム・ブレーンストーミングという形で、プロジェクトに関わるすべての人が参加する会話をすることです。チーム全員が議論に参加することで、プロセスのあらゆる部分でプロジェクトが直面しうる多くの問題が見えてくるのです。チームワークは夢を実現する、そうでしょう？リーンUXでは、まさにそれが重要なポイントなのです。
リーンUXの問題提起に取り組む
仮説は、証拠がないただの問題です。その問題点を中心に質問し、議論を重ねることで、それを検証するための仮説を立てることができるのです。
ユーザーテストが成功すれば、その証拠になります。そうでない場合は、そのアイデアを破棄して、次のアイデアに移ることができます。
しかし、同じようにユーザーテストを行うことで、ユーザーテストなしでは見えなかった別の問題が見つかるかもしれません。MVPがあれば、モデル全体を破棄して、より良い、より教育された立場から再スタートしなければならなくなったとしても、失うものはほとんどないのです。
問題文によって、議論とテストを続けることができます。目標は、製品と最初の目標を探求し、改善することであり、顧客のニーズについてさらに学び、ユーザーと次の段階のリーンUXペルソナのために最高の結果を提供することです。
リーンUXのエッセンス
アジャイルとリーンUXは性能が似ていますが、本質的な違いは、リーンUXは各MVPに依存する学習ループを使うことです。
実行可能な最小限の製品 は、UXデザイナーやリサーチャーができるだけ早くアイデアを検証できるようにするためのものです。したがって、機能が少なければ少ないほど、ノイズが少なく、素早く構築でき、テストスペースに落とすことができます。
ご覧のように、角を切るのではなく、無駄なディテールに邪魔されることなく、その周囲を飛び回っているのです。
各ラーニングループでは、UXリサーチとテスト技術に基づき、モニターで計測されたMVPを提供します。
では、リーンUXとアジャイルUXのテストループの違いは何なのでしょうか？
- リーンUXテストは、何が問題なのかを問い、そこから学ぶ。
- アジャイルUXテストループは、その最新版が本来の機能を発揮するかどうかを検証する。
最初の質問に戻ります：あなたのリーンUXチームは、プロアクティブですか、それともリアクティブですか？
リーンUXは、理論的には、ユーザーデータを基にした問題やニーズを発見するためにリサーチやデザイン思考を用い、各ステップでプロアクティブなプロセスを確保する必要があります。
しかし、ステークホルダーが自分の仮説に近すぎて、代替案を見出せない場合もあります。そのため、UXリサーチや仮説と仮説の対話を適切に行うことなく、最初のMVPを作成し、テストすることになります。これでは、ユーザーの仮説ではなく、一人のステークホルダーが立てた仮説を検証する、反応的なチームが出来上がってしまいます。
悲しいかな、これはリーンUXの的を外した典型的な状況であり、ユーザーテストによって てこずり はなく、ステークホルダーのアイデアに 咄嗟に 適切に構成された問題文を探求する。
このような状況では、プロダクトオーナーやステークホルダーは、自分自身の目隠しを外し、大局的な視点に立ち、理想的にはUXリサーチの基本に立ち返る必要があります。 デザイン協議会 ダブルダイヤモンド アプローチすることができます。左側のダイヤモンドに取り組むことで、単一で偏った仮定よりも真の問題を発見する可能性がはるかに高くなります。これは、デザイナーや研究者が、解決策を発見したり提案したりする前に、問題空間を完全に探索するのを助ける標準的なツールです。
ダブル・ダイヤモンド・アプローチをまだご存知ない方、あるいは、ダブル・ダイヤモンド・アプローチがどのようにして実際に解決すべき問題を決定するのか、簡単にご説明しますと、4つのシンプルなステージから2つのダイヤモンド・ステージを経て、私たちが解決すべき問題を確実に解決します。 しかるべきデザイン と 意匠権.
- ステージ1 ?リサーチで正しいものを発見する
- ステージ2 ?合成で正しいことを定義する
- ステージ3 ?アイデア出しを通じた正しい方法での開発
- ステージ4 ?実装を通して正しい方法で物事を実現する
フレームワークでは、次の4つを推進しています。 ようこう 問題解決者ができるだけ効率的に仕事ができるように：
- 人を第一に考える ?ニーズ、強み、願望を理解する。
- 視覚的に、そして包括的に伝える ?問題やアイデアについて、全員が共通の理解を得られるようにする。
- コラボレーションとコ・クリエイト ?一緒に仕事をすることで、インスピレーションを促進します。
- イテレート ?継続的なテストは、エラーを早期に発見し、リスクを低減し、信頼を築きます。
これらの重要な原則に聞き覚えがあると思われたなら、おめでとうございます。あとは、リーンUXの構築中に、これらの原則を確実に記憶し、軌道に乗せるだけです。
結論
今日は、私たちが定期的に目にする特定の問題を、シンプルなリーンUXの要約を使ってその場に落とし込んで考えてみました。デザインツールやリサーチツールを最大限に活用するためには、意図したとおりにプログラムを進めることが重要です。新しいベンチャーや機能の興奮に流されがちですが、夢を追いかけるのではなく、データを追いかけることがより重要です。
リーンUXについてもう少し理解したい方は、リーンUXをより深く理解するためのページをご覧ください。 アジャイルとリーンUXの違い 如何して リーンUXは、デザイン失敗の恐怖を克服するのに役立つ.最後に、このページでは、? ぜんかんきょうどう リーンUXでは、より広範で、より情報に基づいた、充実した問題や解決策を発見することができます。
UX24/7がリーンUXのアプローチでどのようにお役に立てるか、詳しくお知りになりたい方は、以下のメールアドレスまでご連絡ください。 hello@ux247.com.
