it-swarm-pt.com

Lidando com datas efetivas em um aplicativo administrativo

Ao lidar com informações baseadas em seguros, geralmente precisamos implementar o uso de datas efetivas na maioria dos nossos dados. Existem inúmeras razões para isso em que não vou entrar, é desnecessário dizer que parte do design não pode ser alterada.

O problema com que frequentemente encontro é quando preciso criar uma interface administrativa para esses dados para nossos usuários corporativos. Geralmente, na parte superior da tela em que estão, o usuário seleciona uma data efetiva. Essa data efetiva determina quais dados são apresentados a eles para fins de edição. (ou seja, esses dados são efetivos para esse período)

Agora, sempre que o usuário faz uma alteração, solicitamos a data efetiva dessa alteração. Em seguida, fazemos uma alteração no banco de dados, dependendo do que o usuário fez.

  • Se eles excluíram um registro, marcamos a data de término do registro como
    a data efetiva da alteração.

  • Se eles atualizarem um registro, terminamos a data do registro antigo e criamos um novo
    registre com a nova data efetiva.

  • Se eles adicionarem um registro ... bem, nós adicionamos um registro.

Aqui estão os problemas que estou enfrentando com uma boa interface do usuário/experiência do usuário.

  1. O usuário precisa nos informar constantemente a data efetiva de uma alteração. Isso é complicado e irritante para o usuário.

  2. O usuário não pode ver as alterações em sua tela, a menos que efetue a alteração imediatamente. Isso ocorre porque a data efetiva é escolhida na parte superior da tela. Além disso, eles quase nunca fazem uma alteração efetiva imediatamente.

  3. Por fim, como não estamos realmente fazendo as alterações esperadas, não podemos apenas mostrar a eles os dados em formato de tabela, porque não faria muito sentido para eles. Eles acham que um dado está lá uma vez, mas o vêem 25 vezes por causa de 25 alterações.

Eu esperava poder receber algum feedback de que tipo de alterações você faria em uma interface do usuário para ajudar com um problema como esse. Não tenho certeza se é um problema com o qual as pessoas precisam lidar com frequência, mas no setor de seguros, temos que lidar com isso com muita frequência. A tecnologia não importa, Thick Client, Web App, etc.

Editar

Para ser um pouco mais claro.

  1. O aplicativo ao qual estou me referindo é o aplicativo administrativo que lida com a modificação dos dados de back-end. O próprio aplicativo já está em vigor e em execução usando os dados de back-end.
  2. Quando se refere a datas efetivas. Quando o aplicativo real solicita dados, ele passa em uma data efetiva para descobrir quais registros são "Efetivos" nessa data. Há uma "Data de término" correspondente que é nula ou preenchida. Em um banco de dados de 20 tabelas, provavelmente pelo menos 10 terão datas efetivas em seus registros.
  3. Quando digo que não estamos fazendo o que eles esperam. O que quero dizer é que eles dizem "Excluir este registro" e na verdade terminamos com ele. Eles dizem "Atualizar este registro" e na verdade terminamos a data e criamos um novo.
  4. Cada entrada requer uma data efetiva. Se for um novo registro, o aplicativo ainda precisa saber quando entra em vigor, e o raciocínio pode ser simplesmente porque é quando a empresa o deseja ou porque é quando uma certa lei entra em vigor. Não há como adivinhar.

É verdade que posso simplesmente postar mensagens de confirmação/status para o usuário após a conclusão de uma ação, mas o que estou tentando fazer é implementar uma interface com o usuário que torne esse processo um pouco mais suave, mais informativo e mais intuitivo para o usuário. usuário final. Portanto, embora possam não conhecer todos os detalhes do que realmente está acontecendo no back-end, eles se sentirão confiantes de que está fazendo o que precisa.

5
Jeff Sheldon

Você poderia criar uma interface de guia vertical, com cada guia representando uma data efetiva? Clique em uma guia para ver os dados a partir dessa data efetiva. (Pense no Time Machine da Apple sem a animação chique.)

Para fazer uma alteração, o usuário começaria inserindo uma data efetiva. Isso criaria e selecionaria uma nova guia, uma cópia da que a precedeu, com campos editáveis. Portanto, fica claro qual data efetiva está sendo editada e também é possível clicar nas guias e visualizar a política em outros momentos.

Com o modelo sugerido aqui, uma política nunca "terminaria" (embora ainda haja uma data final no banco de dados); seria apenas substituído na próxima data efetiva.

Infelizmente, isso significa que a política nunca termina após a última data efetiva. Você pode tornar a última guia um marcador sinalizando o fim da política. Portanto, em vez de "excluir", os usuários simplesmente alterariam a data efetiva da guia final. (Você ainda pode ter um botão "excluir" - isso mudaria a data efetiva da guia final para hoje).

4
Patrick McElhaney

É difícil solicitar ao usuário uma data efetiva para cada alteração se ele precisar fornecer uma data efetiva específica para cada alteração. Existem algumas oportunidades, no entanto. Faça uma pesquisa sobre como as pessoas estão usando seu software e veja se você consegue descobrir alguns padrões. Por exemplo, talvez os usuários estejam gerenciando contas e as contas sejam sempre alteradas no último dia do mês. Se for esse o caso, você pode parar de perguntar aos usuários sobre datas específicas para essas mutações e apenas preenchê-las (escolhendo uma opção padrão ou ocultando o controle - teste do usuário para ver o que funciona melhor). Você também pode verificar se há datas periódicas ao longo do ano ou a cada mês, nas quais certas coisas acontecem, e talvez as ofereça como modelos. Por exemplo, "Dia da revisão do desempenho" ou "Última sexta-feira de cada mês". Por fim, você precisa identificar padrões para ver como otimizar o fluxo de trabalho e reduzir a entrada do lado do usuário.

Edit: cancelou a exclusão e me livrei da maioria das respostas em que eu não sabia o que estava acontecendo

3
Rahul