Pesquisa e diagnóstico
Entender o processo como ele realmente acontece, conversando com quem executa, e não só com quem descreve. Costuma ser aqui que aparece o problema que ninguém tinha formulado.
Disponível para vagas e projetos
Doze anos somando camadas: front-end, UX, produto, gestão, dados e automação. Hoje conduzo o produto do discovery à entrega, e entrego o sistema inteiro, do problema que ninguém tinha formulado até o que está rodando.
Trabalhei com
A trajetória, 12 anos, e ela fecha um círculo
01 Sobre mim
Comecei como desenvolvedor front-end, há doze anos. No primeiro emprego, recém-saído do ensino médio, desenhar as telas antes de construir era um adicional do plano mais caro, e não o padrão da casa. Foi ali que eu comecei a fazer UX sem saber que aquilo tinha nome. Aos vinte anos abri uma agência com uma sócia, que chegou a mais de duzentos clientes ativos e cinco pessoas no time, e onde eu desenhava e programava as entregas.
Doze anos somando camadas: pesquisa, interface, sistema, time, dados, automação. Construir foi a última a voltar, e agora o caminho inteiro começa pela necessidade, não pela solução.
No meio desse caminho eu passei anos especificando o que outras pessoas construíam. Trabalhando por conta própria, entregava o projeto e terceirizava a produção, ou deixava a decisão com o cliente. Foi o período em que fiz projetos para empresas como John Deere, Volvo e SEBRAE.
Nos últimos cinco anos o movimento foi o mesmo de sempre, só que mais rápido. Comecei desenhando telas e entregando handoff para os desenvolvedores. Depois criei o design system que a empresa não tinha. Virei responsável pelo design das três empresas do grupo, com um time de sete pessoas e reportando direto à presidência. E, na última fase, passei a construir eu mesmo o que antes eu especificava.
No fundo, boa parte desse trabalho foi sempre a mesma coisa em escalas diferentes: descobrir onde uma informação nasce e garantir que ela chegue inteira onde precisa ser usada. Cheguei a mapear os processos de todos os setores de uma empresa, não pelo que acontece dentro de cada área, mas pelo que acontece nas fronteiras entre elas, onde uma atividade sai de uma e precisa chegar em outra. É assim que eu penso automação: gatilho, ação e resultado. De onde vem, o que acontece no meio, para onde vai. E é o mesmo desenho de um fluxo de usuário ou de uma integração entre dois sistemas que nunca se falaram. Muda a escala, não o raciocínio.
O que mudou nos últimos anos não foi o diagnóstico. Foi o que vem depois dele. Sair de “entendi o problema” para “está no ar” exigia montar uma frente para cada camada: back-end, front-end, QA, infraestrutura. Cada especialista com sua agenda, e o problema esperando no meio disso. Hoje eu atravesso essas camadas sozinho, e não é território novo para mim: é o lado de onde eu vim.
Não é que a equipe deixou de importar. Em escala, importa muito. O que deixou de existir é a barreira de entrada: uma empresa não precisa mais gastar meses e meia dúzia de pessoas em cima de um problema só para descobrir se a solução era a certa.
Mesmo quando o trabalho era investigar dado bruto na origem, eu tratava aquilo como UX. Antes de qualquer coisa, eu precisava entender tudo sobre o usuário: como o sistema funcionava, como pensava quem era dono do processo, e o que essa pessoa queria ver no fim. E eu nunca trazia um número antes de validá-lo com quem era responsável por ele. Minha palavra nunca era a última.
Sites institucionais a partir de templates, recém-saído do ensino médio.
Desenhar antes de construir era um item do plano mais caro. Foi ali que começou, e eu ainda não sabia que aquilo tinha nome.
Sócio de 50%, com mais de 200 clientes ativos e um time de cinco pessoas. Desenhava e programava as entregas: HTML, CSS e JavaScript. Todo projeto começava pelo entendimento da marca do cliente.
Projetos para John Deere, Volvo e SEBRAE, e identidade visual para marcas da região de Campinas.
Cinco anos, quatro fases, cada uma ampliando o escopo da anterior.
Especialização com as principais referências do país, feita ao longo dos anos na Bittar. O MBA foi concluído já com o time sob a minha gestão.
Desenho e entrego sistemas inteiros, do problema à produção.
02 O que faço
Desenhar e entregar costumam ser trabalho de duas pessoas diferentes. Eu faço as duas coisas, e é justamente aí que o tempo entre entender e resolver encurta.
Descobrir e desenhar
Entender o processo como ele realmente acontece, conversando com quem executa, e não só com quem descreve. Costuma ser aqui que aparece o problema que ninguém tinha formulado.
Do fluxo à interface final. Produto novo, ou redesenho de um sistema que cresceu sem plano e ficou difícil de usar.
Criar do zero ou organizar o que já existe: tokens, componentes, documentação e, principalmente, a adoção pelo time, que é a parte que costuma falhar.
Entregar funcionando
Entender como o trabalho realmente acontece em cada setor e, principalmente, o que acontece nas fronteiras: onde uma atividade sai de uma área e precisa chegar em outra. É nas fronteiras que mora quase todo o retrabalho.
Com o processo mapeado, automatizar o que se repete e levar IA para dentro da rotina das áreas, resolvendo a tarefa que hoje ocupa alguém toda semana, não como demonstração de tecnologia.
A ferramenta que substitui a planilha, a corrente de e-mail e o processo que só existia na cabeça de alguém. Desenhada, construída e entregue no ar.
Fazer sistemas que não se falam conversarem, e deixar o dado consistente o suficiente para alguém tomar decisão em cima dele.
Trabalho como PJ, CLT ou projeto fechado, presencial em Uberlândia ou remoto.
03 Como faço
Toda vez que precisei resolver alguma coisa, uma tela, um processo, uma base de dados, a pergunta foi a mesma: de onde isso vem, o que acontece no meio, e onde precisa chegar.
De onde vem?
Onde a informação nasce, e o que faz o processo começar. É a parte que mais se pula, e quase todo erro que aparece lá na frente nasceu de um gatilho mal entendido.
O que acontece no meio?
O que é feito com essa informação: a regra, o tratamento, a decisão, a tela. É onde o trabalho aparece, e onde ele é invisível se as outras duas pontas estiverem certas.
Onde precisa chegar?
Quem recebe, em que formato, e para tomar qual decisão. Se ninguém do outro lado muda de comportamento com aquilo, o processo não terminou. Só rodou.
| Escala | Gatilho | Ação | Resultado |
|---|---|---|---|
| Fluxo de usuário | O que a pessoa quer fazer | O caminho que ela percorre | O que ela consegue no fim |
| Automação | O evento que dispara | A regra aplicada à informação | Onde ela chega, e quem usa |
| Processo entre setores | A atividade que termina numa área | O caminho até a área seguinte | O setor certo sabendo que chegou |
| Camada de dados | O sistema onde o dado nasce | Tratamento e validação | A decisão que ele sustenta |
Sempre no dado bruto, no sistema onde ele nasce, nunca no relatório que já passou por três transformações. Divergência entre duas plataformas quase sempre se resolve uma camada abaixo de onde ela aparece.
Nenhum número circula antes de passar por quem é dono do processo. Minha palavra nunca é a última, e é por isso que, quando o número sai, ninguém precisa conferir de novo.
Não em apresentação, não em protótipo que alguém vai ter que construir depois. Se ficou em slide, o problema continua exatamente onde estava.
04 Por que eu
Comprometido, criativo e atento aos detalhes é o que todo mundo escreve nesta parte do site. Prefiro ir pelo que dá para verificar.
Não existe repasse entre pesquisa, design e desenvolvimento. As três acontecem na mesma cabeça, e o que costuma se perder na tradução entre times simplesmente não precisa ser traduzido.
Comecei a carreira como desenvolvedor front-end, e cheguei a tocar uma agência onde eu mesmo programava as entregas para mais de duzentos clientes. Quando digo que entrego funcionando, é volta ao ponto de partida, não promessa apoiada em ferramenta que apareceu ano passado.
Fui responsável pelo design de três empresas de um grupo, com sete pessoas no time. Sei o que é depender do prazo de outra área, ter prioridade mudada no meio e deixar alguém esperando um handoff, e trabalho contando com isso, não reclamando disso.
Parte do meu trabalho foi destravar provisões e compensações dentro de sistemas de RH para que a empresa conseguisse fechar uma conta que não fechava. Design que nunca encosta no número da empresa tem alcance curto.
Não é preciso montar uma frente para cada camada antes de descobrir se a solução era a certa. Em escala, time continua sendo necessário, mas ele deixou de ser pré-requisito para começar.
05 Contato
Respondo em até um dia útil. Se for projeto, a primeira conversa serve para entender o problema e o que ele está custando hoje, e ela não custa nada.
Para vagas
Currículo completo, com a trajetória e as decisões por trás de cada fase. Disponível para PJ, CLT ou projeto fechado, presencial em Uberlândia ou remoto.
Para projetos
Me conte o que atrapalha hoje e quem é afetado. Do diagnóstico ao sistema no ar, com uma pessoa só do outro lado do processo inteiro.