Sistema Modular de Pricing: de inconsistência cross-produto a design system escalável

No Portal TIM, pricing é o módulo onde a conversão acontece. É ali que o cliente compara planos e decide o que contratar. O problema é que esse módulo não era um só. Quatro squads de produto recriavam e aplicavam a sua própria versão, cada uma com layout e estrutura diferentes.

O efeito era cumulativo. O usuário tinha dificuldade de comparar ofertas entre produtos, principalmente em transições naturais como migrar do Pré para o Controle. A conversão global ficava abaixo do esperado por puro excesso de carga cognitiva. E os times de UX e engenharia reinventavam a roda a cada página, gerando retrabalho constante.

Some a isso um detalhe que definiu o tom do projeto: o ambiente tinha baixa maturidade de design e de testes. Validar com usuário não era rotina, era algo a ser construído do zero junto com a solução.

Cada produto tinha uma regra de negócio própria e inegociável. Não dava para impor um único layout de cima para baixo, porque cada squad resolvia uma necessidade real e diferente.

O desafio não era escolher uma regra como certa. Era encontrar uma estrutura que respeitasse as quatro ao mesmo tempo.

O primeiro passo foi olhar o que as ferramentas de analytics já diziam sobre como as diferentes aplicações do módulo impactavam o resultado. Quatro padrões se repetiam.

Navegando pelas páginas dos produtos no mobile, encontrei o ponto mais grave. O dimensionamento do card empurrava o CTA para fora da primeira dobra, somado à sobrecarga de informação e à pouca diferença percebida entre ofertas vizinhas.

Com os aprendizados sintetizados, formulei junto à PO uma hipótese para direcionar a solução.

Rever a estrutura de informação do módulo, garantindo que ele atenda às diferentes regras de negócio e facilite o entendimento do usuário sobre as ofertas. Com isso, esperamos reduzir a taxa de rejeição e aumentar a interação com o módulo.

Antes de desenhar, analisei concorrentes e referências de outros mercados para entender como simplificar o card sem perder informação relevante.

benchmarking · referências de mercado

Como o módulo precisava servir as quatro squads, não fazia sentido decidir sozinho. Facilitei uma dinâmica de cocriação com o time de UX de cada squad, para que as soluções nascessem já contemplando as demandas de todos.

figjam · cocriação

Refinando as sugestões mais votadas na dinâmica, montei a primeira versão do card. Ela já trazia o destaque para a oferta mais vantajosa, mais peso para Giga e Preço, a escolha da forma de pagamento dentro do card, um texto de apoio para diferenciar as ofertas e a simplificação dos benefícios em um collapse.

Para captar a visão de negócio, levei essa versão a uma critique com os POs das quatro squads. A principal preocupação foi com os benefícios que ficariam ocultos no collapse, justamente o que cada squad considerava diferencial estratégico.

Aqui está um dos pontos que mais me orgulho no projeto. Em um ambiente de baixa maturidade de testes, estruturar uma avaliação formal já era, por si só, demonstrar o valor de testar: captar e antecipar problemas antes de levar qualquer coisa para produção.

Conduzi um teste moderado remoto com 5 usuários para avaliar a eficiência do novo módulo. Aproveitei para validar quais fatores eles consideram ao contratar uma oferta. Giga e Preço foram os mais citados, confirmando a hierarquia que eu já vinha reforçando.

figma · teste de usabilidade

Ao final, os participantes responderam ao questionário SUS para medir a facilidade de uso percebida.

A nota alta não me deixou cego para os problemas. Durante as sessões, dois pontos críticos apareceram no card, destacados abaixo.

1

2

1Benefício só em texto: exigia esforço extra para o usuário perceber o valor

2Toggle sem ação clara: não comunicava que geraria uma ação

Reestruturei a hierarquia visual em dois blocos. O primeiro destaca o principal diferencial da oferta, agora com as logos dos serviços em vez de texto puro. O segundo reúne os benefícios complementares. No lugar da escolha de pagamento, entrou a opção de adicionar um serviço extra, com o toggle mais explícito.

A resposta para as quatro regras não foi um card único e fechado. Foi um sistema modular. As boas práticas validadas ficam fixas e garantem consistência; o conteúdo que muda de produto para produto fica configurável.

Com isso, cada squad monta a sua variação sem quebrar a comparabilidade entre produtos nem reabrir as decisões já validadas. Os módulos ligam e desligam conforme a regra de cada produto, do card completo ao mais enxuto.

tim.com.br/planos

A atuação foi transversal, conectando quatro squads que antes trabalhavam isoladas.

Para validar as melhorias, a squad de TIM Controle foi a primeira a implementar o novo pricing.

A formatação mais enxuta elevou a taxa de visualização média ao longo da página, e a navegação vertical no mobile facilitou a exploração das ofertas, com aumento na taxa de cliques para contratação. Mais do que os números, o projeto deixou um sistema que as quatro squads adotaram e um precedente: o de que vale a pena testar antes de subir para produção.

Metodologia: ganhos de visualização e cliques medidos na implementação da TIM Controle, primeira squad a adotar o módulo. São indicadores direcionais, ainda sem consolidação cross-produto.