Validações de Dados

Time

1 Product Designer, 1 Tech Lead, time interno pequeno

Contratados pra analisar dado. Viraram auditoria de arquivo.

Antes de tudo, o contexto: eu era designer numa consultoria de dados, e a HDI, seguradora, era nossa cliente. O usuário final do projeto era o time de Analytics da HDI.

E esse time tinha um problema. Um time de Analytics deveria gastar o tempo dele analisando dados, esse aqui gastava mais tempo corrigindo dados do que olhando pra eles. Eles eram responsáveis por criar dashboards com dados de mercado, mas parte da rotina era tratar dados públicos de fornecedores: milhares de arquivos, cheios de erro, corrigidos um por um, todos os dias, na mão. O trabalho analítico, o motivo pelo qual esse time existia, ficava em segundo plano.

Objetivo: simplificar e automatizar esse processo de tratamento de dados.

O problema não era o produto. Era eu não entender o problema.

Meu maior desafio nesse projeto não foi de design. Foi que eu não tinha o repertório técnico pra entender, sozinha, as dores de quem eu ia ajudar.

Nas reuniões e entrevistas com o time técnico, eu me perdia. Falavam de esteiras, validações, cenários de erro, e eu não conseguia mapear onde cada dor acontecia no processo. Um designer que não entende o problema não desenha a solução; desenha um chute bonito.

Então, em vez de fingir que entendia, montei um sistema pra contornar isso.

A solução foi uma troca, não um socorro.

Trouxe uma tech lead pra participar ativamente de todo o Discovery. Mas não como muleta, como parceira numa troca de duas vias:

• Ela me traduzia o técnico. Cada dor relatada, cada etapa do processo, cada porquê, ela transformava em algo que eu conseguia mapear.
• Eu a ensinava a pesquisar. Nas partes dos workshops que eu não conseguia conduzir sozinha (por falta de domínio do assunto), ensinei a ela métodos de pesquisa, como fazer perguntas menos enviesadas, como conduzir sem induzir a resposta. Assim ela cobria o que eu não alcançava, sem contaminar os achados.
• E fechávamos juntas. Ao fim de cada rodada, fazíamos um debriefing: eu pegava o que tinha saído e traduzia de volta pra uma linguagem simples, deixando os problem statements evidentes pro resto do time.

O resultado dessa dinâmica não ficou só no projeto, mais adiante eu volto nisso.

Eu achava que era uma esteira. Eram três.

Entrei no projeto com uma hipótese confortável: a esteira de validação era direta, linear, uma coisa só. Automatizar parecia questão de mapear os passos.

Estava errada.

Na real, eram três esteiras diferentes, e, no meio delas, vários cenários mapeados que a automação simplesmente não conseguia resolver. Eram casos que precisavam, obrigatoriamente, remeter a uma decisão humana. Descobrir isso cedo mudou o desenho inteiro da solução: não bastava automatizar e sumir com o trabalho manual; era preciso desenhar para onde o humano entra quando a máquina não dá conta.

Antes de desenhar tela, documentei o que ninguém tinha documentado.

Esse time trabalhava com essas validações todos os dias, então já sabia, na prática, quais etapas mais importavam pra garantir dados limpos. O problema? Nada disso estava escrito em lugar nenhum.

Comecei por um workshop, em três movimentos:

Levantamento dos tipos de validação,pra entender o escopo e dar à tech lead o que ela precisava pra estudar cenários de automação.

Votação das validações mais prioritárias,pra facilitar a priorização no roadmap.

Dinâmica 5W1H em cada validação,pra medir impacto e alinhar o time sobre o que vinha primeiro.

Ela construiu o pipeline. Eu traduzi pra leigos.

Com o mapa em mãos, a divisão ficou clara: a tech lead tocou as automações, o pipeline técnico da solução. Eu cuidei de traduzir toda essa lógica técnica em linguagem de entregas de valor e desenhei as telas, de um jeito que o time de negócio também entendesse, não só o time técnico.

Nem tudo dava pra automatizar. E isso virou parte do design.

Lembra dos cenários que exigiam decisão humana? Eles definiram a solução. Mesmo automatizando a identificação dos erros, a correção de alguns sempre precisaria de gente, e casos específicos exigiam tratamento específico. Sem prever isso, dado demais seria simplesmente descartado das análises.

Por isso desenhei uma interface para um funil de validações: erros fáceis de identificar, com tratativas claras sempre que precisassem de ajuste humano. A automação resolvia o volume; o design resolvia a exceção.

A entrega

• Páginas de sinalização de bloqueio, uma para cada tipo de validação, mostrando exatamente qual arquivo travou e por quê.
• Histórico de validações, uma visão central e analítica pra acompanhar progresso e enxergar padrões de erro ao longo do tempo.

O resultado que passou do projeto

O fluxo foi validado e o processo manual e desgastante deu lugar a um funil claro, com o humano entrando só onde realmente precisa.

Mas o impacto maior não coube dentro do projeto, nem parou na HDI. A dinâmica de pesquisa + tradução técnica que criei com a tech lead funcionou tão bem que virou referência pro modelo TaaS da consultoria onde eu trabalhava. Hoje existe uma etapa de design e desenvolvimento no onboarding dos projetos da consultoria, e eu co-liderei essa iniciativa junto com a tech lead e uma gerente nossa.

O que eu levo desse projeto

• Não entender o problema técnico não é desculpa pra não liderar, é um convite pra colaborar melhor. Em vez de esconder minha limitação, transformei ela num sistema: eu ensinava pesquisa, a tech lead traduzia o técnico. Os dois lados saíram mais fortes.
• A realidade quase sempre é mais complexa que a hipótese. Achei que era uma esteira, eram três, e o que a automação não resolvia foi tão importante de desenhar quanto o que ela resolvia.
• Bom processo escala além do projeto. O maior resultado aqui não foi uma tela, foi um método de trabalho que a consultoria inteira passou a usar.

Vamos conversar?

Aberta a novos projetos, parcerias e conversas sobre produto e design.