Hace unos días, charlando con un colega sobre workflows de diseño, me surgió una pregunta que me ha tenido dándole vueltas: ¿por qué hay diseñadores que necesitan obligatoriamente pasar por Figma antes de tocar una línea de código, mientras que otros van directo al HTML como si fuera lo más natural del mundo?
No se trata de que unos sean mejores que otros, pero sí creo que revela algo sobre cómo cada uno entiende el medio web.
El diseñador que necesita ver vs el que piensa en el medio
Los que van siempre a Figma primero necesitan visualizar antes de construir. Muchas veces se montan sistemas de diseño súper elaborados, con componentes, variables, estados… un setup que puede llevar más tiempo que el propio proyecto. Es un proceso muy visual y, admito, bastante seguro. Sabes exactamente cómo va a quedar antes de escribir ni una sola línea de CSS.
Los que van directo al código piensan directamente en el medio web. No necesitan esa representación intermedia porque su cerebro ya traduce ideas a HTML/CSS de forma natural. Es como si pensaran directamente en el lenguaje del navegador, sin necesidad de un intérprete visual.
La web es un medio vivo, no una imagen estática
Aquí viene mi reflexión principal: la web no es un lienzo estático. Es un medio interactivo, responsive, que cambia según el dispositivo, la conexión, el navegador, las preferencias del usuario. Cuando diseñas directo en código, estás diseñando para este medio desde el primer momento.
Cuando haces un mockup en Figma, estás diseñando para una representación del medio. Una muy buena representación, pero al final del día, una representación.
El caso del responsive «de verdad»
¿Cuántas veces has hecho un diseño responsive perfecto en Figma con sus 3-4 breakpoints, y luego al implementarlo te das cuenta de que en esa pantalla intermedia de 950px se ve horrible? En código, ves ese problema inmediatamente. Redimensionas la ventana y sientes cómo se comporta tu diseño.
Los que diseñamos directo en HTML/CSS desarrollamos una especie de intuición sobre cómo va a funcionar algo en diferentes tamaños. Es como si el navegador fuera nuestro lienzo natural.
La accesibilidad, la eterna olvidada de los mockups
Y aquí viene un tema que me da mucha rabia: la accesibilidad. En Figma puedes crear el mockup más bonito del mundo, pero ¿has pensado en el contraste de colores? ¿En cómo va a navegar alguien con teclado? ¿En qué pasa cuando un usuario usa un lector de pantalla?
Cuando diseñas directo en HTML, la accesibilidad está presente desde el minuto uno. Usas etiquetas semánticas porque es lo natural, piensas en el orden de tabulación porque lo estás viendo en tiempo real, te das cuenta inmediatamente si ese gris sobre gris no tiene suficiente contraste.
He visto demasiados proyectos donde la accesibilidad se trata como un «añadido» al final, cuando en realidad debería ser la base sobre la que construyes. Es como diseñar una casa y luego recordar que necesitas puertas para que la gente pueda entrar.
El HTML semántico no es solo para los robots
Otra cosa que he notado: los diseñadores que van directo al código tienden a usar HTML más semántico. No porque sean más listos, sino porque cuando estás escribiendo <button> en lugar de <div class="button">, tu cerebro entiende que eso es un botón de verdad, no solo algo que parece un botón.
Esa diferencia es enorme para la accesibilidad. Un <button> real tiene comportamientos incorporados: es focusable, responde al Enter y la barra espaciadora, los lectores de pantalla lo anuncian correctamente. Todo eso gratis, sin configuración extra.
La falsa sensación de control
He visto diseñadores que pasan horas perfeccionando un mockup en Figma: cada pixel en su sitio, cada sombra con la opacidad exacta, cada espaciado milimétrico. Y luego, cuando lo implementan, se frustran porque no se ve «exactamente igual».
¿Pero es que tiene que verse exactamente igual? La web es fluida por naturaleza. Querer controlar cada pixel es como querer controlar el agua: puedes canalizarla, dirigirla, pero nunca dominarla completamente.
Y menos aún cuando consideras que tus usuarios pueden tener configuraciones de alto contraste, fuentes más grandes, o estar navegando con un magnificador de pantalla. Tu pixel-perfect design se va al traste en el momento en que alguien aumenta el zoom al 200%.
Testing real desde el primer momento
Cuando diseñas en código, puedes probar la accesibilidad sobre la marcha. Navegas con el teclado, pruebas con un lector de pantalla, ves cómo se comporta con diferentes configuraciones. No necesitas «acordarte» de probar la accesibilidad después; la estás probando mientras creas.
Es como la diferencia entre escribir un discurso en papel y practicarlo en voz alta. Hasta que no lo dices en voz alta, no sabes si realmente funciona.
Cuándo sí necesitas Figma
No estoy diciendo que Figma sea malo, ni mucho menos. Hay casos donde es imprescindible:
- Proyectos complejos: Necesitas una visión global del sistema
- Equipos grandes: Tienes que comunicar el diseño a otros desarrolladores
- Clientes que necesitan ver antes de aprobar: Algunos clientes no visualizan el resultado final hasta verlo «real».
- Sistemas de diseño elaborados: Para documentar componentes y estados.
Pero incluso en estos casos, deberías considerar hacer prototipos funcionales en código para validar la accesibilidad y usabilidad real.
Mi teoría personal
Creo que los diseñadores que pueden ir directo al código tienen una comprensión más profunda de cómo funciona realmente la web. No porque sean mejores diseñadores, sino porque han desarrollado esa intuición de pensar en el código mientras diseñan.
Es como la diferencia entre un músico que compone en ordenador y otro que compone directamente en el instrumento. Ambos pueden crear música increíble, pero el segundo tiene una conexión más directa con el sonido real.
Y cuando hablamos de accesibilidad, esa conexión directa con el medio es fundamental. No puedes hacer web accesible de verdad si no entiendes cómo funciona la web.
¿Y tú cómo trabajas?
Al final, cada uno tiene su proceso y no hay una forma «correcta» de hacerlo. Pero si nunca has probado a diseñar directo en HTML, te animo a que lo intentes en tu próximo proyecto pequeño.
Y por favor, mientras lo haces, navega con el teclado de vez en cuando. Tus usuarios te lo agradecerán.
Bueno, da igual si lo va a hacer la IA
Aunque pensándolo bien, con el ritmo que van las cosas, puede que dentro de poco este debate sea irrelevante. Ya tenemos Motiff, UXPilot, Bolt y otras IAs especializadas en diseño que te crean interfaces completas desde un prompt. Pronto puede que ni siquiera necesitemos decidir entre Figma o HTML directo.
Nota: Reflexión basada en años de ver frustraciones innecesarias entre diseñadores y desarrolladores que, en muchos casos, podrían evitarse con una metodología más directa.