Clickmax

O Clickmax é o produto SaaS de page builder e funis de conversão da Bilhon. O CX Admin é o back-office que sustenta essa operação: onde o time modera produtos, atende clientes, publica templates, acompanha o financeiro e mantém a plataforma rodando por dentro.

Entrei nesse trabalho em parceria com André (Design Lead do time). Ele conduziu o redesign das telas de Produtos e Clientes; eu fiquei responsável pela navegação estrutural (a nova sidebar) e pela arquitetura completa do gerenciamento de templates: do problema à hipótese ao código shipado.

Duas superfícies de navegação competindo pela atenção. O CX Admin antigo tinha um menu superior com as macro-áreas (Produtos, Clientes, Marketplace, Suporte, Financeiro, Templates…) e um rail lateral com os sub-itens da área ativa. O operador tinha que ler duas regiões pra saber onde estava, e o rail secundário só ganhava função quando havia 2+ filhos. Nas outras, era espaço morto.

Templates de funis eram ativo de engenharia. Cada novo template precisava ser implementado via código pelo time de dev: ticket, sprint, deploy. Não havia gestão dentro do CX Admin. Consequência prática: catálogo estagnado, backlog de "criar template X" crescendo, e time de eng ocupando dias por sprint em trabalho que não era engenharia, era curadoria.

Consolidei os dois menus numa única barra lateral. Cada área é um bloco expansível; quando o item tem filhos, a navegação secundária abre inline dentro do próprio bloco. Não vaza pra outra região da tela.

A topbar deixa de carregar navegação e passa a fazer o que faz de melhor: orientação. Breadcrumb à esquerda (CX Admin / Produtos / Visão geral), notificações e conta à direita. Uma leitura, uma decisão, um clique.

A estrutura já comporta o crescimento: novas áreas ou novos sub-itens entram sem redesenho. O que era um problema recorrente de arquitetura virou uma decisão de conteúdo.

Aqui é onde o case deixa de ser sobre interface e vira sobre impacto no produto. Publicar um template de funil, que antes era ticket de eng + deploy, virou um fluxo dentro do próprio CX Admin:

1. Admin seleciona o usuário dono da conta base.
2. Escolhe o workspace e o projeto.
3. Seleciona o funil elegível a virar template.
4. Define capa e descrição (a própria plataforma sugere texto automaticamente).
5. Atribui plano e categoria.
6. Publica no catálogo.

Poucos cliques, mesmo resultado que antes exigia arquivo em repositório, code review, merge e deploy.

Desenhei a arquitetura, os estados, o modelo de dados e o fluxo. Implementei front e back-end com apoio de IA (Claude Code). Cada etapa foi revisada e validada pelo time de engenharia. Nada foi mergeado sem passar por olhos de dev sênior.

O escopo era grande (design + front + back de dois territórios do produto). Pra manter code review possível numa base desse tamanho, fatiei tudo em PRs planejados por escopo: cada um pequeno o suficiente pra ser revisado com atenção, grande o suficiente pra fazer sentido isoladamente.

A cada PR: review do time de engenharia antes do merge, validação rigorosa do QA em ambiente de staging. Os ajustes de QA por PR foram pouquíssimos. E isso não é sorte. É evidência de shaping bem feito antes de escrever a primeira linha de código.

A plataforma segue sendo melhorada release a release. A base arquitetural aguenta o crescimento.

• Cross-stack com disciplina. Designer que shipa código só vira valor quando o time está no processo: code review dev, validação de QA, PRs granulares. IA acelera a execução; o time garante a qualidade. Fugir dessa disciplina vira dívida.
• Discovery orientada a custo. A mudança que gerou impacto real não era visual: era estrutural. Saber onde o esforço rende (no fluxo do operador, no throughput do time de eng) muda a conversa com stakeholders.
• Colaboração com Design Lead. Dividir escopo com o André (ele em Produtos/Clientes, eu em sidebar/templates) exigiu alinhamento de padrão, ritmo e linguagem visual. Sênior não trabalha sozinho. Trabalha em par com quem tem a visão do time.
• Shaping precede execução. Poucos ajustes de QA num escopo desse tamanho não é sorte. É investimento na etapa antes do código: entender o problema, dividir em PRs, deixar critérios claros.