Video de lanzamiento para un producto de software
Producir un video de 30 a 60 segundos que haga que alguien entienda y quiera el producto.
La decisión que lo define todo: reconstruir, no grabar
Las grabaciones de pantalla te combaten. La latencia real es aire muerto. Las repeticiones son costosas. No puedes mantener un fotograma, no puedes ralentizar un ritmo y acelerar otro, y no puedes recortar de forma apretada sin llegar a la compresión granulada.
Por lo tanto, reconstruye la interfaz de usuario como React impulsado por fotogramas dentro de Remotion. Cada visual es una
función pura de useCurrentFrame(). La escritura llega en una curva exacta, un
estado de carga se resuelve en el ritmo, y una repetición cuesta un número.
Esto solo es razonable porque puedes leer el código real del producto (si es local) o el DOM+CSS (si está alojado) y reproducirlo fielmente. Hazlo — toma los nombres de clase reales, los colores reales, el texto real. La reconstrucción debe ser indistinguible de una grabación, 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 ser
reconstruida, 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. 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.
- 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, incorporación de rutina — estos casi nunca son la historia. 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 sembrada en su entorno de desarrollo local. Si ninguno está disponible, no te rindas y no finjas una sesión que nunca viste: cambia al formato de 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 incorrecta 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 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 recorrido de características.
| compás | trabajo |
|---|---|
| Gancho (0–5s) | Plantear el problema en las propias palabras del espectador. Sin interfaz de usuario aún. |
| Pregunta (5–12s) | El usuario pide la cosa. Enfocado en la entrada. |
| Trabajo (12–25s) | El producto hace visiblemente algo difícil. Muestra las pruebas. |
| Artefacto (25–35s) | El resultado, completo, en tamaño legible. |
| Control (35–45s) | El usuario lo cambia y permanece 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 una maqueta. "Me preguntó en lugar de adivinar" y "Pude editar lo que hizo" 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 implementado. 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 introducida por una tarjeta de etiqueta en lenguaje sencillo, luego mostradas.
enganche → [01 etiqueta → característica] → [02 etiqueta → característica] → [03 etiqueta → característica] → pizarra
Úsala cuando el producto esté restringido y estés trabajando desde su página de aterrizaje, o cuando las características realmente no compartan un recorrido de usuario, o cuando quieras tres clips independientes de una sola construcción. Tres es el número — cuatro significa que ninguno impacta.
No dividas en capítulos una secuencia. Si las capacidades ocurren una tras otra en una sola sesión (investigación → borrador → edición), eso es un flujo de trabajo, y etiquetarlo como tres características va en contra del material. Si alguien pide capítulos para 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 tiempo de ejecución, historia intacta.
structure.md cubre el diseño de tarjetas de capítulo, cómo escribir las etiquetas (nombra el resultado, no el mecanismo; roba las propias palabras del producto), transiciones y orden.
Fase 3 — Fundamentar todo
Cualquiera que sea el dominio del producto, no inventes su contenido. Si es un producto legal, el estatuto debe ser real. Si es análisis, los números deben ser plausibles y consistentes internamente. 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. Nombres de partes, fechas y cifras en dólares está bien inventar — esos son específicos de un cliente, no afirmaciones sobre el mundo.
Mantén una nota de procedencia en el archivo de datos diciendo de dónde vino cada hecho. El tú del futuro lo querrá.
Fase 4 — Construir
Ejecuta el andamiaje, que fija las versiones que realmente funcionan juntas y escribe la configuración:
python3 <directorio-del-skill>/scripts/scaffold_video.py <directorio-destino> \
--name "lanzamiento-producto" --fps 60 --seconds 45
Crea un proyecto Remotion independiente (su propio repositorio git — nunca agregues herramientas de video al repositorio del producto a menos que te lo pidan), copia useCamera.ts, y te deja un módulo de línea de tiempo para completar.
Luego, en orden:
-
src/timeline.ts— matemáticas de fotogramas y límites de tomas. Elige un BPM cuyo ritmo sea un número entero de fotogramas (a 60 fps: 120 BPM = 30 fotogramas, 90 BPM = 40). Pon cada límite de toma en un ritmo. Incluso sin música, esto le da al corte un ritmo interno, y significa que se puede agregar una base musical más tarde sin reeditar. -
src/data/script.<idioma>.ts— cada cadena, cada número, cada pieza de contenido de documento, en un archivo con comentarios de procedencia. Nada codificado en componentes. Reajustar el tiempo y traducir se vuelve trivial. -
Componentes — recrea la interfaz de usuario del producto. Copia nombres de clase reales. Si el producto usa Tailwind, incluye su configuración y CSS de tema; si usa variables CSS para color, debes traerlas 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 lo lee: 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 generalmente necesita de tres a cinco eventos en total. Un pop significa que apareció algo, un swish significa que un elemento se movió dentro de la toma, un whoosh significa que la toma se movió.
python3 <directorio-del-skill>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
Música — references/music.md. Pregunta antes de construir una. La mayoría de las personas tienen una opinión y muchas ya tienen una pista; preguntar cuesta una oración y puede ahorrar todo el esfuerzo:
¿Quieres una base musical? Si tienes una pista, envíala y la cortaré a ella. Si no, puedo sintetizar una — enérgica, tranquila, cinematográfica, minimalista, cálida o tensa?
Si tienen una pista, córtala a 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 cuya disposición cambie y caiga en tus cortes al fotograma:
python3 <directorio-del-skill>/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 leer en lugar de sentir. Música en pico ~0.30, efectos en ~0.62. Elige el estado de ánimo según lo que es el producto — un tema serio requiere una base más tranquila, y un corte ocupado necesita una más escasa.
Fase 6 — Verificar con imágenes fijas, antes de renderizar
Este es el bucle rápido, y saltarlo desperdicia horas.
npx remotion still <CompositionId> out/f0700.png --frame=700
Luego mira realmente el PNG. Renderiza una imagen fija por toma, más una en cada transición. Verifica: ¿el sujeto está en el cuadro?, ¿algo está cortado a mitad de palabra?, ¿hay espacio muerto?, ¿el texto cabe.
Agrega una composición silenciosa (defaultProps: { withAudio: false }) para que las imágenes fijas no necesiten que el archivo de audio exista.
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 las imágenes fijas estén correctas.
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
Limita la concurrencia a alrededor de 4 en una máquina de 16 GB — Remotion inicia una pestaña de Chrome por ranura y el valor predeterminado (número de núcleos) hará intercambio.
Fase 7 — Entregarlo con honestidad
Envía el archivo. Luego di claramente:
- Lo que no pudiste verificar. Puedes leer imágenes fijas; 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 con acceso restringido. Enuméralas y ofrece rehacer esos compases si comparten acceso.
- Dónde tomaste una decisión subjetiva 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 las personas lo harán. Esa observación a menudo vale más que el video.
Archivos de referencia
Léelos cuando llegues a la fase relevante — 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 a partir de la página de aterrizaje de un producto con acceso 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, orden |
references/camera.md | Construcción de tomas — espacio de diseño, cámara de punto de enfoque, corte vs empuje vs morph, 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, sintetización 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 | Léelo antes de tu primer renderizado. Errores que cuestan horas reales, cada uno con la solución. |
Scripts incluidos
<directorio-del-skill> a continuación es el directorio de este skill — la ruta que se te dio cuando se cargó el skill. No asumas una ubicación de instalación fija; el skill puede estar instalado personalmente, como complemento, o verificado en un proyecto.
| script | qué hace |
|---|---|
scripts/scaffold_video.py | Crea el proyecto Remotion con fijaciones de versión funcionales y configuración |
scripts/make_sfx.py | Sintetiza una pista de efectos de sonido a partir de una lista JSON de eventos. 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 disposición alineada a tu corte. Mismas dependencias. |
assets/useCamera.ts | El hook de cámara de punto de enfoque — copia en src/hooks/ |
assets/ChapterCard.tsx | Tarjeta de capítulo para el formato de capítulos — copia 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 realmente separadas, entonces tres capítulos con etiquetas claras. Fundamenta cada hecho del dominio. Los fotogramas son la unidad de todo. Aísla un componente en lugar de recortar la página. El movimiento de la interfaz de usuario es de 150 a 300 ms, los movimientos de cámara son de aproximadamente 1 s. Cuatro sonidos son suficientes. Pregunta antes de hacer música. Mira las imágenes fijas antes de renderizar. Di lo que no pudiste verificar y lo que inferiste.