Video de lanzamiento para un producto de software
Produce un video de 30 a 60 segundos que haga que alguien entienda y quiera el producto.
La decisión que lo determina todo: reconstruir, no grabar
Las grabaciones de pantalla te complican. La latencia real es tiempo muerto. Las retomas son costosas. No puedes mantener un fotograma, no puedes ralentizar un compás y acelerar otro, y no puedes recortar con precisión sin llegar a una compresión granulada.
Así que reconstruye la interfaz de usuario como React impulsado por fotogramas dentro de Remotion. Cada elemento visual es una
función pura de useCurrentFrame(). El texto aparece en una curva exacta, un
estado de carga se resuelve en el compás, y una retoma cuesta un número.
Esto solo es razonable porque puedes leer el código real del producto (si local) o DOM+CSS (si está alojado) y reproducirlo fielmente. Hazlo: toma las clases reales, los colores reales, el texto real. La reconstrucción debe ser diferenciable de una grabación, y luego mejor.
Cuándo grabar en su lugar: 3D pesado, contenido de video dentro del producto, una
superficie canvas/WebGL, o una aplicación de escritorio nativa. Si una superficie específica no puede
reconstruirse, graba solo esa superficie y compónela con <OffthreadVideo>.
Fase 1: Comprender el producto
Lee references/discovery.md antes de comenzar esta fase. Cubre el
procedimiento de navegación y triaje, la conversación sobre credenciales y cómo extraer
un sistema de diseño de un sitio en vivo.
Versión corta:
- Dada una URL: navega por ella. La página de aterrizaje primero (te dice cómo se posicionan), luego la aplicación en sí. Averigua qué trabajo hace el producto y para quién.
- Dado un repositorio local/servidor de desarrollo: lee el código. Mucho más rico: obtienes los componentes reales, los tokens de tema reales, los datos de semilla reales.
- Haz triaje de las páginas. La mayoría de los productos tienen 20 pantallas y 3 que importan. Autenticación, configuración, facturación, privacidad, cuenta, plantillas de incorporación: estas casi nunca son la historia principal. Encuentra la pantalla donde el producto hace lo que solo él puede hacer.
- Si lo bueno está detrás de un inicio de sesión, pregunta primero: credenciales de prueba, o una
cuenta con datos de semilla en su entorno de desarrollo local. Si no hay nada disponible, no te rindas
y no finjas una sesión que nunca viste: cambia a la estructura por capítulos y construye
a partir de las tarjetas de características, el texto y los componentes de la propia página de aterrizaje.
discovery.mdtiene el procedimiento de recolección y las reglas de honestidad.
Luego confirma tu interpretación con el usuario antes de construir: una interpretación errónea del producto cuesta toda la construcción. Muéstrale: lo que crees que hace el producto, las 2 a 4 pantallas que planeas destacar, el escenario principal, la lista de tomas y la pregunta sobre la música (ver Fase 4). Un punto de control, luego ejecuta.
Fase 2: Elegir la estructura
Lee references/structure.md. Dos estructuras funcionan; elegir mal cuesta la
construcción.
Estructura A: la narrativa única. La predeterminada. Un usuario haciendo un trabajo y obteniendo un artefacto. No es un tour de características.
| compás | trabajo |
|---|---|
| Gancho (0–5s) | Plantea el problema en las propias palabras del espectador. Aún sin interfaz. |
| Pregunta (5–12s) | El usuario pide lo que quiere. Enfoque en la entrada. |
| Trabajo (12–25s) | El producto hace visiblemente algo difícil. Muestra las pruebas. |
| Artefacto (25–35s) | El resultado, completo, en un tamaño legible. |
| Control (35–45s) | El usuario lo cambia y sigue al mando. |
| Pizarra (45–50s) | Logotipo, una línea, dominio. |
Los compases de Trabajo y Control son lo que separa una demostración real de un mockup. "Me preguntó en lugar de adivinar" e "Pude editar lo que creó" son argumentos de confianza, y la confianza es lo que un video de lanzamiento realmente vende.
Elige el momento en que el producto hace algo que una persona no podría hacer fácilmente por sí misma, y haz que el resultado sea concreto y visible: un documento generado, un gráfico construido, un error corregido, un sitio desplegado. Los artefactos concretos son lo que la gente recuerda.
Estructura B: la película de características por capítulos. Tres características, cada una presentada por una tarjeta de etiqueta en lenguaje sencillo, y luego mostradas.
gancho → [01 etiqueta → característica] → [02 etiqueta → característica] → [03 etiqueta → característica] → pizarra
Úsala cuando el producto está restringido y trabajas desde su página de aterrizaje, o cuando las características genuinamente no comparten un recorrido de usuario, o cuando quieres tres clips independientes de una sola construcción. Tres es el número: cuatro significa que ninguno impacta.
No conviertas una secuencia en capítulos. Si las capacidades ocurren una tras otra en una sola sesión (investigación → borrador → edición), es un flujo de trabajo, y etiquetarlo como tres características va en contra del material. Si alguien pide capítulos en un producto secuencial, ofrece el camino intermedio en su lugar: mantén la narrativa única y coloca las etiquetas sobre la acción a medida que aparece cada capacidad. Misma legibilidad, mismos límites de clip, sin costo de runtime, historia intacta.
structure.md cubre el diseño de la tarjeta de capítulo, cómo escribir las etiquetas (nombra el
resultado, no el mecanismo; toma las propias palabras del producto), transiciones y
ordenamiento.
Fase 3: Fundamenta todo
Sea cual sea el dominio del producto, no inventes su contenido. Si es un producto legal, la ley debe ser real. Si es de análisis, los números deben ser plausibles e internamente consistentes. Si es una herramienta de código, el código debe compilar en la cabeza del lector.
Extrae lo real del repositorio, la API, los datos de semilla o la documentación. Los expertos en el dominio ven estos videos y un detalle inventado te cuesta a todos ellos. Los nombres de las partes, las fechas y las cifras en dólares están bien para inventar: son específicos de un cliente, no afirmaciones sobre el mundo.
Mantén una nota de procedencia en el archivo de datos que diga de dónde vino cada hecho. El tú del futuro lo agradecerá.
Fase 4: Construir
Ejecuta el andamio, que fija las versiones que realmente funcionan juntas y escribe la configuración:
python3 <directorio-de-habilidad>/scripts/scaffold_video.py <directorio-de-destino> \
--name "product-launch" --fps 60 --seconds 45
Crea un proyecto Remotion independiente (su propio repositorio git: nunca añadas herramientas de video
al repositorio del producto a menos que se te pida), copia useCamera.ts y
te deja un módulo de línea de tiempo para rellenar.
Luego, en orden:
-
src/timeline.ts— matemática de fotogramas y límites de tomas. Elige un BPM cuyo compás sea un número entero de fotogramas (a 60fps: 120 BPM = 30 fotogramas, 90 BPM = 40). Pon cada límite de toma en un compás. Incluso sin música, esto le da al corte un ritmo interno, y significa que se puede añadir una base musical más tarde sin re-editar. -
src/data/script.<lang>.ts— cada cadena, cada número, cada pieza de contenido del documento, en un archivo con comentarios de procedencia. Nada codificado en componentes. Reajustar el tiempo y traducir se vuelven triviales. -
Componentes — recrea la interfaz de usuario del producto. Copia los nombres de clase reales. Si el producto usa Tailwind, provee su configuración y CSS de tema; si usa variables CSS para el color, debes traerlos o todo se renderiza sin color.
-
src/scenes/ProductScene.tsx— un objetoBexportado que contiene cada compás como un número de fotograma absoluto. Todo lee de él: el DOM, la cámara, el sonido. Reajustar el tiempo significa editar ese bloque y nada más.
Lee references/camera.md para el sistema de tomas, references/motion.md para
duraciones y tipografía.
Fase 5: Audio
Dos pistas, dos archivos, dos etiquetas <Audio>: efectos y música. Mantenlos
separados para que cualquiera pueda ser reemplazado sin regenerar el otro.
Efectos — references/sound.md. La moderación es toda la disciplina: un
video de 45 segundos normalmente necesita de tres a cinco eventos en total. Un pop significa que algo
apareció, un swish significa que un elemento se movió dentro de la toma, un whoosh significa que la
toma se movió.
python3 <directorio-de-habilidad>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Música — references/music.md. Pregunta antes de construir una. La mayoría de la gente
tiene una opinión y muchos ya tienen una pista; preguntar cuesta una frase y puede
ahorrar todo el esfuerzo:
¿Quieres una base musical? Si tienes una pista, envíala y la sincronizaré. Si no, puedo sintetizar una: enérgica, tranquila, cinematográfica, minimalista, cálida o tensa.
Si tienen una pista, sincronízala con ella: encuentra su BPM, ajusta la línea de tiempo para que coincida, mueve los límites de las tomas a sus compases. De lo contrario, sintetiza una base cuyo arreglo cambie en tus cortes al fotograma:
python3 <directorio-de-habilidad>/scripts/make_music.py music.spec.json public/music.wav
Pon una entrada sections en cada límite de toma real, una entrada hits en tu
corte más grande, y una entrada ducks debajo de cualquier línea sostenida que quieras que se lea en lugar de
sentir. Música a pico ~0.30, efectos a ~0.62. Elige el estado de ánimo según lo que el producto
es: los temas serios requieren una base más tranquila, y un corte rápido necesita una más
escasa.
Fase 6: Verificar con fotogramas fijos, antes de renderizar
Este es el bucle cerrado, y saltarlo pierde horas.
npx remotion still <IdentificadorDeComposición> out/f0700.png --frame=700
Luego mira realmente el PNG. Renderiza un fotograma fijo por toma, más uno en cada transición. Verifica: ¿está el sujeto en el encuadre?, ¿está algo cortado a mitad de palabra?, ¿hay espacio muerto?, ¿encaja el texto.
Añade una composición silenciosa (defaultProps: { withAudio: false }) para que los fotogramas fijos
no necesiten que exista el archivo de audio.
Ajusta numéricamente siempre que puedas. Curvas de easing, distancias de desplazamiento, contenido espectral: todo esto es computable. Escribe un script Python desechable que muestree la curva e imprima lo que de otro modo estarías adivinando. Es más rápido que un renderizado y es correcto.
Solo renderiza el video completo una vez que los fotogramas fijos estén bien.
npx remotion render <IdentificadorDeComposición> out/video.mp4 --concurrency=4
Limita la concurrencia a alrededor de 4 en una máquina de 16 GB: Remotion genera una pestaña de Chrome por ranura y el valor predeterminado (número de núcleos) intercambiará.
Fase 7: Entregarlo honestamente
Envía el archivo. Luego di claramente:
- Lo que no pudiste verificar. Puedes leer fotogramas fijos; no puedes juzgar cómo se sienten ocho segundos, y no puedes escuchar el audio. Dilo.
- Cualquier pantalla que reconstruiste en lugar de observar — especialmente en un producto restringido. Enuméralas y ofrece rehacer esos compases si comparten acceso.
- Donde tomaste una decisión con la que podrían no estar de acuerdo.
- Cómo cambiar la música: coloca cualquier WAV o MP3 en
public/music.wavy vuelve a renderizar. - Cualquier cosa que encontraste en su producto mientras construías: un error de renderizado, una etiqueta incorrecta, un estado faltante. Acabas de leer su interfaz de usuario más cuidadosamente de lo que la mayoría de la gente jamás lo hará. Esa observación a menudo vale más que el video.
Archivos de referencia
Léelos cuando llegues a la fase correspondiente: son detallados y no tiene sentido cargarlos todos al principio.
| archivo | cuándo |
|---|---|
references/discovery.md | Fase 1: navegación, triaje de páginas, credenciales, sistemas de diseño, y construcción desde la página de aterrizaje de un producto restringido |
references/structure.md | Fase 2: narrativa única vs capítulos, diseño de tarjetas de capítulo, escritura de etiquetas de características, transiciones, ordenamiento |
references/camera.md | Construcción de tomas: espacio de diseño, cámara de punto focal, corte vs push vs morfosis, aislamiento de componentes |
references/motion.md | Duraciones de animación, tipografía, patrones de gancho, el carrete de preguntas |
references/sound.md | Diseño de sonido: el vocabulario pop/swish/whoosh, moderación, síntesis de teclado y clics |
references/music.md | Obtener vs sintetizar una base, elegir un estado de ánimo, alinear secciones a cortes, mezclar bajo los efectos |
references/pitfalls.md | Lee esto antes de tu primer renderizado. Errores que cuestan horas reales, cada uno con la solución. |
Scripts incluidos
<directorio-de-habilidad> a continuación es el directorio propio de esta habilidad: la ruta que se te da cuando
se cargó la habilidad. No asumas una ubicación de instalación fija; la habilidad puede estar instalada
personalmente, como un complemento, o verificada en un proyecto.
| script | qué |
|---|---|
scripts/scaffold_video.py | Crea el proyecto Remotion con fijaciones de versiones funcionales y configuración |
scripts/make_sfx.py | Sintetiza una pista de efectos de sonido a partir de una lista de eventos JSON. Sin muestras, sin dependencias más allá de numpy. |
scripts/make_music.py | Sintetiza una base musical en uno de seis estados de ánimo, con su arreglo alineado a tus cortes. Mismas dependencias. |
assets/useCamera.ts | El hook de cámara de punto focal: cópialo en src/hooks/ |
assets/ChapterCard.tsx | Tarjeta de capítulo para la estructura por capítulos: cópiala en src/components/ |
La versión corta
Reconstruye en lugar de grabar. Una historia, un artefacto — a menos que el producto esté restringido o sus características sean genuinamente separadas, entonces tres capítulos con etiquetas claras. Fundamenta cada hecho de dominio. Los fotogramas son la unidad de todo. Aísla un componente en lugar de recortar la página. El movimiento de la interfaz es de 150 a 300 ms, los movimientos de la cámara son de aproximadamente 1 s. Cuatro sonidos es suficiente. Pregunta antes de hacer música. Mira los fotogramas fijos antes de renderizar. Di lo que no pudiste verificar y lo que inferiste.