Laboratorio de flujos de trabajo: implementa diseños directamente con Figma Make

Bienvenido a Laboratorio de flujos de trabajo, donde presentamos un flujo de trabajo de muestra usando productos y herramientas de Figma.

Tradicionalmente, el recorrido desde "Noté un pequeño detalle" hasta "Ya está implementado" pasa por un ticket. El diseñador documenta el cambio, este llega al backlog y termina enterrado bajo todo lo que el equipo de ingeniería ya se comprometió a entregar. Cuando se trata de pequeños ajustes de alta calidad, esa cola de trabajo es donde las buenas intenciones terminan perdiéndose. Son cambios demasiado pequeños para convertirse en una prioridad y demasiado importantes para descartarlos, por lo que quedan pendientes.

También hay un segundo costo. Cuando el diseñador entrega una descripción por escrito, los matices se pierden. "Reduce un poco el espaciado" o "El lector de pantalla anuncia esto de forma incorrecta" se convierten en un interminable intercambio de capturas de pantalla y aclaraciones, y el ingeniero termina traduciendo decisiones que el diseñador podría haber tomado directamente. ¿Y si hubiera otra forma de abordar este flujo de trabajo?

El problema

Tomemos como ejemplo el Museum of Speculative Futures (MOSF), un museo ficticio que explora cómo la cultura imagina el futuro. El equipo está mejorando la accesibilidad de su sitio web al mismo tiempo que lleva a cabo una reescritura completa de su arquitectura. Con varias prioridades compitiendo entre sí, asignar recursos a este proyecto representa un gran desafío. El diseñador quiere resolver las deficiencias de accesibilidad, mientras que el ingeniero necesita mantenerse concentrado en la reescritura, que también es una prioridad. Para alcanzar ambos objetivos, el gerente de producto propone un enfoque diferente: que los ingenieros se ocupen del trabajo más complejo y que el diseñador asuma de principio a fin los cambios de detalle,de menor esfuerzo, utilizando Figma Make con el código de producción. Ese último 20 % es precisamente lo que diferencia a un sitio web que simplemente funciona de uno que realmente es accesible, así que el equipo acuerda seguir ese plan. Acompaña al diseñador mientras cambia la forma habitual de trabajar y lleva sus cambios desde el lienzo, pasando por la revisión, hasta una pull request fusionada, todo ello sin crear un solo ticket.

Recopilar feedback en el lienzo

Antes de modificar nada, el diseñador quiere poner a prueba la experiencia actual. Para ello, utiliza el agentede Figma Design para generar un conjunto de personas sintéticas: una persona que visita el sitio por primera vez para planificar una visita, un miembro habitual y una persona que navega con un lector de pantalla. Luego hace que cada una recorra el sitio para recopilar feedback.

El feedback es concreto y, en su mayoría, se refiere a pequeños detalles: una etiqueta confusa en la página de exposiciones, una llamada a la acción que pasa desapercibida, un selector de fechas difícil de interpretar de un vistazo y una búsqueda que termina en una pantalla vacía cuando una colección no devuelve resultados. Ninguno de estos problemas supone un gran cambio por sí solo, pero, en conjunto, hacen que el sitio web sea más fácil de usar.

El diseñador implementa los cambios sugeridos y vuelve a presentarlos al equipo para obtener una primera validación. El diseñador, el ingeniero y el gerente de producto revisan juntos cada propuesta: una etiqueta más clara en la página de visitas, una llamada a la acción más visible y un selector de fechas más fácil de usar. Todos coinciden en que estos cambios contribuyen al objetivo compartido: un sitio que cualquier persona pueda recorrer y disfrutar, independientemente de cómo interactúe con la web.

Trabajar directamente con el código para evitar la acumulación

Como los cambios acordados son pequeños y están bien definidos, el diseñador, en vez de crear un ticket y esperar, pide al ingeniero acceso a la base de código. No pretende hacerse cargo de la reescritura, sino encargarse directamente de estas correcciones específicas.

El ingeniero concede el acceso y el diseñador conecta el repositorio de GitHub del proyecto a Make. Con la base de código de producción ya disponible dentro de Figma, el diseñador crea una nueva rama a partir del sitio actual y comienza por el cambio que parece más sencillo de la lista: el selector de fechas de la página de exposiciones, que las personas sintéticas generadas por el agente de Figma señalaron como difícil de interpretar.

En una maqueta estática, este cambio lleva cinco minutos. Pero, al trabajar directamente sobre el código, Make revela algo que el lienzo no puede mostrar: el selector de fechas no es un elemento aislado. Es un componente compartido, el mismo que se utiliza en el calendario de eventos y en el flujo de registro de membresías. Lo que parecía un único ajuste resulta ser un cambio que debe aplicarse simultáneamente en tres lugares.

Con un flujo de trabajo basado en tickets, probablemente solo se habría corregido el selector de fechas de la página de exposiciones, mientras que el calendario de eventos y el flujo de registro de membresías habrían seguido utilizando la versión anterior, generando una inconsistencia que quizá nadie detectaría hasta mucho después, si es que llegara a detectarla. Como el diseñador está trabajando directamente con el código, esa dependencia compartida es visible desde el principio y la corrección puede realizarse una sola vez, en el lugar adecuado.

Una vez completado ese cambio, el diseñador continúa con el resto de la lista: la etiqueta más clara, la llamada a la acción más visible y los estados vacíos más intuitivos. Cada cambio es pequeño por separado, pero, en conjunto, son los que transforman un sitio que simplemente funciona en uno que transmite cuidado por los detalles: ese último 20 % del trabajo que normalmente nunca sale del backlog.

Revisar los cambios con todo el equipo

Con los cambios ya implementados, el diseñador comparte el trabajo con el equipo para la revisión final. Es en este punto donde el objetivo de accesibilidad adquiere un carácter más concreto. Las mejoras visibles ya están listas. Ahora el equipo anota, directamente sobre cada elemento, cómo debe comportarse con las tecnologías de asistencia. Esto incluye: la aria-label que debe anunciar el selector de fechas compartido para que no solo sea legible, sino también comprensible cuando un lector de pantalla la lea en voz alta;una etiqueta para lectores de pantalla que coincida con el texto mostrado en pantalla;un orden de enfoque que llegue a la llamada a la acción en lugar de omitirla; y un estado vacío con un mensaje que pueda anunciar un lector de pantalla, para que una búsqueda sin resultados no termine en un silencio absoluto.

El gerente de producto confirma que todos los cambios siguen alineados con el objetivo de accesibilidad, el ingeniero define qué debe resolverse en el código y el diseñador incorpora los últimos ajustes.

Enviar la PR

Una vez resueltas las últimas anotaciones, el diseñador envía una pull request (PR) a la base de código directamente desde Make. El ingeniero revisa el código —que ahora incluye la intención de diseño actualizada, los comentarios del equipo y las anotaciones de accesibilidad asociados al mismo cambio—, lo aprueba y fusiona la rama. Las correcciones que habrían permanecido un trimestre en el backlog se implementan en un solo día.

Esta forma de trabajar supone un pequeño cambio con beneficios duraderos. Un ticket se cierra y desaparece, y con él se pierde el razonamiento que contenía. En cambio, un cambio fusionado conserva ese contexto: los comentarios, las anotaciones de accesibilidad y los motivos por los que el selector de fechas pasó a ser un componente compartido. Cuando alguien vuelva a revisar ese selector seis meses después, el recorrido que condujo hasta ese punto seguirá estando disponible como parte del historial compartido del equipo.

Camino a producción: otra forma de hacer la transferencia

El modelo tradicional de transferencia trata al diseñador y al ingeniero como dos estaciones de una línea de montaje. Ese enfoque funciona bien para funciones grandes y claramente definidas. Pero los acabados más finos, las mejoras de accesibilidad y el nivel de pulido que define la experiencia completa del producto requieren otra forma de trabajar: una en la que el diseñador intervenga directamente sobre el código.

Esta forma de trabajar no pretende que el diseñador se convierta en ingeniero ni que el ingeniero se convierta en diseñador. Permite que cada uno aporte su criterio donde más valor genera: los ingenieros permanecieron centrados en la renovación de la arquitectura, el diseñador se encargó de las mejoras de principio a fin y el gerente de producto mantuvo el proyecto alineado con el objetivo. La rama reunió las contribuciones de todo el equipo —el diseño visible, el feedback escrito y las etiquetas que leerá un lector de pantalla— desde el lienzo hasta una PR fusionada.

Con este flujo de trabajo, el último 20 % no se eliminó. Se envió.

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