ワークフロー(ステータスラベル)のステップに名前を付けるための適切なガイドを見つけることができませんでした
いくつかの原則/ベストプラクティスは何ですか?
興味があれば、私の具体的なケースは次のとおりです。
ユーザーが支払いリクエストを送信するシステムがあります。カスタマーサービスチームが確認するまでにユーザーが支払い要求をキャンセルしない場合、カスタマーサービスは要求を確認し、「詐欺」としてマークするか、承認します。数十のリクエストを承認した後、CSの従業員はボタンを押して、承認されたすべてのリクエストをサードパーティの支払いシステムにアップロードできます。その後時間が経過するため(応答は即時ではありません)、これらの項目はリンボ状態になります(私は "uploaded_for_processing"の呼び出しを考えています)。サードパーティの支払いシステムは、最終的に各リクエストに対して「成功」または「失敗」を返します。成功した場合は、ステータスを「完了」に設定します(ローカルシステム内)。障害のステータスは、CS担当者がそれらを確認できるように設定する必要があります(たとえば、failed_to_process)。それぞれについて、CS担当者はユーザーに連絡して、支払い要求が失敗したこと、および再試行する必要があることを通知する必要があります。次に、CS担当者はリクエストを「reported_failure_to_user」としてマークします。
ただし、これらのステータスラベルの選択について何かが適切ではないので、名前を適切に指定する方法を検討するための適切なフレームワークがあるかどうか疑問に思っています。
また、これらのステータスラベルは内部(カスタマーサービス)で使用するためのものです。お客様には見えません。
適切なラベル付けのポイントは次のとおりです。
ユーザーのアクションが必要なアイテムに注目するために、色分けを使用できます。
ビジネスプロセスの学習に最小限の労力で、ユーザーのワークフロースキーマを表示できます。
ここでの重要な目標は、内部ユーザーにとって意味のあるラベルを作成することです。あなたは、いくつかの内部ユーザーと少し勉強することができます。システムの状態を説明するカードを渡して、各状態にラベルを付けるよう依頼します。また、各参加者にラベルの選択について詳しく説明して、ユーザーがドメインについてどのように考えているかを理解するよう依頼することもできます。いくつかの傾向が見られる場合があります。顧客は内部にいるため、参加者の募集は簡単かもしれません。参加者が簡単にできるように、電子メールで州の説明を提供することを検討し、各参加者にラベルで直接返信するよう依頼することもできます。幸運を!
「対象読者の語彙を使用する(それを理解してください)」というささいなアドバイスを超える方法があると思います。
何かにラベルを付けるときは、ラベルがユーザーにとって何を意味するかを説明するようにしてください。技術的な意味やその意味ではありません。
たとえば、ショッピングカートを表示するときは、行やエントリではなく、商品やアイテムの中にあるものを呼び出します(my 同様の質問への回答 を参照)。
あなたのケースでは、各状態がユーザーに何を意味するかを考えてみてください。インターフェースをより「アクション可能」にしたい場合は、ユーザーが各状態に属するアイテムをどのように処理する必要があるかに従って、名前を付けることを検討します。 「レビューが必要」。