Direção Visual do Playbook Guiado

Documento canônico: visuals/playbook-visual-direction.md

Status: v2 publicada para #54 + rotas por audiencia #53 + ofertas #81 + biblioteca visual #83 Destino: playbook.techhuman.com.br Fonte: Docs Tech Human + regra de donos canonicos

Tese

Sim: o Playbook deve ser muito mais visual, facil e memoravel que o Docs. O Docs guarda a integra; o Playbook transforma a estrategia em entendimento.

O objetivo visual nao e impressionar por efeito. E fazer uma pessoa do comercial, time interno, parceiro ou board entender em minutos:

quem e dono de cada parte;
o que e empresa, produto, metodo e operacao;
como o cliente entra;
quando Tech Human vira Trustyu;
como JARVIS, Forge, Score e NeedyU.ai se conectam sem virar bagunca.

Stack recomendada

Para a versao premium do Playbook, a melhor arquitetura e converter 07-playbook-site para uma app moderna estatica:

Camada	Recomendacao	Por que
Framework	Next.js App Router com static export	Mantem deploy simples no GitHub Pages e permite evolucao
Linguagem	TypeScript strict	Reduz erro em manifestos e componentes
UI	shadcn/ui + Radix	Componentes acessiveis, editaveis e premium
Estilo	Tailwind CSS + tokens do Brand Kit	Consistencia e velocidade
Icones	lucide-react	Padrao visual limpo
Animacao	Motion / Framer Motion	Sequencias suaves, estados e transicoes
Mapas interativos	React Flow	Ecossistema, ownership e handoffs
Dados visuais	D3 quando houver hierarquia, sankey ou matrix	Visualizacoes realmente explicativas
Diagramas Docs	Mermaid	Bom para Docs, nao como experiencia premium principal
Conteudo	Manifestos TypeScript/MDX curados	Evita copiar MD integral no Playbook

Nao precisamos instalar tudo no primeiro PR. A regra e instalar apenas quando um componente exigir.

Experiencias visuais prioritarias

Visual	Objetivo	Formato recomendado
Mapa de donos canonicos	Mostrar quem e dono de Tech Human, Trustyu, JARVIS, Score, Forge e NeedyU.ai	React Flow com agrupamentos por dono
Arquitetura comercial completa	Mostrar BMAI, Portas A/B/C, execucao, memoria, pessoas, governanca e Trustyu	Fluxo visual por etapas
Camadas de conteudo	Diferenciar site, Playbook, Docs e repo	Scroll narrative com cards fixos e linhas de relacao
Jornada do cliente	Mostrar dor -> porta -> entrega -> governanca -> Trustyu	Timeline horizontal responsiva
Flywheel	Mostrar loop de caixa, aprendizado e upside	Diagrama animado por passos
Matriz empresa/produto/metodo	Evitar venda errada	Tabela visual filtravel
Caminhos por audiencia	Comercial, equipe, parceiros, founder/board, tecnico, compliance, produto, THunting e conteudo	Hub + rotas dedicadas de 5 e 30 minutos

Principios de UX/UI

O primeiro viewport deve explicar a arquitetura em uma frase e um visual.
Toda animacao deve revelar relacao ou sequencia; nada de movimento decorativo.
O Playbook deve ter leitura progressiva: 5 minutos, 30 minutos e leitura profunda no Docs.
Cada bloco deve ter link para a fonte integral no Docs.
Cards sao permitidos para itens repetidos; secoes nao devem parecer pilhas de cards.
Evitar paleta monotematica: base escura Tech Human, lime como sinal de acao, cores secundarias apenas para diferenciar negocios/camadas.
Textos curtos no visual; detalhes ficam em tooltips, accordions ou links para Docs.

Direcao visual executiva

Os materiais executivos derivados do Playbook — decks, one-pagers, posts e capas — devem seguir a direcao definida em ../03-market-materials/business-plan/executive-visual-language.md:

pessoa real em primeiro plano;
estatistica ou conceito grande;
fundo lime ou branco de alto contraste;
copy curta e provocativa;
CTA unico;
fonte clara para qualquer dado usado.

Essa direcao vale especialmente para materiais de board, vendas e conteudo executivo. O Playbook em si continua priorizando mapas, fluxos e caminhos de entendimento.

Estrutura inicial do Playbook

1. O ecossistema em uma frase
2. Mapa visual: empresa, produto, metodo, operacao, SaaS e venture builder
3. Arquitetura comercial: BMAI -> Portas A/B/C -> execucao -> memoria -> pessoas -> governanca
4. Donos canonicos: quem documenta profundamente cada parte
5. Jornada do cliente: onde cada oferta entra
6. Quando vira Trustyu: dor repetivel -> Forge -> SaaS/equity/exit
7. Caminhos por audiencia
8. Biblioteca de links para Docs

Relacao com `visuals/legacy`

Os visuais antigos continuam como referencia historica, mas a partir da v2 o Playbook passa a ter componentes nativos em 07-playbook-site/src/components/playbook-visuals.tsx. O legado nao deve ser publicado diretamente nem tratado como fonte final.

Legado	Reaproveitamento v2	Decisao
`legacy/ecosystem-map.html`	Mapa React Flow do ecossistema	Manter como mapa de entidades, donos e handoffs
`legacy/customer-journey.html`	Timeline E2E	Mostrar cliente sente, Tech Human entrega e decisao por etapa
`legacy/flywheel.html`	Flywheel operacional	Conectar caixa, aprendizado, memoria, pessoas e upside Trustyu
`legacy/5-niveis.html`	Escada de risco	Ligar nivel de uso, aprovacao, Trust Score e Governanca
`legacy/positioning.html`	Matriz de venda segura	Transformar posicionamento em guardrail de venda
`legacy/messages.html`	Caminhos por audiencia	Alimentar #53 com rotas, scripts e treinamento
`legacy/trust-score.html`	Pagina futura de oferta/score	Revisar nomenclatura Trust Score / Trustyu Score antes de publicar

Entrega v2 da issue #54

Publicada no Playbook:

roteador visual BMAI -> Portas A/B/C -> cadeia operacional;
infograficos por porta comercial;
escada de risco dos 5 niveis;
timeline E2E da jornada do cliente;
flywheel operacional;
matriz de venda segura;
mapa de reaproveitamento dos visuais legacy.

O criterio de aceite passa a ser validado tambem pelo export estatico do Playbook: npm run validate em 07-playbook-site verifica que os textos centrais da biblioteca visual entram no HTML gerado.

Entrega da issue #53

legacy/messages.html deixa de ser apenas uma referencia visual e passa a alimentar uma experiencia nativa em /audiencias/. A nova estrutura evita que o Playbook dependa de uma unica pagina longa e organiza a leitura por papel:

hub por categoria: venda, operacao e rede;
paginas dedicadas por audiencia;
roteiro de 5 minutos;
roteiro de 30 minutos;
versao falada para reuniao e treinamento;
FAQ/objecoes por audiencia;
lista de frases que nao devem ser usadas;
links profundos para Docs.

As estatisticas e promessas comerciais antigas do legado nao devem ser reaproveitadas sem fonte atualizada. A nova versao prioriza afirmacoes estruturais, fronteiras de arquitetura e decisao comercial segura.

Entrega da issue #81

A camada comercial por oferta passa a viver em ../03-market-materials/commercial-kit/offers/. O Playbook deve traduzir esses materiais em uma rota guiada em /ofertas/:

matriz dor -> porta -> oferta -> proximo passo;
cards por oferta com sinal, promessa, CTA e guardrail;
links profundos para os one-pagers no Docs;
separacao clara entre venda Tech Human e handoff Trustyu.

Entrega da issue #83

A direcao visual executiva sai de uma referencia dentro do Business Plan e passa a ter biblioteca propria em ../03-market-materials/executive-visual-library/. O Playbook traduz essa biblioteca em /visual/, com uma leitura mais simples para equipes que vao criar decks, one-pagers, posts e materiais de board.

Essa camada nao substitui o Playbook principal. Ela define como os materiais executivos devem parecer quando saem do ecossistema para uma reuniao, uma proposta ou uma peca publica:

pessoa real como primeiro sinal humano;
estatistica, decisao ou pergunta como protagonista;
fundo lime, branco ou preto com alto contraste;
copy curta e sem jargao;
CTA unico;
fonte, data e contexto em toda estatistica;
proibicao explicita de robo, holograma, circuito e estetica generica de IA.

Criterio de aceite para os novos visuais

Um visual so entra no Playbook se responder uma pergunta real:

“O que e isso?”
“Quem e dono?”
“Quem vende?”
“Quando aparece?”
“Para onde encaminha?”
“Onde leio a integra?”

Se o visual nao responder nenhuma dessas perguntas, ele nao deve entrar.