Qué es un design engineer y cómo empezar con IA

En este artículo

1. 01 Qué es un design engineer
2. 02 Por qué aparece este rol
3. 03 Qué hace en la práctica
4. 04 Qué no es un design engineer
5. 05 Design engineer frente a otros perfiles
6. 06 Del handoff a la colaboración
7. 07 Más allá de los píxeles
8. 08 Cómo empezar con IA
9. 09 Claude Code como sistema de trabajo
10. 10 De Figma a código: un ejemplo
11. 11 Lo que la IA puede hacer y lo que depende de ti
12. 12 Habilidades necesarias
13. 13 Cómo crear un portafolio
14. 14 Errores comunes
15. 15 Plan de siete días
16. 16 Preguntas frecuentes
17. 17 Conclusión
18. 18 Fuentes

Una interfaz puede verse perfecta en Figma y seguir estando incompleta.

El problema aparece cuando ese diseño llega al navegador: el contenido cambia, faltan estados, el responsive se rompe, la animación no se siente igual o una interacción resulta difícil de usar con teclado. Diseñar una pantalla no es lo mismo que construir una experiencia.

Ese espacio entre la intención visual y el producto funcional es donde aparece el design engineer: alguien que combina diseño, frontend, prototipado y sistemas de diseño para convertir decisiones visuales en experiencias que se pueden probar, medir y mejorar. Adobe sitúa el rol en tres áreas: prototipar nuevas experiencias, construir sistemas e infraestructura de diseño y aportar detalle a productos que requieren una implementación especialmente cuidada (Adobe ↗).

La inteligencia artificial está haciendo este camino más accesible. Herramientas como Claude Code ayudan a explorar un proyecto, crear componentes, modificar interfaces y verificar cambios, siempre que se usen con contexto, tareas pequeñas y criterios claros (Claude Code ↗).

Este artículo explica qué es un design engineer, qué hace en la práctica y cómo puedes empezar a desarrollar este perfil con IA sin dejar de pensar como diseñador.

Qué es un design engineer

Un design engineer trabaja en la intersección entre diseño de producto, frontend, prototipado y sistemas de diseño. Su trabajo no termina cuando una pantalla se ve bien en Figma: también considera qué ocurre cuando esa pantalla se convierte en una interfaz real, con datos, usuarios, dispositivos, errores y restricciones técnicas.

Vercel lo describe como una combinación de sensibilidad estética y habilidades técnicas que permite comprender un problema, diseñar una solución y enviarla con autonomía (Vercel ↗).

El rol recibe distintos nombres según la empresa: UX engineer, UI engineer, design technologist, experience developer, design prototyper o creative technologist. Adobe agrupa estas denominaciones en una misma familia de perfiles que trabajan en el espacio común entre diseño e ingeniería.

Tampoco hay una única trayectoria. Algunas personas llegan desde el diseño visual o de producto; otras empiezan como frontend engineers y desarrollan más sensibilidad por la experiencia; otras vienen de la animación, la dirección de arte, los sistemas de diseño o la tecnología creativa. Lo que las une es la capacidad de conectar problema, diseño, código, interacción, sistema, verificación y resultado.

Por qué aparece este rol

El software se ha vuelto más visual, interactivo y exigente. Ya no basta con que una aplicación funcione técnicamente: los usuarios esperan interfaces claras, interacciones rápidas, animaciones cuidadas, estados comprensibles, un responsive bien resuelto, accesibilidad, buen rendimiento, consistencia entre pantallas y detalles que transmitan calidad.

Por eso la distancia entre diseño e implementación importa cada vez más:

• Un diseño puede ser visualmente atractivo y difícil de construir.
• Una implementación puede funcionar correctamente y perder la intención original.
• Un componente puede verse bien en una pantalla y fallar en otra.

El design engineer trabaja sobre ese espacio intermedio. No reemplaza al diseñador ni al frontend engineer: ayuda a que las decisiones de experiencia se exploren, implementen y validen más cerca del producto real.

Qué hace en la práctica

Prototipa nuevas experiencias

Hay preguntas que una pantalla estática no puede responder del todo:

• ¿La interacción se entiende?
• ¿La animación es demasiado lenta?
• ¿El menú funciona con teclado?
• ¿El gesto táctil es fácil de descubrir?
• ¿El usuario entiende qué acaba de cambiar?
• ¿El scroll aporta valor?
• ¿La transición conserva el contexto?

En esos casos, un prototipo funcional puede ser más útil que seguir agregando pantallas en Figma. Adobe señala que los prototipos de alta fidelidad escritos en código ayudan a reducir supuestos, acelerar decisiones, detectar limitaciones técnicas y evitar errores costosos durante el desarrollo.

El prototipo no tiene que convertirse en producto. Puede servir para aprender, para probar una hipótesis con usuarios o para decidir si una idea merece una implementación completa. Vercel también menciona que animaciones, controles de teclado y gestos táctiles pueden ser más fáciles de explorar directamente en código que de recrear en otra herramienta.

Construye sistemas de diseño

Un design engineer también trabaja en la infraestructura que mantiene la calidad a escala: tokens, componentes, variantes, estados, documentación, reglas de uso, bibliotecas de código, herramientas internas, plugins y accesibilidad.

El objetivo no es crear una biblioteca enorme, sino convertir decisiones de calidad en piezas reutilizables. Un botón no debería resolver el focus de una manera distinta en cada pantalla. Un campo no debería inventar un estado de error cada vez que se usa. Una tarjeta no debería tener una estructura incompatible en cada sección del producto.

Adobe relaciona el design engineering con la construcción de sistemas de tokens, documentación, plugins y bibliotecas de componentes accesibles, eficientes y fáciles de integrar.

Implementa interfaces

El design engineer puede transformar una propuesta visual en código de producción. Según el equipo, trabaja con HTML, CSS, JavaScript, TypeScript, React, Next.js, Framer, Webflow, sistemas de componentes internos, WebGL o Three.js.

La herramienta no define el rol. Lo importante es que la implementación conserve la intención del diseño y funcione con distintos tamaños de pantalla, cantidades de contenido, dispositivos, métodos de entrada, estados y velocidades de conexión.

Revisa la calidad

La revisión no se limita a comparar una captura. También implica comprobar rendimiento, accesibilidad, responsive, compatibilidad entre navegadores, estados de focus, navegación con teclado, preferencias de movimiento, tiempo de carga, consistencia visual y calidad de las transiciones.

Vercel incluye entre las preocupaciones del design engineer las interacciones, los componentes reutilizables, la velocidad de página, el soporte entre navegadores, los diferentes modos de entrada, las preferencias del usuario y la accesibilidad.

Qué no es un design engineer

No es un diseñador que dejó de diseñar

Aprender a programar puede cambiar tu proceso, pero no elimina tu capacidad de diseñar. Te ayuda a pensar mejor en estados, datos reales, responsive, accesibilidad, reutilización, costos técnicos, mantenimiento y límites del navegador.

Cuando entiendes cómo se implementa una decisión, puedes hacer preguntas más completas: ¿cómo debería comportarse?, ¿qué ocurre si cambia el contenido?, ¿este componente debería ser reutilizable?, ¿la animación aporta suficiente valor para justificar su costo? También detectas antes cuándo una solución necesita simplificarse.

El código es una herramienta. No reemplaza la intención de diseño, la investigación ni la comprensión del usuario. La pregunta no es si un diseñador debe convertirse en ingeniero, sino qué parte del proceso quieres comprender y controlar mejor.

No es un frontend engineer genérico

Un frontend engineer puede trabajar en arquitectura, datos, integración, rendimiento y mantenimiento. Un design engineer también puede participar en esas áreas, pero suele poner el énfasis en la calidad visual, la interacción, el prototipado, los sistemas de diseño, el detalle de implementación y la traducción entre diseño y código. La frontera depende de la empresa y de la persona.

No significa saberlo todo

No necesitas dominar backend, infraestructura, animación 3D, accesibilidad, WebGL y sistemas nativos antes de empezar. Adobe presenta el design engineering como un campo con especialidades diversas, desde prototipado y sistemas de diseño hasta frontend, gráficos y herramientas internas. Puedes tener una base amplia y desarrollar profundidad en una o dos áreas.

No significa trabajar solo

La autonomía no equivale a aislamiento. En Vercel, los design engineers colaboran con diseñadores, ingenieros, producto, marketing y otros equipos. Puedes llevar una iniciativa con autonomía, pero sigues necesitando feedback, revisión y colaboración.

Design engineer frente a otros perfiles

Frente al product designer

Esto no significa que un rol sea superior al otro. Un producto necesita investigación, estrategia, contenido, diseño visual, interacción, ingeniería y validación. El design engineer aporta profundidad en la conexión entre varias de esas áreas.

Frente al frontend engineer

En equipos pequeños, una misma persona puede cubrir partes de ambos perfiles. Vercel describe situaciones en las que el design engineer implementa la interfaz mientras otros miembros del equipo trabajan en la API y la infraestructura.

Del handoff a la colaboración

En un proceso tradicional, el trabajo se ve así:

Problema → Diseño → Handoff → Desarrollo → Revisión → Publicación

Puede funcionar bien, sobre todo en equipos grandes y proyectos complejos. Pero cada transición puede producir una pérdida de contexto: una interacción se simplifica, un estado queda fuera, una animación se elimina sin analizar su propósito, un componente se construye como una excepción difícil de mantener o un problema de responsive aparece cuando la implementación ya está avanzada.

Un proceso más integrado se parece a esto:

Explorar → Construir → Revisar → Ajustar → Publicar

El diseño no tiene que estar completamente cerrado antes de que aparezca el código. Diseñador y design engineer pueden empezar con una idea, construir una versión, revisarla y volver a modificarla, a través de Figma, código, capturas, videos, enlaces de preview, mensajes y revisiones. Vercel describe precisamente este modelo: colaborar desde las primeras ideas e iterar en Figma o en código hasta llegar al resultado final, sin el handoff tradicional.

La ventaja es que las discusiones se vuelven concretas. En lugar de debatir si una animación funcionará, puedes construirla. En lugar de explicar cómo debería comportarse un menú, puedes abrirlo en el navegador. En lugar de asumir que un componente es reutilizable, puedes probarlo en varios contextos.

Más allá de los píxeles

Una interfaz de calidad no se define solo por una captura.

Rendimiento. Una experiencia puede verse excelente y ser lenta. Hay que considerar el peso de las imágenes, la carga de fuentes, el JavaScript innecesario, las animaciones costosas, los saltos de layout, el tiempo de respuesta y los dispositivos menos potentes. Una animación atractiva no sirve si salta frames o retrasa una acción importante.

Accesibilidad. Debe formar parte del diseño y la implementación desde el inicio: HTML semántico, focus visible, navegación con teclado, etiquetas claras, contraste suficiente, lectores de pantalla, estados que no dependan solo del color y respeto por prefers-reduced-motion.

Compatibilidad. La interfaz debe funcionar en distintos navegadores, tamaños de pantalla y resoluciones, con pantalla táctil, mouse, trackpad o teclado, y con el zoom del navegador. No es solo un problema técnico: afecta directamente la percepción de calidad del producto.

Estados reales. Una interfaz completa considera carga, vacío, error, éxito, sin conexión, permisos insuficientes, contenido largo, datos parciales y acciones deshabilitadas. En Figma puedes representar estos estados; en código puedes probar cómo conviven con el resto de la experiencia.

Cómo empezar con IA

La IA puede reducir la distancia entre una idea y un prototipo, pero no elimina la necesidad de aprender fundamentos.

El objetivo inicial no debería ser construir una aplicación completa, sino llevar una decisión concreta desde el diseño hasta una experiencia funcional. Buenos primeros proyectos: una landing page, un dashboard, un formulario, un sistema de tarjetas, un menú responsive, un flujo de onboarding, un estado vacío, un modal accesible, un selector de fechas o una página de pricing.

1. Elige una pantalla. Una que ya exista en Figma o una pequeña definida desde cero.
2. Define una pregunta. ¿Cómo debe comportarse el filtro? ¿Qué ocurre cuando no hay resultados? ¿Cómo se muestra la carga? ¿Cómo funciona en móvil? ¿Qué ve el usuario cuando la petición falla?
3. Define el alcance. Decide qué vas a construir y qué queda fuera.
4. Usa la IA para explorar. Pide a Claude Code que analice el proyecto antes de modificarlo.
5. Construye una pieza. Implementa solo el componente o flujo elegido.
6. Verifica. Revisa build, tests, navegador, responsive y accesibilidad.
7. Itera. Usa el resultado para dar feedback específico.

Claude Code como sistema de trabajo

Claude Code puede trabajar dentro de un proyecto: explorar archivos, crear componentes, modificar interfaces, ejecutar comandos y corregir errores. Pero usarlo bien no consiste en escribir un prompt enorme y esperar que la herramienta resuelva todo. La diferencia está en el sistema de trabajo.

La documentación oficial recomienda separar la investigación y la planificación de la implementación, usar CLAUDE.md como contexto persistente, dividir las tareas complejas y darle al modelo comprobaciones que pueda ejecutar (Claude Code ↗). Ese sistema se organiza en cuatro partes: contexto, tareas pequeñas, planificación y verificación.

Contexto

Claude Code lee un archivo llamado CLAUDE.md al inicio de cada conversación. Ahí puedes contarle cómo se ejecuta el proyecto, qué tecnologías usa, cómo está organizado, qué componentes existen, qué convenciones y reglas visuales seguir, qué dependencias están permitidas, qué comandos ejecutar y qué archivos no tocar. Un ejemplo:

# Proyecto
Dashboard para gestionar proyectos.

## Stack
- React
- TypeScript
- Vite

## Reglas
- Reutiliza componentes existentes.
- No agregues dependencias sin aprobación.
- Mantén accesibilidad por teclado.
- Usa los tokens del sistema de diseño.
- Evita duplicar componentes.
- Ejecuta el build después de cambios importantes.

## Comandos
- npm run dev
- npm run build
- npm run test

Puedes usar /init para generar una primera versión y ajustarla después. La documentación recomienda mantenerlo corto, escrito para humanos y enfocado en la información que realmente evita errores.

Tareas pequeñas

Evita empezar con "construye la aplicación completa". Una tarea más útil se ve así:

Implementa únicamente el estado vacío de la pantalla de proyectos.

Utiliza:
- El layout actual.
- El componente EmptyState.
- Los tokens existentes.

No modifiques:
- La navegación.
- La API.
- El sistema de autenticación.

Criterios de aceptación:
- Aparece cuando no existen proyectos.
- Incluye un CTA para crear uno.
- Funciona en desktop y móvil.
- El build pasa correctamente.

La tarea tiene un objetivo, un alcance, componentes de referencia, restricciones y criterios de finalización. La documentación de Claude Code recomienda mencionar archivos concretos, restricciones y patrones de referencia, porque las instrucciones precisas reducen las correcciones posteriores.

Planificación

Cuando una tarea afecta varios archivos, conviene separar el análisis de la implementación:

Analiza la tarea, pero no hagas cambios todavía.

Identifica:
- Archivos implicados.
- Componentes reutilizables.
- Dependencias.
- Riesgos.
- Decisiones pendientes.
- Forma de verificación.

Devuelve un plan breve.

Claude Code tiene un modo de planificación para explorar una tarea antes de editar el proyecto. Es especialmente útil cuando no conoces bien el repositorio, la tarea toca varios archivos, hay más de una solución posible, el cambio puede alterar la arquitectura o no sabes qué componentes existen. Para un cambio muy pequeño, como corregir un texto o una variable, probablemente no necesitas planificar.

Verificación

Dale a Claude Code algo que pueda ejecutar para comprobar su trabajo: tests, build, linter, typecheck, scripts, capturas o comparaciones visuales. La documentación también recomienda pedir evidencia concreta: el comando ejecutado, el resultado obtenido o una captura. Una instrucción puede terminar así:

Antes de responder:
1. Ejecuta el build.
2. Ejecuta los tests relacionados.
3. Revisa la pantalla en desktop y móvil.
4. Comprueba que no exista overflow horizontal.
5. Enumera los archivos modificados.
6. Indica qué problemas quedan pendientes.
7. Genera una captura del resultado.

La verificación automática no reemplaza la revisión humana. Un test puede decir que el código pasa y una captura puede mostrar diferencias, pero todavía hay que decidir si la experiencia es clara y si conserva la intención del diseño.

De Figma a código: un ejemplo

Imagina un hero diseñado en Figma con eyebrow, título, descripción, CTA principal, CTA secundario e imagen, en versión desktop y móvil. Un flujo de trabajo razonable tiene cuatro pasos.

Paso 1: analizar.

Analiza la implementación actual del hero. No hagas cambios todavía.

Identifica:
- Componentes reutilizables.
- Tokens visuales disponibles.
- Breakpoints.
- Diferencias entre desktop y móvil.
- Estados que faltan.
- Archivos implicados.
- Riesgos técnicos.

Devuelve un plan breve antes de modificar el proyecto.

Paso 2: implementar la estructura.

Implementa únicamente la estructura responsive del hero.

Conserva la navegación, el sistema actual de botones, el contenido
existente y la sección siguiente.

En móvil:
- Apila el texto y la imagen.
- Mantén el CTA principal antes del secundario.
- Evita overflow horizontal.

No agregues dependencias. Ejecuta el build al terminar.

Paso 3: revisar visualmente. Compara desktop, móvil y anchos intermedios: tipografía, espaciado, posición de los botones, tamaño de la imagen y relación con la sección siguiente. Puede que el resultado funcione técnicamente, pero que la imagen ocupe demasiado espacio en móvil. El feedback puede ser:

La estructura funciona, pero en móvil la imagen ocupa demasiado espacio
y desplaza el CTA debajo del primer scroll.

Mantén este orden:
1. Eyebrow.
2. Título.
3. Descripción.
4. CTA principal.
5. CTA secundario.
6. Imagen.

Reduce la altura de la imagen solo en móvil. No modifiques desktop.
Genera una nueva captura móvil.

Paso 4: agregar estados.

Agrega estados hover, focus, loading y disabled al CTA principal.

Utiliza los tokens existentes. El focus debe ser visible con teclado.
El texto no debe cambiar el ancho del botón durante loading.

Verifica desktop, móvil, navegación con teclado y build.

La diferencia entre "haz el hero" y estas instrucciones es el nivel de intención, alcance y verificación.

Qué se aprende al construir

Cuando una interfaz empieza a funcionar aparecen problemas que no siempre eran visibles en Figma: una frase se divide de forma extraña, un botón queda demasiado cerca del borde, una imagen provoca overflow, el texto real cambia la composición, una animación distrae, el estado de carga no conserva el contexto, un error rompe el layout, el focus no se ve, el componente necesita otra variante o el comportamiento móvil no coincide con el de desktop.

Eso no significa que el diseño inicial estuviera mal. Significa que la implementación ofrece información nueva. El navegador se convierte en una herramienta de investigación: el código no sirve solo para producir el resultado final, también para descubrir qué funciona y qué debe cambiar.

Lo que la IA puede hacer y lo que depende de ti

La IA puede escribir código más rápido, pero no decide qué vale la pena construir. Si la dirección no está clara, puede producir muy rápido una solución incorrecta. Por eso el valor del design engineer no está en escribir prompts: está en formular problemas, elegir criterios, revisar resultados y tomar decisiones.

Habilidades necesarias

No existe una lista universal. Vercel destaca que no hay una herramienta única ni un perfil de origen correcto para este rol, y que las capacidades pueden variar y complementarse dentro del equipo. Aun así, hay áreas especialmente útiles:

Cómo crear un portafolio

Un portafolio de design engineering no debería mostrar solo capturas finales. Una captura demuestra apariencia; un caso de estudio completo demuestra criterio.

1. Presenta el problema. Qué se quería resolver, para quién, qué restricciones existían y qué parte era incierta.
2. Muestra las exploraciones. Bocetos, alternativas, prototipos, decisiones descartadas, pruebas de interacción y experimentos en código.
3. Enseña el resultado funcional. Cuando sea posible: enlace de preview, video, prototipo, repositorio, capturas responsive y estados reales.
4. Documenta la implementación. Qué componentes construiste, qué tokens usaste, cómo resolviste el responsive y la accesibilidad, qué verificaciones ejecutaste y qué problemas encontraste.
5. Explica lo aprendido. Un caso no necesita fingir que todo fue perfecto: qué no funcionó, qué simplificaste, qué quedó pendiente, qué harías diferente, qué aceleró la IA y qué decisiones tomaste tú.

Vercel resume este enfoque con el principio "Iterate to Greatness": publicar, aprender y mejorar continuamente sin quedar atrapado en la búsqueda de la perfección.

Errores comunes

• Pensar que necesitas saberlo todo. Elige una especialidad y desarrolla profundidad con proyectos pequeños.
• Pedir que la IA construya todo. Una aplicación completa contiene demasiadas decisiones ocultas. Divide el trabajo en exploración, plan, estructura, componentes, estados, integración y verificación.
• Copiar código sin entenderlo. Lee lo que se genera y pregunta qué hace cada archivo, por qué se eligió ese patrón, qué componente se reutilizó, qué riesgos existen y cómo se puede probar.
• No dar contexto. Si Claude no sabe qué stack usas, qué componentes existen o qué restricciones respetar, tendrá que adivinar.
• Aceptar la primera versión. Una primera implementación es un punto de partida, no el resultado final.
• Confundir un build exitoso con una buena experiencia. Que la aplicación compile no significa que sea clara, accesible o visualmente correcta.
• No probar contenido real. Usa textos largos, listas vacías, errores y distintas cantidades de información.
• Ignorar la accesibilidad. Revisa teclado, focus, semántica, contraste y movimiento reducido.
• Trabajar sin feedback. Comparte el preview, pide a otras personas que usen la interfaz y observa dónde dudan.
• Crear demasiadas excepciones. Si cada pantalla necesita un componente único, quizá el sistema no está suficientemente definido.

Plan de siete días

Preguntas frecuentes

¿Un design engineer es diseñador o ingeniero?

Puede venir de cualquiera de los dos campos. El rol se define por la combinación de responsabilidades, no por una carrera académica.

¿Necesito saber React?

No necesariamente. React es importante en algunos equipos, pero puedes empezar con HTML, CSS, JavaScript, Framer, Webflow u otra herramienta. Lo importante es comprender cómo se construyen y se comportan las interfaces.

¿Necesito una carrera de ingeniería?

No hay una única ruta. Puedes desarrollar el perfil con experiencia práctica en diseño, frontend, sistemas de diseño y prototipado. Los requisitos dependen de cada empresa y posición.

¿Claude Code puede convertirme en design engineer?

No por sí solo. Puede ayudarte a aprender, explorar y construir más rápido, pero el criterio, la dirección y la verificación siguen dependiendo de ti.

¿El design engineer reemplaza al diseñador?

No. Colabora más de cerca con el diseñador y reduce la distancia entre diseño e implementación.

¿Un design engineer trabaja solo?

No necesariamente. Puede tener autonomía sobre una iniciativa, pero normalmente colabora con diseño, ingeniería, producto, marketing y otros equipos.

¿Qué debería mostrar en mi portafolio?

Un problema, tus exploraciones, el prototipo funcional, la implementación, los estados y las decisiones que tomaste.

¿Qué herramientas usa un design engineer?

No hay una lista obligatoria: Figma, HTML, CSS, JavaScript, React, Framer, Webflow, Git, sistemas de diseño, herramientas del navegador, Three.js, Blender o Claude Code. Vercel menciona capacidades tan variadas como diseñar en Figma y en código, depurar rendimiento, GLSL, Three.js, Blender y edición de video dentro de su equipo de design engineering.

Conclusión

Una interfaz puede verse perfecta en Figma y seguir estando incompleta. Todavía falta saber cómo se comporta con datos reales, distintos dispositivos, errores, estados, accesibilidad y usuarios reales. Ahí es donde el design engineering aporta valor: no consiste solo en que un diseñador aprenda a programar, sino en conectar problema, diseño, código, interacción, sistema, verificación y resultado.

La IA puede hacer este camino más accesible. Claude Code puede ayudarte a explorar un proyecto, construir componentes, modificar interfaces y repetir iteraciones, pero el resultado mejora cuando no le pides que lo haga todo de una vez. Trabaja con contexto, tareas pequeñas, restricciones, planificación y verificación.

No necesitas ser experto en todo. Puedes empezar con una pantalla, una interacción y una pregunta concreta. Construye una primera versión, comprueba cómo funciona, rómpela, corrígela y documenta lo que aprendiste.

Porque el diseño no termina cuando la pantalla se ve bien. Termina cuando la experiencia funciona para alguien.

Fuentes

• Vercel, Design Engineering at Vercel: What we do and how we do it ↗.
• Adobe Design, Should you pursue a career in design engineering? ↗.
• Claude Code Docs, Best practices for Claude Code ↗.