Auditoria SaaS — Design Centrado em Receita (RCD)
Audite qualquer SaaS para que seu design sirva ao valor do usuário E à receita ao mesmo tempo. Esta skill transforma um corpo de conhecimento de design comportamental em uma auditoria repetível que revela pontos de melhoria concretos e priorizados — cada um vinculado a um viés ou princípio cognitivo nomeado, com uma correção recomendada.
Fonte e crédito. Estas estruturas sintetizam postagens e artigos públicos de Richard — "Design for startups" (@richardrx): Design Centrado em Receita, o Índice Canivete Suíço, as 4 fases de startup, precificação GBB, o filtro de funcionalidades e muito mais. A ciência subjacente é creditada a seus originadores (Kahneman & Tversky, Dan Ariely, Eugene Schwartz, Aronson & Mills, Nir Eyal, Fitts, Hick, Nielsen Norman Group). Aplique a persuasão eticamente — consulte Gate de ética.
Tese central
Design neutro não é "objetivo" — é omissão. Uma interface que não guia deliberadamente a atenção torna o caminho para o valor mais longo e a receita mais difícil. O bom design de produto nunca é valor do usuário ou receita do negócio; é ambos, por construção. Vieses cognitivos são as alavancas; o ciclo de vida do cliente é o mapa; a fase da startup define as prioridades.
O que esta skill faz
Dado um SaaS (um URL, capturas de tela, uma descrição, um código-fonte ou uma superfície específica como "nossa página de preços"), produzir uma auditoria: uma lista priorizada de pontos de melhoria, cada um com evidência, o viés/princípio que viola, uma correção concreta e uma estimativa de esforço×impacto. Funciona para uma auditoria completa ou focada (apenas precificação, apenas onboarding…). Para uma solicitação focada, ainda realize a Etapa 0–1 (fase + ICP) primeiro — elas reformulam tudo — depois pule para o estágio relevante.
Fluxo de trabalho da auditoria
Copie esta lista de verificação em suas notas de trabalho e preencha-a:
Progresso da auditoria:
- [ ] Etapa 0: Fase da startup calibrada (ARR/MRR + prioridades)
- [ ] Etapa 1: Clareza do ICP verificada
- [ ] Etapa 2: Ciclo de vida percorrido (Aquisição → Ativação → Retenção → Monetização → Métricas)
- [ ] Etapa 3: 9 princípios RCD pontuados
- [ ] Etapa 4: Lista de verificação mestra executada
- [ ] Etapa 5: Descobertas emitidas no modelo de relatório
Etapa 0 — Calibrar para a fase da startup → references/startup-phases.md
A falha mais comum é aplicar o conselho da fase errada (loops de crescimento de escala em um produto de sobrevivência). Estabeleça o ARR/MRR (ou a melhor estimativa) e defina o que importa:
| Fase | Faixa de ARR | Objetivo | Onde o design compensa |
|---|---|---|---|
| Sobrevivência | R$0–240k | Provar que alguém paga | Diferenciação visual, camada de confiança, velocidade até o valor |
| Tração | R$240k–1,2M | Sorte ou sistema? | Comportamental: onboarding, TTV, realização de valor, alavancas de upsell, controle de churn |
| PMF | R$1,2M–6M | Provar escala (usuários chegam, ficam, indicam) | Eficiência de retenção, margem |
| Escala | R$6M+ | Competir por atenção | Otimização contínua + defensabilidade (efeitos de rede, fosso de dados) |
Etapa 1 — Verificar a clareza do ICP → references/acquisition.md
Tudo a jusante depende de um ICP nítido e mal atendido que: (a) sinta a dor com peso real (a perda quando não resolvida é grande), (b) seja grande o suficiente (TAM bottom-up), (c) possa pagar o ticket que sua economia unitária precisa, (d) tenha fit com o fundador. Um ICP vago ("qualquer um que queira o produto") torna cada descoberta posterior ambígua e erros não diagnosticáveis. Se o ICP não for claro, essa é a descoberta nº 1.
Etapa 2 — Percorrer o ciclo de vida
Para cada estágio, leia a referência correspondente + a seção correspondente da lista de verificação e registre as lacunas.
| Estágio | Leia | Procurando por |
|---|---|---|
| Aquisição | references/acquisition.md | Hero falha no teste de 5 segundos, jargão, CTA genérico, sem/com pouca prova, incompatibilidade de consciência, LP que não qualifica |
| Ativação / Onboarding | references/onboarding-activation.md | Nenhum momento-aha definido, TTV lento, dashboard vazio, tour passivo, atrito administrativo, lacuna de jornada |
| Retenção / Churn | references/retention-churn.md | Dívida de expectativa, churn por jargão, fluxo de cancelamento morto, modelo de trabalho único, comunicações reativas, baixa adoção de funcionalidades, nenhum loop de hábito, nenhum fosso |
| Monetização / Expansão | references/pricing-expansion.md | Sem isca/âncora, >4 planos, gratuito ancorado em zero, defaults ruins, caminho de upgrade fraco, upsell que interrompe em vez de atender a um limite |
| Métricas / Experimentação | references/metrics-experimentation.md | Métricas de vaidade, testes A/B com poder baixo, LVT combinado, LTV:CAC inflado, matemática de balde furado ignorada |
| Estratégia de produto / design | references/product-design-strategy.md | Excesso de funcionalidades (Índice Canivete Suíço), sem filtro de funcionalidades, dashboard poluído, refatorações apenas cosméticas |
Etapa 3 — Pontuar os 9 princípios RCD → references/revenue-centric-design.md
Avalie cada princípio como Passa / Parcial / Falha com uma frase de evidência. Este é o scorecard transversal.
Etapa 4 — Executar a lista de verificação mestra → checklists/master-audit-checklist.md
O detector de lacunas abrangente e ciente da fase. Cada conceito do corpus aparece aqui. Cada item é uma verificação sim/não marcada com seu viés/princípio e um ponteiro para a referência da correção.
Etapa 5 — Emitir descobertas → assets/audit-report-template.md
Preencha o modelo: fase + veredito do ICP, tabela de descobertas (área · descoberta · evidência · viés/princípio · severidade · correção · esforço×impacto), top-5 vitórias rápidas, scorecard RCD.
Navegação — qual arquivo responde a qual pergunta
| Pergunta | Arquivo |
|---|---|
| "O que cada princípio RCD significa e como verificá-lo?" | references/revenue-centric-design.md |
| "Qual viés se aplica aqui / qual é o estudo por trás dele?" | references/cognitive-biases.md |
| "A landing page / hero / copy / CTA / posicionamento estão corretos?" | references/acquisition.md |
| "Por que os trials não ativam? Qual padrão de onboarding se encaixa?" | references/onboarding-activation.md |
| "Por que as pessoas estão cancelando? Como reter e construir um fosso?" | references/retention-churn.md |
| "Como a precificação/tiers/defaults/upgrades devem ser estruturados?" | references/pricing-expansion.md |
| "Esta métrica ou experimento é confiável?" | references/metrics-experimentation.md |
| "Muitas funcionalidades? Dashboard poluído? O que cortar?" | references/product-design-strategy.md |
| "O que devo priorizar na minha fase?" | references/startup-phases.md |
| "Me dê a lista de verificação completa." | checklists/master-audit-checklist.md |
Como escrever recomendações
- Seja específico e quantificado. "Substitua o título do hero 'A plataforma completa de produtividade' por um que nomeie o ICP + resultado, por exemplo 'Controle de comandas para oficina mecânica'" — não "melhore o título."
- Vincule cada descoberta a um viés ou princípio nomeado (por exemplo, Ancoragem, Aversão à perda, RCD #6 Defaults). O "porquê" é o que torna uma recomendação persuasiva e confiável.
- Respeite a fase. Não recomende otimização de estágio de escala para um produto de sobrevivência. Na sobrevivência, priorize diferenciação/confiança/velocidade até o valor; na tração, onboarding comportamental e churn; depois, eficiência de retenção e fosso.
- Prefira correções de alta alavancagem a cosméticas. Estrutura de preços, defaults e a sequência de onboarding movem métricas muito mais do que a cor de um botão. (1% melhor no preço ≈ 8–11% mais lucro vs ≈2% de 1% melhor na aquisição — ProfitWell.) Sinalize "repintura" disfarçada de "refatoração."
- Quantifique o vazamento quando puder. Use a matemática de balde furado e LTV de coorte em
references/metrics-experimentation.mdpara traduzir um ponto de churn em R$.
Gate de ética
A persuasão aqui é para clareza e impulso, não coerção. Reforce estes ou a auditoria se torna um manual de padrões obscuros:
- Defaults devem ser eticamente defensáveis. Uma caixa pré-marcada que prende usuários em gastos é isca de churn e risco de ReclameAqui/reembolso — recomende defaults que correspondam ao que um usuário informado do ICP escolheria.
- Promessa deve igualar prova (RCD #4). Nunca recomende uma alegação que o produto não pode demonstrar — isso cria dívida de expectativa e causa churn.
- Escassez/urgência deve ser real. Recomende escassez honesta apenas (limites verdadeiros, prazos reais), nunca contagens regressivas fabricadas.
- Atrito que qualifica ≠ atrito que prende. Adicione atrito para qualificar a intenção ou aprofundar o compromisso; nunca para obstruir o cancelamento.
Referência rápida de benchmarks
Use como marcos aproximados (principalmente SaaS; alguns dados dos EUA — ajuste para o mercado). Fontes em references/.
| Métrica | Fraco | OK | Forte | Nota |
|---|---|---|---|---|
| Taxa de ativação | <20% | 30–37% | 40%+ | <20% = problema estrutural de onboarding/produto |
| Retenção D7 | <10% | 10–15% | >30% | |
| Tempo até o Valor (TTV) | dias | ~1d12h (mediana) | <5 min (topo) | Userpilot, 547 empresas |
| NRR (B2B) | <100% | ~100% | >110% | Separa crescimento de funil furado |
| Trial→pago, com cartão vs sem cartão | 8,9% (sem cartão) | — | 31,4% (com cartão) | Chartmogul 2026, EUA, 200 produtos |
| LTV:CAC | <3:1 | 3:1 | >3:1 | Recalcular por coorte; combinado superestima em 30–50% |
| Índice Canivete Suíço | <0,3 | — | ≥0,3 | funcionalidades usadas por >40% dos ativos/30d ÷ total |
| Níveis de preço | 1 ou 5+ | — | 3 (2–4 máx.) | Lei de Hick; isca precisa de um plano intermediário |
| Ponto ideal de avaliações | 5,0 (parece falso) | — | 4,2–4,5★ | Northwestern |
Ao citar um número, atribua a fonte e observe que é um benchmark, não uma garantia.