Laboratorio de flujo de trabajo: desplegar diseños directamente con Figma Make

Bienvenido a Workflow Lab, donde presentamos un ejemplo de flujo de trabajo utilizando productos y herramientas de Figma.

Tradicionalmente, el camino desde "noté algo mínimo" hasta "se lanzó" pasa por un ticket. El diseñador lo redacta, se coloca en el listado de tareas pendientes y queda enterrado bajo todo lo que el equipo de ingeniería ya ha comprometido. Para pequeñas correcciones de alta calidad, esa cola es donde mueren las buenas intenciones. El trabajo es demasiado granular para priorizarse y demasiado importante para descartarse, por lo que permanece latente.

También hay un segundo coste. Cuando el diseñador entrega una descripción escrita, se pierde el matiz. "Haz el espaciado sea un poco más ajustado" o "el lector de pantalla anuncia esto de forma incorrecta" se convierten en un ir y venir de capturas de pantalla y aclaraciones, y el ingeniero se convierte en un traductor de decisiones que el diseñador podría haber tomado directamente. Pero ¿y si hay otra manera de abordar este flujo de trabajo?

El problema

Tomemos como ejemplo el Museo de Futuros Especulativos (MOSF), un museo ficticio que explora cómo la cultura imagina lo que viene a continuación. Están mejorando los aspectos de accesibilidad de su sitio web al mismo tiempo que realizan una reescritura completa de la arquitectura. Con diversas prioridades en competencia, dotar de recursos a este proyecto es un gran desafío. El diseñador quiere abordar las brechas de accesibilidad, mientras que el ingeniero necesita centrarse en la reescritura igualmente importante. Para cumplir ambos objetivos, el PM sugiere un camino diferente: mantener el trabajo pesado con los ingenieros, mientras que el diseñador se encarga de los cambios menores y artesanales de principio a fin utilizando Figma Make con su código de producción. El último 20% es precisamente lo que separa un sitio web que funciona técnicamente de uno que es verdaderamente accesible, por lo que el equipo se alinea en este plan. Sigue el proceso mientras un diseñador cambia este guion y lleva su trabajo desde el lienzo, a través de la revisión, hasta una solicitud de extracción fusionada, todo sin presentar un solo ticket.

Recibiendo comentarios en el lienzo

Antes de tocar nada, el diseñador quiere probar la experiencia actual bajo presión. Utilizan el agenteen Figma Design para generar un conjunto de personas sintéticas: un visitante por primera vez que planea un viaje, un miembro que regresa, alguien navegando con un lector de pantalla y hace que cada uno navegue por el sitio para recopilar comentarios.

Los comentarios vuelven específicos y en su mayoría pequeños: una etiqueta confusa en la página de exhibición, una llamada a la acción que es fácil de pasar por alto, un selector de fechas difícil de entender de un vistazo y una búsqueda que termina en una pantalla en blanco cuando no se encuentra ningún resultado en una colección. Ninguno de estos es un gran cambio, pero juntos son detalles que hacen que el sitio web sea más fácil de usar.

El diseñador aborda los comentarios, luego lleva los cambios de diseño de vuelta al equipo para un chequeo general. Juntos, el diseñador, el ingeniero y el gerente de producto revisan cada uno: una etiqueta más clara en la página de visita, una llamada a la acción más visible y un selector de fecha más fácil de usar. Están de acuerdo en que estos sirven al objetivo compartido: un sitio que todos puedan navegar y disfrutar, independientemente de cómo experimenten la web.

Trabajar directamente con código para evitar la lista de tareas pendientes

Los cambios acordados son pequeños y bien entendidos, por lo que en lugar de escribir un ticket y esperar, el diseñador le pide al ingeniero acceso al código base, no para hacerse cargo de la reescritura, sino para manejar estas correcciones específicas directamente.

El ingeniero concede acceso, y el diseñador conecta el repositorio de GitHub del proyecto a Make. Con la base de código de producción ahora viva dentro de Figma, el diseñador crea una nueva rama a partir del sitio actual y comienza con lo que parece ser la corrección más sencilla de la lista: el selector de fecha en la página de exposición, que las personas del agente de Figma encontraron difícil de interpretar.

En un mockup estático, esto es un cambio de cinco minutos. Pero al trabajar contra el código, Make resalta algo que el lienzo no puede: el selector de fecha no es un caso aislado. Es un componente compartido, el mismo que se usa en el calendario de eventos y dentro del flujo de registro de membresía. Lo que parecía un ajuste único es en realidad un cambio que necesita darse en tres lugares a la vez.

Un flujo de trabajo basado en tickets podría haber solucionado solo el selector de fecha en la página de exhibición, dejando el calendario de eventos y el flujo de membresía en la versión antigua, una inconsistencia que nadie notaría hasta mucho más tarde, si es que lo hace. Debido a que el diseñador está en el código, la dependencia compartida es ahora visible, y la corrección se puede hacer una sola vez, en el lugar correcto.

Una vez completado, el diseñador trabaja en el resto de la lista: la etiqueta más clara, la llamada a la acción más visible, los estados vacíos más amigables. Cada uno es menor por sí solo, pero juntos son lo que convierte un sitio que simplemente funciona en uno que se siente considerado: el último 20% que generalmente nunca sale de la lista de pendientes.

Revisando con todo el equipo

Con los cambios realizados, el diseñador envía el trabajo al equipo para una revisión final. Aquí es donde el objetivo de accesibilidad se vuelve específico. Las correcciones visibles están hechas. Ahora el equipo anota cómo debería funcionar cada uno para la tecnología asistiva, justo donde se encuentra. Eso incluye: la etiqueta aria que el selector de fechas compartido debería anunciar para que no solo sea legible sino también audible, una etiqueta de lector de pantalla que coincida con lo que está en la pantalla, un orden de enfoque que llegue a la llamada a la acción en lugar de saltarla, y un estado vacío con un mensaje que un lector de pantalla pueda anunciar para que una búsqueda sin resultados no sea una respuesta silenciosa.

El PM confirma que todo sigue alineado con el objetivo de accesibilidad, el ingeniero opina sobre lo que se debe manejar en el código, y el diseñador integra los últimos ajustes.

Empujando el PR

Una vez que se abordan las últimas anotaciones, el diseñador envía una solicitud de incorporación al código base directamente desde Make. El ingeniero revisa el código (ahora con la intención de diseño actualizada, los comentarios del equipo y las anotaciones de accesibilidad todas adjuntas al mismo cambio), lo aprueba y fusiona la rama. Las correcciones que habrían pasado un trimestre en la lista de tareas pendientes se lanzaron en un día.

Esta forma de trabajar es un cambio simple con un beneficio a largo plazo. Un ticket se cierra y desaparece, y las decisiones que vivían dentro de él se evaporan con él. El cambio fusionado las conserva: los comentarios, las anotaciones de accesibilidad, el razonamiento para hacer del selector de fecha un elemento compartido. Cuando alguien revisite el selector de fecha en seis meses, el camino que llevó a este punto estará ahí en la historia compartida del equipo.

Camino a producción: un tipo de entrega diferente

El modelo de entrega tradicional trata al diseñador y al ingeniero como dos estaciones en una línea de ensamblaje. Eso funciona bien para características grandes y bien definidas. Pero acabados más finos, mejoras de accesibilidad y detalles que definen la experiencia completa del producto, requieren un tipo diferente de entrega, una en la que el diseñador trabaje directamente en el código.

Esta forma de trabajar no exige que el diseñador se convierta en ingeniero, o el ingeniero en diseñador. Permite a cada uno aplicar criterio donde más importa: los ingenieros se quedaron en la remodelación de la arquitectura, el diseñador se encargó de los refinamientos de principio a fin, y el PM mantuvo todo el proyecto orientado hacia la meta. La rama llevó la contribución de todos: diseño visible, comentarios escritos y las etiquetas que un lector de pantalla leerá en voz alta, desde el lienzo hasta una PR fusionada.

Con este flujo de trabajo, el último 20% no fue eliminado. Fue lanzado.

Obtenga más información cómo enviar directamente sus proyectos de Make a GitHub en nuestro centro de ayuda o vea nuestras últimas charlas de Config sobre diseñar en código y trabajar con el agente de diseño de Figma.