Entregas diseño-ingeniería más allá de los comentarios
Por qué los comentarios de Figma no bastan para cerrar la brecha en las entregas diseño-ingeniería, y qué funciona de verdad para equipos pequeños.
By Ellis Keane · 2026-04-06
La mejor herramienta de entrega diseño-ingeniería es una que los ingenieros nunca abren
Cuanto más invierten los diseñadores en perfeccionar su entrega en Figma – auto-layout, tokens de diseño, anotaciones del modo dev, documentación de componentes –, peor suele ser la entrega diseño-ingeniería real. No porque el trabajo de diseño sea malo – generalmente es brillante –, sino porque todo ese esfuerzo vive en una herramienta que los ingenieros abren a regañadientes, hojean rápidamente y luego cierran para construir lo que creen que vieron.
He estado en ambos lados. Empecé como diseñador (bueno, «diseñador» – hacía sitios web de casas de empeño en New Hampshire, así que seamos generosos con el título) y ahora escribo la mayor parte del código de ingeniería de Sugarbug. El problema de la entrega diseño-ingeniería no es un problema de herramientas, es un problema de flujo de trabajo. La información existe, solo está en el lugar equivocado en el momento equivocado.
La entrega diseño-ingeniería típica se parece a esto: un diseñador pasa tres días puliendo un frame en Figma, añade doce comentarios explicando decisiones de espaciado y casos límite, etiqueta al ingeniero y luego espera. El ingeniero abre Figma, mira el frame durante unos noventa segundos, piensa «bien, entendido», cierra la pestaña y construye algo que es un 80 % correcto y un 20 % incorrecto – de formas que llevarán otra semana de ida y vuelta para resolver. ¿Los doce comentarios? Quizás leyó cuatro.
Una entrega diseño-ingeniería no es un archivo que se lanza por encima de un muro. Es contexto que necesita vivir donde trabaja el ingeniero – en el issue, en el PR, en el código –, no en una herramienta de diseño que visita una sola vez.
Por qué los comentarios de Figma tienen la forma equivocada para las entregas
Uso Figma todos los días y genuinamente me gusta (que probablemente sea un defecto de personalidad a estas alturas). Pero los comentarios de Figma están optimizados para la colaboración entre diseñadores, no para la entrega diseño-ingeniería, y la diferencia importa más de lo que la mayoría de los equipos reconoce.
El desajuste fundamental es este: los comentarios de Figma están anclados espacialmente a frames y componentes. Existen dentro de un archivo de diseño. Pero los ingenieros no trabajan dentro de archivos de diseño – trabajan en issues de Linear, PRs de GitHub y su IDE. Cuando un diseñador deja un comentario en un frame diciendo «este desplegable debería colapsar en viewports móviles por debajo de 640px», esa información ahora está atrapada en Figma. No se convierte en una tarea. No aparece en el flujo de trabajo del ingeniero. Existe en un universo paralelo que el ingeniero tiene que recordar visitar, y (aquí está la parte que realmente importa) abrir Figma no forma parte del ciclo de trabajo natural de un ingeniero de la forma en que sí lo hace revisar Linear o hacer review de PRs.
El resultado es predecible: las decisiones de diseño críticas se pierden, no porque alguien sea descuidado, sino porque la información está en la herramienta equivocada. Es como dejar un post-it en el escritorio de alguien que trabaja desde casa.
Dónde los diseñadores dejan contexto
- Comentarios de Figma – Espaciales, anclados a frames
- Anotaciones del modo dev de Figma – Detalladas pero requieren abrir Figma
- Hilos de Slack – Conversacionales, no buscables pasada una semana
- Documentación del sistema de diseño – Exhaustiva pero rara vez consultada a mitad de sprint
Dónde miran los ingenieros realmente
- Descripción del issue de Linear – Lo primero que leen antes de empezar
- Descripción del PR de GitHub – Referencia durante la implementación
- Comentarios de código – Descubiertos durante la revisión
- IDE – Donde pasan el 90 % de su tiempo
Qué funciona de verdad (de alguien que hace ambas cosas)
Durante el último año construyendo Sugarbug, he sido el diseñador y (principalmente) el ingeniero, lo que significa que he tenido la inusual experiencia de hacerme entregas a mí mismo y aun así perder contexto. Si yo no puedo recordar mis propias decisiones de diseño del martes pasado, no hay forma de que un ingeniero separado vaya a captar todo de un hilo de comentarios de Figma.
Esto es lo que realmente ha funcionado para el proceso de entrega diseño-ingeniería de nuestro equipo, y nada de ello implica escribir mejores comentarios de Figma.
1. Escribe la decisión de diseño en el issue, no en el archivo de diseño
Antes de que un ingeniero empiece a construir, el contexto de diseño necesita vivir en el issue de Linear (o lo que sea que use tu equipo). No un enlace al archivo de Figma con «ver diseños» – eso es una evasión, y todo el mundo lo sabe. El issue debe incluir:
- Qué: Una captura de pantalla o frame exportado (no un enlace de Figma – un PNG que el ingeniero pueda ver sin abrir otra herramienta)
- Por qué: El razonamiento detrás de las decisiones clave. «Elegimos un panel lateral en lugar de un modal porque el usuario necesita referenciar la lista mientras edita» – una oración que ahorra tres rondas de «¿por qué no un modal?»
- Casos límite: ¿Qué pasa en móvil? ¿Qué pasa con texto largo? ¿Qué pasa cuando no hay datos? Si lo has pensado, escríbelo. Si no lo has pensado, dilo (honestamente, «aún no he resuelto el estado vacío» es más útil que el silencio)
2. Las revisiones de diseño ocurren en el issue, no en Figma
Cuando recibo hallazgos de diseño durante la implementación, los quiero en el hilo del issue de Linear, no como un comentario de Figma que quizás no vea en dos días. El issue es mi única fuente de verdad para el trabajo – si el hallazgo vive ahí, lo veré la próxima vez que revise el issue, que es varias veces al día. Si vive en Figma, lo veré cuando abra ese archivo por casualidad, que quizás no sea nunca.
Esto no significa que nunca se usen los comentarios de Figma. Son estupendos para la colaboración entre diseñadores, para anotar detalles visuales específicos y para conversaciones sobre el diseño en sí. Pero en el momento en que el hallazgo pasa a ser «el ingeniero necesita cambiar algo», tiene que moverse al flujo de trabajo de ingeniería.
stat: "La mayoría" headline: "Los comentarios de Figma no fueron vistos durante más de 48 horas cuando los usábamos para las entregas" source: "Experiencia de nuestro equipo durante 3 meses de seguimiento informal"
3. Cierra el ciclo con capturas de pantalla, no con suposiciones
La forma más barata de validar una entrega diseño-ingeniería es una captura de pantalla. Cuando un ingeniero termina de implementar un componente, pega una captura en el PR o en el issue y etiqueta al diseñador. «¿Esto coincide?» tarda diez segundos y detecta la desviación del 20 % antes de que se publique. Sin reuniones, sin ritual de comparación en Figma – solo un PNG y una pregunta.
Hemos empezado a hacer esto en cada PR de UI, y el número de conversaciones «esto no coincide con el diseño» cayó a casi cero. Las conversaciones que quedan son casos límite genuinos que el diseño no cubrió, lo cual está bien – ese es el tipo de cosa que debería discutirse, no el básico «usaste 16px de padding en lugar de 12px».
4. Deja que el contexto fluya entre herramientas automáticamente
Aquí es donde mencionaré Sugarbug, porque literalmente lo construimos para resolver este problema específico. Nuestro diseñador deja un comentario en Figma sobre un cambio de espaciado. Sugarbug recoge ese comentario, lo conecta con el issue relevante de Linear y el PR de GitHub, y el ingeniero lo ve en su flujo de trabajo sin abrir Figma. La entrega diseño-ingeniería deja de ser un ritual manual de copiar y pegar y empieza a ser algo que simplemente ocurre.
Pero si no usas Sugarbug (y la mayoría de vosotros no lo hacéis – todavía estamos en pre-lanzamiento), la versión manual es: asigna a alguien como «puente de entrega» que revise los comentarios de Figma diariamente y copie el hallazgo relevante en los issues de Linear. Es tedioso, pero funciona, y es infinitamente mejor que esperar que los ingenieros recuerden revisar Figma.
Si yo no puedo recordar mis propias decisiones de diseño del martes pasado, no hay forma de que un ingeniero separado vaya a captar todo de un hilo de comentarios de Figma. attribution: Chris Calo
Tu lista de verificación para la entrega diseño-ingeniería
Si te llevas una sola cosa de este artículo, que sea esta: la solución no son mejores herramientas (bueno, no principalmente – aunque estoy construyendo una, así que tómalo con cautela). La solución es establecer normas sobre dónde viven las decisiones de diseño, y asegurarse de que ese «dónde» esté dentro del flujo de trabajo natural del ingeniero.
- [ ] Exporta los frames clave como PNGs en el issue de Linear (no solo un enlace de Figma)
- [ ] Escribe el «por qué» de cada decisión de diseño importante en la descripción del issue
- [ ] Lista los casos límite conocidos (móvil, estados vacíos, texto largo) – o indica explícitamente lo que aún no has resuelto
- [ ] Mueve el hallazgo de implementación de los comentarios de Figma al hilo del issue
- [ ] Exige una captura de pantalla en cada PR de UI antes de la aprobación del diseño
- [ ] Asigna una persona «puente de entrega» si no tienes herramientas para conectar Figma y Linear automáticamente
Preguntas frecuentes
Q: ¿Por qué fallan los comentarios de Figma como herramienta de entrega diseño-ingeniería? A: Los comentarios de Figma viven dentro del archivo de diseño, desconectados del flujo de trabajo de ingeniería. Los ingenieros trabajan en Linear, GitHub y su IDE, no en Figma. Un comentario en un frame no se convierte en una tarea a menos que alguien lo copie manualmente, y ese paso manual es donde se rompe la entrega diseño-ingeniería. No es un problema de personas, es un problema de límites entre herramientas.
Q: ¿Conecta Sugarbug los comentarios de Figma con los issues de Linear automáticamente? A: Sí – ese es uno de los problemas específicos para los que lo construimos. Sugarbug extrae los comentarios de Figma y los conecta con los issues relevantes de Linear y los PRs de GitHub, de modo que el hallazgo de diseño aparece en el flujo de trabajo del ingeniero sin que nadie copie y pegue entre herramientas. Lo usamos nosotros mismos todos los días, y la diferencia es (honestamente) un poco vergonzosa dada la sencillez de la idea.
Q: ¿Cuál es el mejor proceso de entrega diseño-ingeniería para equipos pequeños? A: Escribe la decisión de diseño en el issue de Linear antes de que el ingeniero empiece a construir. Incluye el razonamiento, no solo lo visual. Si durante la implementación surgen casos límite, discútelos en el hilo del issue, no en un comentario de Figma que el ingeniero tiene que buscar. El proceso más simple suele ser el más duradero.
Q: ¿Cómo se gestionan los cambios de diseño después de que la ingeniería ha comenzado? A: Trátelos como cambios de alcance: documenta el cambio en el issue con un claro antes y después, explica el razonamiento y deja que el ingeniero evalúe el coste de implementación antes de comprometerse. Los peores fallos de entrega ocurren cuando los cambios de diseño llegan como comentarios informales de Figma sobre trabajo que ya ha sido construido – así es como se consiguen ingenieros resentidos y diseñadores frustrados.
Recibe inteligencia de señales directamente en tu bandeja de entrada.