Um portal web pode ser um local onde os utilizadores consultam informações, enviam pedidos ou concluem transações, mas raramente é o único local onde estas atividades ocorrem. Um cliente pode iniciar um pedido numa aplicação móvel, contactar um representante de suporte, receber uma atualização automática e voltar ao portal posteriormente. Um funcionário pode fazer uma alteração através de um sistema interno antes de verificar o portal.
Isto cria um desafio para o desenvolvimento de portais web: o portal precisa de compreender as mudanças que ocorrem para além da sua própria interface.
Se o sistema apenas rastrear as ações realizadas dentro das suas páginas, os utilizadores poderão encontrar informações desatualizadas, tarefas duplicadas ou fluxos de trabalho que parecem estar bloqueados, mesmo que algo já tenha sido alterado noutro local.
Leia também: O problema do código gerado: o que os principiantes em desenvolvimento web devem verificar
As ações externas podem alterar o que o portal necessita de exibir
A parte mais difícil geralmente não é exibir informações. É determinar quais as ações externas que devem alterar o estado do portal.
As APIs podem criar mudanças de estado invisíveis
Uma integração de API pode atualizar uma conta, alterar o estado de um pedido ou desencadear um workflow sem que o utilizador tenha sequer de abrir o portal.
Por exemplo, um cliente pode atualizar o seu endereço através de uma aplicação móvel. Quando esse cliente aceder ao portal posteriormente, as novas informações já deverão estar refletidas. A apresentação do endereço anterior gera confusão e pode levar os utilizadores a questionar qual o sistema oficial.
Isto significa que o desenvolvimento de portais web precisa de ter em conta as mudanças de estado geradas pelas APIs e aplicações conectadas, em vez de tratar o portal como um ambiente isolado.
As equipas de suporte podem alterar o mesmo registo
As ações externas nem sempre são automatizadas. Um representante de suporte pode ajustar uma conta, aprovar um pedido ou resolver um problema em nome do cliente.
Se o portal não receber ou reconhecer esta atualização, o cliente poderá continuar a ver um estado desatualizado. Pior ainda, o cliente poderá repetir uma ação que um colaborador de suporte já concluiu. Por conseguinte, o portal necessita de regras claras sobre como as alterações provenientes de sistemas externos são validadas, sincronizadas e apresentadas.
A sincronização vai além de simplesmente manter os dados atualizados
A sincronização de dados parece simples, mas o timing é crucial. Dois sistemas podem conter informação tecnicamente válida, mas apresentar estados diferentes para a mesma transação.
A atualização mais recente nem sempre é a correta
Uma abordagem simplista de "a última atualização prevalece" pode gerar problemas quando as atualizações chegam fora de sequência. Uma mensagem API atrasada pode sobrescrever uma alteração mais recente, enquanto uma intervenção manual pode entrar em conflito com um fluxo de trabalho automatizado.
O desenvolvimento de portais web modernos exige mecanismos como registos de data e hora, ordenação de eventos, verificação de versões e definição clara da propriedade do sistema para determinar qual a atualização que deve prevalecer.
Os utilizadores precisam de contexto, não apenas de dados atualizados
Um portal deve também explicar as alterações significativas quando estas afetam a próxima etapa do utilizador.
Se um pedido foi aprovado por uma equipa de suporte externa ao portal, a simples alteração do seu estado pode não ser suficiente. A interface também pode indicar que o pedido foi analisado e qual a ação, se alguma, que ainda precisa de ser tomada.
Este contexto torna-se especialmente importante numa experiência omnicanal, onde os utilizadores esperam continuidade independentemente do canal que utilizaram anteriormente.
Projetar para ações que acontecem noutros lugares
Isto muda a forma como as equipas abordam a automatização de fluxos de trabalho. Em vez de criarem fluxos de trabalho baseados apenas em cliques no portal, têm de modelar eventos que podem ter origem em aplicações, APIs, colaboradores e processos automatizados.
Construa em torno de eventos, e não apenas de sessões
Uma abordagem orientada a eventos permite que o portal responda quando algo muda noutro local. O utilizador não precisa de atualizar repetidamente ou reenviar informações simplesmente porque outro sistema concluiu uma ação.
Defina a propriedade antes de ligar os sistemas
Cada dado importante deve ter uma fonte de verdade clara. Sem isso, os sistemas conectados podem sobrescrever-se continuamente ou deixar os utilizadores na dúvida sobre qual a versão a confiar.
Declaração final
Um portal moderno é cada vez mais uma janela para um fluxo de trabalho digital mais amplo, em vez do próprio fluxo de trabalho. Os utilizadores podem realizar ações através de diversos canais, enquanto as APIs e os processos automatizados alteram continuamente o que acontece nos bastidores.
As estratégias mais eficazes para o desenvolvimento de portais web são, portanto, concebidas considerando a jornada completa do utilizador, incluindo ações que nunca realiza dentro do portal. Quando os eventos externos, a propriedade do sistema e a sincronização são geridos adequadamente, o portal torna-se um reflexo fiável do processo subjacente, em vez de uma vista desconectada do mesmo.
