Reconstruir a landing page do Daily Sudoku depois do lançamento na Play Store

O app foi publicado na Google Play em 10 de julho. Quatro dias depois, a landing page ainda dizia “Out now” ao lado de um mockup genérico, o JSON-LD afirmava suporte a iOS e Web que não existiam, e o botão de download ficava abaixo da dobra num laptop. A página não estava quebrada. Apenas não estava fazendo o trabalho dela.

O que segue é o que mudamos numa sessão — não uma reconstrução do zero, mas uma nova versão da home existente, mantendo a mesma rota, a mesma estrutura de i18n e o mesmo sistema de layout compartilhado. A sessão inteira foi feita em pair programming com um assistente de IA, e a revisão de design passou pelo Impeccable, uma ferramenta open-source de crítica e iteração de design para interfaces frontend.

O problema não era estético, era de honestidade

A página antiga parecia boa. Fundo creme quente, headline em Fraunces, roxo de destaque que casava com o jogo. Mas um visitante decidindo se instalava tinha que lidar com três coisas que não eram verdade:

1. O JSON-LD declarava operatingSystem: "iOS, Android, Web". O único botão de loja apontava para a Google Play. Um usuário de iPhone podia achar que o app existia para ele e bater num beco sem saída.
2. A barra de prova dizia “5 / Níveis de dificuldade”, “Offline / Jogue sem sinal”, “Salvo / Retome qualquer tabuleiro”. Esses são recursos, não sinais de confiança. Eles ocupam o espaço mais valioso da página — logo depois do hero — sem reduzir o risco de instalar.
3. O headline do hero estava hardcoded em inglês dentro do componente Astro. A versão em português tinha um headline diferente no arquivo de conteúdo, mas o componente ignorava.

Cada um é pequeno. Juntos, fazem a página parecer um placeholder que ninguém revisou depois do lançamento.

O que mantivemos e o que removemos

A página já tinha a estrutura certa: BaseLayout, Header e Footer compartilhados de @apps/site-ui, conteúdo bilíngue em src/content/landing/ e um schema em content.config.ts que validava cada campo. Mantivemos tudo isso.

Duas seções não justificavam o espaço:

• “Como funciona” — três passos numerados (Baixar, Escolher dificuldade, Jogar offline). O template genérico de 3 passos de landing. Ninguém precisa de instruções para instalar um app grátis.
• “Fundador” — uma seção sobre o estúdio. Pertence ao site institucional, não a uma página de conversão onde o trabalho é fazer alguém tocar no botão da Play Store.

Mantemos o FAQ porque ele responde perguntas reais de pré-instalação: jogo offline, progresso salvo, suporte a iniciantes, restauração de créditos. A resposta sobre créditos é honesta para uma landing de jogo mobile, e essa honestidade faz mais trabalho que uma bio de fundador.

Screenshots são prova, não decoração

A página antiga usava um único app.png placeholder. Pegamos dois screenshots reais do jogo rodando — um do tabuleiro em andamento, um da tela home — e os colocamos no mockup do hero e numa nova seção de showcase.

O mockup de celular é o componente assinatura: frame quase preto, cantos arredondados grandes, screenshots reais. Se uma seção pode usar um screenshot real, deve, antes de qualquer painel abstrato ou grade decorativa. A identidade visual do jogo — a direção Editorial Ink que descrevemos em dando a um app de Sudoku uma direção de arte de verdade — chega ao site pelos mesmos tokens semânticos.

Também corrigimos o alt text. Os dois screenshots usavam o mesmo ariaLabel do schema de conteúdo. Adicionamos um campo homeAriaLabel para cada screenshot descrever o que realmente mostra. “Tela inicial do Daily Sudoku com ações para continuar, novo jogo, desafio diário e estatísticas” é mais útil que um genérico “Captura do Daily Sudoku”.

O header estava mentindo sobre a própria largura

O componente Header compartilhado renderiza com container-shell, que limita a largura do conteúdo e centraliza. Correto para a marca e os links de navegação. Mas nós aplicamos o fundo, a borda e a sombra diretamente em body > header, então a faixa visual parava nas bordas do container em vez de cruzar a viewport.

A correção foi um pseudo-elemento ::before com width: 100vw atrás do conteúdo. O conteúdo do header continua containerizado; o tratamento visual vai de ponta a ponta. Esse é o tipo de bug que parece quebrado numa tela grande mas passa no mobile, onde o container quase preenche a viewport.

Toggle de tema e header sticky

O site institucional da Sunstone Apps já tinha um toggle claro/escuro no header. O site do Daily Sudoku não. Reusamos os mesmos ThemeScript e ThemeToggle de @apps/site-ui, com uma chave de localStorage própria.

O CSS também precisou mudar. O tema escuro antigo era controlado por @media (prefers-color-scheme: dark), o que significa que o toggle brigaria com a preferência do sistema e perderia. Substituímos cada regra prefers-color-scheme por :root[data-theme="dark"] para o toggle realmente controlar a paleta.

O header agora é sticky, com fundo translúcido, backdrop-filter: blur(18px) (prefixo -webkit- para Safari/iOS) e barra ::before full-bleed. O toggle fica no slot de actions do header, então acompanha o usuário pela página em vez de sumir depois do hero.

O ciclo de crítica

Rodamos a crítica de design do Impeccable depois do primeiro passe. Impeccable é uma ferramenta open-source que pontua interfaces frontend contra heurísticas de Nielsen, roda um detector determinístico de anti-patterns em CSS/HTML e pode injetar um overlay ao vivo no browser para inspeção visual. Pontuação: 29/40 — base visual forte, gaps de conversão e clareza.

O assistente de IA gerou o CSS e o componente iniciais, mas foi o ciclo de crítica que pegou o que a geração pura não pegou:

• A escala do headline do hero empurrava o CTA para baixo da dobra num laptop de 900px. Baixamos o teto do clamp() de 7.8rem para 6rem.
• A barra de prova repetia as mesmas promessas do hero, do showcase e das features. Reformulamos de recursos para prova: “Google Play / App Android publicado”, “Offline / Puzzles disponíveis”, “Sem conta / Comece sem cadastro”.
• O JSON-LD dizia iOS, Android e Web. Mudamos para Android e adicionamos um item de FAQ: “Onde posso baixar Daily Sudoku? — Disponível para Android na Google Play. A versão iOS não está listada nesta página hoje.”
• A cor do texto muted #78716C media 4.2:1 de contraste contra o fundo quente — abaixo de WCAG AA. Escurecemos para #5F5650, que mede 6.4:1.

A crítica também marcou o touch target do toggle de tema em 40x40px. O mínimo é 44x44. Corrigimos no componente compartilhado, então o site da Sunstone Apps ganhou a correção de graça.

Depois da crítica, rodamos o comando de layout. O problema principal era ritmo: cada seção tinha a mesma estrutura, e o grid de features era seis cards idênticos.

Introduzimos um layout bento para as features. O primeiro card é maior, ocupa duas colunas e duas linhas, e tem um motivo sutil de grade de Sudoku no canto. Os cards restantes preenchem ao redor. Quebra o padrão de “grid de cards idênticos” sem abandonar o sistema de grid.

Também adicionamos um CTA secundário no hero. O botão primário vai para a Google Play. O secundário — “Ver detalhes práticos” / “Read practical details” — rola até o FAQ. Visitantes que não estão prontos para instalar podem responder suas perguntas sem sair da página.

Avisos de compatibilidade de browser que importavam

Dois avisos do painel de compatibilidade do Edge DevTools levaram a correções reais:

1. backdrop-filter sem prefixo -webkit-. Safari e iOS Safari precisam da versão prefixada. Adicionamos em todo lugar onde backdrop-filter aparece — no site do Sudoku, no site da Sunstone Apps e no contract.css compartilhado.
2. color-mix() sem fallback. Chrome antes de 111 não suporta color-mix(). Adicionamos uma declaração de fallback antes de cada chamada de color-mix() no contrato compartilhado e no CSS do site. O fallback usa um valor de token sólido; a declaração moderna o substitui em browsers que suportam color-mix().

Um aviso que não corrigimos: o color-mix() na regra .eyebrow do contrato compartilhado. O Edge Tools continuava acusando mesmo com fallback. Removemos o color-mix() dessa regra e mantivemos o token sólido. A diferença visual é irrelevante, e o aviso sumiu.

Como a IA moldou a sessão

A reconstrução inteira foi feita em pair programming com um agente de código baseado em Claude. A IA gerou a reescrita inicial do componente Astro, o sistema CSS, as adições de schema e o copy bilíngue. Um humano revisou a saída no browser, pegou o bug de largura do header visualmente e apontou os links de navegação faltando e os avisos de compatibilidade do Edge DevTools.

A parte mais útil não foi a geração — foi o ciclo avaliar-depois-corrigir. A IA rodou os comandos critique, layout, clarify e polish do Impeccable sequencialmente, cada um consumindo o snapshot anterior como backlog. Esse ciclo encontrou a falha de contraste, o touch target, o desalinhamento do JSON-LD e a copy repetida da trust bar. Sem ele, a página teria saído com visual polido mas mentindo sobre a plataforma e falhando WCAG AA no texto corrido.

A IA também validou cada mudança programaticamente: Playwright mediu overflow, posição do CTA, estado do toggle de tema e persistência do data-theme em larguras mobile e desktop. É mais rápido que QA manual para regressões de layout, embora não substitua checar a página num celular de verdade.

As lições de indexação e metadata desta sessão se conectam com trabalho anterior que documentamos em checklist de indexação do Google para sites Astro no Cloudflare Pages — as correções de JSON-LD e alinhamento de plataforma aqui são consequência direta do que aquele checklist nos ensinou.

O que ainda mudaríamos

A página está melhor, mas não está pronta. A crítica levantou perguntas que não respondemos:

• O mockup do hero deveria mostrar o momento de “continuar jogo salvo” em vez de só o tabuleiro? Esse é o maior diferencial, e o screenshot atual mostra um tabuleiro em andamento, não o fluxo de retomada.
• O que um jogador que já tem três apps de Sudoku aprende em 10 segundos que faz este valer a pena instalar? A página ainda depende de promessas básicas: offline, progresso salvo, interface calma. Uma comparação ou uma seção “por que este Sudoku” poderia responder.
• A estética premium deveria parecer um caderno calmo de puzzle ou um produto sério de treino mental diário? A resposta muda densidade tipográfica, estratégia de prova e ritmo de CTA.

Essas perguntas são para o próximo passe. A página atual é honesta sobre a plataforma, o CTA é visível num laptop, os screenshots são reais e o toggle de tema funciona. Isso é um salto real de “não está quebrada” para “está fazendo o trabalho.”