Video de lanzamiento para un producto de software
Produce un video de 30 a 60 segundos que haga que alguien entienda y desee el producto.
La decisión que lo define todo: reconstruir, no grabar
Las grabaciones de pantalla luchan contra ti. La latencia real es tiempo muerto. Las repeticiones son caras. No puedes mantener un fotograma, no puedes ralentizar un compás y acelerar otro, y no puedes recortar con precisión sin llegar a la compresión.
Por lo tanto, reconstruye la interfaz de usuario como React basado en fotogramas dentro de Remotion. Cada elemento visual es una
función pura de useCurrentFrame(). La escritura llega en una curva exacta, un
estado de carga se resuelve en el compás, 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, 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 ser
reconstruida, graba solo esa superficie y compónela con <OffthreadVideo>.
Fase 1 — Entender el producto
Lee references/discovery.md antes de comenzar esta fase. Cubre el
procedimiento de navegación y clasificación, 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. Primero la página de inicio (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.
- Clasifica 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: estos casi nunca son la historia. Encuentra la pantalla donde el producto hace lo único que 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 desarrollo local. Si no hay ninguna disponible, no te rindas
y no falsifiques una sesión que nunca viste: cambia a la forma de capítulos y
construye a partir de las propias tarjetas de características, texto y componentes de la página de inicio.
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 una construcción. Muéstrales: lo que crees que hace el producto, las 2–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 forma
Lee references/structure.md. Dos formas funcionan; elegir mal cuesta la
construcción.
Forma 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) | Enunciar el problema en las propias palabras del espectador. Aún sin interfaz de usuario. |
| 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) | La salida, completa, a 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 una maqueta. "Me preguntó en lugar de adivinar" y "pude editar lo que hizo" son argumentos de confianza, y la confianza es lo que realmente vende un video de lanzamiento.
Elige el momento en que el producto hace algo que una persona no podría hacer fácilmente por sí misma, y haz que la salida sea concreta y visible: un documento generado, un gráfico construido, un error corregido, un sitio desplegado. Los artefactos concretos son lo que la gente recuerda.
Forma 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 mostrada.
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 inicio, o cuando las características genuinamente 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 ninguna impacta.
No dividas en capítulos una secuencia. Si las capacidades ocurren una después de otra en una sola sesión (investigación → borrador → edición), eso es un flujo de trabajo, y etiquetarlo como tres características lucha contra el material. Si alguien pide capítulos en un producto secuencial, ofrece el camino intermedio: 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 duració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 — Fundamenta todo
Sea cual sea el dominio del producto, no inventes su contenido. Si es un producto legal, la ley debe ser real. Si son 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 cantidades en dólares están bien para inventar: esos son específicos de un cliente, no afirmaciones sobre el mundo.
Mantén una nota de procedencia en el archivo de datos que indique de dónde proviene cada hecho. El tú del futuro lo querrá.
Fase 4 — Construir
Ejecuta el andamio, que fija las versiones que realmente funcionan juntas y escribe la configuración:
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --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 se te pida), 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 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 agregar una base musical más tarde sin volver a 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, incluye su configuración y CSS de tema; si usa variables CSS para el color, debes traerlas o todo se renderizará 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
las duraciones y la tipografía.
Fase 5 — Audio
Dos pistas, dos archivos, dos etiquetas <Audio>: efectos y música. Mantenlas
separadas para que cualquiera pueda ser reemplazada sin regenerar la otra.
Efectos — references/sound.md. La restricción es toda la disciplina: un
video de 45 segundos generalmente 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 <skill-dir>/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é para que coincida. Si no, puedo sintetizar una — ¿enérgica, calmada, cinematográfica, minimalista, cálida o tensa?
Si tienen una pista, córtala para que coincida: 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 organización de cambios caiga en tus cortes al fotograma:
python3 <skill-dir>/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 sentirse. Música al pico ~0.30, efectos a ~0.62. Elige el estado de ánimo de lo que el producto
es: 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 apretado, 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 encuadre?, ¿algo está cortado a media palabra?, ¿hay espacio vacío?, ¿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 bien.
npx remotion render <CompositionId> 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 (recuento de núcleos) causará 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 ocho segundos se sienten, 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.
- 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 correspondiente — son detallados y no tiene sentido cargarlos todos al principio.
| archivo | cuándo |
|---|---|
references/discovery.md | Fase 1 — navegación, clasificación de páginas, credenciales, sistemas de diseño, y construcción desde la página de inicio 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, 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, restricción, síntesis de teclado y clics |
references/music.md | Obtener vs. sintetizar una base, elegir un estado de ánimo, alinear secciones a cortes, mezcla 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
<skill-dir> debajo es el directorio de esta habilidad en sí — la ruta que se te dio cuando
la habilidad se cargó. No asumas una ubicación de instalación fija; la habilidad puede estar
instalada personalmente, como un plugin, o descargada en un proyecto.
| script | qué |
|---|---|
scripts/scaffold_video.py | Crea el proyecto Remotion con pines de versión 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 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 la forma 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 genuinamente separadas, entonces tres capítulos con etiquetas sencillas. 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–300 ms, los movimientos de cámara son de ~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.