Recorrido de revisión de una app de Figma Make

¿A qué debe corresponder el recorrido?

Empiece por la solicitud original, no por la construcción. Si un ticket pedía que «los usuarios puedan filtrar la lista por estado», el recorrido debe mostrar exactamente eso: la lista, el control de filtro y el resultado filtrado. Todo lo que el vídeo muestre más allá de esa solicitud es, en el mejor de los casos, un extra y, en el peor, una distracción de lo único que el revisor está comprobando.

Esta es una tarea más estrecha que un vídeo de traspaso a un cliente, donde el objetivo es obtener una decisión de alguien que ni siquiera conocía la solicitud de partida. Un revisor interno ya conoce la especificación. La única tarea del recorrido es cerrar la brecha entre la especificación y el resultado visible.

¿Qué debe indicarle la indicación a GogoScreen que grabe?

Escriba la indicación como un reflejo directo de la solicitud. Si la solicitud era que «los usuarios puedan filtrar la lista por estado», la indicación debería leerse algo así como «desde la lista completa, aplique el filtro de estado y muestre el resultado filtrado», no una descripción más amplia de toda la pantalla. GogoScreen devuelve un MP4 narrado construido en torno a esa indicación, con zooms en los clics relevantes, suavizado del cursor, cortes de silencios muertos y subtítulos, aproximadamente dos minutos después del envío.

Pruebe el flujo a mano antes de enviar la renderización. Confirme que el filtro, el formulario o la interacción que nombra la solicitud producen realmente el resultado esperado, y compruebe si hay alguna redirección, estado vacío o interrupción que pudiera desviar la grabación. Una renderización construida alrededor de un flujo que en realidad no funciona solo hará que el problema salga a la luz más tarde, delante del revisor en lugar de antes. Detectar ese tipo de carencia durante la comprobación manual cuesta unos minutos. Detectarlo en la reunión con el revisor cuesta todo el ciclo de revisión.

Mantenga el texto de la indicación ajustado a los términos usados en la solicitud o el ticket original, en lugar de los nombres internos utilizados dentro de la propia construcción. Un revisor que comprueba el vídeo frente a una especificación escrita debería poder seguirlo sin tener que traducir entre dos vocabularios distintos para la misma función.

¿Dónde encaja esto con el resto del proceso de revisión?

Una vez que una construcción supera la revisión interna, a menudo necesita pasar a otras audiencias. Un vídeo de demostración de Bubble, un vídeo de página de destino de Bubble, un vídeo de lanzamiento en Product Hunt de Bubble, compartir un proyecto de Bubble con un cliente y una demo de portafolio de Bubble cubren el mismo conjunto de tareas para esa plataforma, útil cuando una solicitud abarca dos constructores distintos. La guía de indicación de flujo en una línea profundiza en cómo escribir la indicación con precisión, y la guía de vídeo de demostración de app con inicio de sesión cubre el caso en el que el flujo solicitado está detrás de una cuenta real.

Para un formato de recorrido más amplio basado en el navegador, consulte la guía de vídeo de recorrido de aplicación web. Una vez que la construcción está aprobada y lista para una audiencia más amplia, la guía de vídeo de demostración de página de inicio y la guía de vídeo de demostración de Product Hunt cubren ese siguiente paso. Para una comparación de herramientas de grabación para el trabajo de revisión interna, lea GogoScreen frente a Screen Studio. Comience en la página de inicio de GogoScreen, consulte los precios, explore la biblioteca de guías completa, o vea el resto de las comparaciones.