it-swarm-ja.com

管理アプリケーションでの有効日の取り扱い

保険ベースの情報を扱う場合、ほとんどのデータで発効日の使用を実装する必要があることがよくあります。これには私が入り込まない理由はたくさんあります。言うまでもなく、デザインの一部は変更できません。

私がよく遭遇する問題は、ビジネスユーザーのためにこのデータの管理インターフェイスを作成する必要があるときです。通常、ユーザーは画面の一番上で発効日を選択します。この発効日により、編集目的で提示されるデータが決まります。 (つまり、そのデータはその期間に有効です)

ここで、ユーザーが変更を行うたびに、この変更の発効日を尋ねます。次に、ユーザーの操作に応じてデータベースを変更します。

  • 彼らがレコードを削除した場合、実際にはレコードの終了日を
    変更の発効日。

  • 彼らがレコードを更新した場合、古いレコードの日付を終了し、新しいレコードを作成します
    新しい発効日を記録します。

  • 彼らがレコードを追加した場合...まあ私たちはレコードを追加します。

これが、UI /ユーザーエクスペリエンスの問題で発生している問題です。

  1. ユーザーは常に変更の発効日を通知する必要があります。これは、ユーザーにとって煩わしく煩わしいものです。

  2. ユーザーは、変更をすぐに有効にしない限り、画面に変更を表示できません。これは、画面上部で有効日が選択されているためです。さらに、変更がすぐに有効になることはほとんどありません。

  3. 最後に、私たちは実際に彼らが期待する変更を加えていないので、データを表形式で表示することはできません。彼らは一度データがそこにあると思いますが、25回の変更のために25回表示されます。

このような問題を解決するために、UIにどのような変更を加えるかについてフィードバックを得ることができればと思っていました。それが人が頻繁に対処しなければならない問題かどうかはわかりませんが、保険業界では非常に頻繁に対処しなければなりません。シッククライアント、Webアプリなど、テクノロジーは重要ではありません。

編集する

もう少し明確に。

  1. 私が言及しているアプリケーションは、バックエンドデータの変更を処理する管理アプリケーションです。実際のアプリケーション自体は、すでに設置されており、上記のバックエンドデータを使用して実行されています。
  2. 発効日に言及する場合。実際のアプリケーションがデータを要求すると、その日付が「有効」なレコードを見つけるために、有効日が渡されます。対応する「終了日」があり、これはnullまたは設定されています。 20テーブルのデータベースでは、おそらく少なくとも10テーブルのレコードに有効日があります。
  3. 私が言うとき、私たちは彼らが期待していることをしていません。つまり、彼らは「このレコードを削除します」と言っており、実際にそれを終了します。彼らは「このレコードを更新します」と言って、実際にそれを終了し、新しいレコードを作成します。
  4. すべてのエントリには発効日が必要です。それが新しいレコードである場合でも、アプリケーションはそれがいつ発効するかを知る必要があります。理由は、単にビジネスがそれを求めているとき、または特定の法律が発効しているときです。それを推測する方法はありません。

確かに、アクションが完了したら確認/ステータスメッセージをユーザーに投稿するだけですが、私がやろうとしていることは、このプロセスを少し円滑に、より有益で直感的にするユーザーインターフェイスを実装することです。エンドユーザー。したがって、バックエンドで実際に起こっていることの詳細をすべて知っているわけではないかもしれませんが、彼らは彼らが必要なことをしていると確信します。

5
Jeff Sheldon

各タブが発効日を表す、垂直タブインターフェースを作成できますか?タブをクリックすると、その発効日のデータが表示されます。 (派手なアニメーションのないAppleのTime Machineを考えてください。)

変更を行うには、ユーザーは有効日を入力することから始めます。これにより、編集可能なフィールドを持つ、前のタブのコピーである新しいタブが作成および選択されます。したがって、編集されている発効日が明確であり、タブをクリックして他の時点のポリシーを表示することもできます。

ここで提案されたモデルでは、ポリシーは決して「終了」しません(ただし、DBにはまだ終了日があります)。それは、次の発効日によって置き換えられるだけです。

残念ながら、これはポリシーが最後の発効日後に終了することはないことを意味します。最後のタブを、ポリシーの終わりを示すマーカーにすることができます。したがって、「削除」する代わりに、ユーザーは単に終了タブの発効日を変更するだけです。 (まだ「削除」ボタンがあるかもしれません-それは終了タブの発効日を今日に変更するでしょう)。

4

変更ごとに有効日をユーザーに尋ねるのは簡単ではありません変更ごとに特定の有効日を指定する必要がある場合。ただし、いくつかの機会があります。人々があなたのソフトウェアをどのように使用しているかについていくつかの調査を行い、いくつかのパターンを理解できるかどうかを確認してください。たとえば、ユーザーがアカウントを管理している場合、アカウントは常に月の最終日に変更されます。その場合は、それらの変更の特定の日付についてユーザーに質問するのをやめ、代わりにそれらに入力するだけです(デフォルトのオプションを選択するか、コントロールを非表示にする-ユーザーテストで何が最適に機能するかを確認します)。また、年間を通じて、または毎月、特定のことが発生する定期的な日付があるかどうかを確認し、それらをテンプレートとして提供することもできます。たとえば、「パフォーマンスレビューの日」や「毎月の最終金曜日」などです。最終的には、ワークフローを最適化してユーザー側の入力を減らす方法を確認するために、パターンを特定する必要があります。

編集:何が起こっているのかわからなかった回答のほとんどを削除して取り除いた

3
Rahul