製品ライフサイクル
アジャイルUX：UXと製品設計をアジャイルに組み込む方法
DevOpsは、多くの場合、企業のソフトウェアおよびシステム開発を取り巻くプロセス、運用、方法論、ツール、および文化として定義されます。
しかし、エンジニアリングは真空状態では機能しません。ブループリント、アイデア、デザイン、およびコンセプトは、レイアウト、フロー、および対話性を決定する製品設計スペシャリストから提供されます。これらは、DevOpsの目標と望ましい結果を共有するエンジニアリング以外の個人およびチームです。
DevOpsはそれだけではありません 開発者がITに接続する方法、インフラストラクチャを管理する方法、フレームワークを改善する方法よりも。それは、ソフトウェア開発プロセスに実際に関与しているチームの数、それらの役割と作業がどのように絡み合っているかを認識し、全員がテーブルにいることを確認するためのより良い方法を見つけることです。
開発者とエンジニアリングアーキテクトは、製品チームとクリエイティブチームがソフトウェアまたはシステムを設計するときに関与したいと考えています。しかし、それは現在のDevOpsの定義のどこにありますか？製品、UX、およびクリエイティブチームは、エンジニアリングプロセスに関与し続けたいと考えていますが、非常に多くの方法論でそれらが除外されています。これらは、分解する必要のある古いサイロです。
あなたの顧客はあなたのユーザーエクスペリエンス（UX）だけを見ます。彼らはあなたが何人の開発者を持っていたか、あるいはあなたがアジャイルかリーンかを知りません。彼らは、どのDevOpsツールが使用されているのかわかりません。あなたの会社のUXは製品であり、それはあなたを成功させたり壊したりする可能性があります。彼らは誰がこのがらくたを作ったのか疑問に思います。非常に多くの競争があり、アプリをアンインストールしたりWebサイトを離れたりすることを喜んでいる人々がいる中で、あなたはあなたを捨てた顧客との2度目のチャンスを得ますか？
アジャイルはUXに関するトレーニングやUXスペシャリストとの協力はめったにありません
多くのエンジニアリングチームは、UXがサイロ化されており、コラボレーションが難しいと感じることがよくあります。 UXは無駄がないようで、アジャイルの多くのフレーバーはUXの操作方法の詳細を除外しています。一部のアジャイルアプローチは、機能を説明する製品所有者が「十分に良い」ことを具体的に示唆しています。
SAFe Agileは、UXサイロ化を解決する最善の方法はそれらを完全に除外することであると判断するという間違いを犯します。 SAFeは、「アジャイルチームに力を与えて」独自の「リーンUX」を実行します。より多くの企業が法人化の価値を理解するにつれて UXスペシャリスト そして完全なUXプロセスでは、SAFeは間違った方向に進んでいます。
アジャイルトレーニングや書籍からUXとそのプロセスを説明していないため、世界中のチームが専門の製品デザイナーの関与を排除または最小限に抑えています。
- UXがページにボックスを描画するだけだと誤って想像すると、「私はその仕事をすることができます」と簡単に推測できます。多くのアメリカンアイドルのオーディション対象者のように、彼らは地球上で最高の歌手であると確信しています。 プロダクトマネージャー エンジニアはUXが優れていると自己評価します。これは通常、彼らがスクリーンのレイアウトに優れていると信じていることを意味します。しかし、この記事では実際にUXの仕事に何が入るのかを説明しているので、UXスペシャリストが、ワイヤーフレームを作成する開発者をUXタスクを与えられるべき人物と見なさないことがわかります。
- スクラムに関する本は、UXスペシャリストがボトルネックになった場合、彼女は自分の仕事をするために非UXの役割を訓練する必要があることを示唆しています。この種の決定は、ソフトウェア開発における他の役割についてはめったに提案されません。ブートキャンプの後やプログラミングに関する本を読んだ後でも、訓練を受けていない開発者や経験の浅い開発者にコーディングをしてもらいたくはありません。開発者がボトルネックになった場合、コーディングを行うようにプロジェクトマネージャーをトレーニングする必要があることを示唆することは決してありません。
- UXが芸術的（UI）の仕事であると誤って信じている採用マネージャーは、UXの仕事をするためにアーティストを雇います。 UXとUIの学位の間に教育的な重複はありません。自然の才能はしばしば重複しません。 UXが得意な人は貧しいアーティストかもしれませんし、その逆もあり得ます。 「UX / UI」を採用すると、UXの経験、専門知識、プロセス、または教育が最小限の優れたアーティストになることがよくあります。
収益だけを見ている人は、UXの教育、経験、専門知識、スキル、または自然な才能が不足している可能性のある個人にUXタスクを与えることで、予算を削減したいと考えています。しかし、これは近視眼的であり、生産性、効率、文化、製品、および顧客満足度の低下につながる可能性があります。
2018年後半、経営コンサルティング会社McKinsey＆Companyは次のように発表しました。 デザインのビジネス価値 」、300社を超える企業で行った調査に関するレポート。
彼らは、「企業が群衆から目立つことができる唯一の方法はデザインである」ことを発見しました。競合他社が近い機能セットを持っている場合、何がそれらを際立たせますか？デザインは、美学、またはこれを私たちのブランドのように見せるものとして考えられることがあります。ただし、「UX」と一緒に使用する場合、デザインとは、機能のアーキテクチャと、画面、ステップ、フロー、レイアウト、プロセス、構成、およびメニューに関して行われる決定を意味します。
UXは継続的な改善プロセスの一部であり、常にユーザーをよりよく理解し、ユーザーのニーズに最適な機能と製品を選択して設計し、問題点を解決し、有意義なイノベーションをもたらすことを目指しています。
マッキンゼーはまた、「企業は、設計を後で適合する小さなツールと見なすのではなく、プロセスの早い段階で全体的に採用する必要があります」と報告しました。ユーザーエクスペリエンスへの注意は、製品のリリース後に最小限に抑えたり、除外したり、実行したりできるものであると想定しているチームは、間違ったアプローチを取っています。
マッキンゼーは定量的データを収集し、UXデザインを採用した企業が5年間で32％多くの収益と56％多くの株主利益を生み出したことを発見しました。会社を「ユーザー中心」であると宣言するだけでは不十分です。計画やポートフォリオから開発やQAに至るまで、UXの実践者とプロセスを統合することで歩みを進める必要があります。
UXの有無にかかわらずソフトウェア開発プロセス
あなたの会社がソフトウェアの設計と開発プロセスにUXスペシャリストを含めていない場合、あなたのプロセスはおそらく下の画像のようになります。
Javaメモリリークインタビューの質問
クライアント、プロダクトマネージャー、CEO、またはビジョンを持った人がエンジニアリングに彼らが望むものを伝えます。エンジニアリングはそれを構築し、テストし、ステージングサーバーまたは本番サーバーに取得します。ビジョンを持っている人はそれを見て、あなたは知らないでしょう、彼らは幸せではありません。彼らは何か違うものを望んでいるか、考えを変えました。
次に、エンジニアリングは最初に戻って、この人が今何を望んでいるのかを見つけ、構築し、テストし、これが魅力であることを指で交差させる必要があります。
チームにUXの専門家がいる場合、プロセスはまったく異なります。ビジョンを持ったその人は、アイデア、データ、および顧客の問題点を持ってUXに来ます。 UXは、ユーザー中心の設計プロセスでタスクを循環し、エンジニアリングがコード行を記述する前にこれらの概念をテストします。これにより、構築を検討している製品または機能が、ターゲット顧客にとって適切なアイデアを適切に実行することが保証されます。
テストによっていくつかの欠陥が明らかになる可能性があります。これにより、UXを繰り返し、多くの場合、再度テストすることができます。 UXのプロセスが完了すると、完全に精査された設計をエンジニアリングに提供する準備が整います。
誰かが途中で気が変わった場合、その人は開発者への変更要求としてそれを入れるのではなく、UXに話しかけます。 UXはプロセス中に干渉を実行し、UXが実際の顧客または典型的な顧客の設計、決定、およびテストに関与しない限り、エンジニアリングに何も送信されません。
この時点で誰かが考えを変えるためのコストは最小限であるため、この時点での心の変化は災害ではありません。エンジニアリングは青写真が提供されておらず、開始されておらず、再構築するものもありません。 UXは設計を繰り返し、ユーザーテストを実行して、アイデアが顧客ベースとよく一致していることを確認できます。心の変化は時間の燃焼ですが、予算への全体的な影響はわずかです。
UXには形式化されたプロセスがあります
ユーザー中心設計（UCD）は、UXスペシャリストに調査、設計、プロトタイプ作成、実際のユーザーまたは典型的なユーザーのテストを指示し、テストからの学習に基づいて反復するタスクを含む形式化されたプロセスです。
これらの領域のいくつかに焦点を当てて、 要件と初期の議論 機能とプロジェクトについて。 UXが最初に要件やその他のプロジェクト情報を取得したとき、すぐにコラボレーションを開始することが重要です。 UXは、構築できないものを設計したことを後で知ることはできません。
製品またはプロジェクトマネージャーが機能と優先順位を決定するときに、UXワーカーまたはマネージャーを取り込むことから始めます。ユーザーにとって価値のないプロジェクトを削除することができ、莫大な時間とお金を節約できます。ここで、行われていない作業の量を最大化することが重要になります。製品とエンジニアリングは、機能またはプロジェクト全体を削減または削除することでエンジニアリングの作業が少なくなる場合に、UXをサポートする必要があります。ただし、プロジェクトにエゴが添付されていることが多く、チームメートはこれらの初期の会話からUXを除外して、プロジェクトに資金を提供することがよくあります。
研究 UXが行うことの重要な部分です。ユーザーの関与なしにユーザー中心ではありません。統計と定量的データは素晴らしいですが、ユーザーにインタビューし、ユーザーを深く理解し、定性的データを取得することに代わるものはありません。 UXは、何だけでなく、なぜかを知りたがっています。
UXリサーチでは、ターゲット顧客の原型であるペルソナの周りの全員を統合することで、チームメイトを同じページに集めることもできます。ユーザーへのインタビューに基づいて、私たちは学んだことを集約し、6人以下のペルソナに全員を要約します。何が彼らを動機づけますか？彼らは何をする必要がありますか？当社、製品、またはサービスの機会はどこにありますか？
ペルソナの最良の使用法は、どこにでもそれらを含めることです。製品は、ペルソナ（および優れたデータ）に基づいて機能を想像します。ペルソナに基づくUXデザイン。 QAは、これらのペルソナであると想像しながらテストします。マーケティングは人口統計やその他の詳細を追加できますが、ブランドの声、ソーシャルメディア、広告がペルソナにどのように話しかけるかについても考慮する必要があります。
ペルソナは、UX以外の労働者が「まあ、私はこのように気に入っている」または「CEOがこのように気に入っている」から逃れるのに役立ちます。私たちはこれらのターゲット顧客向けに設計しており、あなたやCEOがペルソナに適合しない場合、UXはエゴや個人的な好みに左右されません。 UXは顧客志向を維持する必要があります。
情報アーキテクチャ 階層、構造、および分類法と関係があります。これは、サイトナビゲーションの場合もあれば、eコマースデータベースで製品が分類される方法の場合もあります。カテゴリ、メタデータ、フィルタで商品を簡単に見つけられるようにしたいと考えています。
インタラクションデザイン は、エクスペリエンスデザインとも呼ばれ、ほとんどの人がUXを想像するときに考えます。これらは、ワイヤーフレームとプロトタイプ、デザインとコンセプトの青写真です。これらには、プロセスフロー、レイアウト、メニュー、インタラクション、パス、選択肢などが表示されます。
UXプロトタイプは、生き生きとしたワイヤーフレームのようなものです。それらはクリック可能なインタラクティブなデジタルモックアップです。コードを書く必要はありません。これらをすばやく作成するのに役立つソフトウェアがあります。より現実的なプロトタイプを探している企業は、条件付きロジック、変数、モバイルスワイプジェスチャ、ドラッグアンドドロップ、およびあらゆる種類のイベントトリガーを備えているため、Axureを使用しています。ほぼすべてのタイプのデバイスのプロトタイプを作成できます。
UXプロトタイピングは次の目的で行われます。
- ブレーンストーミング
- コラボレーション
- 繰り返す
- ソリューションを探る
- 投資家への売り込み（スタートアップ向け）
- プロトタイプをテストして、ソリューションがターゲットオーディエンスとうまく接続されているかどうかを確認します。
- 開発者や他のチームメイトにインタラクティブモデルを提供します。これは、ドキュメントのページよりも好まれることがよくあります（クリック可能なモデルはありません）。
今それは行きます ユーザーテスト 、ユーザビリティテストとも呼ばれます。これは、UXプロセス中、エンジニアリングがコード行を書き込む前に行われます。コンセプトとデザインをテストして、アイデアと実行がターゲット顧客にとって素晴らしいものであることを確認する必要があります。
ユーザーテストは欠陥を明らかにし、UXにアイデアを繰り返す機会を与えます。これは、エンジニアリングが構築または再構築するものがないため、現時点では安価です。
UXがエンジニアリングに提供する前にテストを実行する5つの主な理由があります。
- エンジニアリングの時間とリソースを最大限に活用します。 テスト参加者にエンジニアが作成した完成品を見てもらいたい場合は、バグがないかビルドしてテストする必要があります。 UXテストで必要な変更が明らかになった場合、開発者は再構築し、QAは再テストする必要があります。 UXテストでコンセプトの大きな失敗が示された場合、これはどこかに行き着くコードではないため、エンジニアリングの時間が完全に無駄になったことを意味する可能性があります。コンセプトは再考され、再設計され、新たにテストされる必要があります。
- 舞台裏で繰り返します。 企業がそれを構築し、出荷し、繰り返し、そして構築して再度出荷する場合、これは顧客がさまざまなバージョンを見ていることを意味します。彼らは進行中の作業を見て、ソーセージが作られているのを見ています。これは多くの場合、顧客が進化しているシステムを再学習し続けることを要求する、苛立たしくて混乱する経験です。 UXプロセスの舞台裏を繰り返し、それがプロトタイプまたはデモンストレーションバージョンであることをテスターに明確にすることをお勧めします。
- 監視と測定。 新しいコンセプトがライブでリリースされた場合、UXの研究者は、人々がそれを使用するのを見て、質問をし、UXが何かの準備ができているか、別の反復が必要かを判断するために必要なフィードバックの種類を取得する良い方法がありません。 UXは常に、何を、いくつだけでなく、その理由、定性を知りたいと考えています。ユーザーはどのように支出、コンバージョン、エンゲージメントなどを行っていますか？適切なUXテストを回避すると、問題や顧客の問題点を診断して修正することが難しくなります。
- UXテストはそれ自体で報われます。 UXテストは大きな出費ではありません。サードパーティのテストツールの中には、テスト参加者1人あたり100ドル未満を必要とするものもあれば、年間最低数千ドルのコミットメントを必要とするものもあります。ソフトウェア開発プロセスに対する会社の全体的な予算と、早期のテストフィードバックの重要性を考えると、これらは莫大な費用ではありません。ユーザーテストのラウンドは、ほとんどの場合、プログラマーに元に戻したり、再度ビルドしたりする必要があるものをビルドさせるよりも、コストが低く、動きが速くなります。
- ユーザーテストは引数を解決します。 あなたの会社がUXスペシャリストに製品の設計方法に関する最終決定を許可していない場合、何を構築してリリースするかについてさまざまなアイデアがあると、UXが製品、エンジニアリング、または利害関係者と競合することに気付く可能性があります。お客様。または、UXに2つの強力なアイデアがあり、どちらが顧客とのつながりが良いのか疑問に思っている場合はどうでしょうか。ここでの解決策は、ユーザーテストです。
UXは概念のプロトタイプを作成できます。特にアイデアやチームメンバー間で妥協点をすでに見つけている場合は、競争を最高の2つのデザインにまとめることが最善です。つまり、UXが何を望んでいるか、製品が何を好むか、エンジニアリングヘッドが何を好むか、スクラムマスターが良いアイデアのように思えるか、CEOのライフパートナーが何を好むかをテストしていません。
ユーザーテストにより、顧客は声を上げ、機能や製品の正しい方向性を見つけることができます。チームにハードな定量的および定性的データを提供することで議論を解決し、どのアイデアが最も顧客満足度を高める可能性があるかを全員に伝えます。
ユーザーを巻き込まないユーザー中心設計ではありません。これは、推測、想定、または「出荷する」のではなく、実際の顧客または典型的な顧客を対象に調査およびテストを行うことを意味します。 「出荷するだけ」のものがユーザーテストを通じて精査され、優れたアイデアの優れた実行であることを確認する必要があります。
UXが回避または削減されるとどうなりますか？
Skypeは最近、Snapchatのようにすることを目的とした2017年の再設計が失敗したことを発表しました。ユーザーは新機能を望んでいなかった、必要としなかった、または気に入らなかった。反発は十分に大きかったので、Skypeは2018年にSkypeを再設計すると発表しました。 （（ https://devops.icu/skypes-coming-redesign-of-their-last-redesign/ ）
UXの専門家は、プロセスの多くのステップで、これらの機能が不要であるか失敗する可能性があることを知っていたでしょう。ターゲットユーザーを対象にした調査では、SkypeをSnapchatにしたくないことがすぐに明らかになりました。この早い段階でプロジェクトを殺したり、ピボットしたりすることで、Skypeに数百万ドルを節約し、さらに悪い報道や顧客の疎外を防ぐことができたはずです。
UXの調査が迂回されたとしても、ユーザーでUXプロトタイプをテストすると、顧客はSkypeがこの方向に進むことを望んでいないことが明らかになります。 UXはまだプロセスを進めているため、エンジニアリングはまだコード行を記述していません。これにより、時間、費用、人的資源を大幅に節約でき、シンプルさを称え、作業エンジニアリングを行う必要がなくなりました。
アジャイルUXプロセス
アジャイルマニフェストの原則を覚えておいてください。あなたの最優先事項は、価値のあるソフトウェアを構築することによる顧客満足です。 （UX）ワーカーに必要な環境とサポートを提供し、仕事を成し遂げるために彼らを信頼します。仕事量を最大化する ない 完了しました。優れたデザインへの継続的な注意は敏捷性を高めます。
前進しているプロジェクトは、適切な研究、設計、およびテストを開始できるように、UXに巨大な滑走路を与える必要があります。 UXをキックオフミーティングに招待しないでください。最終的なワイヤーフレームを数日で納品する必要があるという要求で彼らを驚かせてください。 それはUXではありません。
これをBigDesign Up Front（BDUF）と見なさないでください。これは、人々をうんざりさせ、これを回避する必要があることを宣言するために設計された用語です。プロジェクトや機能が大規模または新規の場合、UXは、すべてではないにしても、ユーザー中心の設計プロセスのほとんどを循環する必要があります。 UXの場合、より大きな機能を実現するための最小の要素は、ユーザーのワークフローまたはプロセスです。より小さなものを設計してテストすると、真のユーザーエクスペリエンスの全体像が得られないというリスクがあります。
たとえば、ユーザーが登録して購入するフローを設計している場合、パスワード選択フィールドを設計してエンジニアリングに送信するだけでは不十分です。 UXが細かく機能する場合、プロセス全体はいつテストされますか？フロー全体をテストしないと、フロー全体に対するユーザーの反応を知ることはできません。つまり、ユーザビリティテストに進む前に、フロー全体を設計する必要があります。
機能、ストーリー、または修正が小さい場合、UXの実践者は、ユーザー中心の設計プロセスのサブセットを実行して、より迅速に作業できます。 UXは常に可能な限り高速に実行されますが、優れたUXスペシャリストは、実行中の作業の品質を犠牲にすることを避けるために、できる限りのことを行います。速い対良い戦いでは、UXは常に速いよりも良いものを選びます…そしてあなたもそうすべきです。
予算とタイムラインは、UXが迅速なフィードバックを取得して反復することを妨げるものです。 UXの実践者は常にフィードバックと製品を改善する機会を求めており、顧客にとって実際に機能するものを設計することを目指しています。ポートフォリオの管理と計画の早い段階でUXの実践者を呼び込むことで、UXは必要な時間と予算を見積もることができます。これらは後で驚きや対立の原因になるべきではありません。
UXプラクティショナーはアジャイルチームの一員です
UXデザイナーをアジャイルチームに組み込みます。計画、スタンドアップ、レトロ、およびUXについて話し合う可能性のあるすべての会議をリリースするように招待します。 UXがリリース計画中に時間を見積もることができるようにして、UXタスクに必要なタイミングについての驚きがないようにします。それらなしで決定を下さないでください。 UXチームメイトが会議に参加できなかった場合は、チャット、電子メール、または会社が使用している方法で、直接会うことができるまで待ちます。
質問、あいまいさ、またはバグをJIRAまたは使用しているバグ追跡システムのUXチームメイトに割り当てます。 UXの問題が他の問題と同じシステムにあることを確認してください。他のすべてにVersionOneを使用している場合は、TrelloボードにUXの問題をドロップしないでください。
UXの長い滑走路ができた後、この機能または製品に必要な場合は、エンジニアリングの前にUXを2スプリント以上にすることをお勧めします。 UXはあなたと一緒にスプリントすることができます。たくさんの技術的な話や技術的負債の修正をバックログに入れてください。そうすれば、UXの創造的で周期的なプロセスの実行が遅れたり、より多くのスプリントが必要になったりした場合でも、開発者は本当に機敏に対応できます。 UXを待つ代わりに、製品やエンジニアリングが優先している、ぶら下がっている果物に切り替えることができます。
また、リソース、割り当て、および人員配置も検討してください。プロジェクトのサイズに応じて、1人のUXデザイナーに割り当てるプロジェクトは3つまでです。テストと分析も行う個別のエキスパートUX研究者がいる場合は、1人の研究者を3人以下のUXデザイナーに割り当てます。 UXプラクティショナーがT字型と呼ばれるものである場合、つまり、彼女は研究、テスト、その他のUXサブスペシャリティにも精通しており、優れている場合は、あまりにも多くのプロジェクトに割り当てられて、誤ってボトルネックにならないようにしてください。
測定結果
顧客満足がなければ、顧客がいない可能性があります。顧客満足度の指標を使用して、UXを統合することによるプロセスの改善がどのように前向きな変化をもたらしたかを判断できます。
- 苦情が少ない
- より良いアプリレビュー
- より高いアプリ評価
- サポートチケットが少ない
- コールセンターへの電話が少ない
- ソーシャル投稿のよりポジティブなセマンティクス
- より多くのアプリのインストール、より少ないアンインストール
- AOV（平均注文額）の増加
- より高いコンバージョン率
また、市場投入までの時間や修正間の時間など、必要なDevOpsの目標を測定することもできます。 UX革命の前後に、ストーリー、プロジェクト、叙事詩が市場に出るまでにどのくらい時間がかかりますか？開発者の時間の見積もりは、ストーリーや現在行っていることから作業するのではなく、見積もりの基礎となるUXデザインを完成させた方が正確になる可能性があります。
UXが青写真を提供していて、それが守られている場合、予期しない変更や再構築を減らすことで、エンジニアリングの作業が減ることを期待しています。 UXデザインを早期に改善し、後で修正する回数を減らします。
アジャイルUXは、それ自体で支払う以上の投資です
多くのプロジェクトマネージャーは、UXを削除または削減できる予算ラインと見なしており、採用マネージャーはUXタスクを別の役割と組み合わせるというアイデアに興奮しています。しかし、訓練を受けた経験豊富なUXスペシャリストが実施する適切なUXプロセスに投資する以外に方法がないことを学ぶ企業が増えています。
エリックリース、著者 リーンスタートアップ 、「誰も望まないものを自分たちで作っていることに気づいたらどうなるでしょうか。その場合、時間通りに予算内でそれを行った場合、何が問題になりましたか？」組織がリーン方法論を使用していない場合でも、警告は当てはまります。 DevOpsの望ましい結果は、お客様に適切なものを構築し、お客様の満足度を向上させ、お客様の価値の高い機能を開発することを目指している場合に、これを反映しています。
ゲシュタルトの原則は何ですか
顧客を知り、プロセスに顧客を関与させ、真のニーズと好みに合わせて構築することは、最終的には、タイムライン、予算、フレームワーク、およびツールよりも重要です。適切なアイデアの適切な実行を構築すれば、収益がそこにあると信じてください。
基本を理解する
UXとUIデザインとは何ですか？
UXデザインは、機能または製品のプロセスフローと実行を概念化し、設計し、レイアウトするプロセスです。焦点は、学習と使用の容易さ、顧客のニーズへの対応、およびアクセシビリティにあります。 UIは、ビジュアルデザイン、ブランディング、タイポグラフィ、アイコン、その他の美学に重点を置いています。
アジャイルUXとは何ですか？
アジャイルUXは、アジャイルソフトウェア開発と、UXスペシャリストによる製品およびインタラクションデザインをもたらします。アジャイルチームにUXエキスパートを組み込み、UXの役割を理解して評価する必要があります。これは、調査とテストを含むUXの全プロセスに時間と予算を割り当てることを意味します。
リーンUXとは何ですか？
リーンUXは、ビルド、測定、学習の迅速なサイクルを使用して、製品設計を反復します。リーンUXは、MVP、最小限の実行可能な製品をリリースすることを目的としたソフトウェア開発プロセスにおける研究、テスト、およびコラボレーションの必要性を強調しています。機能が少ない製品は、より迅速に展開できます。
リーンUXとアジャイルUX：違いは何ですか？
リーンとアジャイルは、顧客のニーズに最適な製品を生み出す迅速な開発サイクルを目指しています。 UXの実践者はそれぞれに少し異なるアプローチをとる必要がありますが、どちらもUXの構築、テスト、学習を必要とし、エンジニアリングがコーディングを開始する前に、高速フィードバックと反復を使用して製品を検証します。
アジャイルリリーストレインとは何ですか？
アジャイルリリーストレイン（ART）は、エンドユーザーに利益をもたらすソリューションの構築を目的としたチームのクロスファンクショナルチームです。トレインは、機能、実装、展開、リリースの定義を循環して、ソリューションを提供します。 ARTは、Scaled Agile FrameworkIncのSAFeAgileの構成です。
