Hace poco vi una charla sobre design engineering que puso en palabras algo que llevo tiempo sintiendo. Hay una brecha en cómo la mayoría de equipos construye software y me lleva molestando bastante tiempo.
El escenario es este: tienes diseñadores que se preocupan profundamente por cómo se ve algo, e ingenieros que se preocupan profundamente por cómo funciona. Ambos grupos son buenos en lo suyo. Pero no hablan el mismo idioma. Un diseñador entrega un archivo de Figma a un frontend engineer que no termina de entender tipografía o sistemas de espaciado. Un ingeniero intenta explicar restricciones de paginación a un diseñador que nunca pensó en gestión de estado. Y en ese handoff, en ese hueco entre ambos lados, la calidad se muere en silencio.
Los design engineers viven en ese hueco.
Entonces, ¿qué es exactamente un design engineer?
No hay una definición única y limpia, pero en el núcleo un design engineer es alguien que se mueve con fluidez tanto en código como en diseño y se niega a tratarlos como cosas separadas. Es el intérprete. Puede mirar un mockup de Figma y ya ver el árbol de componentes en su cabeza. Puede tomar una API backend caótica y convertirla en algo que realmente se sienta bien al usarlo.
Lo interesante es que los design engineers no son todos iguales. Hay un espectro completo. Algunos están obsesionados con el último tramo del acabado: toman una feature que ya está “lista” y le añaden animaciones, transiciones y pequeños detalles que la hacen sentirse viva. Otros están más metidos en design systems, construyendo librerías de componentes y asegurándose de que el código sea tan limpio y consistente como el propio producto. Ambos hacen falta. El hilo común es que todos se preocupan por cómo se siente la interfaz y empujan ese diez por ciento extra que la mayoría se salta.
¿En qué se diferencia esto de un frontend engineer o de un diseñador?
Buena pregunta. Un frontend engineer recibe un diseño y lo implementa. Hará que funcione, que respete la spec y que se publique. Pero muchas veces le falta criterio (hablo de eso en un segundo) para tomar decisiones por su cuenta sobre lo que no estaba en la spec. La mayoría de diseños en Figma son estáticos. Nadie especificó qué pasa cuando un botón transiciona entre estado de carga, en progreso y completado. Un frontend engineer ve tres estados e implementa tres estados. Un design engineer ve una oportunidad de convertir esa interacción mínima en algo memorable.
Los full stack engineers tienen las habilidades todavía más repartidas, de backend a frontend. Están intentando sacar el producto y van a pasar por encima de detalles en los que un design engineer se quedaría más tiempo.
¿Y los diseñadores? Su trabajo termina en Figma. Pueden hacer algo precioso, pero no pueden navegar una web dentro de Figma. Un design engineer puede diseñar el producto y construirlo. Esa fase de handoff entre medias directamente se la salta.
Por qué realmente necesitamos este rol
Para mí, hay tres razones claras.
El problema del slop. Ahora mismo estamos ahogados en basura generada por IA. Alguien abre una herramienta de coding con IA, escribe “hazme una web” y salen gradientes morados, espaciados malos, colores incoherentes y copy flojo. Y lo más importante: la gente normal lo nota. Quizá no sabe explicarlo técnicamente, pero siente que algo está mal. No hay calidez humana. Los design engineers son la línea de defensa contra eso. Se aseguran de que lo que se publica se sienta hecho por una persona que cuidó los detalles.
El criterio. Esta es la grande y merece tiempo. En la charla había una demo muy buena de dos versiones de un botón que cambiaba de estado. En una versión solo cambiaba el texto y el contenedor mantenía el mismo ancho. En la otra, el contenedor se adaptaba con una transición suave al nuevo contenido. La mayoría de apps habría hecho el botón de ancho completo para esquivar el problema o directamente habría evitado la transición. Un design engineer detecta ese momento y piensa: “aquí puedo añadir algo que la gente recuerde”.
Velocidad. Con herramientas de IA, los design engineers pueden meterse en terrenos desconocidos muy rápido. La persona de la charla construyó un laboratorio de sonido completo con Web Audio APIs sin experiencia previa en sound design. Antes de IA eso eran dos semanas de investigación mínimo. Ahora son unas horas. Pero la clave es esta: la salida de IA era fea. Botones crudos, sin estilo. El trabajo del design engineer fue inyectar criterio: toques de color, objetos que mutan, detalles que convierten una herramienta funcional en una experiencia. Esa capa final es la diferencia entre algo que funciona y algo que la gente realmente disfruta.
Vale, ¿pero qué significa realmente “criterio”?
La palabra “criterio” se usa mucho online y a veces se vuelve un debate raro. Pero en realidad es más simple de lo que parece.
La charla usaba la analogía de un productor musical famoso que estuvo en la sala de algunas de las canciones más grandes de la industria. La cosa es que ni siquiera es realmente músico. Es la persona a la que le preguntan: “¿esto está bien o está mal?”. Y la gente confía en su juicio. Eso es criterio. Como design engineer, necesitas ser esa persona en la sala capaz de recibir un diseño y decir: “vamos a dar un paso atrás, probemos otra opción, experimentemos”. Necesitas ese ojo con opinión.
Y esta parte me gustó mucho: la persona de la charla insistía en que el criterio no es algo con lo que naces. Se puede desarrollar. Tres vías:
Estudiar. Mira los mejores productos. No solo los uses: inspecciónalos. Intenta entender por qué se sienten bien. ¿Qué hace la tipografía? ¿Qué timing tiene la animación? Con el tiempo construyes sensibilidad y una biblioteca mental. En la charla hubo un momento muy bueno donde acercaron el zoom en la navegación de un producto conocido y detectaron que, durante una transición, el contenido interno desbordaba ligeramente el contenedor. Un detalle mínimo, casi invisible. Pero ese ojo sale de años de observar y construir.
Notar. Entrena tu capacidad para detectar inconsistencias. Había una demo con tres elementos animados donde los dos de los extremos compartían timing y el del medio era ligeramente distinto. La mayoría no lo detectaría de forma consciente, pero sí sentiría que algo “no cuadra”. Ese “se siente raro” que reportan usuarios sin saber explicarlo. Un design engineer necesita ser quien lo nombre.
Construir. Copia lo mejor. Está ese principio de robar como un artista. Toma una interacción buena que viste en otra app, recréala, cambia colores, hazla tuya. Si repites esto suficientes veces, empiezas a desarrollar instinto para elegir cuándo usar una animación con spring y cuándo un easing más simple, cuándo ajustar el letter spacing y cuándo no tocar nada.
El equilibrio entre forma y función
Algo que me resonó mucho fue la parte de saber cuándo no añadir animación. En la charla contaban un error de carrera temprana: obsesión con blur effects y con que todo “mutara”. Su manager básicamente dijo: “eso no es lo que este producto necesita. La gente quiere algo nítido y rápido”.
Y eso cambió toda la perspectiva. Si construyes una herramienta que la gente usa cientos de veces al día, ese loading spinner bonito es genial la primera vez y molesto la vez número cien. Es como una cinemática no saltable en un videojuego: terminas machacando botones para pasarla.
Una forma útil de pensarlo: la novedad tiene retornos decrecientes. Como un power-up en un juego de plataformas que solo aparece una vez por nivel. Lo persigues porque es raro. Si estuviera en todas partes, perdería valor. En una landing, sí, puedes permitirte una intro más llamativa. Pero en una app de uso diario, la mejor animación puede ser ninguna. Cuando la gente necesita resolver cosas, la velocidad es forma.
Cómo convertirse realmente en design engineer
Si eres diseñador, de hecho tienes ventaja inicial. Ya tienes ojo. Lo difícil para ti es aprender a convertir diseños en código real. Empieza pequeño. Toma algo que diseñaste y constrúyelo, aunque quede tosco al principio. Usa herramientas de IA para cerrar la brecha. Con el tiempo, diseñarás en Figma sabiendo ya cómo se verá en código.
Si eres ingeniero, ya tienes la otra mitad. Tu trabajo es entrenar el ojo. Empieza a estudiar los productos que usas a diario. Pregúntate por qué eligieron esa fuente, ese espaciado, ese estilo de botón. Luego intenta implementar lo que observes en tu propio trabajo.
En ambos casos, se aprende construyendo. Si no estás construyendo, no estás aprendiendo.
El tema del portfolio
Aquí también hubo un buen punto. Si quieres demostrar que eres design engineer, no basta con llenar un portfolio de microinteracciones bonitas. Muestra que realmente te gusta este trabajo. Publica experimentos, incluso los más verdes. Muestra progresión. La gente quiere ver cuidado y dedicación, el recorrido desde trabajo desordenado hasta el nivel actual. Enseña qué te inspiró, enseña tu versión, mete tu personalidad. Esa autenticidad destaca mucho más que una cuadrícula impecable de componentes sin alma.
Hacia dónde va todo esto
Creo que vamos hacia un punto en el que la mayoría de equipos de producto tendrá design engineers como parte central del equipo, no como un nice-to-have. La IA está haciendo posible que cualquiera genere una web funcional en minutos, lo cual deja el listón de “funciona” prácticamente en el suelo. Lo que va a separar productos buenos de productos olvidables es la capa humana: el cuidado, el criterio, la sensación de que a alguien realmente le importó cómo se siente usar eso.
Estamos en un momento raro, casi de renacimiento. Las herramientas para crear nunca fueron tan accesibles, pero eso también significa más ruido que nunca. Las personas capaces de cortar ese ruido construyendo productos que se sientan de verdad pensados, de verdad humanos, ahí es donde se está moviendo el valor.
En fin. Ve a estudiar algunas webs. Copia algo interesante. Publica algo feo y luego hazlo menos feo. Ese es básicamente todo el playbook.