質問: ユーザーエクスペリエンスとui javascriptコンポーネントライブラリ 恐ろしいユーザーエクスペリエンスでuiコンポーネントライブラリ(primefacesとicefaces)を使用するアジャイル開発チームに出くわす人...コードを変更してより良いユーザーエクスペリエンスをサポートしない人。ユーザーエクスペリエンスを保護し、uiコンポーネントライブラリが悪いユーザーエクスペリエンスを提供していることを上級管理職に納得させる方法に関する回答を探しています。
回答: 私の考えでは、これはアジャイル開発プロセスに固有の問題ではありません。この質問は、uxが開発プロセスの一部であることを保証するという問題に関係しています。質問の最初のコメントの1つ 「アジャイル作業環境で開発プロセスのどの時点でuxを使用する必要がありますか?」 、ユーザーaaron mciverは(正しく)「アジャイルは何でもエンドユーザーに価値をもたらします。現在取り組んでいるアジャイルチームがuxを考慮していない場合、それはプロセスではなくチームと関係しています。」あなた/あなたのuxチームは開発プロセスに適切に関与していないではないようです、プロセスの一部である開発者は協議なしにuiを実装していますuxでは、そのuiは悪いですが、それでも彼らはそれをより良くするための推奨に耳を傾けません。これは悲しいことに典型的なものであり(ソフトウェア開発方法に関係なく)、私の経験では、解決策はuxバイインで「問題レイヤー」より1レベルか2レベル高いため、チームの全員が責任を明確にできるようにする必要があります。あなたはできる: 引き続き、uiに関する優れたuxベースの推奨事項を提供する 文書化すべて推奨(明らかに)するが、実際に何が行われたかを直ちに文書化し、実装がどのように推奨されていないかを非常に明確に述べる プロジェクトのux部分が実装部分によって損なわれていることをプロジェクトマネージャーと常に通信します。平均的な方法ではなく、ドキュメントに基づいて定量化できる方法で通信します。 uxとdevが製品開発ライフサイクル全体で相互に連携していることを確認する方法を見つけます(自分の場所の階層に応じて、またはマネージャーを通じて)。 優れたuxに関する推奨事項とドキュメントを提供できる最善の仕事を続けます。uxがそこに評価されていない/設定を変更できないことに気付いた場合は、どれだけ激しく戦い続けるかを決定します。 基本的なプロセスの問題があることを人々が理解するまで、私にとっての鍵は常に自分自身を害虫にし、その後i/uxの作業に戻ることです。チームは、「aは良い。bは悪い。aをお勧めします。開発者はbを実装しました。開発者がbを実装し続ける場合、発生する問題は次のとおりです。」結局のところ、経営者は何を使いたいかを決定します。関係者がuxがサポートしていないものを承認した場合、それは残念なことですが、それは彼らが行うことです。da01が行った私の回答には、コンポーネントライブラリ自体に対処するためのタックはしていません。それは、より大きな問題がプロセスと管理の1つであると私が見ているためです。開発プロセスにuxが組み込まれていない場合、非ux/ui指向の開発者は、誰かが止めるまで、好きなように/快適に使用できるものをすべて取得して使用します。