Saltar al contenido
Guía7 min de lectura

Demo de portafolio para Figma Make

Ponga la app en funcionamiento en su portafolio, no una captura de ella.

Muestre una app de Figma Make funcionando en un portafolio, no una captura estática, y demuestre el flujo antes de que lo pida un responsable de contratación.

Ver cómo funcionaLos primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargarlo.

Una entrada de portafolio construida en torno a una captura de pantalla le está pidiendo al revisor que confíe en que todo lo que queda por debajo del pliegue también funciona. Una captura de pantalla demuestra la composición. No demuestra que un botón haga algo, que un formulario valide correctamente o que la interacción que realmente le importa a un responsable de contratación se comporte como la imagen fija da a entender. La distancia entre "parece terminado" y "funciona" es exactamente lo que cierra un vídeo, y es la mayor diferencia entre una entrada de portafolio que recibe una segunda mirada y otra que se pasa de largo desplazando la página. Un revisor que avanza por una pila de solicitudes rara vez tiene tiempo de abrir cada proyecto enlazado, así que las entradas que sobreviven a ese primer repaso son las que responden a la pregunta de si funciona sin exigir un clic adicional.

Una app de Figma Make se presta bien a esto porque el resultado es un prototipo funcional accesible en un enlace de vista previa compartible, y no un archivo de diseño que necesite tener Figma abierto para inspeccionarlo. Ese enlace suele ser accesible sin iniciar sesión, ya que la mayoría de los proyectos de Figma Make son prototipos y no software con un sistema de cuentas completo detrás, lo que significa que el flujo mostrado en el vídeo es el mismo flujo que un revisor podría abrir y probar por sí mismo justo después de verlo.

¿Qué debe demostrar una demo de portafolio?

Una demo de portafolio debe demostrar la única interacción que exigió más criterio para hacerse bien. Rara vez es la pantalla de inicio de sesión o la barra de navegación. Suele ser una pieza concreta de lógica: un formulario que reacciona con inteligencia a la entrada de datos, una disposición que se reorganiza de una forma que costó una iteración real, o un flujo que resuelve un problema de interfaz genuinamente incómodo. Nombre ese momento antes de grabar nada, de la misma forma en que nombraría el punto más fuerte de un caso de estudio escrito.

Un vídeo de galería de lanzamiento tiene que ganarse la atención de un desconocido en los primeros dos segundos. Un espectador de portafolio ya ha elegido mirar más de cerca, normalmente porque un currículum o un enlace lo llevó hasta allí, así que el vídeo puede permitirse un arco algo más largo: un comienzo que plantea el problema, un desarrollo que muestra la interacción y un final que muestra el estado resuelto.

Momento del portafolioQué debe demostrarQué dejar fuera
PlanteamientoEl problema que resuelve la interacciónUn recorrido por páginas no relacionadas
InteracciónLa lógica o la decisión de diseño concretaCada ruta alternativa por la misma pantalla
ResoluciónEl estado que muestra que la interacción funcionóUn discurso de ventas cargado de narración

¿Cómo se prepara la app para la grabación?

Abra el enlace de vista previa como lo haría un revisor, en frío, sin suposiciones sobre en qué estado debería estar. Busque cualquier cosa que parezca inacabada: texto de marcador de posición que quedó de un borrador anterior, una lista vacía sin nada dentro, o un componente que todavía muestra valores predeterminados en lugar del contenido que pretendía demostrar. Un revisor que evalúa una entrada de portafolio ya está buscando motivos para pasar a la siguiente, y un detalle obviamente inacabado le entrega ese motivo gratis.

  • Abra el enlace de vista previa en frío y confirme que nada parece un estado de un borrador anterior.
  • Rellene cualquier lista, formulario o tabla con contenido que parezca intencionado, no vacío.
  • Pruebe la interacción concreta de principio a fin antes de escribir la indicación para la renderización.
  • Elimine cualquier cosa que se parezca a los datos de una persona real, incluso texto de marcador de posición que resulte demasiado específico.

Rellene los datos que respaldan la interacción sin fingir que son la información de un usuario real. Un calendario sin eventos o un panel sin cifras no le da al revisor nada a lo que reaccionar, mientras que unos datos que son claramente un sustituto siguen dejando que la interacción se lea con claridad.

Poner el proceso en orden ayuda a mantener el vídeo correctamente acotado desde el principio:

  1. Nombre la interacción más sólida de la app antes de grabar nada.
  2. Prepare el enlace de vista previa para que se abra en frío sin ningún estado inacabado visible.
  3. Escriba la indicación nombrando el estado inicial, la interacción y el resultado, y después revise la renderización antes de publicarla.

¿Qué grado de detalle debe tener la indicación?

Escriba la indicación de la misma forma en que describiría la pieza a un revisor de diseño en una entrevista. Nombre el estado inicial, la interacción y el resultado. "Desde el formulario vacío, introduzca un valor que active el mensaje de validación y después muestre el estado corregido" es lo bastante concreto como para que la renderización de GogoScreen tenga un objetivo claro y lo bastante acotado como para que el revisor del vídeo terminado pueda comprobarlo frente a la indicación.

GogoScreen devuelve un MP4 narrado y editado construido a partir de esa indicación y de la URL, con zooms en el clic que importa, suavizado del cursor, cortes de los silencios muertos y subtítulos integrados. Nada de eso sustituye la elección de la interacción correcta. Una grabación limpiamente editada de una pantalla genérica sigue siendo una entrada de portafolio genérica, y los revisores que ven muchas de estas en un día notan rápido la diferencia entre una afirmación concreta y una general.

¿Qué acompaña al vídeo en el portafolio?

Acompañe el vídeo con una nota breve escrita que nombre el problema, la decisión y por qué esa decisión fue la correcta. El vídeo muestra el resultado. El texto explica el razonamiento, que suele ser lo que un responsable de contratación o un cliente realmente está evaluando. Mantenga las dos cosas separadas en lugar de superponer narración de proceso sobre la interacción en marcha, ya que un revisor que intenta ver la interfaz funcionar y leer una explicación al mismo tiempo tiende a no asimilar bien ninguna de las dos.

Revise la renderización terminada frente a cómo se comporta realmente la interacción antes de publicarla en cualquier sitio. Aproximadamente una de cada cinco renderizaciones necesita un segundo intento o falla directamente, y el tiempo solo se usa cuando una renderización sale bien, así que incorpore un breve repaso de revisión al proceso en lugar de publicar el primer archivo que llegue. Ese repaso también es el momento en el que suele salir a la luz un desajuste entre la indicación y la interfaz, así que vale la pena ver el clip entero una vez antes de decidir que está listo para publicarse.

¿Dónde encaja esto con las guías relacionadas?

Para un revisor que necesita dar el visto bueno antes de que la app se publique, en lugar de juzgarla como una pieza de portafolio, la guía de recorrido de revisión de una app de Figma Make cubre esa audiencia distinta y el problema de traspaso que llega antes de que valga la pena hacer una entrada de portafolio. Para un tratamiento parecido en otro creador, compare con un vídeo demo de Bubble, un vídeo demo de página de destino de Bubble, un vídeo de lanzamiento de Bubble en Product Hunt, y compartir un proyecto de Bubble con un cliente, ya que las apps de Bubble suelen estar más a menudo detrás de un inicio de sesión real por defecto.

Para demostrar un resultado de interacción concreto en lugar de un flujo general, la guía de vídeo demo de resultado de prueba de un agente de IA y la guía de vídeo demo de control de calidad de un agente de IA cubren formatos de prueba relacionados. Un vídeo demo de producto incrustado es útil una vez que la entrada de portafolio necesita insertarse dentro de una página en lugar de enlazar hacia fuera, un vídeo demo de una app de Lovable cubre el mismo trabajo para ese creador, y un recorrido de producto más amplio para un SaaS es el formato correcto una vez que la entrada necesita cubrir más de una interacción. Para una comparación de herramientas de grabación para este tipo de trabajo, lea GogoScreen frente a Clueso. Empiece por la página de inicio de GogoScreen, consulte los precios, explore la biblioteca completa de guías, o vea el resto de las comparaciones.

Aclaraciones

Antes de empezar

¿Por qué una captura de pantalla no es suficiente para una entrada de portafolio?

Una captura de pantalla solo demuestra que la interfaz se puede componer correctamente en un instante congelado. No puede mostrar si la interacción realmente funciona, que suele ser justo lo que un revisor intenta juzgar.

¿El vídeo del portafolio debe mostrar el proceso de Figma Make o la app terminada?

Muestre la app terminada haciendo el trabajo para el que fue construida. El proceso pertenece a un caso de estudio escrito junto al vídeo, no dentro del mismo clip, ya que mezclar ambas cosas diluye las dos.

¿Necesito datos reales en la demo para que resulte convincente?

Necesita datos verosímiles, no datos reales. Un contenido de marcador de posición que parezca intencionado basta para mostrar que la interacción funciona, y usar material real de un cliente no es apropiado para una entrada de portafolio pública.

Pegue una URL, describa un flujo y obtenga un vídeo de demostración de su aplicación web.

Los primeros 60 segundos de vídeo son gratuitos, con marca de agua. Verifique su correo electrónico para descargar el vídeo.