Traiter les dates d'entrée en vigueur dans une demande administrative
Lorsque nous traitons des informations basées sur l'assurance, nous devons souvent implémenter l'utilisation de Dates d'entrée en vigueur sur la plupart de nos données. Il y a de nombreuses raisons à cela que je ne vais pas aborder, inutile de dire qu'une partie de la conception ne peut pas être modifiée.
Le problème que je rencontre souvent, c'est quand j'ai besoin de créer une interface administrative pour ces données pour nos utilisateurs professionnels. Habituellement, en haut de l'écran sur lequel il se trouve, l'utilisateur sélectionne une date effective. Cette date effective détermine les données qui leur sont présentées à des fins d'édition. (c'est-à-dire que les données sont efficaces pour cette période)
Désormais, chaque fois que l'utilisateur effectue un changement, nous lui demandons la date d'entrée en vigueur de ce changement. Ensuite, nous modifions la base de données en fonction de ce que l'utilisateur a fait.
S'ils ont supprimé un enregistrement, nous marquons simplement la date de fin de l'enregistrement comme
la date d'entrée en vigueur du changement.S'ils mettent à jour un enregistrement, nous terminons la date de l'ancien enregistrement et créons un nouveau
enregistrer avec la nouvelle date d'entrée en vigueur.S'ils ajoutent un enregistrement ... eh bien nous ajoutons un enregistrement.
Voici les problèmes que je rencontre avec une bonne interface utilisateur/expérience utilisateur.
L'utilisateur doit constamment nous indiquer la date d'entrée en vigueur d'un changement. C'est lourd et ennuyeux pour l'utilisateur.
L'utilisateur ne peut pas voir les modifications sur son écran à moins qu'il n'effectue la modification immédiatement. Cela est dû au fait que la date d'entrée en vigueur est sélectionnée en haut de l'écran. De plus, ils n'effectuent presque jamais un changement immédiatement.
Enfin, puisque nous n'effectuons pas réellement les changements attendus, nous ne pouvons pas simplement leur montrer les données sous forme de tableau, car cela n'aurait pas beaucoup de sens pour eux. Ils penseraient qu'une donnée est là une fois, mais ils la verraient 25 fois en raison de 25 changements.
J'espérais pouvoir obtenir des informations sur le type de changements que vous apporteriez à une interface utilisateur afin de résoudre un problème comme celui-ci. Je ne sais pas si c'est un problème auquel les gens doivent souvent faire face, mais dans le secteur des assurances, nous devons y faire face très souvent. Peu importe la technologie, client lourd, application Web, etc.
Éditer
Pour être un peu plus clair.
- L'application à laquelle je fais référence est l'application administrative qui gère la modification des données backend. L'application proprement dite elle-même est déjà en place et fonctionne à l'aide desdites données dorsales.
- En ce qui concerne les dates d'entrée en vigueur. Lorsque l'application réelle demande des données, elle passe une date effective afin de savoir quels enregistrements sont "effectifs" à cette date. Il existe une "date de fin" correspondante qui est soit nulle, soit remplie. Dans une base de données de 20 tableaux, au moins 10 auront probablement des dates d'entrée en vigueur dans leurs enregistrements.
- Quand je dis que nous ne faisons pas ce qu'ils attendent. Ce que je veux dire, c'est qu'ils disent "Supprimer cet enregistrement" et nous finissons par le dater. Ils disent "Mettre à jour cet enregistrement" et nous finissons par le dater et en créer un nouveau.
- Chaque entrée nécessite une date d'entrée en vigueur. S'il s'agit d'un nouveau dossier, l'application doit encore savoir quand elle entrera en vigueur, et le raisonnement pourrait être simplement parce que c'est quand l'entreprise le veut, ou parce que c'est quand une certaine loi entre en vigueur. Il n'y a aucun moyen de le deviner.
Il est vrai que je peux simplement poster des messages de confirmation/d'état à l'utilisateur une fois qu'une action est terminée, mais ce que j'ai essayé de faire, c'est d'implémenter une interface utilisateur qui rend ce processus un peu plus fluide, plus informatif et plus intuitif pour le utilisateur final. Ainsi, même s'ils ne connaissent pas tous les petits détails de ce qui se passe réellement à l'arrière, ils seront convaincus qu'il fait ce dont ils ont besoin.
Pourriez-vous créer une interface à onglets verticaux, chaque onglet représentant une date effective? Cliquez sur un onglet pour voir les données à partir de cette date effective. (Pensez à Time Machine d'Apple sans l'animation de fantaisie.)
Pour effectuer une modification, l'utilisateur commencerait par entrer une date effective. Cela créerait et sélectionnerait un nouvel onglet, une copie de celui qui le précédait, avec des champs modifiables. Il est donc clair quelle date effective est en cours de modification, et il est également possible de cliquer sur les onglets et d'afficher la politique à d'autres moments.
Avec le modèle suggéré ici, une politique ne se "terminerait" jamais (bien qu'il y ait encore une date de fin dans la base de données); il serait simplement remplacé par la prochaine date d'entrée en vigueur.
Malheureusement, cela signifie que la politique ne se termine jamais après la dernière date d'entrée en vigueur. Vous pouvez faire du dernier onglet un marqueur signalant la fin de la politique. Ainsi, au lieu de "supprimer", les utilisateurs modifieraient simplement la date d'entrée en vigueur de l'onglet de fin. (Vous pouvez toujours avoir un bouton "supprimer" - cela changerait la date d'entrée en vigueur de l'onglet de fin à aujourd'hui).
Il est difficile de se déplacer en demandant à l'utilisateur une date d'entrée en vigueur pour chaque changement s'il doit donner une date d'entrée en vigueur spécifique pour chaque changement. Il existe cependant des opportunités. Faites des recherches sur la façon dont les gens utilisent votre logiciel et voyez si vous pouvez comprendre certains modèles. Par exemple, les utilisateurs gèrent peut-être des comptes et les comptes sont toujours mutés le dernier jour du mois. Si tel est le cas, vous pouvez cesser de demander aux utilisateurs des dates spécifiques pour ces mutations et au lieu de simplement le remplir pour eux (en choisissant une option par défaut, ou en masquant le contrôle - test utilisateur pour voir ce qui fonctionne le mieux). Vous pouvez également vérifier s'il existe des dates périodiques tout au long de l'année, ou chaque mois, auxquelles certaines choses se produisent, et peut-être les proposer comme modèles. Par exemple, "Performance Review Day" ou "Last Fridday of every month". En fin de compte, vous devez identifier les modèles pour voir comment vous pouvez optimiser le flux de travail et réduire les entrées côté utilisateur.
Edit: undeleted et débarrassé de la plupart des réponses où je ne savais pas ce qui se passait