ユーザーインターフェイス設計は開発プロセスにどのように適合しますか？
ソフトウェア開発プロセスにおいて、ユーザーインターフェイス設計はどこに適合しますか？
小さなチーム（ジュニア2名、シニア2名、チームリーダー、ウェブデザイナー）に対してアジャイルアプローチを採用する場合、通常は次のようにする必要があります。
- 要件のリストがお客様とともに生成されます。
- 使用要件から抽出された機能のリストと、各要件に対してシナリオのリストが記述されています。
- 各シナリオは受け入れテストに変換され、開発はTDDの使用を開始します。
このチームでは、開発者はフロントエンドとバックエンドの両方の開発を行います。
これまでは、ユーザーインターフェイスの設計に大きな価値を与えていませんでした。ほとんどの場合、実装するためにWebデザイナーに与えられる非常に単純なモックアップを自分で作成しました。ユーザーインターフェイスは、機能が実装される前に作成されることもあれば、その後に作成されることもあります。
現在、ユーザーインターフェイスのデザインにもっと注意を払い、プロセスにお客様を参加させたいと考えていますが、ユーザーインターフェイスをいつどのように実行する必要があるのか、またユーザーインターフェイスが要件にどのように影響するのかについてはわかりません。
免責事項
私たちの分野はまだかなり若いので、私たちが使用する用語の多くは、これが収束するほど一般的な議論には十分に安定していません。
さらに、安定化された用語は、「使いやすさ」のように時代遅れと見なされ、現代的であるために回避されます。
ここでの回答の多く（私はそれらすべてが好きです！）が同じ単語を使用して何らかの形で異なるものを参照していることを確信しているので、「使いやすさ」以外のそのような単語はすべて避けようとします。 「これは今まで言及されていませんでした。
ソフトウェア開発プロセスにおいて、ユーザーインターフェイスの設計はどこに適合しますか？
まあ、どこにでも答えがあります。 「ユーザーインターフェースデザイン」がグラフィックデザイナーの仕事を意味する場合を除き、どこに当てはまるのでしょうか。
「ソフトウェア開発」とはどういう意味ですか？
Songoのチームの規模を考えると、彼らはかなり小さなWebサイトまたはWebアプリケーションで作業していると推測できます。
サイズが重要で、それは非常に重要です。
ほとんどのアプリケーションは、ワイヤフレームの小さなセット（たとえば、10または20）で定義できます。インタラクションコンテキスト（IC、画面、ダイアログ、通常は物理的なボタンパネル、またはユーザーがシステムと通信するために使用できるもの）が相互にどのようにインタラクトするかは、そのようなワイヤフレームセットで推測または明示できます。
ワイヤーフレームは完全なソフトウェア仕様として機能します。
代わりに、アプリが数千のICで構成されている場合、相互作用を説明するために別のアーティファクトが必要になります。
どちらの場合も、IC間の相互作用は、ユーザビリティを達成するための試みにおいて最も重要な部分であり、ユーザーは（ISO/IECのユーザビリティの定義に従って）効率、効率、満足度を問わず何でもできるようになります。
どうして？はい、最初に、ユーザーが flow state を失うことなく、UIを介してユーザーの目標に直接やり取りする一連のやり取りを徹底的に進める必要があります。
したがって、どのような開発プロセスが適切であるかを回答するには、これらの変数のいくつかをテザリングする必要があります。
同様に、アプリケーションのサイズ、その複雑さ、ドメインの複雑さ、それに取り組む開発者の数など、もっと多くのものが必要です。
とにかく、すべてを行う必要があります
物事は、利害関係者（アプリに既得権を持つ人）からの要求から始まります。これはソフトウェア要件のインスタンスではなく、多くてもビジネス要件です。
次はフィールド調査です。
ユーザーまたはpersonasへのインタビュー。
安定化されたアプリケーションの永続的な方法に取り組んでいる小規模なチームの多くは、実装しようとしていることに対するユーザーの反応を理解しようとする衝動を感じず、彼らは正しいかもしれません、そのため、フィールド調査はレーダーには表示されませんが、少なくとも一部のユーザーが新しいUIを使用していることを想像して（長い経験に基づいて）どのように適合するかを理解している必要があります。
ユーザーと新しいパーツに対するユーザーの反応に関する知識は、新しいUIをどのように使用するかを想像するために使用されます。理想的には、personasを使用して操作し、Joe Sixpackがそれを実行できるかどうかを調べます。
この段階では、できるだけ抽象的なままであることが理想的です。機能分析者はそれを行うことができ、UIを描画せずに操作しているユーザーについて説明します。他の人はもっとgraphicで、できるだけ早く描き始めたいと思っています。この衝動に抵抗することで、UIの向上、開発の迅速化、使いやすさの向上につながります。要するに、いったんコンクリートに入ると、コンクリートに閉じ込められて、デザインを破棄する可能性が低くなりすぎるからです。抽象的であると、花でいっぱいの庭にいる蝶のように、選択肢の間を自由に移動できます。
一方、高忠実度のモックアップを描いた場合、それは粗雑なフィラートのアイデアであったとしても、それで行き詰まってしまう可能性があり、それを愛し始める可能性があります。そしてマネージャーがそれを見た場合、それは凍結されます。
抽象的ではありますが、この部分はUIの設計とその動作方法の重要なコンポーネントです。
時間の経過（1時間または1か月、状況によって異なります）は、UI（「シナリオ」と呼びます）を使用するユーザーの説明を記述したものであり、インテリジェントなコンセンサスによって安定します。
一連のブレインストーミングセッションで、チームは、目標を達成するためにシステムを使用するためにユーザーが実行する必要があるアクションのリストを書き込むことができます。
アプリのメニューなど、ユーザーが実行できるすべての操作のリストが作成されます。リストが1つまたは2つのアイテムで構成されている場合は、暗黙的であるため、正式に実行しないでください。
ここで、ユーザーとシステムのダイアログの観点から、それがどのように機能するかについての説明を書き留めます（まだ描画せず、申し訳ありません）。これらの目標のそれぞれについて、最初から最後まで成功するために必要なステップのリストが書かれています。
これを行った後、ほとんどのやり取りを追跡して、パスワードが一致しないログインのやり取りなど、失敗する可能性のあるほとんどのことをチームがブレインストーミングします。
システムが管理できる落とし穴のみがリストされます。たとえば、データセンターを破壊するエアロライトは範囲外です。
次に、リストされた問題を処理するための対話ステップを追加すると、ユースケースのニースセットのコアができます。
これらは非公式、テキスト、かなり構造化された、可能な限り単純なドキュメントです。
事前にブレインストーミングを行い、これらすべての条件をどのように処理するかを決定したことで、開発者向けの堅固な仕様が完成しました。
そして、それが好きかどうかに関係なく、UIの動作について実質的な定義を行いました（まだどのように見えるかわからないのに）。
しかし、テスト担当者にそれらのUCを処理すれば、彼らはあなたを愛します。
開発者は、ある状況が発生した場合に何をすべきかを尋ねるために午前3時に電話する代わりに、あなたを愛します。
全体として、結果はより簡単に達成されるより良いバーになります。
開発者へのUCを処理する前に、2つのこと、または3つのことを行うことにより、グラフィカルな禁欲を満たす必要があります。
1-コントロールギャラリーを実行する
2-ワイヤーフレームを描画
3-スタイルを定義する
コントロールギャラリーは、国際住所や電話番号などの各データを表示する方法の定義です。データのラベル付け方法、値の入力方法、検証の方法などです。
私たちは常にすべてを行います
これらのすべてのステップの面白いことは、意識的にかどうかにかかわらず、常にそれらを実行することです。
正しい順序であるかどうか。
多くの場合、ステップをスキップするだけで、後でそれを実行する必要があり、コストがはるかに高く（労力の点で）、劣った結果が得られます。
これらのすべてのステップにより、UIが正常に動作し、合理的に見えるようになります。今、あなたはそれにそれを素晴らしいものにする魔法のタッチを与えることができます。
個人的には、UXをALM（アプリケーションライフサイクル管理）の対象外とは見なしていません。また、UXを単一のプロセスだけとは見なしていません。私たちのプロジェクトでは、アジャイル環境で次のように機能します。
- BAおよびUXチームがお客様から要件を抽出
- グループがバックログストーリーの作成を開始します
- BAはUXと連動して機能的なストーリーを作成します
- UXはBAとともにワイヤーフレームを作成します
- グループは顧客との承認のために戻る
- ワイヤーフレームがストーリー要件になるグループグルーミングバックログ
- ストーリーがスプリントに入る
- ストーリーのUXデザインが行われます
- ストーリーの展開が行われる
- QAテストが行われます
- ストーリーは完了です
- UAの受け入れが行われます
UXプロセスを実際に行われる処理に分解すると、要件の収集と開発をALMプロセスにうまく適合する場所に分離できます。
私は現在、UXが重要な役割を果たす大規模なマルチチームアジャイル開発プロジェクトに参加しています。あなたが説明しているのは、設計が後から考えられている、ほとんどの開発実行プロジェクトでの一般的な問題であり、設計に対する「ただよくする」アプローチです。
私の控えめな意見では、アジャイルは適切なUX配信のための理想的なプロジェクト方法論ではないので、この変更をプロジェクトに導入するのは少し戦いでした。ユーザーインターフェイスのデザインだけでなく、ユーザーエクスペリエンスという用語を使用していることに注意してください。現在のワークフローでは、UXDが最初のスコープセッションから始まるすべての反復計画会議に関与しています。要件を受け取り、最初のストーリーの内訳が完了すると、UXDはストーリーを取り、ソリューションを作成するために必要な労力を見積もります。ほとんどの場合、見積もりはストーリーによって分割され、俊敏性を高めます。要件の複雑さに応じて、これは反復全体（またはその問題の場合は複数の反復）または数日になる場合があります。この見積もりは、プロジェクトの全体的な計画に含まれます。つまり、言い換えると、実際の開発を開始する前に、UXスプリントを含めることを検討できます。
また、UXDは開発チームと緊密に連携して、開発が開始されると反復レビューを確実にし、ほとんどの場合、機能がQAに移行する前に2、3回の反復があります。また、QAはUXDとも連携して、最終的なサインオフにUXのサインオフが含まれるようにし、本番環境にプッシュされる最終的なソリューションが技術的な観点から確認されたものであることを確認しますUXの観点だけでなく、.
UXを置くbefore開発が進むべき道です。クライアントがアプリケーションを使用するときに小さな修正が行われますが、UXの大部分は計画段階で行われます。紙の上で物事を変更する方が、開発者にアプリケーションの一部を最後に書き直させるよりもはるかに簡単です。土壇場での方向変更は、コードの品質と開発者の士気を傷つけ、通常は期限の延長を意味します。
ここでの答えの多くは、開発の前にUXを実行する必要があると述べています。それはアジャイルの正反対であり、あなたのニーズを満たすのに最適ではないでしょう。
とはいえ、UXのsomeレベルが事前に発生する必要があるという点で、いくつかの真実があります。これを処理する1つの方法は、UXを1つのイテレーションで実行し、次にdevを実行することです。このようにして、UXは高レベルのUX作業を行う数回の反復よりも進んでいますが、現在の反復で開発されている現在のUX作業も検証しています。
これはトリッキーになる可能性があり、管理するもう1つのことですが、機能します。
考慮すべきもう1つのことは、アジャイル開発プロセスの影響を受けたリーンUXです。
http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/
それはユーザーインターフェイスについてではありません。これはUser eXperience（UX）の一部にすぎず、最大のUX問題領域ではない可能性があります。
開発者は、UXとフロントエンドを実行する必要がある人ではなく、デザイナーが開発を行う必要があります。多くの開発者はこれを取得しませんが、優れたUXと設計者（または同じ人物である必要はないため、人々）が必要ですあなたのチームに。あなたはより良い製品、そして（私の経験では）より短い開発時間で終わるでしょう。
私はあなたがUXから始めるべきであるという難しい方法を学ばなければなりませんでした。顧客から機能のリストを取得するだけで、アプリケーションで実行したいと思ったことのリストが常に得られます。 すべての機能を実装すると、アプリケーションは99％の時間で使用できなくなるためです
例：Nokia 5800（Symbian）とiPhone 3GS（iOS）。技術的には、Symbianにはより多くの機能があり、技術的に優れていました。しかし、それは恐ろしいUXを持っていたと思いますが、それはエンジニアと開発者によって設計されたと確信しています。そのため、iPhone 3GSほど成功したわけではありませんでした。
結局のところ、顧客はあなたのアプリケーションのバックエンドがどれほど素晴らしいかを見ないでしょう。彼らはそれとの相互作用の経験に基づいてそれを判断するので、それはあなたが最初に焦点を当てるべきものです。
TL; DR：経験豊富なUX担当者にUXを最初に依頼してください。
UXは、要件収集プロセスの一部として、要件仕様と一緒に行われます。どちらのプロセスにも、顧客からのデータの取得、利害関係者との話し合い、ワークショップの実施など、いくつかの同様の活動が必要です。どちらも、UXがプロトタイプとユーザーテストで想定を検証し、BAがその結果を検証してユーザーストーリーの作成を始める前に、解決すべき問題を発見しようとします。
開発者が始める前にすべての要件をボトムアウトする必要があるTDDショップにいない場合でも、これは開発前の反復ですべて行われているはずです。
UI（または実際にはUXデザイン）は、開発が始まる前の最初のフェーズである必要があります。場合によっては、一部の作業が重複する可能性があります。コンセプトの準備ができたら、すべてのフローが確立され、これに基づいて、データベース構造やプログラム機能への機能の偽造などの計画を開始できます。
UXデザインが概念から完成に至るまでの詳細については、この図を参照してください。 http://www.jjg.net/elements/pdf/elements.pdf
UXデザインのもう1つの側面は制御です。本番環境では、UIデザイン、フロー、プログラミングの両方の変更を伴う多くの状況が発生する可能性があります。
ほとんどの人が指摘しているように、いくつかのuxスキルをチームに取り入れることを検討する必要があるようです。おそらく、uxコンサルタントが現在のWebデザイナーと協力して、自分で構築するために必要なスキルとテクニックのいくつかを伝えることができます。私自身の経験から、多くのソフトウェア開発会社がデザインを最後の上部に配置できる光沢のあるレイヤーと見なしているのは興味深いことです。ただし、インターフェース設計だけでは、今日のテクノロジーとデバイスの幅が広く、アプリケーションがどのように機能するかを適切に通知するには不十分です。ユーザーはあらゆる段階で考慮される必要があります！
プロセスの面では、「アジャイルUX」をググる価値があります。設計と並行してアプリケーションを開発する間の緊張に取り組むためのさまざまな方法を提案する素晴らしい記事がいくつかあります。