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.
Product Designer UX/UI Designer
Doze anos somando camadas: front-end, UX, UI, design system, produto e gestão de time. Nenhuma substituiu a anterior. Hoje desenho a solução e acompanho até a mão de quem vai usar.
Trabalhei com
A trajetória, em 12 anos
01 Projetos
Três empresas, nenhum padrão comum. Um sistema construído com as áreas.
Ver caseNove públicos num prédio, e quase nenhum escolheu o software. Plataforma modular.
Ver caseDo autônomo à rede com franquia, no mesmo motor. Escopo tirado de quatro concorrentes.
Ver caseDezoito aplicações internas numa porta só, e cada pessoa vendo o que o trabalho pede.
Ver caseOs projetos de cliente estão sob acordo de confidencialidade, então neles nada real é exibido. Outros do mesmo período estão sendo escritos neste formato: se um deles for o que interessa para a sua vaga ou para o seu projeto, me peça e eu adianto a conversa.
02 Sobre mim
Comecei desenhando e programando a mesma entrega. Depois entraram pesquisa, interface, sistema, time e dado, e nenhuma dessas camadas substituiu a anterior: o que veio antes continuou valendo.
Hoje elas trabalham juntas: o mesmo projeto que eu pesquiso e desenho é o que eu construo e entrego. É isso que faz o caminho inteiro começar pela necessidade, e não pela solução.
Em doze anos, o começo foi sempre o mesmo: descobrir de quem é o problema antes de decidir qual é. O resto desta página é sobre como.
Desenho e entrego sistemas inteiros, do problema à produção.
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.
Cinco anos, quatro fases, cada uma ampliando o escopo da anterior.
Projetos para John Deere, Volvo e SEBRAE, e identidade visual para marcas da região de Campinas.
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.
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.
03 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.
04 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.
05 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, é ofício de doze anos, 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.
06 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.