ストーリーボードを作成するときに何に焦点を当てるべきですか？アプリケーションの相互作用またはユーザーの目標？
どのような状況で「仕事からやり直し」のストーリーを構築するのか知りたいのですが。教師が特定のインシデントを報告するためのポータル/システムを構築します（現在、彼らは使用していません）。
たとえば、「いつ…、したい…、できる…」という方法を使っています。
ストーリーを作成すればするほど、最も混乱します。彼らがポータル/システムと対話しているとき、私は観点からストーリーを書きますか、それとも彼らの通常の日常ベースで観点からストーリーを書きますか？.
ポータルと対話するストーリー：システムにログインすると、...を表示できるようにしたいので、...
OR
通常の日々のストーリー：状況を監視したいときに、できるようにしたいので、...
それとも両方が同じものですか？
===編集===現在、教師は状況を監視していないため、私もジレンマに陥っています。しかし、学校のプロセスの変更により、彼らは現在、状況を監視する必要があります。ですから、「状況を監視したいときは、関係者を確認して追跡できるようにしたい」とは言えません。なぜなら、彼らが「やりたいこと」ではないからです。それらに必要な「ルール」。これについて深く考えすぎているかどうかはわかりません。
では、どうやってJTBDを書き始めますか？
これらの種類のストーリーの目標は、通常、製品がこのニーズにどのように対応するかの専門性ではなく、ユーザーの実際のニーズに基づいてストーリーを確立することです。
たとえば、ユーザーがインシデントを報告できるようにすることを製品の目的とする場合は、「ログイン」するのではなく、インシデントを報告する必要があります。
私のアドバイスは、ストーリーを次のように設定することです。
インシデントが発生したときは、ポータルにサインインして、インシデントに関する重要な詳細を記録できるようにしたいと考えています。
これらのストーリーの利点は、将来のユーザーに「大丈夫です。インシデントが発生したと仮定して、このポータルを使用して詳細を記録したい」などと尋ねることで、設計を後で「テスト」できることです。これは、事件を報告する彼らの責任に直接付随します。あなたの話が「システムにログインしたとき...」のようなものだった場合は、インシデントを報告する責任は付きません。
「ルールの変更」について、また、ルールの変更の結果としてユーザーが「したい」または「強制された」ものであるかどうかについては、「必要」を「必要」に置き換えます。例えば：
インシデントが発生した場合、規制に従ってインシデントを記録できるように、ポータルにサインインする必要があります。
（「欲しい」の言い回しは、顧客がめったに必須を行うことのない商業分野での使用に適しています。）
ストーリーボードの目的は、私が理解しているように、（ペルソナを作成および開発することによって）ユーザーの立場に身を置き、彼らの目標に最も合うようにデザインを形作ることです。
したがって、両方の質問にメリットがあります。
私には、これらの質問は順序付けされているようです（ただし、あなたが提示した方法とは逆です）。最初に、ユーザーはログインすることを目標とします。次に、ユーザーは複数の異なる目標を達成する必要があります。その1つは状況を監視することです。
最初：システムにログインするときに、使用可能なすべてのツールを表示して、アプリケーションのどこに移動する必要があるかをすばやく見つけられるようにしたいと考えています。
次へ：（ユーザーはこの時点で多くの異なるオプションを持っています）
状況を監視したいときは、報告した未解決のインシデントを確認して、それぞれのステータスを確認したり、追加情報で更新したりできるようにしたいと考えています。
インシデントをフォローアップしたいときは、インシデントを見つけて、そのインシデントに割り当てられている担当者の連絡先情報に簡単にアクセスできるようにしたいと考えています。
「いつ...、私は...したいのであれば、あなたのストーリーの他の設定を試してみると役立つかもしれないので、私は...」は役に立ちません。たとえば、目標を設定し、そこからシステムから最も役立つ応答を設計する実験を行うことができます（したがって、「をもっとしたいので、...システムが... "に役立つ」。
JTBDフレームワークでのユーザーの実際のニーズは、まずこれらの主要なパラメーターを持つモデルに従って分離する必要があります。
主要パートナー：
Who are your key partners?
Who are your key suppliers?
Which key resources are we acquiring from partners?
Which key activities do partners pereform?
主な活動：
What Key activities do your Value Propositions require?
What are your Distributun channels?
How would you maintain your Customer Relationships?
What are your main Revenue streams?
主なリソース：
What key resources do your Value propositions require?
Types of resources like Physical, Human, Financial,
価値命題：
What value do you deliver to the customer?
Which one of your customer problems are you solving?
What bundles of products and services are you offering to each **Customer Segment?**
Which customer needs are you satisfying?
顧客関係：
What type of relationshp does each of your Customer Segments expect you to establish?
Which ones have you established?
顧客セグメント：
From whom are we creating value?
Who are your most imortant customers?
チャンネル：
Phases are like Awareness, Evaluation, Purchase, Delivery, After Sales
How are we integrating the phases with customer routines?
収益ストリーム：
For what values are your customers willing to pay?
コスト構造：
You need to find whether your business is cost driven or value driven and then decide parameters to it
これは、情報アーキテクチャ全体を作成し、シナリオを特定するのに役立ちます。このアーキテクチャモデルに基づいて、次のような機能を作成する必要があります。
機能1
機能2
機能3
機能のテーマセグメンテーションを行うこともできます。 Virality、Security、Reportsなどのテーマ.
したがって、このFeature 1内では、あなたがしたようにストーリーを作成します： "の方法を使用して..."、...したい...、だから私は... "
これで十分な情報があるので、他の機能ではなく、各機能の視点に基づいてストーリーを簡単に作成できます。