Pular para o conteúdo
Voltar para trabalhos

SOS Beleza Absoluta — um style guide posto à prova

Construir um sistema de estilos próprio sobre o Braip Foundations e usar uma landing page de quatorze seções em três breakpoints como teste de resistência dele.

Papel
Style guide e biblioteca de variáveis · UI e design responsivo · direção de arte e composições de produto
Período
Março de 2026
Plataforma
Landing page responsiva · Figma
Hero da landing page SOS Beleza Absoluta — modelo sorrindo com a mão no cabelo ao lado do título "Recupere sua autoestima e beleza natural", sobre fundo bege claro.

Em resumo

Problema
Uma landing page longa nasce como um monte de decisões soltas — cada seção inventa seu próprio tom de bege, sua própria escala de título, seu próprio espaçamento. Em quatorze seções e três breakpoints, isso vira dívida antes de virar página.
O que eu fiz
Construí um style guide dedicado ao projeto — Color Styles, Text Styles e uma biblioteca de variáveis de cor e tipografia herdando o Braip Foundations — e só então desenhei a página, tratando cada seção como um teste de cobertura do sistema.
Resultado
Quatorze seções em desktop, iPad e mobile sobre dezessete componentes próprios, sem cor ou tamanho de texto avulso. Os depoimentos e os valores de produto ficaram pendentes de conteúdo do cliente, e estão declarados como tais.

Contexto

SOS Beleza Absoluta é um protocolo de beleza de dois produtos: um encapsulado com vitaminas de A a Z e um óleo de babosa de uso tópico. A promessa é de dentro para fora — nutrição interna sustentando o resultado, ação externa dando o brilho imediato. O produto se vende por uma landing page longa, do tipo que responde toda objeção antes de pedir o cartão.

A copy veio pronta do time de marketing. A estrutura de argumento — dor, protocolo, diferencial, linha do tempo, prova social, garantia, oferta, FAQ — já estava decidida quando o arquivo chegou em mim. O que estava em aberto era tudo que vem depois: como isso se parece, como se comporta em três larguras de tela, e o que impede que as quatorze seções pareçam quatorze páginas diferentes.

O problema

Landing page longa tem um modo de falha específico e chato: ela apodrece por adição. A seção 3 pede um bege um pouquinho mais quente que o da seção 2. A seção 7 precisa de um título entre os dois tamanhos que existem, então nasce um terceiro. Ninguém toma uma decisão ruim — cada uma delas é razoável isolada. No fim, você tem onze beges, seis escalas de título e nenhuma forma de mudar a marca sem abrir seção por seção.

Multiplique por três breakpoints. Desktop com 1768 px de largura, iPad com 1024, mobile com 480 — e uma página que, no mobile, tem 15.302 px de altura. É aí que a decisão avulsa cobra: cada valor solto vira três valores soltos.

Então o problema real não era "desenhar uma landing page". Era: existe um conjunto pequeno o bastante de decisões visuais que cobre uma página inteira de venda, sem exceção? A página virou o experimento que responde isso.

Meu papel

  • Style guide do projeto: Color Styles, Text Styles e biblioteca de variáveis de cor e tipografia, herdando o Braip Foundations
  • Biblioteca de componentes própria da página — dezessete componentes e component sets
  • UI das quatorze seções e adaptação para desktop, iPad e mobile
  • Direção de arte e composições de produto

O que não foi meu: a copy inteira, incluindo headline, bullets, FAQ e depoimentos, veio do time de marketing. A arquitetura de argumento da página também. Eu recebi o que a página precisava dizer e decidi como ela diz.

Processo

O trabalho começou pelo avesso do óbvio: antes de qualquer tela de alta fidelidade, montei os wireframes das três larguras com a copy que existia. O changelog do arquivo registra essa versão como 1.0, em 20 de março de 2026 — "versão somente com a copy desenvolvida até o momento". Só depois do retorno do time é que parti para arte e imagens.

Entre o wireframe e a arte entrou o style guide. Ele não é um artefato entregue ao cliente; é infraestrutura minha, feita para que a fase seguinte fosse rápida e para que a página não pudesse divergir de si mesma.

O Braip Foundations deu a base — o design system em que eu já trabalhava a arquitetura de tokens. Isso encurtou a parte cara: eu não recomecei a escala de cor nem os fundamentos de tipografia do zero, herdei e especializei. Vale dizer isso com todas as letras, porque é o motivo de um style guide de projeto ter cabido no cronograma de uma landing page.

Decisões-chave

O sistema antes da primeira tela

Color Styles, Text Styles e uma biblioteca de variáveis vieram antes da seção 1. A regra que me impus foi simples e desconfortável: nenhuma cor ou tamanho de texto entra numa seção sem estar no sistema. Quando uma seção pedia algo que não existia, a pergunta não era "qual valor uso aqui", era "essa necessidade é real o suficiente para virar decisão do projeto?".

Na maior parte das vezes, não era — e a seção se resolvia com o que já havia. Foi assim que a paleta ficou pequena: ela é pequena porque foi obrigada a ser, não porque eu fui disciplinado no momento de cada tela.

Dezessete componentes em vez de quatorze seções

A página não é feita de seções, é feita de peças. Produto, Button, Card Modal, Timeline Text, FAQ, Card/text image, Image/Flow, Promo bar, Picture/Sanfona, Footer responsive — cada um com suas variantes.

Isso muda o custo do responsivo. Adaptar quatorze seções para três larguras é quatorze problemas resolvidos três vezes. Adaptar dezessete componentes é dezessete problemas resolvidos uma vez, e as seções herdam. O carrossel de mobile, por exemplo, é um component set próprio — a seção de protocolo não sabe que virou carrossel, ela só compõe a peça certa.

Desenhar o tempo como parte do produto

Este é o ponto onde o sistema encostou no conteúdo. O protocolo só entrega com constância — as primeiras duas semanas são de adaptação, o primeiro mês traz queda menor, o terceiro é quando outras pessoas percebem. Uma página que só mostra "antes e depois" mente sobre isso.

A seção de linha do tempo existe para tornar a espera visível em vez de escondê-la, e ela usa um componente próprio, Timeline Text, com variantes por marco. Cada estágio tem o mesmo peso tipográfico dos outros — nenhum é destacado como "o momento em que funciona". É uma decisão de sistema com efeito de honestidade: sem hierarquia entre os marcos, a página não consegue insinuar que o resultado chega antes do que chega.

Três ritmos, não três preços

A seção de oferta apresenta três planos — três meses, dois meses e um mês, com óleos inclusos conforme o plano. A tentação padrão é ordenar por preço e destacar o do meio. Preferi tratar os planos como durações de tratamento, coerente com o argumento que a página vinha construindo há dez seções: o produto é tempo, não frasco.

Os três cards compartilham o mesmo componente e a mesma composição de produto; o que muda é a quantidade de tempo comprada. O selo de desconto é o mesmo em todos os três, o que também foi uma decisão de sistema — variar o selo criaria a impressão de que um plano é objetivamente melhor, e essa não é uma afirmação que eu tinha como sustentar.

Resultado

O que foi entregue, de fato:

  • Landing page completa em três breakpoints — desktop, iPad e mobile — com quatorze seções
  • Style guide do projeto: Color Styles, Text Styles e biblioteca de variáveis de cor e tipografia
  • Biblioteca de dezessete componentes e component sets próprios, com variantes de breakpoint
  • Composições de produto e direção de arte das seções
  • FAQ estruturado sobre a base regulatória informada pelo cliente (RDC 240/2018)

Nenhuma cor ou tamanho de texto ficou fora do sistema — que era a pergunta que o projeto se propôs a responder, e a resposta foi sim.

Sobre resultado de negócio: não tenho. A página foi entregue como arquivo de design; números de conversão, se existem, ficaram com o cliente. A frase "+100K de autoestima revitalizadas" que aparece na seção de prova social é um claim fornecido pelo cliente e não é uma métrica que eu tenha verificado ou que este case reivindique.

O que ficou pendente

Registrado no próprio changelog do arquivo, como dependência externa:

  • Depoimentos. A seção de prova social tem três depoimentos escritos e cards ainda em placeholder, com texto reciclado de outra seção. É por isso que não há nenhuma imagem dessa seção aqui — fotografar um placeholder seria vender uma seção que não existe.
  • Valores de produto. Os preços em tela funcionam como estrutura, mas ainda dependiam de confirmação do cliente.
  • Uma inconsistência de copy que passou. A seção de garantia tem o título "Desafio 90 dias" e, no corpo, "caso você realize o desafio de 30 dias". Duas datas diferentes na mesma seção. É erro de revisão, e o fato de estar aqui é o registro de que não peguei a tempo.

O que eu faria diferente

Desenhei os cards de depoimento antes de existir um depoimento real. Criei o componente a partir de um formato que imaginei — uma citação curta, um nome, cinco estrelas — e preenchi com placeholder para seguir o layout.

O problema aparece quando os depoimentos reais chegam: os três que o time já tinha escrito são longos, narrativos, com um começo de medo e uma virada. Não são citações curtas. São histórias. O card que desenhei aperta esse conteúdo até ele perder exatamente a parte que convence.

O certo era o inverso: pedir um depoimento real antes de desenhar qualquer coisa, desenhar o card em cima dele, e só depois generalizar para os outros. Fiz o movimento na ordem confortável em vez da ordem correta, e a seção que mais depende de conteúdo real é justamente a que foi desenhada sem ele.

Os resultados estão descritos de forma qualitativa: não tenho autorização para divulgar as métricas de negócio destes projetos.

Próximo case studyCreators Figma Kit — temas de marca por variável