Como criar tabelas de preços claras

Uma tabela de preços útil permite responder a três perguntas sem abrir uma calculadora ou outra aba do navegador: qual plano atende ao meu trabalho? Quanto vou pagar de fato? O que acontece se eu escolher esse plano?

Parece simples até você colocar os detalhes reais do produto no layout. Um plano inclui cinco editores, outro cobra por editor, a cobrança anual aparece como um valor mensal equivalente, e o recurso mais importante fica escondido abaixo de doze marcas de confirmação idênticas. Os cards podem parecer bem acabados enquanto a decisão continua difícil.

Os exemplos detalhados usam o Fieldnote, um serviço fictício de colaboração.

Defina a escolha antes de desenhar os cards

Escreva em uma frase a decisão que você espera que o visitante tome. No caso do Fieldnote, é escolher um plano de espaço de trabalho para um pesquisador independente, uma pequena equipe de projeto ou uma organização que precisa de administração centralizada.

São necessidades operacionais diferentes. Elas oferecem um ponto de partida mais útil do que decidir que toda página de preços precisa de três colunas. Um produto com um único pacote pago pode precisar de uma explicação do preço, em vez de uma comparação. Um serviço com produtos separados pode precisar primeiro de um seletor de produto. Colocar compras fundamentalmente diferentes em colunas lado a lado pode sugerir que elas são intercambiáveis quando não são.

Pergunte à pessoa responsável pelo produto quais informações realmente mudam a escolha. Neste exemplo, as mais importantes são projetos ativos, editores incluídos, acesso para convidados e administração. O armazenamento também varia, mas provavelmente não determina a primeira decisão do público pretendido. Essa distinção organiza a página: primeiro mostre a adequação do plano, depois apresente os detalhes necessários para confirmá-la.

Mantenha uma ficha de referência curta fora do design. Registre, para cada plano, nome, público, unidade de cobrança, quantidade incluída, limite, condição de mudança para um plano superior e caminho de compra. Se a fonte indicar que um item ainda não foi decidido, registre-o como pendente. Um mockup atraente é um lugar particularmente ruim para definir, sem querer, uma política comercial que ainda não existe.

A ficha também protege contra revisões inconsistentes. Se a equipe alterar a quantidade de editores incluídos, talvez seja preciso atualizar o resumo do plano, a linha de comparação, a calculadora e as perguntas frequentes. Trate esses elementos como representações diferentes de um mesmo fato, e não como textos independentes que por acaso contêm o mesmo número.

Design de tabelas de preços: primeiro selecione, depois compare

Os cards dos planos e a matriz de recursos cumprem funções diferentes. Os cards ajudam o visitante a selecionar as opções mais promissoras. A matriz permite confrontar essa seleção com requisitos específicos. Tentar colocar todos os detalhes nos cards produz colunas longas em que é difícil localizar as diferenças.

As orientações do Figma sobre preços distinguem uma apresentação concisa dos planos de uma tabela comparativa mais completa e recomendam explicitar as unidades de cobrança perto do preço. É uma base útil para a estrutura proposta aqui. Orientações do Figma para páginas de preços.

No Fieldnote, o card Solo poderia descrever projetos independentes e, em seguida, mostrar preço, limite de projetos ativos e acesso para convidados. O card Team poderia descrever pesquisa compartilhada e apresentar preço, editores incluídos e capacidade de projetos compartilhados. Já o card Organization poderia explicar a administração centralizada e a compra mediada pela equipe comercial. Não é preciso inventar um preço público para esse último card se o modelo comercial exige um orçamento.

Mantenha a ordem das informações consistente, mesmo quando os valores forem diferentes. Se um card colocar as condições de cobrança abaixo do botão e outro as colocar ao lado do preço, o leitor terá de procurar essa relação. O alinhamento passa a explicar a estrutura: a mesma posição corresponde ao mesmo tipo de informação.

Leia a página de preços do GitHub em duas etapas

A página de preços do GitHub oferece um exemplo real útil da diferença entre o resumo de um plano e uma comparação detalhada. A área dos planos apresenta as opções disponíveis e os caminhos de compra; a comparação de recursos abaixo oferece outro nível de detalhe. Os preços registrados nas capturas ilustram essa estrutura de página; consulte a página atual para conhecer as condições em vigor.

Examine as duas áreas com perguntas diferentes. No resumo, você consegue identificar uma opção plausível para sua equipe? Na matriz, consegue verificar o requisito que faria você descartá-la? Essa divisão é útil porque um card introdutório e uma verificação para contratação não exigem a mesma densidade de informação. Um card que reproduz todas as linhas da matriz deixa de ser um resumo.

Peça a uma pessoa que possa vir a comprar o produto que escolha um plano adequado e explique o compromisso assumido. Essas respostas testam o que o layout comunica.

Calcule a cobrança que o leitor realmente está escolhendo

Para um exemplo separado de cobrança por licença, imagine um serviço fictício chamado SeatMeter. Seu plano é apresentado como $12 por editor por mês, cobrado anualmente, com um mínimo de cinco editores. Uma equipe de três pessoas não necessariamente pagaria $36 a cada mês. Sob essas condições, o compromisso anual mínimo é $12 × 5 × 12 = $720.

É nesse ponto que o design de preços costuma falhar, mesmo quando cada número está correto isoladamente. A hierarquia visual torna memorável o valor mensal equivalente e deixa o pagamento efetivo quase invisível. Peça a alguém que explique quanto espera pagar hoje. Se a resposta for a tarifa, em vez do total cobrado, aumentar ainda mais o destaque da tarifa não resolverá o mal-entendido.

Não deixe que um selo de economia esconda a base de comparação. Se a opção anual economiza vinte por cento em relação a doze pagamentos mensais, informe qual valor mensal foi usado no cálculo. Se uma promoção vale apenas para o primeiro período, mantenha essa condição perto do preço promocional. Um selo que parece permanente, associado a uma oferta temporária, cria uma expectativa que uma nota de rodapé talvez não consiga desfazer.

O mesmo cuidado vale para a capacidade incluída. “Cinco editores incluídos” e “mínimo de cinco editores pagos” podem corresponder ao mesmo tamanho inicial de equipe, mas descrevem regras comerciais diferentes. Registre a regra verdadeira na ficha de referência e preserve esse mesmo significado no card, na matriz e na passagem para o checkout.

A cobrança por espaço de trabalho segue outro cálculo

Mantenha juntos valor, moeda, unidade de cobrança e compromisso assumido. Nas assinaturas anuais apresentadas como um valor mensal equivalente, o total anual deve aparecer no mesmo grupo visual.

Suponha que o Fieldnote Team custe $30 por espaço de trabalho a cada mês, na modalidade mensal. A oferta anual separada, também baseada em espaço de trabalho, custa $288 por espaço de trabalho por ano, o equivalente a $24 por mês. Um card anual claro pode destacar esse equivalente mensal e trazer imediatamente depois uma frase informando que são cobrados $288 por ano. O visitante não deve precisar deduzir que existe a opção de fazer doze pagamentos de $24.

A diferença entre o preço por espaço de trabalho e o preço por licença merece o mesmo cuidado. “$24 por mês” é uma informação incompleta se uma equipe de seis pessoas vai pagar, na verdade, seis vezes esse valor. Mostre se o preço inclui uma quantidade fixa de editores, se é cobrado por editor ou se parte de uma quantidade mínima. Coloque essa premissa de quantidade na mesma área do preço, em vez de escondê-la em uma dica distante.

Quando a cobrança varia conforme o uso, explique os limites antes de acrescentar uma calculadora. Sem uma base visível, a calculadora pode dar aparência de precisão a um preço incerto. Informe o uso incluído, o que gera cobrança adicional e se a estimativa exibida inclui itens opcionais. Se não houver uma tarifa estável para calcular, explique quais informações a equipe comercial precisa receber.

Não misture várias unidades em uma mesma linha de comparação. Uma célula com “10” e outra com “Ilimitado” são ambíguas se a linha não explicar o que está sendo contado e em qual período. “Projetos ativos” é diferente de “Projetos criados por mês”. Essa distinção pode mudar a compra mesmo quando os números parecem iguais.

Trate o seletor de cobrança como uma mudança de condições

Alternar entre cobrança mensal e anual deve atualizar, ao mesmo tempo, todas as informações afetadas. É mais do que animar o número em destaque. O total anual, a explicação da economia, o texto sobre o compromisso e o destino da ação de compra precisam continuar coerentes com a modalidade selecionada.

No exemplo do Fieldnote, a cobrança mensal soma $360 ao longo de doze meses, enquanto a anual custa $288. A diferença é de $72, ou vinte por cento do total da modalidade mensal. Se o design mostrar essa economia, deixe clara a base de cálculo. Comparar um valor anual com desconto com alguma outra tarifa promocional contaria uma história diferente.

A opção ativa precisa de um rótulo e de um estado inequívocos. Duas palavras ao lado de um pequeno interruptor podem deixar dúvidas sobre se o rótulo da esquerda descreve o valor atual ou a alternativa disponível. Um controle segmentado com a opção selecionada bem visível costuma ser mais fácil de explicar em um protótipo. Seja qual for o tratamento escolhido, o estado selecionado precisa continuar identificável durante o uso por teclado e não deve depender apenas da cor.

Alterne o controle enquanto observa um plano mais abaixo na página. Ainda é possível identificar qual período de cobrança se aplica? Repetir o período perto de uma comparação longa pode ser mais útil do que um seletor que desapareceu muito acima. A repetição se justifica quando evita que o preço perca o contexto.

Decida também o que deve permanecer estável. A ordem dos planos e os limites dos recursos não devem mudar apenas porque o visitante alterou a frequência de cobrança, a menos que a oferta real também mude. Uma reorganização inesperada dificulta a comparação entre os dois estados e pode dar a impressão de que o serviço mudou enquanto a pessoa lia.

Crie linhas que permitam uma comparação honesta

Cada linha deve fazer uma pergunta e respondê-la para todos os planos. “Capacidade de projetos” pode conter um número. “Acesso para convidados” pode conter “Incluído” ou “Não incluído”. “Suporte” precisa de uma descrição se um plano oferecer atendimento por e-mail e outro incluir um contato designado. Uma marca de confirmação, sozinha, não expressa essas diferenças.

Use a mesma unidade e o mesmo nível de precisão em toda a linha. Se a coluna Solo disser “Três projetos ativos”, não escreva “Muito espaço para crescer” na coluna Team. A segunda frase evita justamente a comparação que a tabela deveria permitir. Coloque a linguagem promocional na explicação ao redor e o limite real na célula.

Diferencie ausência de incerteza. Um traço pode significar indisponível, não aplicável, não divulgado ou zero. Quando a distinção importar, use palavras explícitas. Se optar por um símbolo compacto, explique claramente o significado e garanta que ele também seja transmitido às tecnologias assistivas. Quem compra nunca deveria precisar adivinhar se uma célula vazia indica uma limitação ou um erro de publicação.

Os nomes dos recursos também devem permanecer estáveis. Chamar a mesma capacidade de “Pastas compartilhadas” no primeiro plano e “Espaços colaborativos” no segundo pode sugerir uma melhoria que não existe. Quando a capacidade realmente mudar, descreva a diferença: mais membros, histórico mais longo, permissões diferentes ou outro compromisso de atendimento.

Agrupe as linhas em torno de perguntas reconhecíveis. O Fieldnote poderia ter seções para trabalho em projetos, colaboração e administração. Os grupos devem ajudar a encontrar uma resposta, em vez de reproduzir o organograma interno da equipe de produto. Se o comprador pensa em termos de compartilhar acesso, torne esse caminho evidente, mesmo que várias equipes de engenharia sejam responsáveis pelos recursos envolvidos.

Tenha cuidado com “Tudo do plano anterior”. A expressão encurta o card, mas obriga o leitor a procurar em outro lugar para entender o plano superior. Isso pode ser aceitável em uma visão geral breve. Em uma matriz, repetir o valor efetivo costuma ser mais útil, porque cada linha continua podendo ser comparada de forma independente.

Dê uma razão para a recomendação

Um plano destacado deve explicar para quem é adequado. “Para equipes que compartilham pesquisas entre projetos” dá um motivo para considerar o Fieldnote Team. “Melhor custo-benefício” pede que o leitor aceite um julgamento sem conhecer a base. “Mais popular” é uma afirmação factual e exige evidências; não deve servir como enfeite no lugar de uma recomendação.

Use o destaque para oferecer um ponto de partida e mantenha as alternativas legíveis. Uma borda mais forte, um pequeno rótulo ou uma mudança discreta no fundo podem cumprir essa função. Ampliar tanto o card central que fica difícil examinar as condições ao redor é uma troca ruim. O usuário ainda precisa comparar a opção destacada com as demais.

Confira a página sem esse destaque. Se a oferta se tornar impossível de entender, a ênfase estava assumindo uma função explicativa grande demais. Os nomes dos planos, as descrições do público e as diferenças visíveis devem permitir uma escolha razoável antes de a cor estabelecer uma prioridade.

Adapte às telas estreitas sem esconder as diferenças

Empilhar os cards dos planos é simples; preservar a comparação é mais difícil. Quando cada plano ocupa uma tela separada, lembrar se o primeiro incluía determinado recurso passa a fazer parte da tarefa. Não suponha que um layout vertical organizado torne a comparação automaticamente fácil.

Para poucos planos, mantenha a mesma ordem de recursos nos cards empilhados. Para uma matriz mais longa, considere uma comparação estreita que permita selecionar dois planos ou uma tabela com rolagem horizontal e orientação clara. A escolha depende de os visitantes lerem principalmente um plano ou compararem vários valores específicos.

Uma sanfona pode reduzir o tamanho inicial da página, mas também esconde informações. Deixe as limitações essenciais e as condições de cobrança fora das seções recolhidas. Se a pessoa precisar expandir todos os planos para descobrir qual inclui acesso para convidados, a sanfona apenas distribuiu o mesmo esforço por mais interações.

Ao usar uma tabela de dados de verdade, preserve suas relações estruturais. O tutorial de tabelas do W3C explica como associar células de cabeçalho e de dados para tornar essas relações disponíveis às tecnologias assistivas. Uma grade de textos visualmente alinhados não é uma implementação equivalente. Tutorial do W3C sobre tabelas acessíveis.

Teste a versão estreita com uma comparação concreta: encontre a opção mais barata que comporte seis editores e vinte projetos ativos. Esses requisitos fictícios revelam se o layout preserva as informações necessárias para escolher. Verificar apenas se a página cabe na área de visualização não responde a essa pergunta.

Faça a ação corresponder ao próximo passo

O botão deve descrever a ação imediata que o visitante realmente pode realizar. Iniciar um teste, criar um espaço de trabalho gratuito, escolher uma assinatura paga e entrar em contato com vendas são etapas diferentes. Reutilizar “Começar” em todas elas produz uma fileira consistente de botões, mas deixa vaga a interação.

Coloque as condições importantes perto da ação correspondente. Se o teste exige um meio de pagamento, informe isso antes de a pessoa avançar. Se o plano para organizações começa com uma conversa, evite um botão que sugira um checkout imediato. O objetivo é criar uma expectativa correta, sem explicar todo o processo de compra dentro do card.

Considere também quem já tem uma assinatura. Uma tabela pública genérica pode levar essas pessoas a criar outra conta. Na implementação final, talvez seja necessário indicar o plano atual ou oferecer um caminho para as configurações da conta. Mesmo que o protótipo não implemente essa lógica, registre o estado para que o design não seja avaliado apenas para novos visitantes.

Não use um botão desabilitado para representar qualquer escolha indisponível. Se a elegibilidade depende de uma condição da conta, explique a condição. Um controle desabilitado sem explicação não permite saber se o impedimento é um limite, um erro temporário ou uma regra intencional.

Os cards capturados do GitHub tornam essa distinção concreta. Team oferece “Continue with Team”; Enterprise oferece tanto um teste quanto contato com vendas. O segundo card representa dois caminhos para o mesmo plano, e não dois recursos diferentes dele. Na revisão, siga cada caminho e confira quais informações o visitante precisa fornecer em seguida. Uma cor de botão consistente pode preservar o ritmo visual da página enquanto os rótulos explicam com precisão o próximo passo.

Revise o rascunho com tarefas de decisão

Uma revisão visual fica mais útil quando cada participante tem uma pergunta a responder. Dê a uma pessoa o cenário de trabalho individual e a outra o de uma equipe em crescimento. Peça que escolham um plano e expliquem quais informações determinaram a escolha. Esse raciocínio revela ambiguidades que um pedido aberto de feedback pode deixar passar.

No Fieldnote, uma tarefa pode envolver um pesquisador com dois projetos e vários convidados. Outra pode envolver seis editores; uma terceira, a necessidade de administração para toda a organização. Inclua um cenário que deva descartar o plano destacado. Sem isso, a revisão verifica apenas se a ênfase visual funciona, sem testar se a comparação sustenta outra conclusão.

Depois peça a cada pessoa que diga o valor cobrado imediatamente e o compromisso de cobrança assumido. Uma resposta incorreta continua sendo um problema, mesmo que as palavras certas estejam, tecnicamente, em algum lugar da página. Mova ou reescreva a explicação de acordo com o mal-entendido, em vez de acrescentar automaticamente mais uma nota de rodapé.

Revise a tabela também com um valor propositalmente difícil de acomodar: um nome de recurso longo, um recurso indisponível ou um plano com preço negociado. Não são exceções raras de layout que podem esperar pela implementação. Esses casos determinam se a estrutura comparativa consegue representar a oferta real.

No OpenDesign, uma prévia HTML pode apoiar essa revisão visual. Comentários podem apontar um grupo de preços enganoso ou uma linha de comparação que perde o alinhamento, e ajustes específicos de texto ou estilo podem melhorar a apresentação. Forneça os dados aprovados dos planos como contexto do design. Verifique os cálculos de cobrança, a elegibilidade das contas e o comportamento do checkout no fluxo implementado.

Antes de entregar a página para implementação, compare cada preço e limite visível com a ficha de referência. Confira as duas modalidades de cobrança, todas as ações de compra e o layout estreito. A tabela está pronta quando o leitor consegue explicar corretamente uma escolha adequada e suas condições, inclusive nos casos em que o plano destacado não é o certo.