web-dev-qa-db-ja.com

UXは本質的にリーンでアジャイルであるべきではありませんか?

人々は、アジャイルUXやリーンUXなど、さまざまなタイプのUXについて説明します。アジャイルマニフェストと無駄のない方法論を見ると、UXプロセスの実装を成功させるには、とにかく柔軟で効率的なプロセスが必要であるように思えます。

アジャイルまたはリーンUXの使用は冗長ですか、それとも私が知らないことを意味しますか?

9
Michael Lai

私はUXのアジャイルで無駄のない方法論の堅固なサポーターですが、それらは単なる方法論であることを覚えておくことは重要です。 Xはhowではなく、whatユーザーエクスペリエンスはそうです。

したがって、優れた結果を達成できるさまざまなUX手法があります。多くの場合、1つの方法論が別の方法よりも状況に適しているため、(特定の制約がある場合)無駄のない/機敏な方法論が状況に最適な選択ではない場合があります。

14
JohnGB

これはすべて、UXの定義によって異なります...これは、経験から特定の種類の役割の職務の説明に至るまで、長年にわたって変化している獣でした。

個人的には、修飾子が必要だと私は言います。なぜなら、UXプラクティスは多くの異なるコンテキストで適用できるからです。例えば:

  1. ユーザージャーニーのグローバルな再設計と製品のビジュアルデザインを行うために導入された専用のUXエージェンシー-RUPを実行している既存の製品開発チームによって実装される設計仕様を提供します。彼らは明らかにアジャイルやリーンUXをやっていない。彼らは潜在的に彼らの作業コンテキストで素晴らしいUXの仕事をしている。

  2. スクラムチームで作業している組み込みのIxDとビジュアルデザインのペア-ストーリーの準備完了と完了の定義を理解し、ストーリーが実装されるときに優れたデザインを促進します。彼らはアジャイルチームと協力して、その環境に適したプロセスを選択して適応しています。しかし、彼らの製品は、フォーカスを提供することを学ぶのではなく、フォーカスを提供することを意味します。

  3. スタートアップの製品/市場適合について学習することを目的として製品開発チームに組み込まれたuxプラクティショナーのグループ。学習に重点を置いているため、アジャイルUXではなくリーンUXセクションに配置されます。彼らは多くの同じ慣行を使用しているかもしれません-しかし、彼らの目標は異なります。

さて、私は上記の3つのアプローチのどれがあなたに優れた製品をもたらす可能性が高いかについて私の意見を持っています-しかし、それらを異なるようにラベル付けできることは確かに合理的だと思います。ドメインに応じて、多かれ少なかれ適切なUX設計アプローチがあります。

個人的には、この種のUXプロセスについて議論しているUXドメインの成熟度を表しており、UXの仕事を行うための真の方法がないことに気づいていると思います。

5
adrianh

私の経験では、特にUXをアジャイル開発フレームワーク内に収めようとする場合、アジャイル開発はUXに対して敵対的になる可能性があります。アジャイルの問題は、開発チームにとってどの程度成功するかとは関係ありませんが、スプリント内でUXの概念が試みられた場合、または重要な設計がその場で行われ、開発が設計を推進している場合です。アジャイルは、開発者とUXに最適です。私の経験では、ビルド対象に適切なレベルの仕様を開発プロセスに提供すると、UXが最も効果的に機能します。

そして、それがリーンUXの出番です。私の理解(そして人によって理解が異なる)から、リーンUXはすべて、成果物の量を減らし、最終的なUXのコンセプト、コミュニケーション、テスト、開発に必要なものを作成しようとすることです。 「正しい」とは、プロジェクト間、そして最も重要なこととして、あなたが持っているチーム間で異なります。 1つのプロセスがすべてのチームとすべてのプロジェクトに適しているわけではなく、最終的にはプロジェクトではなくプロセスを失敗させるのはチームです。

リーンUXはまた、デザイナーにすべてのチームメンバーをデザインの共同作業者と見なさせようとするという古い考えを利用します。優れた開発チームはUXリソースとうまく連携し、優れたUXチーム/人は開発者が設計プロセスに関与するようにします。重要な部分は、UXの取り組みが尊重され、開発者にはエンジニアリングと実装に集中する許可が与えられ、設計や機能性に責任を負わないことです。

リーンUXは、UXソリューションが必要なときに開発者に提供される生産ラインが機能しているときに最適に機能しますが、開発者はUXソリューションが実行不可能な場合にのみ責任を負います。

つまり、要約すると、リーンUXは、うまくできていれば、アジャイル開発チームにうまく適合する優れた補完的アプローチですが、実際には同じものではありません。

また、リーンUXはリーンスタートアップと同じではありません。ビルドしてテストする必要はありませんが、ユーザーが物事をどのように使用するかを調査することに時間を費やすことができます。たとえば、イントラネットについてスタッフにインタビューするのに2週間費やした場合、 2か月の研究プロセスは無駄がありませんが、素晴らしいです。

2
Stewart Dean

リーンまたはアジャイルは、ソフトウェア開発であろうとUXデザインであろうと、規律を適用する方法論にすぎません。

UXスペシャリストと開発チーム(外部コンサルタント、社内フルタイムなど)の間の取り決めにより、使用する方法が大きく決まります。たとえば、開発組織の不可欠な部分ではない場合、リーンUXは、不可能ではないにしても、難しくなる可能性があります(この主張について間違っている場合は修正してください)。

UXの方法論に影響を与えるもう1つの要素は、開発チーム自体が使用するものです。ウォーターフォールスタイルで活動している組織がまだあると聞いて驚かれることでしょう(ただし、許可しない場合もあります)。もしそうなら、彼らは仕事を始める前に完全に詳細なUI仕様を期待します。

1
Dvir Adler