Sciene / Companion · 2025-2026
Do ruído ao sinal.
Desenhei o fluxo de alertas da Sciene para ajudar times de Customer Success a identificar contas que precisam de atenção. Depois que a primeira versão sobrecarregou os usuários, refinamos quais alertas apareciam e como agir sobre eles.
Product Designer único · Web App (SaaS corporativo)
Em produção, usado diariamente por centenas de CSMs e diretores
Toda conta parecia urgente.
Cada CSM nos clientes corporativos da Sciene cuida de 10 a 20+ contas. O dia começa com a mesma pergunta: o que está pegando fogo? Sem um sistema para responder isso, problemas críticos, quedas de venda, picos de investimento em anúncios, suspensões de anúncio, pagamentos atrasados, só aparecem quando o cliente liga irritado. Os times remendavam a lacuna com um dashboard externo, fora do ecossistema do produto: útil, desconectado.
O Companion é a suíte da Sciene para operações de Customer Success, com três módulos: Account Flagging, um AI Email Hub e um Meeting Hub. O Account Flagging é o módulo base, a primeira olhada que os CSMs abrem toda manhã, e o ponto de apoio de tudo que vem depois.
Entender como a manhã realmente começa.
Seis semanas de entrevistas: 12 CSMs de diferentes portes de conta, mais 3 diretores. Mapeei como eles realmente procuram problemas, em quais dados confiam e quando escalam. Comecei pelo fluxo de trabalho e deixei a interface vir dele.
A primeira versão criou mais ruído.
O primeiro protótipo mostrava todo alerta que o sistema conseguia gerar. Parecia completo. No teste com CSMs, era ruído. Os insights de IA por cima eram, muitas vezes, tecnicamente corretos e funcionalmente inúteis.
Construí um artifact do Claude ligado ao Databricks que puxava os dados de reconhecimento da v0. Em uma semana o padrão ficou claro: só 34% dos alertas eram reconhecidos em até 24 horas. Dois terços eram ignorados, adiados indefinidamente ou afogados. A IA fazia exatamente o que pedimos: expor tudo que os dados permitiam. Esse era o problema.
A virada: menos alertas, cada um valendo a parada.
Sentei com os CSMs e seus diretores para definir o que "relevante" significava, limite por limite. Depois trabalhei com os engenheiros de IA para codificar isso de volta na lógica de alertas. O design e o modelo se encontraram no meio.
v0 · Expor todos os alertas
Alertas completos, mas difíceis de priorizar. Só 34% eram reconhecidos em até 24 horas.
v1 · Priorizar o que importa
Limites refinados com CSMs e engenheiros, contexto para cada alerta e estados de acompanhamento.
Menos alertas. Motivos claros. Ações explícitas.
Priorizar o que importa
Categorias e filtros refletem a triagem diária dos CSMs.
Explicar o motivo
Frequência, contexto histórico e métricas ajudam a interpretar cada sinal.
Fechar o ciclo
OK, adiar e resolvido tornam o acompanhamento explícito.
Para explorar layout, gerei quatro ou cinco protótipos React no Cursor e testei com CSMs no mesmo dia. A lógica dos limites foi escrita junto com os engenheiros de IA: eu prototipava uma regra de alerta, eles testavam contra dados de produção, e a gente iterava até a taxa de falso positivo ficar aceitável.
Da triagem individual à visão do time.
A v1 deu aos CSMs a triagem da manhã deles. A v2 deu aos diretores o time deles.
O Director Dashboard mostra o MRR sob alerta em todos os CSMs, taxas de resolução, o ciclo de pedidos de ajuda e a priorização por carga de trabalho. Toda métrica volta para o mesmo sistema de alertas.
Os CSMs podem marcar uma conta como "pedi ajuda". Os diretores veem o pedido aparecer na visão deles; o CSM vê o reconhecimento na dele. Um dashboard só, um sistema de dois papéis.
Uma base compartilhada para crescer.
O Account Flagging foi a primeira de três superfícies. O Companion tem três módulos, então os padrões de alerta precisavam se sustentar também no AI Email Hub e no Meeting Hub, ambos desenhados por mim.
Construí o design system do zero junto com a v1: tokens, biblioteca de componentes, padrões de acessibilidade e documentação de handoff, adotados por produto e engenharia. Estados de alerta, tratamento de severidade e controles de reconhecimento viraram primitivos compartilhados que qualquer módulo podia usar. É por isso que o Director Dashboard da v2 saiu sem redesenhar nada do zero.
O que mudou — e o que aprendi.
A virada mudou como eu penso IA em design de produto. Mostrar mais nunca foi a parte difícil. Decidir o que esconder era, e a v1 funciona porque deixamos o modelo enterrar a maioria dos alertas e depois garantimos que os que sobraram valiam a atenção de um CSM.
A IA foi o que deixou esse projeto andar rápido. O julgamento continuou meu, e foi aqui que eu provei isso pra mim mesmo pela primeira vez, dos dois lados da tela.
Como usei IA durante o projeto
Síntese das entrevistas
Em vez de transcrever 12 horas de entrevista na mão, usei o Claude para agrupar as transcrições em padrões de dor. O que levaria quase uma semana levou uma tarde, e me deixou usar o resto dela testando esses padrões contra a fonte bruta.
Um sistema que agentes conseguem ler
O sistema foi documentado para dois públicos: pessoas e agentes de IA. Nomes semânticos de token, descrições de componente escritas como regras de uso e estados listados em estruturas previsíveis fazem com que um assistente LLM consiga compor uma interface válida a partir da biblioteca do mesmo jeito que um engenheiro faz. A documentação também é o prompt.
Documentação
A documentação de handoff para desenvolvedores e as anotações no Figma foram escritas junto com o design, com o Claude, enquanto as decisões ainda estavam frescas. Isso manteve a especificação em sincronia com o protótipo e reduziu o atrito do handoff a quase zero.