Vídeo de lançamento para um produto de software
Produza um vídeo de 30 a 60 segundos que faça alguém entender e desejar o produto.
A decisão que molda tudo: reconstruir, não gravar
As gravações de tela são problemáticas. A latência real é tempo morto. Retakes são caros. Você não pode segurar um frame, não pode desacelerar um momento e acelerar outro, e não pode recortar com precisão sem encontrar compressão granulada.
Portanto, reconstrua a interface como React orientado a frames dentro do Remotion. Cada visual é uma
função pura de useCurrentFrame(). A digitação aparece em uma curva exata, um
estado de carregamento é resolvido na batida, e um retake custa apenas um número.
Isso só é razoável porque você pode ler o código real do produto (se local) ou o DOM+CSS (se hospedado) e reproduzi-lo fielmente. Faça isso — pegue os nomes de classe reais, as cores reais, o texto real. A reconstrução deve ser indistinguível de uma gravação, e depois melhor.
Quando gravar ao invés disso: 3D pesado, conteúdo de vídeo dentro do produto, uma
superfície Canvas/WebGL ou um aplicativo desktop nativo. Se uma superfície específica não puder ser
reconstruída, grave apenas essa superfície e componha-a com <OffthreadVideo>.
Fase 1 — Entender o produto
Leia references/discovery.md antes de iniciar esta fase. Ele cobre
o procedimento de navegação e triagem, a conversa sobre credenciais e como extrair
um sistema de design de um site ao vivo.
Versão resumida:
- Dada uma URL: navegue por ela. A página inicial primeiro (ela mostra como eles se posicionam), depois o aplicativo em si. Descubra qual trabalho o produto faz e para quem.
- Dado um repositório local/servidor de desenvolvimento: leia o código. Muito mais rico — você obtém os componentes reais, os tokens de tema reais, os dados de semente reais.
- Faça a triagem das páginas. A maioria dos produtos tem 20 telas e 3 que importam. Autenticação, configurações, faturamento, privacidade, conta, onboarding padronizado — estas quase nunca são a história. Encontre a tela onde o produto faz a coisa que só ele pode fazer.
- Se o conteúdo relevante estiver atrás de um login, pergunte primeiro — credenciais de teste ou uma
conta com dados de semente no ambiente de desenvolvimento local. Se nenhum estiver disponível, não desista
e não invente uma sessão que você nunca viu: mude para o formato com capítulos e construa
a partir dos próprios cartões de funcionalidades, texto e componentes da página inicial.
discovery.mdtem o procedimento de coleta e as regras de honestidade.
Em seguida, confirme sua interpretação com o usuário antes de construir — uma leitura errada do produto custa uma construção inteira. Mostre a ele: o que você acha que o produto faz, as 2 a 4 telas que você planeja destacar, o cenário principal, a lista de tomadas e a pergunta sobre música (veja a Fase 4). Um ponto de verificação, depois execute.
Fase 2 — Escolher o formato
Leia references/structure.md. Dois formatos funcionam; escolher errado custa
a construção.
Formato A — a narrativa única. O padrão. Um usuário realizando uma tarefa e obtendo um artefato. Não é um tour de funcionalidades.
| batida | função |
|---|---|
| Gancho (0–5s) | Enuncie o problema nas próprias palavras do espectador. Ainda sem interface. |
| Pedido (5–12s) | O usuário pede a coisa. Foco no campo de entrada. |
| Trabalho (12–25s) | O produto visivelmente faz algo difícil. Mostre as evidências. |
| Artefato (25–35s) | A saída, completa, em tamanho legível. |
| Controle (35–45s) | O usuário a altera e permanece no comando. |
| Placa (45–50s) | Logotipo, uma linha, domínio. |
As batidas de Trabalho e Controle são o que separam uma demonstração real de um mockup. "Ele me perguntou, em vez de adivinhar" e "Eu pude editar o que ele criou" são argumentos de confiança, e confiança é o que um vídeo de lançamento está realmente vendendo.
Escolha o momento em que o produto faz algo que uma pessoa não poderia fazer facilmente sozinha, e torne a saída concreta e visível — um documento gerado, um gráfico construído, um bug corrigido, um site implantado. Artefatos concretos são o que as pessoas lembram.
Formato B — o filme de funcionalidades em capítulos. Três funcionalidades, cada uma introduzida por um cartão de rótulo em linguagem simples, depois mostrada.
Gancho → [01 rótulo → funcionalidade] → [02 rótulo → funcionalidade] → [03 rótulo → funcionalidade] → placa
Use-o quando o produto é fechado e você está trabalhando a partir de sua página inicial, ou quando as funcionalidades genuinamente não compartilham uma jornada de usuário, ou quando você deseja clipes independentes de uma única construção. Três é o número — quatro significa que nenhum deles terá impacto.
Não coloque em capítulos uma sequência. Se as capacidades ocorrem uma após a outra em uma única sessão (pesquisa → rascunho → edição), isso é um fluxo de trabalho, e rotulá-lo como três funcionalidades luta contra o material. Se alguém pedir capítulos em um produto sequencial, ofereça o caminho do meio: mantenha a narrativa única e coloque os rótulos sobre a ação à medida que cada capacidade aparece. Mesma legibilidade, mesmos limites de clipe, sem custo de duração, história intacta.
structure.md cobre o design dos cartões de capítulo, como escrever os rótulos (nomeie o
resultado, não o mecanismo; use as próprias palavras do produto), transições e ordenação.
Fase 3 — Fundamentar tudo
Seja qual for o domínio do produto, não invente seu conteúdo. Se for um produto jurídico, a lei deve ser real. Se for análise de dados, os números devem ser plausíveis e internamente consistentes. Se for uma ferramenta de código, o código deve compilar na mente do leitor.
Extraia o conteúdo real do repositório, da API, dos dados de semente ou da documentação. Especialistas no domínio assistem a esses vídeos e um detalhe inventado custa a credibilidade com todos eles. Nomes de partes, datas e valores monetários são aceitáveis para inventar — estes são específicos de um cliente, não afirmações sobre o mundo.
Mantenha uma nota de proveniência no arquivo de dados dizendo de onde veio cada fato. O seu eu futuro vai querer isso.
Fase 4 — Construir
Execute o scaffolding, que fixa as versões que realmente funcionam juntas e escreve a configuração:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
Ele cria um projeto Remotion independente (seu próprio repositório git — nunca adicione ferramentas de
vídeo ao repositório do produto a menos que solicitado), copia useCamera.ts e
deixa um módulo de timeline para você preencher.
Então, em ordem:
-
src/timeline.ts— matemática de frames e limites de tomada. Escolha um BPM cuja batida seja um número inteiro de frames (a 60fps: 120 BPM = 30 frames, 90 BPM = 40). Coloque cada limite de tomada em uma batida. Mesmo sem música, isso dá ao corte um ritmo interno e significa que uma faixa de fundo pode ser adicionada depois sem re-edição. -
src/data/script.<lang>.ts— cada string, cada número, cada pedaço de conteúdo de documento, em um arquivo com comentários de proveniência. Nada codificado diretamente em componentes. Re-temporizar e traduzir ambos se tornam triviais. -
Componentes — recrie a interface do produto. Copie nomes de classe reais. Se o produto usa Tailwind, inclua sua configuração e CSS de tema; se usa variáveis CSS para cores, você deve trazê-las ou tudo será renderizado sem cor.
-
src/scenes/ProductScene.tsx— um objetoBexportado contendo cada batida como um número de frame absoluto. Tudo lê a partir dele: o DOM, a câmera, o som. Re-temporizar significa editar aquele bloco e nada mais.
Leia references/camera.md para o sistema de tomadas, references/motion.md para
durações e tipografia.
Fase 5 — Áudio
Duas faixas, dois arquivos, duas tags <Audio>: efeitos e música. Mantenha-os
separados para que qualquer um possa ser substituído sem regenerar o outro.
Efeitos — references/sound.md. Conter é toda a disciplina: um
vídeo de 45 segundos geralmente precisa de três a cinco eventos no total. Um pop significa que uma coisa
apareceu, um swish significa que um elemento se moveu dentro da tomada, um whoosh significa que a
própria tomada se moveu.
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Música — references/music.md. Pergunte antes de construir uma. A maioria das pessoas
tem uma opinião e muitas já têm uma faixa; perguntar custa uma frase e pode
salvar todo o esforço:
Você quer uma faixa de fundo? Se você tem uma faixa, envie-a e eu cortarei no ritmo dela. Se não, eu posso sintetizar uma — energética, calma, cinematográfica, minimalista, acolhedora ou tensa?
Se eles tiverem uma faixa, corte no ritmo dela: encontre seu BPM, configure a timeline para corresponder, mova os limites das tomadas para os compassos dela. Caso contrário, sintetize uma faixa cujo arranjo mude nos seus cortes no frame:
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
Coloque uma entrada sections em cada limite de tomada real, uma entrada hits no seu
maior corte e uma entrada ducks sob qualquer linha mantida que você queira que seja ouvida em vez de
sentida. Música no pico de ~0.30, efeitos em ~0.62. Escolha o clima com base no que o
produto é — um assunto sério exige uma faixa mais calma, e um corte movimentado precisa de uma
mais esparsa.
Fase 6 — Verificar com stills, antes de renderizar
Este é o ciclo de ajuste fino, e pular isso perde horas.
npx remotion still <CompositionId> out/f0700.png --frame=700
Depois, olhe de fato para o PNG. Renderize um still por tomada, mais um em cada transição. Verifique: o sujeito está no quadro, algo está cortado no meio de uma palavra, há espaço vazio, o texto se encaixa.
Adicione uma composição silenciosa (defaultProps: { withAudio: false }) para que os stills
não precisem do arquivo de áudio para existir.
Ajuste numericamente sempre que possível. Curvas de easing, distâncias de rolagem, conteúdo espectral — tudo isso é computável. Escreva um script Python descartável que amostra a curva e imprime o que você de outra forma estaria adivinhando. É mais rápido que uma renderização e está correto.
Renderize a versão completa apenas quando os stills estiverem corretos.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limite a concorrência em torno de 4 em uma máquina de 16 GB — o Remotion abre uma aba do Chrome por slot e o padrão (número de núcleos) causará troca.
Fase 7 — Entregar com honestidade
Envie o arquivo. Depois, diga claramente:
- O que você não conseguiu verificar. Você pode ler stills; você não pode julgar como oito segundos se sentem, e você não pode ouvir o áudio. Diga isso.
- Qualquer tela que você reconstruiu, em vez de observou — especialmente em um produto fechado. Liste-as e ofereça-se para refazer essas batidas se eles compartilharem acesso.
- Onde você fez um julgamento com o qual eles possam discordar.
- Como trocar a música: coloque qualquer WAV ou MP3 em
public/music.wave re-renderize. - Qualquer coisa que você encontrou no produto deles durante a construção — um bug de renderização, um rótulo errado, um estado faltante. Você acabou de ler a interface deles com mais cuidado do que a maioria das pessoas jamais fará. Essa observação muitas vezes vale mais do que o vídeo.
Arquivos de referência
Leia-os quando chegar à fase relevante — eles são detalhados e não há valor em carregá-los todos de uma vez.
| arquivo | quando |
|---|---|
references/discovery.md | Fase 1 — navegação, triagem de páginas, credenciais, sistemas de design, e construção a partir da página inicial de um produto fechado |
references/structure.md | Fase 2 — narrativa única vs capítulos, design de cartão de capítulo, escrever rótulos de funcionalidades, transições, ordenação |
references/camera.md | Construção de tomadas — espaço de layout, câmera de ponto de foco, corte vs push vs morph, isolamento de componentes |
references/motion.md | Durações de animação, tipografia, padrões de gancho, o rolo de perguntas |
references/sound.md | Design de som — o vocabulário pop/swish/whoosh, contenção, sintetizando teclado e cliques |
references/music.md | Obtenção vs síntese de uma faixa, escolha de um clima, alinhamento de seções a cortes, mixagem sob os efeitos |
references/pitfalls.md | Leia antes da sua primeira renderização. Bugs que custam horas reais, cada um com a correção. |
Scripts incluídos
<skill-dir> abaixo é o diretório desta habilidade — o caminho fornecido a você quando
a habilidade foi carregada. Não assuma um local de instalação fixo; a habilidade pode estar instalada
pessoalmente, como um plugin ou verificada em um projeto.
| script | o que faz |
|---|---|
scripts/scaffold_video.py | Cria o projeto Remotion com fixação de versões funcionais e configuração |
scripts/make_sfx.py | Sintetiza uma faixa de efeitos sonoros a partir de uma lista JSON de eventos. Sem samples, sem dependências além de numpy. |
scripts/make_music.py | Sintetiza uma faixa de fundo em um de seis climas, com seu arranjo alinhado ao seu corte. Mesmas dependências. |
assets/useCamera.ts | O hook de câmera de ponto de foco — copie para src/hooks/ |
assets/ChapterCard.tsx | Cartão de capítulo para o formato com capítulos — copie para src/components/ |
A versão resumida
Reconstrua em vez de gravar. Uma história, um artefato — a menos que o produto seja fechado ou suas funcionalidades sejam genuinamente separadas, então três capítulos com rótulos simples. Fundamente cada fato de domínio. Frames são a unidade de tudo. Isole um componente em vez de recortar a página. Movimentos de interface são 150–300ms, movimentos de câmera são ~1s. Quatro sons é o suficiente. Pergunte antes de fazer música. Olhe para os stills antes de renderizar. Diga o que você não pôde verificar e o que você inferiu.