Como decidir quais tarefas devem ser executadas em segundo plano e quais precisam de uma resposta imediata

Uma tarefa leva vários segundos e a equipe propõe enviá-la para segundo plano. A decisão parece técnica, mas começa com uma pergunta de produto: a pessoa pode continuar seu objetivo sem conhecer o resultado agora? Se a resposta for sim, o processamento assíncrono pode reduzir interrupções. Se ela precisar do resultado para decidir ou concluir a próxima etapa, esperar pode ser mais claro e seguro.

Transferir uma operação para segundo plano não elimina sua duração nem sua complexidade. Isso muda o momento em que o usuário recebe uma resposta e as responsabilidades assumidas pelo produto: comunicar que o trabalho começou, preservar seu estado e facilitar a recuperação caso algo dê errado. Este modelo permite avaliar a experiência, a arquitetura e a operação antes de modificar um fluxo.

A decisão começa pelo que o usuário precisa fazer em seguida

O tempo de execução, por si só, não determina o padrão. Uma operação breve pode ser incômoda se bloquear uma ação importante; uma operação longa pode ser aceitável se o usuário puder continuar outra tarefa e voltar mais tarde. Vale observar o fluxo completo, e não apenas a chamada ou o serviço que demora.

Pergunte-se de qual decisão o resultado depende. Se alguém altera o endereço de entrega e precisa saber se a mudança foi aceita antes de confirmar uma compra, uma resposta imediata ajuda a evitar uma decisão às cegas. Se a pessoa pede a exportação de um relatório para usá-lo mais tarde, normalmente pode deixar que ele seja preparado enquanto continua trabalhando.

O custo da espera também importa. A tela bloqueada impede a conclusão de uma tarefa urgente? A pessoa perderia o que já escreveu se saísse do fluxo? Ela consegue entender o que está acontecendo sem recorrer ao suporte? Quando a espera interrompe um objetivo central, mas o resultado não é necessário para continuar, uma resposta rápida de aceitação e a execução em segundo plano podem resolver melhor o problema.

Critérios para escolher entre primeiro e segundo plano

Avalie cada operação com base em critérios observáveis. Não é necessário transformá-los em uma pontuação universal: eles servem para tornar explícitas as compensações e identificar diferentes pressupostos entre produto, design e engenharia.

• Dependência do resultado: se a próxima etapa exigir que o resultado seja conhecido, mantenha uma resposta imediata ou divida o fluxo para pedir confirmação no momento necessário.
• Impacto da espera: se o usuário ficar bloqueado ou perder o contexto, considere uma execução que permita que ele continue. Se a espera for breve e clara, acrescentar estados e navegação pode gerar mais complexidade do que benefício.
• Possibilidade de recuperar o trabalho: em segundo plano, deve ser possível identificar o que foi solicitado e consultar novamente seu estado. Se sair da tela fizer a operação ou seu contexto desaparecer, o padrão está incompleto.
• Reversibilidade e consequências: quando um resultado altera dinheiro, permissões, dados compartilhados ou compromissos externos, defina cuidadosamente o que significa “solicitado” e o que significa “concluído”. Não confunda aceitação com sucesso final.
• Necessidade de informar o progresso: se conhecer o andamento ajudar no planejamento, ofereça um estado útil. Se só for possível exibir uma barra sem relação confiável com o trabalho real, informe que ele continua em andamento, em vez de simular precisão.
• Dependências externas: serviços de terceiros podem acrescentar variabilidade ou deixar um resultado pendente de confirmação. Elabore a mensagem de acordo com o que realmente se sabe, não com o que se espera que aconteça.

Como regra prática, mantenha em primeiro plano as decisões que exigem uma resposta antes de avançar. Considere o segundo plano quando o usuário já puder considerar a solicitação iniciada, continuar com alguma atividade útil e voltar ao resultado sem perder informações.

Quando o processamento assíncrono é adequado — e quando não é

São bons candidatos os trabalhos que produzem um resultado consultável mais tarde e não condicionam a ação seguinte: gerar uma exportação, processar um conjunto de documentos, preparar uma prévia extensa ou sincronizar informações cujo resultado não seja necessário naquele instante. Nesses casos, o usuário pode receber a confirmação de que o trabalho começou, sair da tela e voltar ao item quando estiver pronto.

O processamento assíncrono também pode ser adequado para processos com várias etapas ou dependências externas cujo desfecho não é imediato. O requisito é que o produto consiga representar estados significativos, como “recebido”, “em andamento”, “requer atenção” ou “concluído”. Se o sistema não consegue determinar o estado do trabalho, não deve apresentar como certa uma conclusão que ainda não verificou.

Por outro lado, costuma ser preferível responder imediatamente quando o usuário precisa corrigir dados antes de continuar, quando o resultado determina uma escolha seguinte ou quando uma confirmação equivocada poderia causar prejuízo. Validar se um formulário tem campos obrigatórios, verificar se uma ação foi aceita ou mostrar se uma configuração foi salva são exemplos de respostas que podem fazer parte do próprio fluxo.

Há casos intermediários. Uma operação pode confirmar imediatamente que a solicitação foi recebida e concluir o trabalho depois. Essa resposta inicial precisa ser explícita: “Recebemos a solicitação” não equivale a “A operação foi concluída”. Essa distinção é especialmente importante para ações financeiras, alterações com efeitos externos e processos que podem exigir intervenção.

O que a interface deve comunicar

Uma experiência assíncrona precisa de mais do que um indicador de carregamento. Antes de começar, explique o que acontecerá e se o usuário poderá sair. Ao aceitar a solicitação, confirme que o sistema a registrou e ofereça uma referência ou um local reconhecível para consultar o resultado, se o fluxo exigir isso.

• Confirmação: indique o que foi solicitado e qual é o estado atual. Evite mensagens que sugiram sucesso definitivo quando houve apenas a confirmação do recebimento.
• Progresso: mostre etapas somente se elas refletirem informações disponíveis e ajudarem a compreender a espera. Se não houver uma estimativa confiável, não invente uma porcentagem nem um horário de conclusão.
• Continuidade: informe se é possível fechar a tela, mudar de seção ou continuar usando o produto sem cancelar o trabalho.
• Resultado e próxima ação: quando o trabalho terminar, explique o que mudou, onde encontrar o resultado e o que a pessoa poderá fazer caso precise revisá-lo ou corrigir algo.
• Problemas: comunique se o trabalho exige uma ação, ficou incompleto ou não pôde ser confirmado. Ofereça uma próxima etapa compreensível e evite mensagens genéricas que obriguem o usuário a entrar em contato com o suporte.

A notificação não substitui um estado persistente. Se o usuário voltar mais tarde, deverá conseguir entender o que aconteceu sem depender de um alerta que talvez já tenha desaparecido. Defina também o que ocorre se o resultado chegar enquanto a pessoa estiver em outra tela ou se o trabalho deixar de ser relevante.

Implicações operacionais e sinais para diagnóstico

O segundo plano transfere parte da experiência de uma tela para a operação do produto. A equipe precisa distinguir trabalhos pendentes, ativos, concluídos e que exigem revisão; investigar casos específicos e explicar divergências ao suporte. Isso não exige expor detalhes técnicos ao usuário, mas requer contexto interno suficiente para responder o que foi solicitado e o que aconteceu.

Observe sinais do fluxo, não apenas o tempo médio de processamento. Se mais usuários abandonarem o processo antes de receber uma confirmação, talvez a espera esteja bloqueando demais. Se houver muitas consultas ao suporte com perguntas como “foi concluído?”, falta visibilidade ou a confirmação é ambígua. Se as pessoas repetirem a ação por não saberem se a primeira solicitação foi registrada, o design pode estar incentivando duplicações. Se quase ninguém consultar o progresso, talvez uma visualização persistente ou uma notificação complexa não agregue valor.

Antes do lançamento, defina quem responderá por um trabalho travado, como comunicar um resultado parcial e o que acontecerá quando uma dependência externa não fornecer uma resposta conclusiva. Para ações sensíveis, defina também quem poderá ver o estado e o resultado. Essas decisões fazem parte do produto, não são detalhes que possam ser deixados para depois até surgir o primeiro incidente.

Perguntas a fazer antes de mudar um fluxo

1. O que o usuário precisa saber para dar o próximo passo, e em que momento?
2. Ele pode continuar trabalhando enquanto o resultado é preparado? Que contexto deve ser preservado?
3. Que confirmação podemos oferecer com certeza: recebimento, progresso ou conclusão?
4. Como ele encontrará o resultado depois de fechar a tela ou voltar outro dia?
5. Quais seriam as consequências de um estado incorreto, incompleto ou difícil de recuperar?
6. Que sinal de uso ou de suporte demonstraria que a espera melhorou, em vez de apenas ter sido transferida para outra tela?

A decisão certa não é automatizar em segundo plano tudo o que demora. É reservar a resposta imediata para os momentos em que ela oferece segurança ou permite avançar, e deixar o restante continuar sem sequestrar a atenção do usuário. Se não for possível explicar como o trabalho é confirmado, consultado e recuperado, o fluxo assíncrono ainda não está completo.