アジャイル開発チームによる一元化されたUI / UX？
異なる場所に、複数の部門にまたがるアジャイルチームがあり、最大2〜3のソリューションを集約する製品に取り組んでいます。そのようなチーム全体で企業が一貫したUXを管理する方法の例はありますか？スタイルガイドは良い出発点ですが、UI/UX設計の一貫性を管理し、新しい設計を推進すると同時に、機能横断的なアジャイルチームに力を与えるにはどうすればよいでしょうか。責任と説明責任を区別できますか？アドビのような企業はこれをどのように管理しますか？考えやフィードバックはありがたいことに受け入れられました。
難しい質問-正解が1つもない場合、これはおそらくモデレーターがこれにすぐにジャンプすることを意味します。しかし、私が役に立つほど速くタイプできると仮定すると...
この作品でジェフ・パットンが与えるアドバイスは、かなりスポットになっています。古い投稿ですが、良い投稿です。私がこじ開ける唯一のものはデュアルトラックアプローチについてのアドバイスです...しかし、それはそれ自体で別のエッセイの答えです。 http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
最も効果的であると私が見たのは、一元化されたグループではなく、各チームにUXフォークを組み込むことです。ほとんどの場合、アジャイルプロセスでは、UXを個別に動作させるにはオーバーヘッドが多すぎます。 UXがボトルネックになると、無視されるかバイパスされることがよくあります。
私が見てきた組み込みUXの利点は次のとおりです。
チーム全体でUXの価値をはるかに上回っています。人々はそれに入る仕事にもっとさらされ、あなたがそれをうまくやることから得られる見返りをより簡単に見ることができます。
特定の問題に集中することができ、より効果的に深く取り組むことができます。開発中にいることで、より多くの日和見的な研究作業を行う機会を得て、研究をフェーズではなく継続的な進行中のプロセスに変えることができます。最初のプロトタイプを顧客が経験するなどして発生する新しい問題を見つける。
UXに携わる人が増える-特にUXの人が少なすぎる状況では。チームに参加している場合は、チームメンバーと時間を費やし、促進し、指導し、より多くの人々に研究活動を手伝ってもらうことができます。もちろん、すぐに人を優れた研究者に変えることはできません。しかし、私は人々が基本を理解し、有用な貢献を始めることができる速さに驚いています。
問題が発生したときにそれを見たり、オプションを提案したり、日和見主義の調査を行って問題を強調表示したり、特定したり、中間文書のアーティファクトを作成する時間を短縮したりするため、フィードバックループがより緊密になります。
私が遭遇した唯一の欠点について、そしてそれが欠点であるかどうかさえもわかりませんが、UX作業を行うためのリソースの不足が表面化する傾向があるということです。しかし、私にとって、あなたがそれから得る価値は、その戦いをする価値がある以上のものです。
裏側は、UXerをマルチタスクにした私の経験です。利点は明白です-より少ない研究者がより多くのチームをサポートします-しかし私の経験では欠点はそれを上回ります：
UXの作業は段階的に行われ、進行中の製品開発作業とは分離される傾向があります。
継続的ではないため、チームとのフェーズ/タッチポイントの間に発生する非常に重要なことを見逃す可能性があります。
UXアクティビティの価値についてチームの他のメンバーが賛同することは、はるかに困難です。
他の人が行ったUXアクティビティを促進および管理するために周りにいないため、UXの作業が少なくなります。
ドキュメントの作成や他のアーティファクトの作成により多くの時間を費やして、チームの他のメンバーと一緒にいる場合は、より簡単にできることを伝えます。研究活動の時間をさらに削減する。
マルチタスクはhardです。プロジェクト間のコンテキスト切り替えに費やす時間を過小評価するのは簡単です。
あなたがまだそれらに遭遇していない場合、興味のあるGDSでのUX研究に関するLeisa Reicheltによるこのブログ投稿を見つけると思います https://gds.blog.gov.uk/2013/08/30/how-we-do-user-research-in-agile-teams /
よくあるもう1つのことは、個別のUXストーリーを用意することです。さまざまな理由から、これはお勧めしません。代わりに、私の推奨するアプローチは次のとおりです。
UXの仕事が機能の提供に関連している場合-その仕事をその機能のストーリーの一部にします。チームがストーリーの準備完了と完了の定義を持っている場合、それは多くの場合、適切な種類のUX入力と作業が適切なタイミングで行われていることを確認できる場所です。
ストーリーではなく、定期的なケイデンスで研究活動を定義します。 （例えば、スプリント後にユーザビリティテストを行う）。
UX作業を、POおよび製品マネージャーが何を構築するかを決定するために使用しているプロセスに統合します。または、最近では、チーム全体がリーンUX /リーンスタートアップの型で研究、実験、製品発見の観点から考えることを奨励しようとしています。
スタイルガイドのトピックについて。アジャイルチームで非常に効果的なのは、ライブスタイルガイドを使用することです（ https://uxmag.com/articles/anchoring-your-design-language-in-a-live-style-guide for簡単な説明）。誰もが同じ「実際の」アーティファクトを重視している場合、位置合わせなどを行うのははるかに簡単です。
あなたが役に立つと思ういくつかの背景の読み：
- ダイアナブラウンによるアジャイルユーザーエクスペリエンスデザイン
- Hugh Beyerによるユーザー中心のアジャイル手法
- Laura KleinによるリーンスタートアップのUX
- リーンUX by Jeff Gothelf＆Josh Seiden
- Lindsay RatcliffeとMarc McNeillによるアジャイルエクスペリエンスデザイン
そして、アジャイル/リーンUXに特化したいくつかのコミュニティ。同様の問題を経験して対処した多くの人々：
私は、高等教育機関向けの一連のアプリケーションを管理するアジャイルプロジェクトのUXデザイナーです。私たちは5つのデリバリーチームと、彼らの仕事（分析、UX、サービス）をサポートする少数のコアチームで構成されています。 5つのチームにはそれぞれ、スプリント構造内でコアUXチーム内に設定された設計標準を実装する専任のUXデザイナーがいます。一貫した方法でチーム全体のUXベストプラクティスの実装を管理するために使用するツールには、次のものがあります。
- 製品全体で使用した要素の例を含むスタイルガイド/パターンライブラリ。これにより、スタイルの一貫性が確保され、アプリケーション間で同じウィジェットを同じように使用できます。
- UXデザイナー全員との毎週のコアチームのミーティング。これらの会議では、私たちの仕事と批評を共有します。これらの一般的に非公式の会議では、他のデザイナーがどのように問題に取り組んでいるかを確認でき、忍び寄る矛盾の認識につながる可能性があります。また、同様に、アプリ内の同僚の作業に基づいて設計を支援することもできます。
- Skypeの会話がたくさん！アジャイル環境では一般的に望ましいことですが、私たちは非公式なコミュニケーションチャネルに大きく依存して、質問を行い、洞察を共有し、私たちのやり方について懸念を表明します。これは一般に、改善の推進が始まる場所であり、問題を特定して修正するための最初のステップです。
私たちのプロセスが完璧であるとは言い切れませんが、調整された自律型のUXチームとして機能する上で非常に役立ち、アプリケーションは常に近づいていて改善されています（ユーザビリティテストで証明されています）。