Business AnalystはコアUX / UIテクノロジーフローのどこに適合しますか
ユーザーエクスペリエンス（UX）デザイナー=リサーチ+デザイン
UI開発者=デザイン+ HTML/CSS/JS
アプリケーション開発者= HTML/CSS/JS +バックエンドコーディング
上の図を参照して、ビジネスアナリスト（BA）がどこに位置するのかを知りたいと思います。
あなたの考えをいただければ幸いです。
BAはコアUX/UIテクノロジーフローには適合しませんが、コアソフトウェア開発フローには適合します。
BAのいくつかの主な機能は、要件を理解してから、ソリューションの論理アーキテクチャを考案することです。
これら2つのタスクはUX/UIに密接に関連しており、UXに影響を与えます。
要件を理解する
私たちは、UXコピーのどこにでも「Know Thy User」を読みました。まあ、BAはユーザーのニーズを調査するための適切な位置にあるものです。 BAは、ITの人々と一般の人々の両方の境界にあります。
別のUXマントラは、事後のユーザーテストではなく、事前の情報収集であるユーザー調査の必要性です。これはBAが行うことでもあります。
BAは、会社のプロセスのウォーターフォールや俊敏性に応じて、詳細情報を収集して書き留めるか、一般的なアイデアを得て、最初に取り組む部分のみの詳細を掘り下げます。
解決策を考案する
BAが十分な情報を収集するたびに、彼女は JakobのNielsenの使いやすさの最初のルール を適用する立場になります。
これは、ユーザーの要求を正確に満たすのではなく、おそらく側面的な考え方でニーズを解決する一連の論理IT構成を考案するために、専門知識を適用することを意味します。
Alan Cooperこの6 'ビデオ で見事に説明しています。
要するに、ソリューションを考案するのはBAの責任です。プログラマー、ビジュアルデザイナーなどではなく、BAとPO（プロダクトオーナー）を組み合わせて、できればマーケティング要件から離れて（結局のところ、非常に優れたUIを備えたものほど優れた市場はありません）。
bAは何をしますか？
以前の回答で述べたように、BAは書いています。
彼女は、企業文化に応じて、ユーザーストーリー、ユースケース、または要件ランドリーリストを作成します。
彼女が洗濯リストを作成する場合、彼女はUXを実行していませんが、このリストを閲覧していないため、私は気にしません。このソリューションは、遅れて予算を超え、最終的に役に立たなくなる可能性が非常に高くなります。
一方、BAがUSまたはUCを作成している場合、彼女が実行していた可能性がありますInteraction Design。
それは彼女の責任ですが、可能であればUX担当者と共有できます。
USによるよりもUCの方が相互作用が定義されるのは、システムに対するユーザーの相互作用ステップの記述です（ただし、両方を使用できます）。
インタラクションデザイン
これは、アプリケーション（またはWebページなど）がsableであることが最も重要です。
ビジュアルデザインの後には必ずその部分が追加されますが、ユーザーがそれを使用するために必要なアクションの蛇行で迷子にならないようにするには、最初にアプリケーションに適度に優れたインタラクションデザインが必要です効率、有効性、満足。
後で重要なのは、ユーザーテストの際に検出されたインタラクションブループが修正されないためですそれは非常に高価であるためそれが必要になります。
BAは、最初にユーザーと話し、ユーザーがどのように機能するかを見て、目標とニーズについて学んだため、インタラクションデザインを所有しています。
開発段階
BAの使命は、プログラマーがプログラミングしているものとデザイナーが設計しているものを、ソリューションのビジョンと一致させることです。
さらに、彼らが（通常のスクラムのように）俊敏なプロセスを実行している場合、開発チームが飢えないように（バックログが不足する）と他の多数のユーザーがストーリーを書くのにフルタイムで取り組んでいます。義務。
しかし、相互作用のデザインを伝える必要があるため、またはプログラマに任せてディルバートスタイルの結果を得る必要があるため、米国について言及します。
使いやすさとUX
ユーザーに快適なエクスペリエンスを提供するには、最初にUIがsableである必要があります。これは、BAが提供する必要があるものです。
その後、「体験」になってしまうかもしれませんが、使い勝手が悪ければ、そもそも私たちが思っていたように感じるのは、決していい体験ではありません。
BAはビジネスニーズを表し、UXはユーザーニーズを表します。
UXとBAは、常に優先的に話し合い、製品の優先順位が正しいことを確認します。
UIとBAは連携して、要件が開発者が解釈できるようにキャプチャされ、テスターがテストできるようにします。
ダイアグラムでは、BAロールはUXロールと並行して、理想的にはビジネスとユーザーの代表者という平等なパートナーシップで実行される必要があります。
UIについても同様です。通常、プロジェクトには複数のBAが存在し、さまざまな責任とさまざまな詳細レベルで作業します。
一般に
BAは、要件（多くの場合、ユーザーストーリー/ユースケースの形式）とプロセスフローを文書化する責任があります。 UXは要件の精査に参加しますが、BAが責任を負います。 UIは要件をワイヤーフレームで表します。
BAは、製品に必要な詳細をキャプチャして追跡します。エラースプレッドシートまたはコンテンツマトリックス。 UX＆UIがこれにフィードします。
BAは利害関係者の管理を行います-適切な人々に相談し、常に情報を提供するようにします。彼らはワークショップを実施して要件を詳しく説明します。 UXは多くの場合、これを達成するためにBAと対等に協力しています。
BAは、ビジネスの問題が発生したときにそれを分析し、その解決方法に関するオプションを製品所有者に提示します。
それは会社ごとに異なりますが、基本的に私の経験から、ビジネスアナリストは特にこのプロセスの最初と最後に関与することがよくあります。彼らはビジネスニーズを抱えている可能性があり、ユーザーエクスペリエンスデザイナーと話し合い、そこから調査とインターフェイスに取り組みます。会社と問題のBAに応じて、彼らは関与する場合と関与しない場合があります。研究とワークショップのフェーズの一部。
私の経験では、BAはプロジェクトの進行に合わせてプロジェクトにチェックインし、関係者に十分な情報が提供されていることを確認し、成功の測定（分析など）に積極的に関与することがよくあります。
結果は、彼らが次の行動方針を決定するのに役立ちます。
肝心な点は、役割は場所によって異なりますが、私の経験（オーストラリアの大規模電話会社）では、プロジェクトの開始時と終了時に関与する傾向があり、ビジネスアイデアを考え出して、それを全体として見るのに役立ちます。 「行う」役割よりも監督する役割.
お役に立てば幸いです。
ビジネス要件が提示されたときのUXデザイナーの一般的な最初のステップである「ユーザーリサーチ」について読むこともできます。
これは、BAとUXが異なり、ユーザーのニーズを考慮して、コアビジネスニーズの点で収束する場所です。