# Alexander Cesar — Design Engineer — conteúdo completo > Todos os cases, depoimentos e marcos de https://alexcesar.com/pt/, em texto puro. > O site renderiza esse conteúdo no cliente, então este arquivo é a versão completa para > qualquer coisa que não execute JavaScript. Gerado da mesma fonte que o site renderiza. Site: https://alexcesar.com/pt Índice: https://alexcesar.com/llms.txt Contact: alexcesar@alexcesar.com # Cases ## Plataforma de Federação Esportiva Nacional - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Umbraco 17 · .NET 10 · HTMX · SCSS - Período: Mar — Mai 2026 - URL: https://alexcesar.com/pt/work/sports-federation-platform/ Uma federação esportiva nacional mantém uma plataforma pública grande: páginas editoriais, informações de clubes e ligas, e um Game Center onde os torcedores acompanham tabela, resultados, classificação, escalações e estatísticas de jogadores durante a temporada. Trabalho no redesign como frontend engineer — um design é aprovado no Figma, e precisa virar software real, acessível, rápido e de fácil manutenção. Resultado: Um redesign em andamento, entregue feature a feature: designs aprovados viraram componentes testados e acessíveis, feitos para aguentar dados de jogo ao vivo — com um documento de convenções de frontend que o time usa como base. ### Meu papel Leio o arquivo aprovado no Figma de perto — espaçamento, tipografia, tokens, estados, movimento — e construo como frontend engineer: markup, SCSS, comportamento em TypeScript, renderizado dentro de views server-side. Game Center, classificação ao vivo com alternância casa/fora, calendários de times e views de playoff, o buscador de clubes, estatísticas de jogadores e de times. Quando um layout quebraria com dados reais — nomes de clube longos, escudos faltando, jogos adiados — resolvo no espírito do design, como parte da construção. ### Como é construído Umbraco v17 sobre .NET 10; os editores compõem páginas a partir de módulos Block Grid, cada um uma view Razor fortemente tipada. O frontend é TypeScript e SCSS vanilla — sem framework SPA — com nomenclatura BEMIT sobre design tokens como CSS custom properties. A interatividade é progressive enhancement com HTMX: filtros, busca e paginação trocam partials renderizados no lugar, então as páginas continuam funcionando e seguem compartilháveis. Os dados de jogo ao vivo chegam por SignalR. ### Acessibilidade como engenharia Estados de foco, ordem de tabulação, ARIA e contraste real não estão no arquivo do Figma — são decisões de engenharia que tomo enquanto construo, verificadas contra a WCAG. ### Detalhes, exercitados Módulos como o slider de patrocinadores vão pro ar com um harness: o componente montado isolado e exercitado nos seus estados do mundo real — quantidade de patrocinadores, larguras de container, breakpoints — para que o comportamento seja verificado antes de chegar a qualquer página. ### Seguro para publicar Toda mudança passa por plano → execução → revisão. Um hook de pre-push faz o build da solução e roda os testes unitários; uma suíte ponta a ponta em Playwright exercita os fluxos do Game Center contra o deploy de preview do pull request antes de qualquer merge. ## Engenharia de um Pipeline de Entrega com IA - Cliente: P&D por conta própria · dentro de um contrato ativo com agência suíça - Papel: Design Engineer - Stack: Claude Code · 7 agentes · verificação adversarial · CLAUDE.md - Período: 2025 — 2026 - URL: https://alexcesar.com/pt/work/ai-delivery-pipeline/ Um ano publicando código em produção com assistentes de IA dentro de um contrato ativo com agência suíça — sem mandato, sem linha de orçamento, sem manual. Cada upgrade de modelo levantava o teto do que era possível, mas os modos de falha seguiam constantes: desvio de escopo, sessões que degradam, agentes isolados, trabalho plausível que não passava na revisão do dono do código. No meio do caminho, a tese se inverteu — o gargalo era orquestração, não inteligência. Parei de otimizar a escolha de modelo e construí a camada em volta dele. A indústria já tem um nome para essa camada: o harness. Resultado: Um harness de entrega calibrado, portátil entre stacks e fornecedores de modelo: um conjunto de instruções persistente, session grounding sobre contexto em checkpoint, subagentes que compõem via síntese, e agentes de revisão treinados por um flywheel de feedback contra as correções reais de pull request do dono do código. Publicado duas vezes: como o plugin de convenções do cliente e como compounder, open source. ### Problema 1 — Desvio de escopo O agente mexe em arquivos fora do ticket, “melhora” código que ninguém pediu e esquece convenções no meio da sessão. A correção foi sem glamour: um conjunto de instruções persistente — um CLAUDE.md codificando convenções, guardrails e disciplina de escopo, refinado toda vez que uma falha revelava uma regra faltando. Estabilidade na região do prompt: sem graça, e responsável pela maior queda isolada em violações de convenção que medi no ano todo. ### Problema 2 — Sessões longas degradam As sessões ficam lentas e a qualidade cai conforme o contexto incha — histórico completo de interação mais arquivos grandes injetados, até o sinal afogar. A intervenção: session grounding. Um hook de SessionStart injeta um conjunto pequeno de arquivos de contexto curados e em checkpoint no lugar do histórico acumulado. A lição que custou caro é um trade-off: o contexto injetado tem que ser pequeno e estável, ou o próprio mecanismo de grounding vira o inchaço. ### Problema 3 — Enxames isolados Agentes em paralelo falham de um jeito específico: cada um completa sua tarefa corretamente isolado, e os resultados não se compõem, porque nenhum agente sabe o que os outros aprenderam. O padrão que resolveu: subagentes rodam em contextos totalmente isolados e devolvem apenas resumos destilados a um agente orquestrador. O contexto fica limitado por agente; o conhecimento ainda circula lateralmente pela etapa de síntese. ### Problema 4 — O flywheel O núcleo do trabalho: cinco agentes de revisão específicos de domínio codificando as convenções da agência — semântica de markup, arquitetura de CSS, padrões de backend, acessibilidade, disciplina de escopo. O loop que desenhei para treiná-los: implementar, os agentes revisam, o code review do dono do código — prática padrão na agência para todo pull request — pega o que sobrou, e eu registro cada correção como feedback estruturado — ground truth — e atualizo os agentes. Repete. A cada ciclo a distância encolhia — medida, não sentida — até o revisor principal chegar a 11/11 de concordância com as correções reais de pull request do lead. Não é aprovação por depoimento; é calibração empírica. ### O que saiu disso O harness deixou de ser um jeito de trabalhar e virou dois plugins. O primeiro ficou com o cliente: um plugin de convenções para os projetos Umbraco da agência, construído em três dias em abril de 2026 — 5 agentes de revisão, 8 skills de carga automática, 2 comandos. Ele roda todos os revisores especializados em paralelo e acrescenta as checagens que nenhum revisor sozinho consegue fazer: um erro de digitação entre um hook js-* no Razor e o querySelector em TypeScript que o procura, um componente usado no Razor mas nunca registrado na init factory, um token usado no SCSS que não existe no variables.scss. Quando o dono do código corrige um pull request, a correção é salva como feedback e codificada como regra no agente correspondente.,O segundo é o compounder, seu sucessor open source — reconstruído do zero e generalizado para além de uma stack, feito para rodar em Fable, Opus, Sonnet e Haiku: 15 skills de cerca de cem linhas cada — o pipeline, mais contratos de objetivo com critérios de aceitação verificáveis, handoffs de sessão, guardrails em camadas e um conselho de avatares para as decisões em volta do trabalho — 7 agentes (pesquisador, quatro revisores, verificador adversarial, executor fork), um hook que captura recados no meio do trabalho para que uma mensagem nunca desvie a tarefa em curso, e /slfg, o pipeline inteiro como enxame. Seus portões de qualidade são rodados por um agente que tenta refutar a evidência em vez de confiar na autodeclaração do próprio pipeline. - compounder.alexcesar.com: https://compounder.alexcesar.com/ ### A indústria alcançou Em fevereiro de 2026, a OpenAI publicou “Harness engineering”, cinco meses entregando um produto sem código escrito à mão. O trabalho do engenheiro, nas palavras deles: “desenhar ambientes, especificar intenção e construir loops de feedback que permitam aos agentes fazer trabalho confiável”. Em julho, pesquisadores publicaram “The Harness Effect”: mesmos cenários corporativos, mesmos prompts, mesmos seis modelos — só a camada de orquestração mudou. Cerca de 38% menos tokens, 41% menos custo, 44% menos tempo de execução, qualidade estatisticamente igual. O vocabulário deles descreveu retroativamente este ano: token maxing era o meu problema de degradação antes do session grounding; harness leverage batia com o que eu via a cada upgrade de modelo. A camada que eu vinha construindo tinha nome. ### Por que um design engineer Harness engineering é design de interface. Decidir que contexto um agente vê é arquitetura de informação. Guardrails e disciplina de escopo são design de restrições. O flywheel é um loop de usabilidade — observar a falha, ajustar o sistema, medir de novo. Quase trinta anos de prática de design acabaram sendo estruturais para um problema que parece, de fora, engenharia pura. - Leia o artigo no LinkedIn: https://www.linkedin.com/pulse/bottleneck-orchestration-intelligence-alexander-cesar-xamsf/ ## App de Pedidos por Voz - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: React Native · Expo SDK 53 - Período: Set 2025 — Fev 2026 - URL: https://alexcesar.com/pt/work/voice-ordering-app/ Um app de pedidos no atacado com a voz em primeiro lugar: o comprador fala o pedido e ele vira itens do catálogo já correspondidos. Seis meses de trabalho de UI — navegação em drawer, checkout em várias etapas com estados animados, um gravador de voz a 60fps com fila de upload e lógica de retry, internacionalização DE/EN. Resultado: App completo e funcionando em iOS, Android e web a partir de um único codebase, mesma linguagem de design nos três. Retorno do cliente: "Alexander construiu de ponta a ponta a experiência mobile de um app B2B de pedidos por voz com IA — captura de voz, permissões, a lista de pedidos e as views de detalhe — e transformou uma especificação complexa em um app limpo e funcionando." ### Por que voz Um comprador do atacado percorre o depósito e pede dezenas de itens — cada um com uma unidade, uma quantidade e uma variante. Digitar isso no celular, um campo por vez, é a interface mais lenta possível para a tarefa. Falar é a mais rápida: a premissa inteira do app é que o comprador fala do jeito que já fala com um representante de vendas, e o software faz o trabalho de transcrição e correspondência. ### Da fala aos itens do pedido O pipeline tem quatro etapas, e o problema de design é que o comprador precisa confiar nas quatro. Meu trabalho no frontend foi manter cada estágio visível e corrigível: o que foi ouvido, o que foi correspondido, que quantidade foi inferida. Nada é enviado automaticamente — a etapa final é sempre um pedido editável que o comprador confirma. ### O gravador tinha que desaparecer Um gravador de voz que engasga destrói a confiança no produto inteiro, então a UI de captura roda a forma de onda e o cronômetro a 60fps, movidos por animação nativa em vez de estado do React. Em volta fica o trabalho sem glamour: fluxos de permissão de microfone nas duas plataformas, uma fila de upload que sobrevive ao app ir para segundo plano, e lógica de retry para o sinal fraco que se pega dentro de um depósito. Um upload que falha nunca perde uma gravação. ### Checkout em etapas O fluxo de pedido é de várias etapas por design — revisar os itens correspondidos, ajustar quantidades, escolher a entrega, confirmar — com transições animadas que mantêm o comprador orientado sobre onde está e o que ainda vem. A navegação é um drawer, então o catálogo, o pedido atual e os pedidos anteriores ficam a um gesto de distância. Toda tela aguenta um nome de produto longo e uma imagem faltando, porque o catálogo real tem bastante dos dois. ### Um codebase, três plataformas React Native com Expo, entregando iOS, Android e web a partir de um único codebase com a mesma linguagem de design nos três. Internacionalização DE/EN completa, já que os compradores e a organização de vendas não falam a mesma língua. Seis meses do repositório vazio a um app funcionando nas mãos do cliente. ## Plataforma de Produção de Liga Esportiva - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Angular · ASP.NET · TypeScript - Período: Jan — Mar 2026 - URL: https://alexcesar.com/pt/work/sports-league-production/ Uma ferramenta de workflow de produção de TV para uma liga esportiva nacional: visão de dashboard e views de detalhe de partida com seis abas alinhadas à especificação, construídas contra um contrato de dados JSON acordado para que frontend e backend pudessem andar em paralelo. Mais refinamento da UI administrativa em ASP.NET legado. Resultado: Frontend entregue contra o contrato — os endpoints reais entraram sem retrabalhar as views. ### Uma equipe de produção, não um público Esta plataforma não é voltada ao torcedor. Seus usuários são as pessoas que colocam as partidas na televisão: a equipe que planeja câmeras, sinais, posições de comentário e janelas de entrega para a temporada de uma liga nacional. Esse público muda toda decisão de design — densidade em vez de decoração, tudo escaneável de relance, e nenhuma interação que custe um clique a mais em dia de jogo. ### Dois níveis, seis abas A arquitetura de informação se acomodou em dois níveis. Um dashboard dá a visão da temporada inteira: o que está agendado, o que está em risco, o que precisa de decisão hoje. Uma view de detalhe da partida reúne seis abas, cada uma alinhada a uma seção da especificação de produção do cliente, então a equipe navega pela ferramenta com o mesmo vocabulário que já usa nos próprios documentos. As abas compartilham um mesmo esqueleto de layout, o que mantém a densidade consistente e o código pequeno. ### Entregando em paralelo com um contrato O backend ainda não existia, e esperar por ele teria custado o cronograma inteiro. Então a primeira entrega não foi uma tela — foi um contrato de dados JSON acordado, negociado com o time de backend e congelado antes de qualquer lado começar. Construí todas as views contra mocks que seguiam exatamente esse formato; quando os endpoints reais chegaram, entraram sem retrabalhar uma única view. Três meses do kickoff a um frontend que a equipe podia usar. ### A metade legada Ao lado do novo frontend em Angular havia uma interface administrativa em ASP.NET já existente — funcional, e visualmente uma década atrás do produto ao qual agora pertencia. Refinei no lugar em vez de propor uma reescrita que ninguém tinha orçamento para pagar: apertei espaçamento e hierarquia, alinhei os controles à nova linguagem de design e corrigi as interações que deixavam o trabalho administrativo de rotina mais lento do que precisava ser. Trabalho sem glamour, e a melhoria mais rápida disponível para o dia real da equipe. ## Portal Corporativo de Clientes - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Angular 17 · Umbraco · SCSS - Período: Jul — Set 2025 - URL: https://alexcesar.com/pt/work/enterprise-customer-portal/ Um portal de clientes montado a partir de uma biblioteca de componentes reutilizáveis que construí: ~15 componentes — tabelas ordenáveis, sidenav deslizante, grupos de botões em abas, campo de telefone, filtros dropdown, modais — compostos em mais de 10 seções, views de admin e de cliente. Um fluxo mock-first desacoplou o frontend do cronograma do backend. Resultado: Biblioteca de 15 componentes sustentando mais de 10 seções do portal a partir de um único design system. Retorno do cliente: "Para um portal de clientes suíço, Alexander entregou a plataforma de administração: uma sidebar recolhível, uma tabela de dados reutilizável e as views de cliente, documentos e perfil — todas responsivas em mobile e fiéis ao design system." ### Um portal é um problema de composição O briefing parecia dez e tantas telas: listas de clientes, arquivos de documentos, gestão de perfil, views de admin. Construído tela a tela, isso vira dez e tantos conjuntos de código de tabela feitos sob medida e dez e tantas interpretações do mesmo design system. Então inverti — a entrega era uma biblioteca de componentes primeiro, e cada seção virou uma montagem de peças que já existiam. ### Quinze componentes, mais de dez seções Uns quinze componentes carregaram o portal inteiro: tabelas de dados ordenáveis, uma sidenav deslizante, grupos de botões em abas, filtros dropdown, modais, paginação, um campo de telefone com tratamento de país. Cada um foi construído uma vez, contra o design system, responsivo por padrão — então um ajuste na tabela melhorava toda seção que a usava, e consistência deixou de ser assunto de code review. ### Mock-first, backend desbloqueado O backend tinha cronograma próprio, então o frontend foi construído contra dados mock no formato das respostas acordadas. Manteve os dois times andando em paralelo e obrigou os componentes a serem honestos sobre os estados — vazio, carregando, erro, uma linha, duzentas linhas — porque o mock produzia todos sob demanda, muito antes de um endpoint real conseguir. ### Admin e cliente, uma linguagem Dois públicos dividem o codebase: o pessoal que administra as contas e os clientes que usam as próprias. Mesma biblioteca, mesma gramática de interação, permissões e densidade diferentes — o que fez o lado admin herdar de graça o acabamento do lado voltado ao cliente, em vez de acabar como o back office abandonado de sempre. ## Heatmap de Segurança no Trabalho - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Angular 17 · TypeScript · SCSS - Período: Jul 2025 - URL: https://alexcesar.com/pt/work/workplace-safety-heatmap/ Um heatmap de segurança no trabalho para um cliente industrial: incidentes mapeados por zona para que os responsáveis pela segurança vejam onde os acidentes se concentram. Traduzi o design system do Figma em componentes Angular funcionando — botões, modais, formulários reativos com seletor de posição no mapa — fiéis aos tokens e às especificações de interação. Resultado: Design system implementado um a um: todo estado especificado ligado, exportação em CSV incluída. Retorno do cliente: "Alexander implementou uma view interativa de mapa de calor e clusters — densa em dados, responsiva e fiel ao design visual pretendido." ### Onde os acidentes se concentram Um cliente industrial registra incidentes de trabalho, e os registros só importam se um responsável pela segurança conseguir ver um padrão neles. A interface responde a uma pergunta de relance — que zonas estão machucando gente — mapeando incidentes a locais físicos como calor e clusters, para que a intensidade seja lida antes de qualquer número. ### Densidade que continua legível Uma view de mapa densa em dados é fácil de deixar barulhenta e difícil de deixar legível. A escala de calor carrega o sinal com um único matiz, os clusters ganham um contorno explícito em vez de mais uma cor, e a UI em volta fica quieta para que nada compita com o mapa. Aguenta responsivamente — a mesma view funciona num laptop no escritório e num tablet no chão de fábrica. ### Um design system, implementado um a um O design visual chegou como um design system no Figma, e meu trabalho era fidelidade: botões com todo estado especificado, modais, formulários reativos incluindo um seletor de posição no mapa para marcar um incidente com precisão. Tokens e especificações de interação implementados como vieram, não reinterpretados — quando um design system é entregue com esse cuidado, a contribuição útil é disciplina, não opinião. ### A parte que os responsáveis pela segurança de fato pediram Exportação em CSV. O mapa responde onde, mas o reporte vive em planilhas e papelada de regulador, então tirar os dados de volta era requisito de primeira classe, não algo pendurado num menu depois. ## Interface de Assistente de IA - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Angular 20 · Signals · CDK Overlay - Período: Set 2025 - URL: https://alexcesar.com/pt/work/ai-assistant-interface/ Uma interface de chat com streaming para a equipe de um distribuidor atacadista: as respostas aparecem conforme chegam, com reações e anexos. Estado gerenciado com Angular Signals — a UI é uma função da conversa — e overlays centralizados pelo CDK Overlay, responsivo até o mobile. Resultado: Chat com streaming publicado com estado baseado em signals e serviços totalmente desacoplados. Retorno do cliente: "Alexander construiu uma interface de chat completa — grupos de conversa, menus de contexto, lightbox, interações da sidebar, criação e exclusão de conversas — com atenção cuidadosa à semântica de interação e ao comportamento mobile-first." ### Streaming é um problema de UI Um assistente que responde à equipe de um distribuidor atacadista precisa parecer que está pensando em voz alta — as respostas aparecem conforme chegam em vez de surgirem prontas depois de uma espera. A consequência de engenharia é que a view re-renderiza sem parar enquanto o usuário ainda está lendo, então toda decisão de layout tem que sobreviver ao texto crescendo por baixo: sem pular a posição do scroll, sem reposicionar os botões de ação, sem piscar na mensagem que está sendo escrita. ### A UI é uma função da conversa O estado vive em Angular Signals: mensagens, status do streaming, anexos, reações. A view deriva deles em vez de ser sincronizada com eles, o que elimina a classe inteira de bug em que a conversa parece desatualizada até você clicar em algo. Os serviços ficam totalmente desacoplados dos componentes, então o transporte pode mudar sem a interface saber. ### Overlays com um só dono Interfaces de chat acumulam coisas flutuantes — menus de contexto, um lightbox para anexos, a sidebar com os grupos de conversa, os fluxos de criar e excluir. Tratadas caso a caso, elas brigam entre si por empilhamento, foco e fechamento. Centralizá-las pelo CDK Overlay deu um único conjunto de regras para posicionar e fechar, e é por isso que a semântica de interação continua previsível não importa como o usuário chegou ali. ### Mobile-first, não mobile-também A equipe usa isso entre outras tarefas, muitas vezes no celular, então o layout estreito foi o ponto de partida em vez de uma compressão tardia do de desktop — alvos de toque, ações alcançáveis, e uma sidebar que vira gesto em vez de coluna permanente. ## Plataforma de CMS para Indústria - Cliente: via OPTEN AG - Papel: Engenharia frontend - Stack: Umbraco 17 · Razor · BlockListBuilder - Período: Fev — Mar 2026 - URL: https://alexcesar.com/pt/work/manufacturer-cms-platform/ Módulos de CMS para um fabricante de materiais de construção: layouts em grid e carrossel compartilhando um mesmo partial base, fallbacks de conteúdo para que módulos preenchidos pela metade ainda renderizem bem, variantes promocionais com embeds de vídeo adiados — e previews responsivos de página para que os editores vejam todo breakpoint antes de publicar. Resultado: Editores não conseguem quebrar um layout deixando um campo vazio — os fallbacks vivem no nível do componente. ### O usuário real é um editor Um módulo de CMS não está pronto quando renderiza o conteúdo desenhado. Está pronto quando um editor de marketing, com pressa, preenche metade dos campos e publica assim mesmo — e a página ainda parece intencional. Para um fabricante de materiais de construção com um catálogo grande e um time de conteúdo pequeno, esse cenário é o caso normal, não o caso extremo. ### Um partial base, três variantes Os layouts em grid, carrossel e promocional compartilham um único partial base, então espaçamento, tipografia e comportamento responsivo são definidos uma vez só. Os fallbacks de conteúdo vivem nessa base: uma imagem faltando colapsa para um layout que ainda equilibra, um texto ausente encurta o módulo em vez de deixar um buraco. A variante promocional adia o embed de vídeo até a interação, então um módulo de marketing nunca custa à página o tempo de carregamento. ### Ver antes de publicar Os editores ganharam previews responsivos de página — todo breakpoint visível antes de qualquer coisa ir pro ar. Elimina o ciclo de publicar-e-conferir-no-celular, e com ele a maior parte dos chamados de layout que esse ciclo gera. ### Construído com BlockListBuilder Umbraco 17 com Razor, composto pelo BlockListBuilder para que os módulos sigam montáveis pelo editor em vez de montados pelo desenvolvedor. A medida de sucesso é negativa: nenhum chamado de suporte que comece com “a página quebrou quando deixei o campo vazio”. ## Holter Log - Cliente: Produto próprio - Papel: Design + full-stack - Stack: Vanilla JS · Supabase · Vercel - Período: 2025 - URL: https://alexcesar.com/pt/work/holter-log/ Um diário clínico para o exame de Holter cardíaco de 24 horas. O paciente toca quando um sintoma aparece; fica registrado com hora direto no painel do médico. Desenhado, construído e publicado sozinho — um PWA full-stack. Resultado: No ar na Vercel. ### O exame tem um problema de interface Um exame de Holter registra o coração por 24 horas — mas os sintomas ficam na memória do paciente. O protocolo clássico é um diário de papel: anote a hora, anote o que sentiu, torça para o relógio estar certo. Correlacionar isso com a gravação depois é adivinhação. ### Um botão, desenhado para um momento ruim A pessoa usando este app pode estar no meio de uma palpitação. Então a interface é uma ação só: toque quando um sintoma aparecer. A hora é registrada automaticamente — nada para escrever, nada para lembrar — e o médico recebe a linha do tempo completa do exame, do começo ao fim. Dados de saúde tratados conforme a LGPD, acesso restrito ao médico. ### A outra metade é do médico Um registro de sintomas só é útil se chegar a alguém. O médico abre um painel: quem está gravando agora, quantos eventos cada paciente registrou, quando veio o último — e, um clique adiante, a linha do tempo completa do exame. ### Um campo, um código Colocar um Holter leva minutos e o paciente já está na sala, então cadastrar um pede um único campo obrigatório. O código de seis dígitos é gerado na hora e sai por WhatsApp ou Telegram — o paciente já está gravando antes de sair da clínica. ### Stack pequena, produto inteiro JavaScript vanilla, Supabase, Vercel — um PWA full-stack sem overhead de framework, instalável no celular do paciente. Desenhado, construído e publicado sozinho: as mesmas mãos fizeram a UX, a interface e o backend. ## EcoDrive - Cliente: Produto próprio - Papel: Design + full-stack - Stack: React Native · Expo · SQLite · Supabase Edge Functions · Claude - Período: 2026 — em andamento - URL: https://alexcesar.com/pt/work/ecodrive/ Um registro de abastecimento feito para o jeito como o brasileiro abastece de verdade: gasolina, etanol, GNV vendido por metro cúbico e, muitas vezes, dois deles na mesma parada. Você fotografa o odômetro e o display da bomba; o Claude lê os números dos dois, e o app responde com consumo real e custo por quilômetro. Desenhado e construído sozinho — interface, banco de dados e backend. Resultado: Um build Android funcionando: duas fotos na entrada, consumo e custo por quilômetro na saída, sem digitar um número. ### Ninguém registra abastecimento Apps de controle de combustível morrem na bomba. Litros, preço por litro, total — três números digitados na pista com uma fila atrás de você e um frentista esperando o cartão. Os números já estão acesos no display; o atrito nunca foi a aritmética, foi o formulário. ### A câmera é o formulário Fotografe o odômetro, depois a bomba. O Claude lê os quilômetros da primeira e quantidade, preço unitário e total da segunda, e um abastecimento vira um registro estruturado em dois gestos. Todo campo continua editável depois, porque um display fotografado contra o sol baixo às vezes merece correção — a leitura preenche o formulário, ela não manda nele. ### Uma leitura que você pode contestar O modelo devolve sua confiança e seu raciocínio ao lado dos números, e a interface mostra os dois: 15.02 m³ a R$4.749 dá R$71.32 contra os R$71.33 exibidos, menos de um centésimo de real de diferença, então dá para confiar na leitura. Quando uma foto é de fato ilegível, o app diz isso e devolve o formulário em vez de inventar um valor. Em um abastecimento eu escolhi gasolina na mão e a leitura me corrigiu — a foto era de uma bomba de GNV. ### Dois combustíveis, um tanque Um carro flex brasileiro com kit GNV recebe dois combustíveis na mesma parada, e nenhuma média honesta abrange os dois: litros e metros cúbicos não se somam. Então um abastecimento carrega até dois combustíveis, cada um na sua unidade — litros, metros cúbicos, quilowatt-hora — e quando há dois, o número em destaque passa a ser o custo por quilômetro, o único que sobrevive à troca de unidade. A conversão de energia por trás disso fica interna; megajoules nunca chegam à tela. ### O primeiro abastecimento não tem média Consumo precisa de dois abastecimentos, o que quer dizer que a versão honesta deste app é inútil no dia em que é instalado. Então a primeira execução faz uma única pergunta — você lembra o odômetro do seu último abastecimento? — e devolve uma média real na hora. Se a resposta for não, um slider recebe os quilômetros semanais e estima o gasto mensal. De um jeito ou de outro, algo verdadeiro está na tela em vinte segundos. ### A foto não pousa em lugar nenhum A imagem vai para uma Supabase Edge Function em São Paulo, passa pela memória até o modelo e nunca é armazenada. A chave da API vive na function, nunca no bundle do app. O consentimento é explícito antes da primeira foto, a localização é opt-in, e as Configurações trazem um reset de fábrica atrás de um toque de dois segundos. Uma leitura custa cerca de US$0.004. ### Uma stack, as mesmas mãos React Native com Expo. Todo o histórico vive no aparelho em SQLite via Drizzle, então o app continua funcionando num posto de estrada sem sinal; o Supabase só entra no caminho quando uma foto está sendo lida. Cadastrar um carro puxa marca, modelo, ano e valor de mercado da tabela FIPE brasileira. Desenhado, construído e publicado sozinho: as mesmas mãos fizeram a UX, a interface, o schema e o backend. ## PromptNinja - Cliente: Produto próprio - Papel: Design + full-stack - Stack: Hono · Cloudflare Workers · D1 · Claude + Gemini · Stripe - Período: 2026 - URL: https://alexcesar.com/pt/work/promptninja/ Um SaaS que transforma uma ideia crua em um prompt estruturado e reutilizável para os principais assistentes de IA. Uma entrada, quatro lentes. Desenhado, construído, cobrado e publicado sozinho no Cloudflare Workers — a infraestrutura roda no plano gratuito da Cloudflare, então o modelo é toda a linha de custo. Resultado: No ar em promptninja.com.br. Infraestrutura no plano gratuito; toda chamada de IA registrada com seu custo. ### As pessoas sabem o que querem. Não conseguem dizer isso a uma máquina A lacuna não são as ideias — é a estrutura. Alguém tem um negócio, um assunto para aprender, um roteiro para escrever, digita duas linhas no ChatGPT e recebe duas linhas de volta. O PromptNinja pega as duas linhas e devolve o prompt que a pessoa deveria ter escrito: contexto, restrições, formato de saída, prompts de continuação — o raciocínio explicitado, pronto para colar no assistente que você já usa. ### Uma entrada, quatro formas de pensar O único controle é um modo: General, Business, Study, Code. Ele não muda para onde vai a saída — muda como o modelo pensa a entrada. A mesma ideia de café vira um plano em fases com KPIs em Business, um currículo progressivo em Study, uma spec com edge cases em Code. Testado colando a saída em quatro assistentes diferentes; a decomposição se mantém. ### Temperatura é decisão de produto Os system prompts importam menos que o espaço que o modelo recebe. Com temperatura 0.7 e 1,500 tokens todo modo desabava na mesma lista de bullets sem relevo; com 1.0 e 4,000 ele decompõe. Esse número é protegido no código como um schema. A interface sai da frente: sem modais, sem spinners abaixo de dois segundos, os resultados aparecem quando ficam prontos. ### O modelo é a linha de custo Toda geração é registrada com tokens, custo e latência. Rodei a mesma entrada de café em cinco modelos lado a lado e li as saídas, não os benchmarks: o plano gratuito roda em Gemini Flash-Lite por uma fração de centavo, o Pro em Claude Haiku porque escreve de duas a quatro vezes mais fundo no modo Business. Os limites diários são dimensionados pelo custo medido, não chutados. ### Reescrito três vezes, de propósito Um protótipo em PHP validou os modos. Uma versão em Next.js validou o Stripe e o fluxo, e então esbarrou no preço da Vercel. Uma reescrita em Python no plano gratuito da Oracle rodou até a instância sumir. O produto vive no Cloudflare Workers com Hono e D1: uma dependência em produção, um edge global, sem servidores, deploy em um comando. Login por magic link, histórico criptografado, assinaturas no Stripe, rate limiting — tudo das mesmas mãos, projetado para rodar sem elas. ## LOPE · Localizador de Pessoas Unificado - Cliente: Petrobras - Papel: Design UX/UI + estratégia - Stack: UX research · WCAG · WAI-ARIA - Período: 2012 — 2014 - URL: https://alexcesar.com/pt/work/lope/ O desafio do LOPE: ajudar a localizar qualquer empregado da força de trabalho da Petrobras o mais rápido possível, digitando até 3 termos na busca. Resultado: Cerca de USD 5 milhões de economia anual entre licenças de hardware e software, equipes de manutenção espalhadas pelo mundo e deslocamentos perdidos por atrasos na liberação de pessoas nos prédios. Tempo de entrada nas instalações da Petrobras padronizado em cerca de 1min30s. Todos os dados da força de trabalho normalizados no BDFTP — a fonte única da verdade. ### Localizador de Pessoas da Petrobras Disponível em 3 idiomas e a primeira aplicação totalmente acessível da Petrobras, o Localizador de Pessoas atende aos requisitos de compatibilidade da W3C, WAI/ARIA e WCAG. Foi inclusive testado por usuários com deficiência visual total. Em operação por aproximadamente 2 anos, de 2012 a 2014, o LOPE teve um total de 16 profissionais multidisciplinares trabalhando em várias equipes. ### Uma nota sobre o NDA Este projeto ficou sob NDA até outubro de 2022 — 10 anos — então não foi possível reunir todo o material necessário para demonstrar o processo de UX inteiro. Fotos, vídeos, prints das entrevistas com usuários, capturas de tela, registros das dinâmicas de grupo: nada disso foi permitido pela Petrobras — nem como registro pessoal. Todo o material reunido e mostrado aqui foi guardado através de backups sucessivos e, na minha opinião, este case vale bem a pena ser demonstrado. ### Quais eram os três principais objetivos do LOPE? ### O que eu fiz no projeto (em resumo)? Fui o designer responsável pela UX, UI, Prototipação e UX Strategy da aplicação. ### O Processo! O primeiro passo foi definir a estratégia para criar essa nova ferramenta de localização de pessoas. De quanto tempo os usuários precisariam para se sentir completamente confortáveis, fora da sua zona de conforto, usando uma nova ferramenta unificada adotada pela empresa inteira? Algo dessa proporção, nessa escala, nunca visto antes na história da empresa, precisaria de um fallback caso as coisas não dessem certo na primeira implementação. Na esteira dessa pergunta, apareceram outras igualmente desafiadoras: ### Benchmarking A estratégia de negócio girava em torno dessa afirmação. Por causa dela, várias equipes com especialistas em todo tipo de tecnologia foram consultadas sobre as possíveis stacks de tecnologia dessa aplicação. Entendidos os desafios de tecnologia, começou a busca pela inovação de valor desse novo produto: o que entregássemos seria simples e fácil de usar? Qual era o produto digital mais simples do mundo, usado pelo maior número de pessoas na maior parte do dia? Esse produto era compatível com as soluções que a Petrobras já tinha em operação? E assim comecei a etapa de mapear e fazer benchmarking de todas as aplicações de localização de pessoas que existiam dentro da Petrobras, comparando-as com os principais buscadores do mercado naquele momento — Google, Bing, Yahoo, DuckDuckGo — para entender as forças, fraquezas e oportunidades de implementação, e as principais ameaças de cada modelo. ### Os grupos identificados como usuários de uma ou mais ferramentas de localização de pessoas Em seguida, levantamos os perfis dos empregados que acessavam ferramentas de localização de pessoas pelo mundo, para escolher representantes desses grupos e convidá-los a participar de um processo de pesquisa e testes ao longo da construção da ferramenta. Com isso, foi possível traçar os perfis de usuário e suas jornadas pelos localizadores existentes — para entender suas necessidades, suas preferências de uso e suas dores no contato diário com as ferramentas. ### Protótipos Com os grupos definidos, começou o processo de criação de protótipos de baixa fidelidade, para validar hipóteses levantadas durante o processo de mapeamento e benchmarking — para termos uma versão 0 construída a partir de um problema conhecido, e coletar feedback sobre o que poderia ser feito para melhorá-la, até termos uma 1.0 estável para o lançamento, testada e validada pelos grupos. Com os protótipos sendo refinados, e a experiência do usuário melhorando pelo caminho através de elementos gráficos, tipografia e uso de cor (o pacote de UI), foi possível chegar à primeira versão estável do projeto. ### Lições aprendidas com o LOPE 1.0 Logo depois que a primeira ferramenta foi liberada ao público geral, o feedback coletado diretamente da força de trabalho colocou a versão 2 em movimento, com mudanças drásticas que tinham sido detectadas durante a versão 1. Por causa desse tipo de implementação — em larga escala, para toda a Petrobras — toda ferramenta de localização de pessoas seria desativada em 90 dias. Nesse período, novos estudos e novas entrevistas foram feitos, novos dados foram adquiridos, e ficou decidido que o LOPE 1.0 serviria como versão de fallback, já que os usuários tinham entendido e se acostumado com a ideia de ter uma única opção de localização de pessoas dali em diante. Além disso, uma solução mais eficaz tinha sido detectada durante o processo da versão 1.0 — mas não foi adotada, por medo de ser inovadora demais para a força de trabalho. Adotou-se a solução mais conservadora, com múltiplos campos para cada tipo de busca: não a mais eficaz, mas a menos problemática para os usuários durante a adoção e o uso do LOPE. A solução mais eficaz usava um único campo de busca e a possibilidade de rodar várias buscas combinando termos para trazer os resultados. E assim nasceu o LOPE 2.0. ### O novo LOPE 2.0 Com um pacote de atualização de performance dos bancos de dados e da tecnologia de front-end, a chegada da nova identidade visual corporativa da Petrobras e melhorias no framework de design corporativo da empresa, o momento não poderia ser melhor para atualizar o LOPE para a versão 2.0. A nova versão do LOPE, segundo o feedback dos usuários da força de trabalho da Petrobras, era mais bonita, mais simples, mais fácil, mais rápida e mais precisa que a anterior. Concebida inicialmente com a capacidade de mostrar imagens aleatórias da Petrobras a cada acesso à ferramenta — imagens de pessoas, embarcações e estruturas que eram referências da empresa — essa versão ficou no ar por pouco tempo. Foi substituída por um tema neutro. ### Tela inicial com imagem vs. tela inicial com grafismo neutro A ideia inicial era usar imagens relevantes através de geolocalização, e com isso aumentar a relevância e o senso de pertencimento dos empregados. Desafio técnico aceito e devidamente resolvido, através da Geolocation API (HTML5) somada aos cookies do portal da intranet da Petrobras. No entanto, mesmo com o desafio técnico vencido, o RH da Petrobras não conseguiu achar uma saída para o dilema do fator humano: como determinar que cada departamento tem a sua própria imagem relevante? E mais: se flexibilizarmos a regra e deixarmos cada empregado fazer upload da sua imagem favorita, que tipo de imagem acabaria sendo exibida? Essa imagem poderia ir contra as normas e princípios da Petrobras. ### Busca com até 3 termos Com a nova tecnologia totalmente compatível com o JAWS, o software usado pelos empregados com deficiência visual total, o sistema de busca conseguia localizar qualquer empregado no mundo usando até 3 termos. Como? Pense assim: se eu te encontro na rua e estamos tendo uma conversa amigável, o princípio básico é que você sabe o meu nome e o lugar onde estamos conversando. Para me achar, seria muito mais simples do que você imagina: bastaria digitar o meu nome, Alexander, seguido de Rio de Janeiro. A lista de fotos traria todas as pessoas com Alexander no nome que trabalham no Rio de Janeiro. Pelo registro visual, você localizaria a pessoa. E não parava aí: uma combinação de até 20 termos tornava uma pessoa localizável instantaneamente — CPF, CNPJ, departamento, cargo, algum fragmento do nome — além dos identificadores diretos que traziam o resultado de imediato. Tudo isso disponível em um único campo! Esse tipo de decisão fez com que não usássemos autocomplete no campo de busca, porque algumas combinações inviabilizam esse funcionamento — CPF vs. números de telefone no Brasil e no exterior, por exemplo. O ganho foi perceptível: o perfil mais crítico, o Recepcionista de jirau, passou a liberar a entrada de um visitante ou empregado no prédio depois de localizar a pessoa em até 1min30s — praticamente acabando com as filas nos períodos críticos, como a primeira hora útil do turno da manhã e a primeira hora útil do turno da tarde. Antes, levava mais que o dobro disso, cerca de 4 minutos, com ferramentas específicas de localização de pessoas. ### Quais foram os resultados desse trabalho? Depois da sua implementação definitiva, o Localizador de Pessoas (LOPE) alcançou uma economia de cerca de USD 5 milhões por ano, entre licenças de hardware e software, a distribuição de equipes de manutenção pelas ferramentas espalhadas pelo mundo e deslocamentos perdidos por atrasos na liberação de empregados nos prédios da empresa. Além disso, com a unificação dos sistemas de localização de pessoas, o tempo de entrada nas instalações da Petrobras foi padronizado e reduzido para cerca de 1min30s entre o visitante ou empregado se identificar na recepção do prédio e ter sua entrada liberada por um empregado que trabalha no local. Boa parte disso graças à nova interface gráfica — muito mais leve e muito mais eficaz — que permite localizar uma pessoa usando até 3 termos na busca. Exemplo de busca: “Marcelo Contratos Edise”. A aplicação aprende padrões e entrega os resultados acessados com frequência cada vez mais rápido, graças ao BDFTP. Por fim, todos os dados da força de trabalho foram normalizados e inseridos em um framework de banco de dados proprietário chamado BDFTP (Banco de Dados da Força de Trabalho da Petrobras), que usa tecnologia de última geração para armazenamento, controle de acesso e performance, suportando com folga o acesso e o backup dos dados 24 horas por dia, 7 dias por semana, todos os dias do ano. Essa nova tecnologia é a fonte única da verdade: o que for buscado ali é a versão final e definitiva sobre um empregado na empresa. Com isso, todos os objetivos foram cumpridos, depois de um projeto longo e dinâmico que durou cerca de 2 anos. ## Canal Eleva - Cliente: Eleva Educação - Papel: Design UX/UI - Stack: Angular · Figma · Fibo DS - Período: 2021 - URL: https://alexcesar.com/pt/work/canal-eleva/ O Canal Eleva é uma plataforma online que disponibiliza videoaulas para os alunos das escolas do grupo Eleva Educação e parceiras. Resultado: Aumento da satisfação dos usuários, medida via NPS. O Canal Eleva virou case dentro do grupo Eleva Educação por velocidade de implementação, atualização de tecnologia e economia de recursos ao migrar a estrutura anterior para a nuvem. ### Como funciona o Canal Eleva? Para acessar, os alunos passam pelo login unificado do Portal Eleva e depois clicam no link reservado do Canal Eleva da escola onde estudam. Por exemplo: um aluno do Colégio Pensi faz login no Portal Eleva e, já logado, vê o portal educacional do Colégio Pensi com um link de acesso ao Canal Eleva. Para os professores o procedimento é o mesmo, com um acréscimo: a possibilidade de publicar videoaulas das suas disciplinas através de um link reservado no seu perfil. ### O problema O principal problema que o Canal Eleva resolve é disponibilizar o conteúdo educacional ao longo dos anos escolares, e ser uma base de conhecimento sólida para o aluno depois da sala de aula. ### Canal Eleva 1.0 A primeira versão do Canal Eleva foi muito celebrada na Eleva Educação, e foi uma conquista. Ter praticamente todos os anos escolares com aulas digitalizadas foi fundamental no momento da pandemia (Covid-19), quando a população passou por restrições sanitárias e isso impactou o modelo de aula: presencial antes, aulas remotas no início da pandemia. P.S.: eu não trabalhei no Canal Eleva v1, só no Canal Eleva v2. Tecnologicamente falando, a plataforma foi construída com KnockoutJS no front end e C# no back end. - Canal Eleva 1.0 no Figma: https://www.figma.com/proto/28QwDONyEcBTs77kYN2BpI/Canal-Eleva-(Copy)?page-id=9%3A76&node-id=9%3A77&viewport=719%2C570%2C0.56&scaling=min-zoom&starting-point-node-id=9%3A77 ### Canal Eleva 2.0 O Canal Eleva foi atualizado tecnologicamente para Angular 9/10 no front end e .NET Core no back end. Além disso, a identidade visual foi atualizada, com os componentes seguindo o novo padrão definido pelo Fibo, o novo Design System criado pela Eleva Educação. O projeto de evolução tecnológica e redesign durou 1 mês. O processo de redesign em si durou 2 semanas. ### Qual foi o meu papel neste projeto? Fui o designer responsável pela UX e pela UI durante o processo de redesign do Canal Eleva. Levando em conta a janela de tempo disponível e a oportunidade de evoluir a experiência do usuário, optei por começar com um processo de discovery, entrevistando alunos e professores para descobrir qual era a dor no uso do Canal Eleva. Cinco pessoas foram entrevistadas, dos seguintes perfis: alunos (3), professores (1) e analistas de help desk que dão suporte à plataforma (1). ### Discovery O resultado foi que a plataforma atual não era tão precisa no processo de localizar o vídeo que o aluno precisava assistir — e isso tornava pouco atraente continuar estudando assistindo a vídeos em casa. Além disso, os alunos evitavam usar o celular para assistir aos vídeos, e não tinha nada a ver com a qualidade da gravação: era a experiência de localizar o vídeo que precisavam assistir, relacionado à aula que tinham estudado naquele dia. A partir dessa informação, foram feitas perguntas sobre os sites, plataformas e apps que os usuários mais gostam, e o motivo dessa admiração. As respostas apontaram para a facilidade de uso que as principais plataformas de streaming oferecem. ### Wireframe + decisão Essa etapa de discovery guiou a coleta de informações sobre os concorrentes (via benchmarking), e facilitou decidir qual caminho seguir depois de esboçar (wireframing) e discutir com os desenvolvedores a viabilidade de implementar algumas funcionalidades novas. E em termos de decisão, escolhemos colocar a ênfase no que todo mundo veria primeiro — o próprio Canal Eleva — em vez de construir ao mesmo tempo a parte administrativa, onde os vídeos são cadastrados. ### Conclusão Como havia um Design System com componentes prontos, as ideias levantadas no papel foram rapidamente traduzidas dentro do Figma — tão rápido que foram apresentadas imediatamente aos usuários e aos stakeholders que decidiam, permitindo coletar dados em tempo real e iterar sobre o que poderia ser modificado e implementado ali mesmo com o time. O feedback visual e de experiência do usuário foi coletado em uma sessão com todos os envolvidos para a primeira apresentação do layout, e pela disponibilização de links específicos para que os usuários navegassem por conta própria depois. Com isso, chegamos ao fluxo finalizado nas versões desktop e mobile, como se vê abaixo. - Versão mobile no Figma: https://www.figma.com/proto/7mbDSwu3jTKN2luYTEfNuO/Novo-Canal-Eleva---Mobile?page-id=0%3A1&node-id=301%3A28&viewport=-955%2C-1168%2C0.49&scaling=scale-down&starting-point-node-id=301%3A28 - Versão desktop no Figma: https://www.figma.com/proto/fmPk8bSXIBe83UQ4oFiMDi/Novo-Canal-Eleva---Desktop?page-id=359%3A955&node-id=359%3A956&viewport=110%2C280%2C0.09&scaling=scale-down&starting-point-node-id=359%3A956 ### Quais foram os resultados desse trabalho? Aumento da satisfação dos usuários (medida via NPS). O Canal Eleva virou case dentro do grupo Eleva Educação por velocidade de implementação, atualização de tecnologia e economia de recursos ao migrar a estrutura anterior para a nuvem. O acesso aos vídeos foi otimizado para dispositivos móveis depois da troca do provedor de hospedagem. Os professores gravaram novas aulas com equipamentos novos, e a qualidade dos vídeos subiu. ## ODGO - Cliente: Cidadania Já - Papel: UX Lead sênior - Stack: Figma · Hotjar · Scrum - Período: Set — Dez 2021 - URL: https://alexcesar.com/pt/work/odgo/ O Odgo é uma plataforma online gratuita que ajuda brasileiros a planejar sua imigração de qualquer lugar do mundo para Portugal. Resultado: Depois de 12 semanas (Set a Dez de 2021), a primeira versão do Odgo foi lançada como MVP — rodando com dados reais e pessoas reais, pronta para ser apresentada a investidores — com as próximas mudanças a serem priorizadas pelo valor percebido pelos usuários e pelo valor agregado ao produto. ### Como funciona o Odgo? Você se cadastra na plataforma e faz um quiz rápido para descobrir seu perfil de usuário — por exemplo: imigrar com a família; trabalhador qualificado; estudante. O planner então fornece todas as informações necessárias para você chegar ao seu objetivo. O app funciona como um checklist que ajuda brasileiros a se mudarem para Portugal: a informação chega por tarefas agrupadas por assunto — saúde, educação, pets, documentos, moradia — e compartilha a base de conhecimento do blog da Cidadania Já. A plataforma é gratuita; o modelo de negócio são parcerias com serviços portugueses, como imobiliárias, instituições de ensino e serviços de terceiros. ### Quantas pessoas trabalharam nele? O time de UX tinha um total de 4 pessoas (1 UX Lead, 3 designers) e trabalhava em paralelo com o time de Desenvolvimento de Produto (5 pessoas: 3 desenvolvedores, 1 Product Owner, 1 designer). Além disso, o CEO do Odgo trabalhou em tempo integral dando direção durante a etapa de lançamento do produto, para que o MVP fosse exatamente o esperado para receber investimento. ### Qual foi o meu papel neste projeto? Como UX Lead sênior, fui responsável pelo time de UX/Research durante o processo de discovery, desenvolvimento e lançamento do produto (Odgo), que permitiria à empresa captar investimento para acelerar a startup. P.S.: o time de UX/Research trabalhava com 3 designers. Depois foi incorporado ao time de Desenvolvimento de Produto. Quando cheguei à Cidadania Já, o time de UX/Research já tinha passado pela fase de pesquisa. Então, usando o modelo Double Diamond (revisto) como base, seguimos para o processo de conectar os dados da pesquisa com as ideias de design (Design Synthesis) — organizando os dados empíricos e formando um problem statement conciso. ### Visão de Produto (CEO) ### Ideação + brainstorming Como atividade-chave, rodamos uma sessão de ideação e brainstorming em que conseguimos estruturar dados, coletar novas ideias e, por fim, apresentar as possíveis soluções de produto e serviço ao CEO, que centralizava todo o processo de aprovação e decisão sobre o Odgo. - Brainstorming no Figma: https://www.figma.com/file/BhkQ3BqScSiCy0Zpne52Lt?node-id=0:1 Em seguida, passamos para a etapa de ideação, trabalhando de forma colaborativa e simultânea durante períodos curtos a cada dia — o equivalente ao pair programming do Agile. Fizemos os primeiros wireframes e simulações de microinterações, e criamos um mood board para ajudar a explorar novas ideias e conexões com o potencial público-alvo, até chegarmos ao processo de desenvolver a marca e o style guide que sustentaria a identidade visual do produto. - Style guide no Figma: https://www.figma.com/file/QaU9pAkNprnflDqV05NWvk/Styleguide-Odgo?node-id=93%3A302 - Branding no Figma: https://www.figma.com/file/KiNfix2aWuSAIkKC9nfaFs/Branding?node-id=571%3A16449 ### Workshops Durante esse processo, descobrimos que o time podia evoluir direto do protótipo de baixa fidelidade para o de alta fidelidade, graças aos componentes criados no style guide. Isso acelerou a entrega dos protótipos ao time de desenvolvimento e nos deu uma vantagem de tempo — time de UX em sprints de 1 semana vs. time de desenvolvimento em sprints de 2 semanas — que foi convertida em workshops semanais para elevar a qualidade das entregas. - Workshop Product-Led Growth no Figma: https://www.figma.com/proto/1RHWuzdSwx9WrEpnHRWLUJ/Workshop-Figma-%2303?page-id=0%3A1&node-id=301%3A12837&viewport=-16%2C120%2C0.04&scaling=contain&starting-point-node-id=301%3A12837 ### Conclusão Para facilitar a construção do MVP e sua aprovação pelo CEO da empresa, dividimos o Odgo em 4 partes distintas: Login, a Definição do Perfil do Usuário (formulário), os Grupos de Tarefas e a Base de Conhecimento. Depois de testes e do acompanhamento da navegação dos usuários pelo Hotjar, foram feitas melhorias na experiência do usuário. Depois de 12 semanas (Set/21 a Dez/21), lançamos a primeira versão do Odgo como MVP. A intenção é que o produto receba muitas mudanças com base nas informações levantadas em pesquisa e testes — priorizadas conforme o valor percebido pelos usuários e o valor agregado ao produto. - Abrir no Figma: https://www.figma.com/file/BhkQ3BqScSiCy0Zpne52Lt?node-id=0:1 # Depoimentos - Noël Bossart, CEO e Cofundador · Noevu GmbH: "Alexander entrega trabalho de frontend em nível sênior — bem arquitetado, mobile-first e fiel até o último pixel do design. Em mais de um ano trabalhando juntos, ele se mostrou confiável, independente e genuinamente comprometido com o ofício. Eu o recomendo sem hesitar." - Aaron Morf, Offshore Lead, Equipe de Gestão · OPTEN AG: "Uma das qualidades mais valiosas do Alex era seu nível de senso de dono e independência. Ele cumpria os prazos acordados de forma consistente, encarava os desafios com uma mentalidade prática e orientada a solução, e dava para contar com ele para entregar trabalho de qualidade no prazo." - Jhony Adell, Data Engineering · Eleva Educação: "Extremamente técnico, criativo e carismático — é assim que eu defino o Alexander. Domínio total, conhecimento e criatividade, entregando a melhor experiência possível para os usuários. Além do conhecimento técnico profundo, ele trabalha bem em time, sempre pronto para ajudar os colegas." - Victor Guerra, Data Platform & AI Engineer · Atos Origin e Petrobras: "Trabalhamos juntos em épocas e empresas diferentes — Atos Origin e Petrobras. O Alexander sempre mostrou muita habilidade e criatividade para representar o que os clientes realmente procuram. Ótimo de time, sempre pronto para ajudar quando você precisa dele." - Carlos Magno Goiabeira Souza, Global IT Program Manager · cliente na Atos Origin: "A maior virtude de um profissional dessa área é a criatividade, e essa foi sua contribuição mais valiosa — sua marca. Além de excelentes habilidades técnicas, Alexander é ótimo de time, compartilhando com vontade suas ideias e sua experiência onde quer que haja necessidade de ajuda." # Linha do tempo - 1997 — 2001 — Autodidata: Primeiros pixels, primeiro código — interfaces e o código por trás delas, aprendidos lado a lado. (Golden Web Award · iBest) - 2001 — 2006 — Flash & Motion: Timelines, easing, inércia — os instintos de animação que ainda guiam meu trabalho de UI. (Adobe Certified Instructor — desde 2005) - 2006 — 2015 — Corporativo: Anos de empresa grande — entregando em escala, mão na massa por stacks que mudavam. (Petrobras · LOPE — ~US$ 5M/ano economizados) - 2014 — 2018 — Design Acessível: Minha primeira empresa — empreendedorismo, primeiros produtos, lições duras. Não deu certo; o aprendizado veio comigo. (Marinha do Brasil · Kawasaki · estúdio próprio) - 2019 — 2025 — Produto & Sistemas: A virada de designer para desenvolvedor — Eleva, ODGO, CESAR. As mesmas mãos, os dois ofícios. (120k alunos atendidos) - 2025 — Atual — Exponencializado por IA: De esboço a app publicado, sozinho — mais rápido do que nunca, o mesmo padrão. (12 projetos · 12 meses · 5 stacks) # Como ele trabalha - Design e código, as mesmas mãos: Sem handoff, nada se perde na tradução — eu entrego exatamente o que desenho. - Movimento é significado: Easing e inércia dos anos de Flash, aplicados a interfaces de produto. - IA como alavanca: Ferramentas que deixam minhas mãos mais rápidas — nunca um substituto para o ofício. - Pronto significa no ar: Um design não está terminado até estar rodando em produção. - Design e código, as mesmas mãos: Nenhum handoff perdido na tradução — eu entrego o que desenho. - IA como alavanca: Ferramentas que me deixam mais rápido, não um substituto para o ofício. - Trabalho em time: Gosto de discutir tradeoffs com um time, não de trabalhar no vácuo. - Entregar, depois refinar: Software funcionando ganha de uma apresentação perfeita, sempre.