違いがあると思いますが、完全に説明するのは難しいかもしれませんが、ユースケースとユーザージャーニーの両方の使用例を使って試してみましょう。
通常、私のプロジェクトでは、ユースケースとユーザージャーニーを使用して、ユーザーのニーズとプロセスを分析します。この例ではライブラリを使用します。
最初のステップでは、ユーザーの目標を概説するユースケースを作成します。
ユースケースの例：
- 図書館員として…本を出したい。
- 図書館員として…本を返却したい。
ユースケースを取得したので、これらの目標をいくつかのステップに分解し、あらゆる可能な段階でプロセスを定義する必要があります。したがって、各ユースケースを取り上げて、通常はそのためのフロー図を作成します（User Journey）。
ユーザージャーニーの例：
- ユーザージャーニー1（ユースケース1に基づく）
ユーザーがライブラリに入る->ユーザーが履歴セクションに移動する->ユーザーがWW1履歴で目的の本を見つける->ユーザーが受付に行く...などなど、ユースケースが満たされるまで、可能な各ステップでフローをたどります。
旅は、改善可能なプロセスの領域を特定するのに役立ちます。
15秒の答え
- 使用例：機能要件プロセス中心のグラフ。
- シナリオ：ユースケース内のパス。
- User Journey：機能しない、ユーザー中心のシナリオの詳細。
ユースケースとシナリオ
使用事例
- クレジット：Ivar Jacobson（et al。）
- 定義：「ユースケースは、システムを使用して特定のユーザーの特定の目標を達成するすべての方法です。」ソース =
- 専門分野：要件エンジニアリング
- 目的：機能要件
- ピボット：プロセス（アクション）中心
- エージェント：人間（アクション）+システム（応答）
- インクルード：理想的なと代替パスの両方
- 構造：循環または非循環グラフ
多くの場合、テキスト形式で説明されていますが、
グラフとして視覚化するのが最適です。
シナリオ
- ユースケースグラフ内のパス（理想的かどうか）
- テスト可能（ Gherkin を参照）
緑の線は、同じユースケース内のシナリオを表します（ source ）：
ユーザージャーニー
- 専門分野：UX
- 定義：「目標を達成するために人がたどるプロセスの視覚化」 ソースおよび適切な概要
- 目的：UX分析+非機能要件
- 感情
- マインドセット
- 機会
- 苦痛点
- 等。
- ピボット：プロセス（アクション）または状態（サイトページ、タッチポイント）指向の可能性があります
- シナリオベース
- 実際の/想定されるユーザーエクスペリエンスとビジネスチャンスに関する洞察を提供します
以下はいくつかのリンクで、2つはIBM Knowledge Centerの記事です。これらの記事を読むと、それぞれのツールは異なって見えます。どちらのツールを使用するかは、視点と状況に基づいて選択できる可能性があります。
おそらく「旅」は、ビジネス目標（つまり、マーケティングキャンペーン）またはユーザーエクスペリエンス（UX）のレビューのほうが多いかもしれません。一方、「ユースケース」は、システム分析、要件の収集、テストケースの開発中に技術とビジネスが連携する機能要件と非機能要件を収集するためのものです。
久しぶりですが、以前はビジネスで開発者やテスターの要件を収集するときにユースケースを使用していました。 User Journeyツールについて知っていれば、ユーザビリティ調査のスクリプト作成にそれらを使用したことでしょう。
興味があるかもしれない関連記事への3つのリンクは次のとおりです： User Journey （usability） ユースケース（IBM）Creating Customer Journeys（IBM）
ユースケースは、アプリケーション開発の開発チームとビジネスチームの両方で使用され、ユーザーフローとユーザーとシステム間の相互作用を記述します。これは、チーム内のさまざまな国の保有者（情報アーキテクト、フロントエンドとバックエンドの開発者、品質保証、ビジネスアナリスト）間で共有できる技術文書です。ユースケースは、さまざまなタイプのフロー（理想、例外、代替、および関連するさまざまな条件）の詳細をキャプチャします。可能なシステム状態の概要を取得できるため、UX/UI設計者にとって非常に役立ちます。エラー、エッジケース。これは、説明および設計できます。
ユーザージャーニーでは、タスクに含まれるステップについても説明しますが、異なるケースに分岐することはありません。ユーザージャーニーには、ペルソナとしてのユーザーの詳細、つまりユーザープロファイル、感情、使用状況が含まれるため、技術情報ではなく、製品設計情報を伝達するためのドキュメントとして機能します。
ユーザージャーニーはユーザー中心のタスクビューであり、ユースケースはシステム中心のビューです。それらは同じですが、異なる観点からです。
ユーザージャーニーには複数のユーザーが関与する場合があります（明らかに、複数のシステムが関与する場合があります）。ユースケースには複数のシステムが含まれる場合があります（明らかに、複数のユーザーが含まれる場合があります）。そのように、彼らは同等に表現力があります。
上記が当てはまる場合、ユーザージャーニーはより有利な点であり、ユースケースから少し進化していますが、適切な値を念頭に置いている場合は、いずれかのツールを使用してユーザーフレンドリーな結果を得ることができます。
UXSEのタグセクションにある定義を参照することにします。これは、Web参照ではなく、定義を調整するのに役立つためです。
ユースケース（タグ定義）
目標を達成するための、通常はロールとシステム間の相互作用を定義するステップのリスト
ser Journey（タグの定義）
ユーザーがシステムと対話しているときにユーザーが実行する一連のステップを含むシナリオ。
私の2セント：
- タグ定義に基づいて、両方のアーティファクトは、ユーザーとシステム/製品/サービスの間の相互作用に関連しています
- タグ定義に基づいて、両方のアーティファクトは開始点と終了点がある論理プロセスを文書化します
- 私の経験では、ユーザージャーニーは通常、より視覚的に提示され（人々がアイデアを理解または探索できるようにするため）、ユースケースは設計の実装を目的として（つまり、仕様または要件のために）記述されることが多い
- 私の経験では、ユーザージャーニーは多くの場合、そのプロセスを通じてユーザーの感情を捉え、改善できる領域、または今後の調査のために集中できる領域を強調します
結論
ユースケースとユーザージャーニーの両方が同様の情報をキャプチャしますが、多くの場合、それらは異なる方法で構造化され、提示されます。ただし、これらは通常UX設計プロセスのさまざまな段階で使用されるアーティファクトであるため（そのプロセスは多くの場合反復的です）、これらのアーティファクトの開発に使用される言語とスタイルにはある程度の一貫性が必要です。
混乱を避けるために、製品の開発に使用しているプロセスの段階と、キャプチャする必要がある情報（または質問/仮定/回答/テスト）に焦点を当てることを選択できます。これは、十分なコンテキストを提供しますアーティファクトに使用する用語に関係なく。
ユースケースとは、シナリオの説明、ユーザーエクスペリエンスとアクション、システムの応答などです。
ユーザージャーニーは、シナリオにつながるユーザーのニーズと感情を表し、多くの場合、ユーザーペルソナが前に付きます。これは、ユーザーの立場に立って、ユーザーエクスペリエンスの意味や感じ方に関するいくつかの質問に答えられるようにすることを目的としています。それがどのような意味を持ち、どのような方法でユーザー、ユーザーの経験、そしておそらくは他の人生の側面に影響を与えましたか。