Prints no suporte: como mostrar o problema sem expor dados

Um print pode explicar um erro e expor os clientes ao mesmo tempo. Um exemplo mostra como preservar a evidência útil do chamado e limitar o que circula com ela.

Folhas translúcidas azuis em camadas, com áreas cobertas por papel azul-marinho e uma moldura verde a destacar uma pequena mudança numa linha azul.

Uma pessoa abre o suporte porque o botão de exportar ficou fora da tela. Para explicar, manda um print. A imagem mostra o problema com clareza, mas também traz nomes de clientes, valores em aberto e uma notificação particular no canto do computador.

O pedido era simples. Agora, quem atende precisa investigar o erro e cuidar de informações que não eram necessárias para isso. Se a imagem seguir para um grupo da equipe, uma tarefa de desenvolvimento e uma apresentação de produto, cada encaminhamento aumenta o trabalho de proteção.

Para quem constrói um SaaS, essa situação merece atenção antes do próximo chamado. É possível pedir evidências melhores e reduzir o que circula junto com elas. O primeiro passo é explicar qual dúvida o print precisa resolver.

Comece pela pergunta que a imagem deve responder

Imagine um sistema fictício de gestão usado por uma distribuidora. Na tela de cobranças, uma analista aumenta o zoom do navegador para ler os valores. O botão “Exportar” desaparece à direita. Ela quer terminar o fechamento do dia e envia uma captura da tela inteira.

A equipe precisa descobrir se o botão saiu da área visível, se a tabela ficou larga demais ou se a ação realmente deixou de estar disponível. Os nomes dos compradores e os saldos não ajudam a distinguir essas hipóteses. Já o tamanho da janela, o nível de zoom e a posição da barra de rolagem ajudam.

Um pedido mais preciso poderia ser: “Você consegue mostrar a região da tabela e do botão, sem os dados dos clientes? Diga também o zoom usado e se acontece com a janela maximizada.” Essa orientação oferece um caminho para colaborar. A frase genérica “envie um print para analisarmos” deixa toda a decisão sobre o conteúdo com uma pessoa que já está tentando resolver outro problema.

Em alguns casos, nem será necessário anexar uma imagem. Saber a tela, a ação tentada, o resultado esperado e o que aconteceu pode bastar para reproduzir a falha em uma conta de teste.

Preserve a pista, retire o que não participa do problema

No exemplo, recortar apenas o botão também seria ruim: desapareceria justamente a relação entre tabela, janela e rolagem. O recorte útil mantém essa geometria e elimina áreas sem relação com a falha, como outras abas, notificações e a barra de favoritos.

Quando possível, reproduza o problema com dados fictícios. Se o erro depender do comprimento de um nome, use um nome de teste com tamanho semelhante. Se depender de muitas colunas, preserve a quantidade e a disposição. Trocar tudo por campos curtos pode esconder o comportamento que a equipe procura.

Quando for necessário trabalhar com uma captura real, use uma ferramenta aprovada pela organização. As áreas sensíveis precisam ser removidas ou ter seus pixels substituídos de forma permanente na imagem enviada. Uma anotação que possa ser movida ou apagada mantém o conteúdo original recuperável.

Exporte uma cópia rasterizada, como PNG, sem camadas editáveis, e abra o arquivo exportado para conferir o resultado antes do envio. Verifique também o nome do arquivo e metadados desnecessários. Para PDFs, o cuidado é diferente: a documentação da Adobe orienta aplicar a remoção de conteúdo e tratar informações ocultas, incluindo metadados e camadas. Desenhar um retângulo sobre a página não equivale a concluir esse processo.

O formulário pode ajudar antes do anexo chegar

Uma orientação no momento de anexar tem mais chance de ser útil do que uma explicação perdida em um documento. Ela pode pedir o trecho relevante da tela, lembrar que nomes e valores devem ser retirados e permitir que a pessoa prossiga sem imagem.

A prévia do arquivo também importa. Antes de enviar, a pessoa deveria conseguir ver o que selecionou, remover o anexo errado e entender para quem ele será enviado. Se o destino for público, isso precisa aparecer antes da publicação. Uma solicitação de melhoria compartilhada com outros usuários exige uma revisão diferente de uma conversa privada com o suporte.

Esse cuidado vale para o contexto coletado automaticamente. Uma URL pode carregar termos pesquisados, e-mails ou identificadores em seus parâmetros. Avalie o que a aplicação coloca nesses endereços e o que suas integrações recebem, em vez de presumir que todo dado técnico é inofensivo.

O Sinalio informa que recebe mensagem, URL atual, ambiente, versão do widget, horário confiável e uma referência externa opcional do usuário. Não captura automaticamente screenshots, conteúdo do DOM, logs do console, teclas digitadas ou replay de sessão. Esse escopo ajuda a orientar a instalação; a equipe ainda precisa revisar os dados que a própria aplicação coloca no contexto enviado.

Quando a investigação pede mais do que um print

Talvez a falha só apareça durante uma requisição de rede. Nesse momento, pedir “todos os logs” pode trazer muito mais informação do que a investigação exige. Defina primeiro o intervalo e a operação que precisam ser observados, preferindo uma reprodução controlada.

O Chrome oferece uma exportação HAR sanitizada que exclui cabeçalhos como Cookie, Set-Cookie e Authorization. Isso não dispensa a revisão do restante do arquivo: URLs e conteúdos de requisições ou respostas podem conter informações próprias da aplicação. O material deve seguir por um canal aprovado, com acesso limitado à investigação.

A orientação da OWASP para logs também recomenda evitar o registro direto de senhas, tokens e outros segredos. Coletar menos na origem reduz o que alguém terá de localizar e retirar depois.

A evidência do chamado não precisa acompanhar a ideia

Depois de reproduzir o erro, a equipe da distribuidora consegue registrar uma conclusão útil: com zoom ampliado, a tabela empurra a ação de exportação para fora da área visível. A tarefa de desenvolvimento pode usar uma captura feita em teste. O feedback de produto pode descrever a dificuldade sem carregar a imagem original.

Se um anexo inadequado já circulou, interrompa novos encaminhamentos e siga o procedimento interno para avaliar acesso, cópias e tratamento do arquivo. Apagar um comentário não demonstra que todas as cópias desapareceram. A documentação do Zendesk, por exemplo, descreve limites da remoção de conteúdo e informa que ela não alcança canais externos.

Na próxima revisão do atendimento, escolha um tipo recorrente de chamado e reescreva o pedido de evidência. Teste se uma pessoa consegue mostrar o problema sem expor seus clientes. Um bom relato deixa a equipe entender o que aconteceu e dá ao usuário confiança para continuar a conversa.

Escrito por

João Müller