Voltar para todos os trabalhos

Entromy · Fluxos de IA · Produto de IA

Reduzindo o tempo de configuração de pesquisas multilíngues com tradução via IA

Substituindo um fluxo manual de exportar-traduzir-colar por um sistema centralizado de tradução com IA, construído para pesquisas corporativas globais lançadas em até 10 idiomas para mais de 1.500 participantes.

Função

Product designer, responsável pelo enquadramento do problema, por todo o design de UX, especificações e prototipagem.

Time

1 PM, 1 engenheiro, 2 QA

Este projeto é coberto por um NDA. Alguns detalhes de interface, dados e especificidades foram simplificados, ocultados ou omitidos abaixo; o processo, as decisões e os resultados são representados fielmente.

A história em 30s

O problema. A Entromy realiza pesquisas corporativas em mais de 62 idiomas para clientes de private equity e empresas, frequentemente lançando de 4 a mais de 10 idiomas simultaneamente para empresas com mais de 1.000 funcionários e avaliações que alcançam mais de 1.500 participantes. A tradução acontecia inteiramente fora do produto: exportar para o Excel, traduzir no Google Tradutor, colar de volta em células separadas por ponto e vírgula, um idioma por vez.

O que eu fiz. A primeira versão que projetei com o PM era totalmente flexível: edição de perguntas lado a lado, substituições por pergunta e um histórico completo de traduções. A engenharia estimou essa construção e ela não era viável para o prazo que tínhamos. Então voltei para a pesquisa para encontrar o fluxo mínimo que ainda resolvesse o problema real: participei de calls com clientes, analisei padrões nos tickets de suporte, mapeei a jornada do cliente com nosso time interno, e fiz uma análise competitiva da Qualtrics, Leapsome, Culture Amp e SurveyMonkey. Triangular o que os clientes diziam, o que os tickets de suporte mostravam e o que os concorrentes ofereciam apontou para um único fluxo: um sistema de tradução centralizado, acionado pelo usuário, dentro da própria plataforma, lançado em três versões sequenciadas por frequência e complexidade. Comunicações primeiro, perguntas da pesquisa em segundo, perguntas de autorregistro por último.

O que mudou. O tempo de configuração para clientes multilíngues caiu cerca de 40 a 50%, a mesma fração que o time de Customer Success estimava ser perdida no processo manual. Uma mudança tardia na fonte em inglês costumava invalidar todas as traduções existentes sem aviso. Esse risco desapareceu.

O raciocínio: o menor fluxo que ainda funciona

O design original, edição lado a lado, histórico por pergunta, controle manual total, era a versão que eu queria construir. A estimativa da engenharia deixou claro que não era viável lançá-la no prazo disponível, então o verdadeiro problema de design passou a ser: qual é o menor fluxo que ainda elimina a dor que os clientes descreviam? Para responder isso, triangulei três fontes em vez de adivinhar: calls com clientes onde ouvi o processo em primeira mão, padrões nos tickets de suporte, e uma sessão de mapeamento da jornada do cliente com nosso time interno para localizar onde estava realmente o atrito. Somei a isso uma análise competitiva da Qualtrics, Leapsome, Culture Amp e SurveyMonkey para ver como plataformas comparáveis lidavam com o mesmo problema. Essa triangulação foi o que me permitiu cortar escopo com confiança em vez de por achismo, eliminando a edição por pergunta, o histórico de traduções e a comparação lado a lado, e mantendo uma única ação enxuta: selecionar idiomas, acionar a tradução automática, sobrescrever tudo em lote.

  • O destrutivo vence o que só parece seguro. Uma abordagem não destrutiva parecia mais segura, mas permitia que traduções parecessem completas enquanto silenciosamente ficavam desatualizadas sempre que o inglês mudava. Sobrescrever a cada execução mantém uma única regra honesta.
  • Uma única fonte de verdade estrutural. Permitir que a estrutura divergisse por idioma quebraria lógicas independentes de idioma, como ramificações condicionais, e transformaria um modelo de tradução um-para-muitos em um muitos-para-muitos impossível de gerenciar.
  • Centralizado, não "mágico." Ações de IA embutidas em cada pergunta teriam aumentado o custo de IA e criado uma lógica de sobrescrita pouco clara, então a tradução é acionada em um só lugar em vez de se espalhar por cada campo.
  • Tudo ou nada, de propósito. Falhas raras de tradução são tratadas de forma próxima a tudo-ou-nada, com mensagens claras, em vez de construir uma lógica complexa de recuperação parcial que os clientes ainda não tinham pedido.
Diagrama de quatro etapas do fluxo de tradução: selecionar idiomas, acionar tradução automática, IA traduz em lote a partir do inglês, traduções ausentes são sinalizadas
1. Selecionar idiomas2. Acionar Tradução Automática3. IA traduz em lote a partir do inglês4. Traduções ausentes ou desatualizadas são sinalizadas

Visão geral da solução

Lançado em três versões, um mesmo padrão reutilizado em todas elas:

  • Comunicações primeiro, para provar o padrão. Um seletor de idiomas, uma única ação de tradução automática que traduz todos os campos para todos os idiomas habilitados de uma vez, edição manual em linha por idioma, e um ícone de aviso quando um idioma está com traduções faltando.
  • Perguntas da pesquisa: mesmo padrão, mais estrutura. O mesmo padrão estendido para lidar com opções de resposta de múltipla escolha, com edições estruturais restritas ao inglês.
  • Autorregistro: o padrão, sem o gargalo. O mesmo padrão novamente, eliminando por completo o formato rígido do Excel e a dependência de um engenheiro.
  • Um gatilho pontual, não um aviso geral. Um alerta direcionado de retradução só é acionado quando a fonte em inglês realmente muda, em vez de deixar conteúdo desatualizado sem sinalização.
Comparação antes e depois

Resultados

  • Eliminou uma estimativa de 40 a 50% do tempo de configuração de pesquisas para clientes multilíngues
  • Eliminou completamente a dependência de um desenvolvedor para traduções de autorregistro
  • Comunicações que antes levavam horas de copiar e colar agora levam um clique, mais um refinamento manual opcional
  • A adoção foi positiva entre grandes clientes que rodam avaliações multirregionais de grande escala (números específicos de adoção limitados pelo NDA)

Reflexão

  1. 1 O primeiro design nem sempre é o que pode ser lançado, e tudo bem. A versão lado a lado, totalmente flexível, era a ideia certa em abstrato, mas voltar para a pesquisa depois da estimativa da engenharia, em vez de tentar defender o escopo original, foi o que nos levou a um fluxo que realmente foi lançado e realmente funcionou.
  2. 2 Triangular transforma cortes de escopo em decisões, não em apostas. As calls com clientes, os padrões dos tickets de suporte, o mapeamento interno da jornada e a análise competitiva apontaram todos na mesma direção, o que permitiu cortar com segurança o histórico, a edição por pergunta e a comparação lado a lado, em vez de cortar só o que era mais fácil.
  3. 3 Explicável vence esperto. Recursos de IA nesse tipo de fluxo corporativo têm sucesso por serem explicáveis e previsíveis, não espertos. Os usuários não queriam mais automação. Queriam saber exatamente o que mudaria, quando e por quê.
Próximo: revisitar a flexibilidade por pergunta e o histórico agora que a versão enxuta provou o fluxo principal, desta vez com dados reais de uso em vez de suposições iniciais.

Trabalhos

Redesign de Dashboard de Analytics Corporativo Sistema Modular de Lojas para Mais de 2.000 Varejistas Escalando uma Plataforma de Gestão de Programas para Startups (Em breve)