Saltar al contenido
Guía7 min de lectura

Compartir un proyecto de Windsurf con un cliente

Algunos clientes nunca harán clic en el enlace. Envíeles el resultado.

Entregue una compilación de Windsurf que funciona a un cliente sin conocimientos técnicos que no abrirá un enlace, usando un vídeo en lugar de una URL.

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

Algunos clientes abren cada enlace que se les envía. Otros no, ya sea por tiempo limitado, comodidad limitada con software que no conocen o simplemente una preferencia por que se les cuente en lugar de mostrarles dónde hacer clic. Un proyecto de Windsurf construido para ese segundo tipo de cliente necesita un traspaso distinto a una URL de vista previa y un mensaje esperanzado. Un vídeo corto que se reproduce solo, sin inicio de sesión y sin navegación necesaria, respeta tanto el tiempo del cliente como el hecho de que puede que nunca en su vida haya abierto un enlace de staging.

Windsurf en sí mismo es un editor de código, y el cliente casi con certeza nunca ha oído hablar de él y no necesita hacerlo. Lo que pidió fue un resultado, descrito con sus propias palabras durante una llamada o un correo electrónico, no una función técnica. El vídeo debe responder directamente a esa solicitud original, usando el vocabulario propio del cliente en lugar de los términos internos de la interfaz, ya que un cliente que tiene que traducir etiquetas que no conoce de vuelta a su propia solicitud está haciendo un trabajo que el vídeo debería haber hecho por él.

Este es un problema distinto de mostrar el mismo proyecto a una audiencia técnica. Una demo de portafolio de Windsurf la juzga alguien que quiere ver oficio y está dispuesto a sentarse a través de algún matiz. Un vídeo de revisión para un cliente lo juzga alguien que quiere una respuesta de sí o no y no se sentará a través de nada adicional. Confundir los dos, enviando a un cliente algo construido para una audiencia de portafolio, es una forma habitual en que un traspaso a un cliente sale mal incluso cuando el vídeo subyacente está bien hecho.

¿Qué necesita ver realmente un cliente sin conocimientos técnicos?

Empiece desde la solicitud original, no desde la estructura de la app. Si el cliente pidió "una forma de que los clientes reserven una hora", el vídeo debe mostrar exactamente ese flujo de reserva, descrito como reserva, no como quiera que se llame el objeto subyacente en el código. Omita cualquier pantalla que el cliente no pidió, incluso una pulida, ya que una pantalla inesperada invita a una pregunta sobre el alcance en lugar de confianza en la entrega.

Los clientes también leen el ritmo de forma distinta a un revisor técnico. Un desarrollador que ve un vídeo de revisión puede seguir un corte rápido entre pantallas porque ya entiende la estructura subyacente. Un cliente no puede, y un vídeo que se mueve a la velocidad de un desarrollador lo dejará sin saber qué acaba de ver. Baje el ritmo, deje que cada pantalla permanezca el tiempo suficiente para registrarse, y resista la tentación de comprimir el vídeo simplemente porque un corte más rápido le parecería más pulido a su propio ojo.

Lo que pidió el clienteLo que debe mostrar el vídeoLo que confunde más de lo que ayuda
Una descripción sencilla de un resultadoEse resultado exacto, de principio a finPantallas o términos que nunca mencionó
Una corrección de algo que estaba rotoLos mismos pasos que antes fallaban, ahora funcionandoUna zona distinta que también se tocó
Una capacidad nuevaEsa capacidad usada tal como la describieronOpciones de configuración dirigidas a un usuario técnico

Una lista de comprobación de vídeo demo de SaaS es una referencia general útil para este tipo de preparación, aunque esta guía concreta está escrita para una audiencia de cliente en lugar de un comprador general.

¿Cómo se prepara la compilación para un cliente que no la explorará?

Abra usted mismo la ruta desplegada y complete la tarea exacta con las palabras del cliente. Confirme que no hay datos de depuración sobrantes, ni texto de marcador de posición, ni nada en pantalla que pudiera plantear una pregunta que preferiría no responder por correo electrónico. Un cliente que no va a explorar la app tampoco le dará el beneficio de la duda sobre nada que parezca inacabado, ya que no tiene otro contexto del proyecto con el que compararlo.

  • Recorra la tarea exacta que describió el cliente, en el orden en que la describió.
  • Elimine cualquier dato de depuración o de marcador de posición que quedara del desarrollo.
  • Prepare una cuenta de demostración si el flujo necesita inicio de sesión, en lugar de enviar credenciales reales.
  • Confirme que nada en pantalla necesitaría una explicación de seguimiento.

Si se necesita un inicio de sesión, se puede preparar una cuenta de demostración para la renderización, y en GogoScreen las credenciales usadas se cifran, se usan para una única renderización y después se eliminan. Si primero se planifica un storyboard, las credenciales se conservan cifradas durante esa sesión y se eliminan como máximo dos horas después de su último uso. Eso importa aquí en concreto, ya que un cliente sin conocimientos técnicos difícilmente sabría qué hacer con un inicio de sesión aunque se le enviara uno, y se le sirve mejor no necesitando nunca uno en absoluto.

Piense en lo que hará el cliente inmediatamente después de ver el vídeo. Si el siguiente paso natural es una respuesta diciendo sí, apruébelo, esa respuesta no debería requerir nada más que el propio vídeo. Si el cliente necesitara hacer clic para verificar algo que el vídeo no mostró, el vídeo en realidad no ha terminado el trabajo, y vale la pena añadir la pieza que falta antes de enviarlo en lugar de esperar una pregunta de seguimiento que una grabación algo más larga podría haber evitado.

¿Cómo deben escribirse la indicación y la narración?

  1. Traduzca la solicitud a las propias palabras del cliente antes de decidir qué mostrar.
  2. Muestre el resultado antes que cualquier detalle de interfaz, ya que eso es lo que pidió.
  3. Narre en lenguaje sencillo, no en terminología de producto, para que nada necesite explicación después.

Escriba la indicación como explicaría el resultado por teléfono, no como se lo describiría a otro desarrollador. Si el mensaje original del cliente usó una frase concreta, reutilice esa frase en lugar de sustituirla por un término más preciso pero desconocido. La precisión que requiere un glosario no es precisión que el cliente pueda usar.

¿Qué va antes y después de este traspaso?

Si el cliente pidió una revisión antes de que el trabajo se considere terminado, esta guía cubre el paso de entrega, mientras que el recorrido de revisión de una app de Windsurf cubre cómo estructurar el flujo en torno a la propia solicitud original. Una vez que un proyecto está aprobado por el cliente y avanza hacia una audiencia más amplia, un tratamiento al estilo de un vídeo demo de Base44, un vídeo de página de destino de Base44 o un vídeo de lanzamiento en Product Hunt de Base44 responden cada uno a una pregunta posterior distinta, aunque el traspaso al cliente en sí todavía no necesite nada de eso.

Si el precio, en lugar de la entrega, es la pregunta abierta con este cliente, un vídeo demo para una página de precios de SaaS es una cuestión distinta y posterior. Si el cliente lo ve desde un hilo público en lugar de un mensaje privado, eso se acerca más a un vídeo demo para Show HN o una demo para Product Hunt de un agente de IA que a un traspaso privado a un cliente, y el tono debería cambiar en consecuencia. La mecánica subyacente sigue siendo la misma en cualquier caso, y la guía de vídeo demo de software a partir de una URL cubre esa mecánica con más profundidad si algún paso anterior no le resultó familiar.

¿Qué debe comprobar antes de enviarlo?

Vea el vídeo terminado como si fuera el cliente, sin conocimiento previo del proyecto. Confirme que el resultado es visible sin narración por si lo ve sin sonido desde un teléfono, y confirme que nada en pantalla necesita una pregunta de seguimiento para entenderse. Compare el formato con Demosmith si está considerando una forma distinta de empaquetar este mismo traspaso.

Deje margen para un reintento, ya que aproximadamente una de cada cinco renderizaciones lo necesita, y un traspaso a un cliente es un mal lugar para un retraso sorpresa. Cada cuenta nueva recibe 60 segundos de vídeo una vez, con marca de agua, lo cual suele ser suficiente para una sola tarea de cliente, y después, el tiempo comprado con recargas nunca caduca y el tiempo solo se usa cuando una renderización sale bien. Consulte los precios para conocer los planes, explore más guías y comparativas, o empiece desde la página de inicio de GogoScreen con la ruta y la indicación con las que se construye este traspaso.

Aclaraciones

Antes de empezar

¿Por qué no enviar simplemente al cliente un enlace de vista previa?

Un enlace de vista previa asume que el cliente lo abrirá, entenderá lo que está viendo e interpretará correctamente una interfaz que no conoce. Muchos clientes sin conocimientos técnicos no harán nada de eso de forma fiable, y un vídeo elimina por completo esa suposición.

¿Qué debe mostrar el vídeo a un cliente que no pidió detalle técnico?

Muestre el resultado que le importa, descrito en su propio lenguaje en lugar de la terminología interna de la app, con suficiente contexto para que no necesite haber visto el proyecto antes.

¿Es esto distinto de un vídeo demo general?

El flujo de grabación es el mismo. La diferencia es la audiencia. Un vídeo de revisión para un cliente se escribe para alguien que decide si el trabajo coincide con lo que pidió, no para un desconocido que decide si probar el producto.

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.