アナリストは、ビジネス、設計、開発の仲裁者であり、定期的に一方向または他の方向にシフトしますが、同時に常識の分野でモバイル製品を作成するプロセスを維持します。 プロセスのすべての参加者間のコミュニケーションを提供し、あるグループから別のグループに知識を送信して、仮説を提示し、その後の決定に十分な情報を提供します。
- ビジネス -KPIの達成を常に考えていますが、開発されたシステムの複雑さとユーザーの利便性を理解することはめったにありません。
- UXデザイナー -常にユーザーのことを考え、時にはビジネスに悪影響を与えます。 彼は常にビジネスの目的を明確に理解しているとは限らず、自分の考えを押し付けようとします。
- 開発者 -システムアーキテクチャとプログラムコードの点ですべてをクールにする方法を考えます。 自分でユーザーシナリオを試してみますが、技術的に精通している人であり、ほとんどのユーザーには一般的ではありません。
私たちのプロジェクトの成功は、重要な欠陥を含まず、ビジネスに必要なすべてを実装する適切に作成されたアプリケーションだけでなく、ユーザーとアプリケーションとの相互作用の十分に開発されたロジック、顧客を引き付ける準備された設計コンセプトの品質と見なされます。 会社でのビジネス分析の役割は、他の領域（開発や設計など）を考慮すると、比較的最近現れました。 摩擦プロセスは、涙と鼻水で痛みを伴いました。
多くの場合、次の性質の問題がありました。
- 要件は詳細すぎるため、好転する余地はありません。 その結果、多くの場合、お客様が承認した要件とは異なる設計を受け取りました。 時には顧客はこれについても満足していました。 結局、それに応じて設計された美しいデザインコンセプトは、ユースケースに変換される一連の複雑なビジネスプロセスよりも視覚的で理解しやすいものです。
- 設計を準備するのに十分な要件がありません。 その結果、時間の遅延、プロジェクトのマイルストーンのシフト、ビジネスアナリストとデザイナーの間の絶え間ない争いを受け、ビジネスとユーザーのさまざまな視点を擁護しました。 私たちはすべてにおいて妥協がなければならないことを理解しなければなりません。 ビジネス目標は、カスタム目標の実装を通じて達成されます。 ユーザーがアプリケーションに興味がある場合、彼は私たちのビジネス目標を達成するのに役立ちます。
BA、UX設計、およびエンドカスタマー間の相互作用をスムーズかつ効率的に行うために、一連の成果物を使用します。
デザイナー、アナリスト、PMの間の設置会議
当初、私たちの仕事は、私たちがどう動くか、そしてチームによると、設計準備段階で最大の問題を引き起こす可能性があるものを理解することです。 原則として、同時に開始しますが、作業範囲を事前に決定します。 製品全体を3つの部分に分けることができます。
- 複雑なビジネスロジックを備えた機能は特別です。 顧客は、これがどのように機能し、この知識を取得する必要があるかを考えています。 アナリストはまず、このタイプのタスクの作業を開始します。 不確実性を最初に除去する必要があります。これが行われない場合、その後の作業について話すことはできません。
- ユーザーフレンドリーである必要がある機能。 顧客は独自のアイデアを持っていますが、改善方法の検討を期待しています。 このようなタスクは、TO BEコンセプトを準備するUXデザイナーに与えられます。
- アプリケーションごとに繰り返される機能。 原則として、それらはすでに要件の形で記述されており、設計がどうなるかというアイデアがあり、再利用のためのコードの準備ができています。 そのようなことはプロジェクトの最終段階まで延期され、設計者とアナリストは定期的な同期とほぼ並行して実行できます。
最初のタイプの機能の場合、多くの成果物を使用してチームメンバー間で知識を伝達します。
業務プロセス図
BPMNダイアグラムを使用して、顧客のビジネスプロセスを説明します。 彼らの利点は、読みやすく、従わなければならない基本的な手順のシーケンスを明確にキャプチャできることです。 それらは顧客によって簡単に認識され（一部の企業では標準です）、設計者が理解できます。
プロセス図
各チャートには必ずテキストが提供されます。 テキストサポートは、すべてのステップをより詳細に説明し、グラフィカルに反映できないビジネス要件、および特定のビジネスプロセス手順に関係するデータをキャプチャします。
サンプルデータと論理データモデル
設計者にとって重要なのは、ビジネスロジックへの準拠だけでなく、どのデータを処理する必要があるかを理解することでもあります。 3つのアイテムのリストを表示すると便利でしょうか。 そう思う。 これらのアイテムが1000個ある場合、同じ単純なリストが機能しますか？ データを転送するには、次のアーティファクトを使用するのが一般的です。
- 論理データモデル
- データ例
論理モデルは、アプリケーションに含まれる基本的なエンティティ、ユーザーが操作する必要があるものを理解するのに役立ちます。 これらのエンティティにはどのような属性があり、強調することが重要であり、その逆は何であるか、ユーザーは興味がなく、表示されません。 実際に証明されているように、1つの論理モデルでは十分ではありません。 また、コンテンツ自体を理解することも重要です-コンテンツの見た目と、ユーザーにとってどのような情報が含まれているか。 そのため、各データモデルにはフラットテーブルが提供されます。フラットテーブルは、これがどのようなエンティティであるか、ユーザーがどれだけ持つことができるかを説明し、エンティティの属性のテキスト説明と「実際の外観」の例を示します。
NB！ 覚えておくことが重要です。 アナリストは、PMプロジェクトの要件の将来の変更をタイムリーに特定して通知する必要があります。 ビジネスプロセス図の形式で知識を転送し、サンプルデータを含む論理モデルでは不十分です。 受け取った情報がチームメンバーによって適切に認識されていることを理解することが重要です。
インテリジェンスカード
このプラクティスを開発しました。UXデザイナーは受け取ったすべての資料を調査し、アナリストに質問した後、将来のデザインの基礎となる一連の機能と機能を備えたインテリジェンスカードを準備します。 準備後、インテリジェンスカードについてアナリストと話し合います。 この段階では、誰もが同じように理解し、誤解がないことを確認する必要があります。
UXデザイナーが設計に組み込みたい将来の機能セットのインテリジェントマップ
最終画面セットと検証
設計を顧客に示す前に、検証チームを実施する必要があります。 開発者は、将来のアプリケーションの実行可能性、分析、ビジネスロジックおよび顧客の期待への準拠を確認します。 そして、プロセスのすべての参加者による承認後にのみ、設計は顧客との承認のために送信されます。
まとめると
説明されたアーティファクトと相互作用のセットは、アナリストがビジネスとUXデザインの間の情報交換を促進し、コミュニケーションを非常に効果的にするのに役立ちます。 インストール会議とインテリジェンスカードの構築により、チームはチーム内で同期し、プロセスの参加者間の不一致や誤解の発生を最小限に抑えることができます。 そして、これはプロジェクト全体の成功の主要な要素の一つです。