Hay una idea que se repite en la industria tech como si fuera verdad absoluta: diseño y desarrollo son disciplinas separadas con territorios claros. Los diseñadores piensan en el “qué” y el “por qué”. Los desarrolladores piensan en el “cómo”. Cada uno en su carril.

Después de años trabajando en la intersección de ambos mundos, puedo decirte que esa separación es artificial — y que los mejores productos que vi nacieron cuando esa línea se difuminó.

De dónde viene la separación

Históricamente, tiene sentido. Cuando el diseño web era estático — archivos de Photoshop convertidos en HTML por otra persona — la división era natural. El diseñador entregaba una imagen. El desarrollador la hacía funcionar.

Pero los productos digitales actuales no funcionan así. Son sistemas dinámicos, interactivos, con estados, con datos en tiempo real, con responsividad. Diseñar un producto sin entender cómo se construye es como diseñar un edificio sin entender la gravedad.

Lo que gano al entender desarrollo

No sé programar en un nivel profesional. No pretendo saberlo. Pero entiendo suficiente como para que mi diseño sea implementable sin sorpresas.

Cuando diseño un componente, pienso en estados: default, hover, active, disabled, loading, error, vacío. Esos no son “estados de diseño” — son estados que existen porque el código los necesita. Si los ignoro, estoy entregando un diseño incompleto.

Cuando propongo una animación, sé si es algo que CSS puede hacer nativamente o si requiere una librería adicional. Eso cambia la conversación con el equipo de desarrollo.

Cuando diseño un listado, pienso en paginación, en qué pasa con 10.000 ítems, en tiempos de carga. No porque sea mi responsabilidad técnica, sino porque esas restricciones afectan la experiencia del usuario.

Lo que los desarrolladores ganan al entender diseño

En ecoPortal, los developers que más disfruto trabajar son los que tienen sensibilidad por el detalle. Los que notan que un spacing está inconsistente, que un texto se trunca mal, que una transición se siente brusca.

No les pido que diseñen. Les pido que les importe cómo se siente usar lo que construyen. Y los mejores, los que realmente hacen la diferencia, tienen esa curiosidad natural.

Cómo mejorar esta relación en tu equipo

Sentate juntos (aunque sea virtualmente)

En vez de entregar diseños como un paquete terminado, sentate con el developer y caminá por el diseño juntos. Explicá las decisiones, preguntá por las restricciones, buscá soluciones en conjunto. Treinta minutos de pair design-development ahorran días de ida y vuelta.

Revisá la implementación juntos

No esperes a QA para ver cómo quedó. Pedí acceso al ambiente de staging y revisá la implementación mientras se desarrolla. El feedback temprano es más barato que el feedback tardío.

Usá los mismos términos

Si el design system tiene un componente llamado “Card”, que en el código se llame “Card”. Si hay un patrón de “Empty State”, que en el código se llame “EmptyState”. La nomenclatura compartida reduce malentendidos.

Celebrá el buen trabajo del otro lado

Un developer que implementó una micro-interacción perfectamente merece que lo reconozcas. Un diseñador que entregó specs claras y completas merece que lo reconozcas. El reconocimiento mutuo construye la relación.

Para cerrar

Diseño y desarrollo no son dos equipos que se pasan una pelota. Son dos perspectivas que, cuando se combinan, producen algo que ninguna podría lograr sola. Si podés romper la barrera entre esos mundos — aunque sea un poco — vas a hacer mejor trabajo. Garantizado.