Si me preguntás cuál es la habilidad más importante de un product designer, mi respuesta no es “empatía con el usuario” ni “pensamiento visual”. Es la capacidad de trabajar bien con developers.
Suena provocador, pero lo digo en serio. Podés ser el diseñador más talentoso del mundo, pero si tus diseños no se implementan bien — o no se implementan del todo — tu talento no le sirve a nadie.
El problema más común
He visto este patrón decenas de veces: un diseñador pasa semanas perfeccionando un diseño en Figma, lo presenta con orgullo, y el developer dice “esto no se puede hacer en el tiempo que tenemos” o, peor, “esto no se puede hacer”. El diseñador se frustra. El developer se frustra. El producto sufre.
¿El problema? Que la conversación empezó demasiado tarde.
Lo que hago diferente
En ecoPortal, mi relación con el equipo de desarrollo es parte del proceso de diseño, no algo que pasa después. Esto es lo que funciona para mí:
Involucro a los devs temprano
Antes de pulir una interfaz, comparto sketches o wireframes con los developers. No para pedir permiso — para entender restricciones. A veces descubro que lo que planeé es trivial de implementar. Otras veces descubro que requiere tres meses de refactoring. Esa información cambia mi diseño, y es mejor saberla al principio que al final.
Hablo su idioma (hasta cierto punto)
No necesito saber programar. Pero sí necesito entender conceptos básicos: qué es un componente, cómo funcionan los estados, qué implica una llamada a una API. Eso me permite tener conversaciones productivas.
Cuando digo “necesito que este dropdown cargue los resultados dinámicamente”, un developer sabe exactamente qué estoy pidiendo. Cuando digo “quiero que esta lista sea mágica y se actualice sola”, no.
Entrego especificaciones claras
Mis archivos de Figma no son obras de arte abstractas que requieren interpretación. Tienen estados documentados (default, hover, error, loading, vacío), notas sobre comportamiento, y medidas cuando son relevantes. No porque desconfíe de los devs — porque respeto su tiempo.
Acepto compromisos técnicos
A veces la implementación ideal no es viable. Y eso está bien. Mi trabajo es encontrar el punto donde la experiencia del usuario sea buena dentro de las restricciones técnicas reales. Eso requiere flexibilidad y pragmatismo.
Lo que los developers necesitan de vos
Le pregunté a developers con los que trabajo qué valoran de un diseñador. Las respuestas más comunes:
- Que no cambie todo a último momento. Las iteraciones son normales, pero los cambios radicales tarde en el sprint son destructivos.
- Que piense en los edge cases. ¿Qué pasa si el texto es muy largo? ¿Y si no hay datos? ¿Y si falla la conexión?
- Que esté disponible para preguntas. Durante la implementación, surgen dudas. Un diseñador que responde rápido hace que el proceso fluya.
- Que entienda que hay deuda técnica. No todo se puede hacer perfecto a la primera. A veces se hace una versión funcional y se mejora después.
Lo que vos necesitás de los developers
La relación es bidireccional. Cosas que un designer puede pedir legítimamente:
- Que te avisen si algo se va a implementar distinto a lo diseñado.
- Que te incluyan en las decisiones técnicas que afectan la experiencia del usuario.
- Que revisen la implementación juntos antes de lanzar.
El secreto que nadie dice
Los mejores productos que vi en mi carrera no salieron de diseñadores brillantes trabajando solos. Salieron de diseñadores y developers que se respetan mutuamente, que hablan seguido, y que entienden que están del mismo lado. Si invertís en esa relación, todo lo demás mejora.