Diagnosticando por que usuários culpavam o SAJ pelas quedas dos tribunais

As falhas de integração aconteciam toda semana e, para alguns clientes, quase todo dia. O PJe era o sistema mais instável, seguido pelo SEEU. Peticionar era a ação mais crítica, porque está ligada a prazos processuais. Autos e intimações vinham logo depois.

O usuário tentava uma ação, ela falhava, tentava outra, e a interface não dava o motivo. O suporte de primeiro nível (N1) ficava sabendo das quedas pelas reclamações em grupos de WhatsApp, muitas vezes ao mesmo tempo que o usuário, e diagnosticava por tentativa e erro.

Havia também uma restrição política. Em vários Ministérios Públicos existe um acordo implícito de não dizer que o problema está no tribunal. Sem como apontar a origem, o SAJ levava a culpa.

Cada conclusão liga um achado da pesquisa a uma decisão de interface e registra o que outra melhoria do produto já cobria.

1. Peticionar é a ação mais crítica.

Afeta prazos e vem primeiro no status. Uma melhoria separada (reenviar a petição após falha de comunicação com o tribunal) já cobria esse fluxo, então o status não precisava agir sobre ele.

2. Autos e intimações também são sensíveis.

O envio de anexos e o recebimento de intimações geram chamados recorrentes. Não havia melhoria prevista para autos, e um cenário de erro dedicado dependia do time responsável por essa área.

3. Prevenção de erros.

O status sinaliza a instabilidade antes da ação. Para autos e intimações, a proposta são cenários de erro dedicados.

4. Uma falha para o trabalho.

O ideal seria sugerir outra tarefa quando uma ação está indisponível. As próximas tarefas dos usuários não estavam mapeadas, então a opção viável é dizer que a instabilidade está sendo tratada e sugerir outras tarefas de forma geral.

5. Informação clara reduz chamados.

As frases são curtas, dizem que o time já está agindo e nomeiam as ações: “Peticionamento, acesso aos autos e envio e recebimento de intimações funcionando normalmente” e “Instabilidade no peticionamento, no acesso aos autos ou no envio e recebimento de intimações”.

6. Status por funcionalidade.

Peticionamento, autos e intimações aparecem separados, em dois estados: “Funcionando normalmente” e “Funcionando com instabilidade”. Os tooltips dizem “Este serviço está ativo e operando sem falhas agora” e “Este serviço está ativo, mas algumas tentativas estão falhando”.

7. Detalhes no hover ou no clique.

Mostram o horário da última verificação, o serviço afetado e o andamento da correção. Desenhei duas opções. Opção 1: um botão no cabeçalho com ícone verde ou amarelo que abre um modal. Opção 2: o modal na barra lateral de Minha Conta, com um alerta e um botão de acesso quando há instabilidade.

8. Status dentro do fluxo da tarefa.

O status aparece no momento da ação, por exemplo antes de enviar uma petição. Para o peticionamento, a melhoria existente já cobria esse ponto.

9. Confiabilidade percebida.

Mostrar que as integrações são monitoradas reforça a confiança. A opção 2 deixa a falha mais evidente, porque dispara o alerta quando a falha acontece. A opção 1 é mais discreta e também pode mostrar o alerta.

10. Variações de contexto.

Alguns usuários não leem mensagens de erro, e outros são mais técnicos. Os detalhes ficam no modal, e alertas e botões usam linguagem simples.

Uma restrição política virou um requisito de linguagem.

Alguns clientes não podem nomear o tribunal, então o status descreve a ação afetada e deixa a origem de fora. Isso permitiu que um único design servisse a todos os clientes.

Ouvir só o suporte deixou uma lacuna.

As previsões dos entrevistados sobre o efeito do painel nos chamados nunca foram checadas com usuários finais, porque o teste foi cancelado.