コンテキスト化/事前条件付けされたユーザーフローの良い例は？
問題を簡単に説明しましょう。私はカスタマーサポートシステムのユーザーフローに取り組んでいます。システムは、いくつかの（水平）モジュール、つまりメッセージング、契約ポリシー、請求などを備えた構造になっています。（垂直に）これらのモジュールは、契約タイプに基づいて条件付けできます。たとえば、保険契約の場合、「請求」を追加した請求モジュールにはわずかな違いがあります。またはメッセージモジュールは、すべてのメッセージではなく、特定の契約に関連するメッセージのみを表示する場合があります。
ここで、ユーザーフローの2つのアプローチを比較したいと思います。a）ユーザーが最初に契約/契約タイプを選択してからモジュールとやり取りする「コンテキスト」アプローチと、b）ユーザーが開始する「オールインワンバケット」フロー、および途中で「専門化」を選択、つまり契約/契約タイプを選択し、そのUIフォームに基づいて更新されます（たとえば、保険契約を選択すると、「請求」の新しいセクションが表示されます）。
既存の製品におけるこれら2つのアプローチの良い例を人々が知っているかどうか、そしてそれらを説明するためにどのような用語を使用するのかを知りたいのですが。
（用語については、ソフトウェア設計から Strategy pattern を借りています。）
Dashboard（「コンテキスト」）とWizard（「オールインワンバケット」）について話しているようです。ダッシュボードは、コンテキストを決定するためのトップレベルのオプションのセットです。 Wizardは通常、結果を決定するために必要な情報/選択肢を要求する画面/フォームのセットです。
ダッシュボードのフローはシンプルで、ユーザーはシステムとそのオプションの感触を前もって得ることができます（考えられる結果を決定するために調査する必要はありません）。
Wizardアプローチは、一連の入力を求めるのに適しています。ユーザーと開発者にとっては、より時間がかかる可能性があります。ユーザーが探索する必要があるシステムが生成される可能性がありますWizardは、考えられる結果を決定するためだけに流れます（ユーザーガイドまたは類似のものがその問題を軽減することができます）。
Wizardフローが実際に何を伴うのか、たとえば「ユーザーがフローを開始する場所」など）フロー？