Trabajar con desarrolladores: cómo colaborar sin pasar diseños por encima de la pared
Cómo colaborar con desarrolladores como diseñador: involucrarlos pronto, nombrar bien el archivo, anotar lo que no se ve y gestionar los cambios.
¿Qué significa realmente trabajar con desarrolladores?
Durante mucho tiempo el modelo fue secuencial: diseño, entrego, construyen. Figma describe ese modelo como uno en el que las pantallas finales y los assets se tenían que lanzar por encima de una valla para que desarrollo los atrapara (Figma, “Guide to Developer Handoff”). El problema es que cada entrega tardía trae sorpresas.
La alternativa es tratar la colaboración como un proceso continuo. El handoff no es un momento: es una serie de conversaciones que empiezan antes del diseño final y siguen mientras se construye.
¿Por qué le importa a un diseñador?
Porque muchos problemas de producto se detectan tarde, cuando cambiar algo cuesta más. Un desarrollador puede decirte en diez minutos que una animación es costosa o que un dato no existe en la base de datos. Si lo sabes en la fase de wireframes, ajustas el diseño sin drama.
Figma recomienda pedir feedback de viabilidad con wireframes, cuando las ideas aún son flexibles, y no con una pantalla pulida que ya nadie quiere tocar (The Designer’s Handbook for Developer Handoff).
¿Cómo se organiza el trabajo día a día?
Estas son prácticas que recomiendan las guías de Figma y de Built In:
- Involucra pronto. Haz una reunión de arranque temprana con desarrollo, para que puedan definir requisitos técnicos y proponer una arquitectura general, y organiza sesiones de ideas conjuntas (Built In, “Designer-developer collaboration”).
- Pregunta con precisión. Pide restricciones de datos, estados que faltan y componentes reutilizables que ya existan. Preguntas concretas dan respuestas útiles.
- Organiza el archivo por estado. Figma cuenta cómo algunos equipos separan el trabajo en páginas: lo que sigue en curso, lo que está listo para recibir feedback y lo que está listo para construir. Así nadie tiene que adivinar qué está terminado.
- Nombra con intención. Un marco llamado “Frame 123” es un div genérico. Figma recomienda dar nombres claros a los estilos de color, tipografía y efecto: así es más fácil hacerlos coincidir con lo que hay en el código. La code syntax de Figma y Code Connect refuerzan ese vínculo.
- Marca el estado. Etiqueta con “Ready for dev” las secciones terminadas y define qué significa “listo para handoff” en tu equipo. Antes de entregar, abre el archivo en Dev Mode para ver lo mismo que verá la persona de desarrollo.
- Menciona a las personas. Etiqueta a cada desarrollador por su nombre en los comentarios del archivo para recibir feedback asíncrono.
Built In señala que la interacción entre diseño y desarrollo no debería limitarse a la fase de handoff, y recomienda recoger feedback de desarrollo de forma directa y regular. Una buena pista: analiza las preguntas que hacen después de revisar las especificaciones, porque indican qué faltó en el archivo.
Si una práctica se repite, déjala por escrito en el handoff de diseño del equipo, no en la memoria de una persona.
¿Qué anotar que no se ve en el mockup?
Un mockup muestra el caso feliz. Los desarrolladores construyen también los casos raros. Anota:
- Comportamiento responsive: qué valores son fijos y cuáles se adaptan al tamaño de pantalla.
- Estados de éxito, error, vacío y carga.
- Diferencia entre un enlace y un botón cuando ambos se parecen.
- Transiciones con sus duraciones y su comportamiento con movimiento reducido.
- Textos largos, imágenes de baja resolución y perfiles incompletos.
Si separas una instancia del sistema de diseño, explica por qué. Ese registro evita que alguien lo “arregle” después creyendo que es un error.
¿Qué conviene preguntar en la reunión de arranque?
La reunión de arranque sirve para que desarrollo defina requisitos técnicos y proponga una arquitectura general. Llévala con preguntas, no con pantallas cerradas:
- ¿Qué datos existen hoy y cuáles habría que crear?
- ¿Qué componentes del sistema de diseño podemos reutilizar?
- ¿Qué partes de la idea son caras de construir y cuáles son baratas?
- ¿Qué estados o casos raros ya conocen por experiencia con el producto?
Anota las respuestas en el propio archivo, junto a las pantallas a las que afectan.
Ejemplo
Ejemplo ilustrativo: un diseñador entrega una pantalla de checkout con el botón “Pagar” centrado y sin más. En el desarrollo aparecen tres preguntas: qué pasa si el pago tarda más de diez segundos, qué ocurre si la tarjeta es rechazada y qué texto ve el usuario sin conexión. Si esos estados se hubieran documentado antes, el equipo habría discutido el flujo de error en una reunión corta y no después de una semana de construcción.
¿Cuándo NO conviene involucrar a todo el equipo?
- En decisiones de exploración personal. Un boceto que quieres probar solo no necesita una reunión con todo desarrollo.
- Cuando la pregunta es de estrategia de negocio. Para eso están producto y stakeholders, no la conversación con el código.
- Cuando el ruido supera el aporte. Si cada cambio de color pasa por el canal de ingeniería, la relación se deteriora.
Errores comunes
- Tratar el handoff como un único momento al final.
- Entregar solo la pantalla final sin estados de éxito ni de error.
- Pedir cambios de alcance después de que algo ya está construido.
- Ceder siempre a la factibilidad técnica a costa de la experiencia del usuario, o al revés.
- Dejar que las preguntas repetidas se queden sin respuesta en la documentación.
Cómo empezar mañana
Antes de tu próxima reunión de diseño, elige una pantalla y escribe en una lista los estados que no aparecen en el mockup. Mándala a una persona de desarrollo con dos preguntas concretas: ¿qué dato no tenemos? ¿qué componente ya existe? Después revisa qué preguntas se repiten y conviértelas en una plantilla de handoff o en parte de tu documentación de diseño.
Si el equipo ya trabaja con un sistema de diseño, mira también cómo contribuir a un design system para que los cambios de ambos lados sigan un camino claro.