リーンUXでは、より大きなビジョンに取り組むことができますか？
私はアジャイルなソフトウェア開発環境で働いています。現在、既存のエンタープライズソフトウェアに3つの大きな新機能を実装する予定です。それらのすべてが長く息をのむようなコンセプトフェーズを経験しています。大きなドキュメントと高品質のワイヤーフレームが作成され、より長い研究期間の後に議論されます。
一方で、これはアジャイルUXアプローチとは関係ありません。一方、これらのかなり大きな新しい機能には、何らかのビジョンが必要です。現時点では、これらの新しい関数の最初のインクリメントが実装されたときに、よりスリムな作業方法が遅かれ早かれ進化する、ある種の移行フェーズにいます。
「リーンUX」は、全体像に取り組むことなく、常にリーンな方法で働かなければならないと言っていますか？ユーザーと利害関係者のニーズに常に（短い頻度で）即座に対応する必要がありますか、それとも、現在の状況でしばらくの間全体像に取り組むことは合法ですか？
私は常にこの種のトピックについての記事に対して「この働き方は新しい誇大宣伝であり、それは完全にエンタープライズビジネスで機能します」というアレルギーがあります。
リーンUXの私の問題は、ワイヤーフレームとプロトタイピングに費やす時間を減らし、ユーザーが製品をより早く使用できるようにすることで、ユーザーエクスペリエンスにより集中できるということですが、ユーザーエクスペリエンスもこれらのワイヤーフレームで作成されます。これらの面白さにもう少し時間を費やすことは私の意見にとって悪いことではありません。
また、Webアプリでできるように反復できないソフトウェアに取り組んでいる場合はどうでしょうか。ソフトウェアを使用すると、多くの場合、最初から正しく理解する必要があります。更新によってUIが変更されることはありません。
事実はすべての会社が異なる働きをすることであり、あなたは最もうまく機能し、feelsあなたにとって最良の戦略を実装する必要があります。ですから、全体像にしばらく取り組むことがうまくいくなら、それをやれば、もう無駄のない仕事をしていると思わないようにしてください。
リーンUXルールをガイドラインとして使用し、コンセプトフェーズに不必要に長い時間がかからないようにしてください。
リーンUXは、処方箋ではなく原則によって推進されます
リーンUXの人気が高まるにつれ、 "do n't create hi-fi wireframes"、またはのような一連の処方箋に翻訳されたのは当然のことです。 ）「デザインは部門を超えて機能する必要があります」。
実際、Leanはこれらの厳格な処方についてはまったく触れていません。リーンUXは情報に基づく原則のコアセットによって推進されます。
- 初期のクロスファンクショナルコラボレーションのメリットへの信念。これは、孤立した、切り離された、時間のかかる線形/ウォーターフォールプロセスが崩壊するためです。
- 小規模なチーム開発への信念。これにより、集中力、コミュニケーション、全体的なチームワークが向上します。
- 開発プロセスの無駄を減らすため、継続的かつ早期の発見に対する信念
- 等.
（詳細なリストについては、Jeff Gothelfが リーンUXに関する本 を開始して、コアリーンUXの原則のセットを定義します）。
これらの原則では、Hi-Fiワイヤーフレームを避けたり、時期尚早の顧客リリースに向けて無謀に充電したりする必要はありません。彼らが代わりに提供するのは、無駄のないUXを実践する方法と理由に関する明確な原則のセットです状況に効果的な方法で。
たとえば、hi-fiワイヤーフレームは、顧客による早期検証を犠牲にするため、多くの環境では意味をなさない場合があります。しかし、一部の環境ではhi-fiワイヤーフレームが適切なリーンUXアプローチかもしれません：
複雑なエンタープライズシステムでは、hi-fi設計のワイヤーフレームは、高価で時間のかかるフロントエンドのコーディング時間を短縮するのに役立ち、製品が顧客の検証にすばやく到達できるようにします。
大規模な多層アプリケーションの場合、詳細な高レベルのストーリーボードがサブチームにはるかに優れた統合ドキュメントを提供し、モジュールとチーム間の無駄な通信を最小限に抑えながら、低Fiのワイヤーフレームとプロトタイプで効果的に機能します。
これらの例の両方で、アプローチリーン原則の使用を最大化してプロジェクトに真の利益をもたらすであるため、高忠実度設計は適切なリーンUXプラクティスを提供します。
同じことが他のリーンUX処方にも当てはまります（「早期の顧客検証」など...時期尚早な検証は、より思慮深いプロトタイプよりも多くの時間と労力を浪費することがあります）。
お役に立てば幸いです。
リーンUXの基本的な目標は、私が理解しているように、不確実性を減らすことです。
これの望ましい副作用は、時間とリソースを浪費しないことですが、これはプロセスや目標自体ではなく、単に快適な副産物です。設計のイテレーションへのレースが見落とすよりも多くの質問に答える助けにならない場合、それはプロジェクトに有害である可能性があります。
アイデアをユーザーテストする前に、最初にアイデアを生成できるようにする幅広いオープンなブレーンストーミングとクリエイティブプロセスに従事する必要があります。それ以外の場合は、ブラインドを装着し、最初に思いついた最初のことをテスト/精査します。数週間後、それが悪いアイデアであり、最初からやり直す必要があることを発見しただけです。このように作業すると、チームは勢いを増し、常に創造的な考え方から出入りすることが難しくなる可能性があります。
これらの「全体像」のセッションは引き続き重要ですが、リーンアプローチを適用することもできます。セッションを使用して不確実性を減らし、内部で繰り返して、プロトタイピングにすぐに移行する場合に考慮しないチーム間の質問と複雑さを明らかにします。
たぶん、優れたUIコンセプトが技術的に実現可能/手頃な価格ではないことにプログラマーが気付くまでに、いくつかの議論といくつかの実験が必要かもしれません。たぶん、設計者はプロジェクトの目的とビジネス目標を不正確に理解していて、これは議論を通してのみ明らかになります。誰もが自分の知らなかった質問や、質問する必要があると気付く資格のない質問に答えるのに役立つように、幅広い議論のプロセスにはまだ余裕が必要です。
ユーザーのフィードバックを収集して統合することと同じくらい（それ以上ではないにしても）、これらの内部の質問に答えることは重要です。そうでなければ、1人が細心の注意を払って検証されたユーザーフィードバックで行うことは、他の人が期待するものとはまったく異なり、リーンプロセス全体を損なう可能性があります。
リスクあり
リーン氏は全体像の無知を規定していませんが、注意しないと忍び寄る可能性があります。本番環境で学習および調整するアプローチを採用すると（これは優れた点です）、常に「バグ」に取り憑かれた一種のUX Dev Opsになることができます。
そして解決策
無駄のないアプローチが全体像の時間を使い果たしていることに気付いた場合は、パスを選択する必要があります。チームをディスカバリーグループとプロダクショングループ（または自分に合ったラベル）に構成できます。または、時間を制限して、分割されていない小さなチームに同様の部門を作成します。