Seguro ya viste este debate mil veces en Twitter, YouTube o LinkedIn: “¿El diseñador tiene que aprender a escribir código o no?”. Algunos defienden que lo nuestro es la composición, la psicología visual y la empatía con el usuario. Otros piensan que, si no sabés construir una aplicación completa, vas a quedarte atrás.
Yo considero que la realidad es mucho más tranquila y menos dramática que eso. Después de varios proyectos tropezando con entregas que no salían como esperaba, llegué a una conclusión bastante clara: no necesitas escribir código para beneficiarte de la programación, pero entender cómo funciona la lógica detrás de la propuesta cambia por completo tu criterio. Eso no me convierte en programador directamente, pero sí cambia la manera en que diseño cada proyecto.
Antes de diseñar tu propuesta, pensá como un programador
Capaz no sea lo más común de escuchar en una clase de diseño, pero te aseguro que los desarrolladores de tu equipo te lo van a agradecer toda la vida. A mí me pasaba seguido al principio: pasaba días enteros puliendo un prototipo en Figma, cuidando que cada sombra estuviera en su lugar y que la tipografía se viera increíble. Lo entregaba emocionado, y un par de semanas después, cuando entraba al staging para ver el resultado final, sentía un balde de agua fría. La tipografía no coincidía, los espaciados estaban descalibrados y la estructura general parecía una especie de Frankenstein mal armado.
Mi primer impulso, como el de muchos cuando empezamos, fue pensar que el programador había hecho todo a la carrera o que simplemente no le importaba la apariencia de las cosas. Pero la realidad era otra muy distinta: no era falta de capacidad técnica de ellos, sino que nunca nos habíamos puesto de acuerdo sobre cómo se iba a montar esa propuesta en el mundo real.
Diseñar una pantalla estática es como dibujar el plano de una casa en una hoja de papel sin considerar por dónde pasan las tuberías de agua o el cableado eléctrico. Se ve bonita en el papel, pero en cuanto tu albañil quiera levantar la primera pared, todo se desmorona. Cuando aprendí a ver los proyectos desde la perspectiva de un programador, me di cuenta de que mucho de lo que yo entregaba era un modelo rígido que no soportaba la realidad del navegador.
Antes de llegar a la etapa de elegir colores o mover botones, hay preguntas básicas que pueden condicionar todo tu diseño, por ejemplo:
- ¿Existen roles y permisos para los usuarios?
- ¿Qué bloques de la interfaz deberían cargar primero mientras el servidor responde?
- ¿Cuál es la arquitectura general sobre la que se va a sostener este proyecto?
- ¿Qué limitaciones concretas tiene la tecnología o el stack que está usando el equipo?
Si ves, hay todo un mapa de decisiones previas que tenés que validar antes de mandar tu archivo final. Yo no escribo código en mi día a día, pero aprendí a entender qué pasa detrás de bambalinas. Me di a la tarea de sentarme con mis compañeros, preguntarles cómo abordaban cada requerimiento y qué hacía exactamente el código que escribían para levantar mis propuestas. Entendí que gran parte de su trabajo es planificar y validar. Si algo no se puede armar de una forma o el stack pone trabas, ellos buscan rutas alternas. Cuando te involucras en esa conversación, tu cabeza deja de pensar solo en “entregar un diseño” y empieza a pensar en soluciones viables. Tu criterio madura, aprendes a iterar más rápido y la comunicación con el equipo fluye sin fricciones.
Las ventajas de saber sobre código y lógica técnica
Entender los fundamentos no significa que tengas que meterte a un bootcamp intensivo de Python de seis meses ni que tengas que aprenderte la sintaxis de memoria. Significa dedicarle tiempo a observar cómo piensan las personas que construyen software. Su trabajo está guiado principalmente por lógica estructurada, relaciones de causa y efecto y manejo de excepciones, más que por la psicología o las emociones. ¹
Menos demos que se rompen a mitad del camino
A todos nos ha tocado esa situación incómoda: estás en una llamada importante presentando una propuesta frente al cliente o tu jefe directo, haces clic en un flujo que en Figma funcionaba perfecto y, en la versión montada, todo se congela o salta un error inesperado. Muchas veces ignoramos que el programador se quebró la cabeza intentando hacer funcionar elementos visuales que a nosotros nos parecen fáciles, pero que por detrás exigen conexiones complejas que nadie planificó.
Cuando conoces los fundamentos, dejas de diseñar solo el “camino feliz”. Empezás a prever qué pasa si el usuario pierde conexión, qué tamaño toma una tarjeta si el apellido del cliente tiene treinta caracteres o cómo debe responder un menú en una conexión lenta. Eso reduce drásticamente las sorpresas desagradables al momento de presentar un avance. Tus prototipos se vuelven robustos porque nacieron considerando la lógica necesaria para ser construidos.
Hablar el mismo idioma que el equipo de desarrollo
No hay nada más cómodo que entrar a una llamada de media hora con un compañero de desarrollo y armar la dinámica de una funcionalidad sabiendo que los dos están en la misma página. Ya no necesitas explicar durante cuarenta minutos por qué necesitas una animación específica; podés explicarla en términos de estados, disparadores y comportamiento de cajas.
Ojo, una cosa es conocer y otra muy distinta es saber ejercer. Nadie te está pidiendo que te pongas a depurar funciones en JavaScript ni que asumas tareas de desarrollo backend. En agencias y empresas locales en El Salvador existe a veces la mala costumbre de buscar al “diseñador todero”: la persona a la que le pagan sueldo de diseñador junior pero le exigen editar video, gestionar pauta, diseñar interfaces y encima picar código de frontend. Conocer fundamentos técnicos no es para que regales tu trabajo haciendo dos roles a la vez; es para que tu voz gane peso estratégico. Cuando sabes justificar técnicamente por qué una solución visual es viable y escalable, tu perfil se vuelve muchísimo más valioso para cualquier cliente o equipo.
La brecha entre diseño y desarrollo se redujo gracias a la IA
El surgimiento de herramientas de inteligencia artificial aceleró este panorama con mucha fuerza. Hoy en día cualquier persona con curiosidad puede abrir una ventana de chat, pedirle a un modelo que genere una estructura básica y ver un prototipo funcionando en cuestión de minutos. Es verdad que también ha servido para inundar internet de cosas repetitivas, como la enésima aplicación genérica para tomar notas. Pero si mirás más allá de eso, la ventaja que tenés en tus manos es enorme: podés hacer tangibles muchas ideas que antes se quedaban archivadas en tu libreta.
Construir tus prototipos, pero no confiar a ciegas en el “vibe coding”
Con la popularidad del “vibe coding”, es fácil emocionarse. Le tirás un par de prompts a una herramienta, ves una interfaz armada con código funcional y sentís que estás creando el proyecto definitivo. Pero esa sensación puede ser engañosa si confiás demasiado.
El vibe coding es fantástico como herramienta de exploración temprana. Te permite comprobar si una idea tiene sentido, palpar la interacción y ver caminos que no se te habían ocurrido en estático. Sin embargo, no podés perder de vista que un producto digital de verdad se sostiene sobre la arquitectura, la seguridad y el criterio de especialistas. Utilizá estas herramientas para explorar y comunicar conceptos con mayor claridad, pero no asumas que un script generado en dos minutos está listo para salir a producción sin que un ingeniero revise qué hay debajo.
Entrená tu capacidad para iterar con ayuda de la IA
Una de las partes más pesadas de cualquier proyecto de diseño es enfrentarse al lienzo en blanco: ese primer borrador que todavía no sabes cómo arrancar o que está lleno de supuestos personales que no has contrastado con nadie. Ahí es donde herramientas como Claude o ChatGPT pueden servirte como un compañero de trabajo para descartar ideas.
Podés pedirle al modelo que analice tu flujo, que te señale qué estados de interfaz estás pasando por alto o que te explique qué limitaciones técnicas podría tener una funcionalidad que querés proponer. Eso te permite pulir tus borradores antes de mostrárselos a tu equipo. Tu criterio profesional no pierde peso porque GPT da una respuesta en treinta segundos; al contrario, tu criterio es el que decide si esa respuesta tiene sentido o si es una solución vacía. Cuando se entiende esto, la IA se convierte en un amplificador del criterio, no en un reemplazo del pensamiento.
Cinco formas de practicar sin cambiarte de profesión
Si querés empezar a construir este criterio sin abrumarte con manuales técnicos, te propongo cinco pasos sencillos que podés aplicar directamente en tu rutina de trabajo:
- Audita tus componentes en Figma: fijate si tus pantallas están compuestas por capas sueltas o si estás usando Auto Layout de verdad. Entender el Auto Layout con dirección vertical, horizontal y espaciados consistentes es exactamente lo mismo que entender Flexbox en CSS. Si tus diseños se adaptan bien en Figma cuando cambias el contenido, ya estás pensando como programador.
- Pedí una conversación corta con un dev de tu equipo: la próxima vez que termines un proyecto, escribile a tu compañero de desarrollo y preguntale: “¿Hubo algo en mi archivo que te haya complicado la maquetación?” Esa pregunta te va a enseñar más sobre buenas prácticas de handoff que diez tutoriales genéricos de internet.
- Inspeccioná tus páginas favoritas con DevTools: entrá a Chrome o Firefox, hacé clic derecho sobre cualquier botón o tarjeta que te guste y dale a “Inspeccionar”. Mirá la pestaña de estilos y fijate en el modelo de cajas: contenido, padding, border y margin. Comprender visualmente cómo esos cuatro valores definen el espacio te va a ahorrar horas de discusiones sobre espaciado.
- Usá la IA para buscar casos de error antes de diseñar: hoy en día evitá usar prompts para tareas aisladas, pero podés pedirle a ChatGPT o Claude que actúe como ingeniero de software senior y te diga qué casos de borde, fallas de red o errores de usuario debés considerar para esta interfaz. Diseñá tomando en cuenta esa lista.
- Documentá los estados de la interfaz en tu entrega: nunca entregues una pantalla sola. Para cada elemento interactivo clave, asegurate de incluir su estado por defecto, hover, deshabilitado, loading y error. Con eso, el equipo de desarrollo tendrá todo claro desde el minuto uno.
Pensalo así: el diseño y el desarrollo no son dos mundos opuestos compitiendo entre sí; son dos caras de la misma moneda. Si conocés los fundamentos detrás de lo que dibujás, dejás de pelear con las limitaciones técnicas y empezás a usarlas a tu favor.
No hace falta que hagas un rol de programador ni que aprendas a levantar bases de datos para sobresalir. Lo que te propongo es cultivar la curiosidad de entender qué pasa cuando tu diseño sale de Figma y entra al mundo real. Probá aplicar estas sugerencias en tu próximo proyecto y vas a notar de inmediato cómo cambia la dinámica con tu equipo.