Por qué un diseñador tiene que conocer el código

Algunos de ustedes piensan que, como son diseñadores, el código les queda lejos: que es trabajo de otros, que a ustedes les corresponde la idea y a un programador la ejecución. Vamos a examinar esa idea, porque de ella depende buena parte de lo que les pase en los próximos diez años.

Argumento 1

El código no limita su creatividad: la amplía

Esa idea supone que el código es una fase posterior al diseño, y ajena a él. En la web esa separación no existe: el código es el material. Un escultor que no conoce la piedra no diseña esculturas; diseña dibujos de esculturas, y luego alguien le explica qué no se puede hacer.

Quien no conoce su material diseña sobre lo que imagina que el medio permite, no sobre lo que el medio permite de verdad. Y lo que se imagina suele ser una hoja de papel con desplazamiento vertical.

Esto les ocurre en dos direcciones:

Y una distinción importante, porque se confunden a menudo: los frameworks —Bootstrap, Tailwind, las plantillas de WordPress— multiplican la productividad, no la creatividad. Hacen más rápido lo que ya decidió otro, y por eso todo lo que sale de ellos se parece.

Conocer el código amplía el espacio de lo posible; el framework solo aumenta la velocidad dentro de un espacio ya acotado.

Ambas cosas sirven, pero no son la misma y no se sustituyen.


Argumento 2

El código es el idioma del equipo donde van a trabajar

Nadie diseña un producto digital en solitario. Van a trabajar en equipos donde conviven diseñadores, desarrolladores y responsables de producto, y donde el punto de fricción es siempre el mismo: el traspaso del diseño a la implementación.

Esto no es una impresión. En el estudio más reciente de Figma, el 92% de los diseñadores y el 91% de los desarrolladores consideran que ese traspaso es mejorable, y el obstáculo que más citan los desarrolladores —el 52%— son los supuestos distintos: cada uno da por hecho cosas que el otro no. El 84% de los diseñadores trabaja con desarrolladores al menos una vez por semana. Es decir: esa fricción no es un episodio ocasional, es su semana laboral.

No se trata de que ustedes programen la aplicación. Se trata de que puedan:

  1. Sostener una conversación técnica: saber qué están pidiendo cuando piden algo, y entender por qué una petición cuesta una hora y otra cuesta una semana.
  2. Defender sus decisiones con criterio propio, en vez de ceder cada vez que alguien dice «eso no se puede hacer».
  3. Enseñar lo que no cabe en una imagen: una transición, el comportamiento ante contenido real, la respuesta a un error.

Quien no habla el idioma del equipo queda fuera de las decisiones, por buen diseñador que sea. Y esas decisiones se toman igual, sin él.

Hay además un movimiento de fondo que conviene que conozcan. En un solo año, los diseñadores que participan en el desarrollo han pasado del 21% al 41%, y los desarrolladores que participan en el diseño, del 44% al 60%. La frontera se está disolviendo en las dos direcciones. Si deciden quedarse en un solo lado, se quedan fuera de la mitad del trabajo.

Y para quien tema que el código le reste valor a su criterio: en ese mismo estudio, el 90% de los encuestados sostiene que el diseño es al menos tan importante como antes de la inteligencia artificial, y cerca de seis de cada diez que lo es más. Lo dicen también el 65% de los desarrolladores. Cuando construir se vuelve barato, decidir qué construir vale más, no menos.


Argumento 3

Es lo que los separa de su competencia

Esta parte es incómoda y se la digo sin adornos: su título universitario en Diseño no les reserva un hueco en el mercado. Cuando salgan a buscar trabajo haciendo sitios web, competirán con:

Frente a ese panorama, ninguno de los dos extremos es defendible:

Lo que sí es escaso es la combinación. Su formación les da precisamente lo que a esa competencia le falta: criterio compositivo, tipográfico, cromático, de jerarquía y de marca, construido durante cuatro años. Eso no se improvisa en catorce semanas. Añadirle el dominio del medio no los convierte en programadores de segunda: los convierte en el perfil que decide y ejecuta, que es exactamente el que las empresas no consiguen cubrir.

El diseño sin código es una propuesta, el código sin diseño es una plantilla, y el valor está en quien reúne las dos cosas.


La otra cara

La objeción contraria, que también conviene conocer

Existe una postura opuesta y es seria. Sostiene que exigir código al diseñador es propio de organizaciones que fusionan papeles para abaratar, y que el riesgo es acabar haciendo dos trabajos por el sueldo de uno.

Mi respuesta es acotada, y por eso esta asignatura es la que es: no les estoy pidiendo que programen aplicaciones. Les estoy pidiendo que dominen HTML y CSS, que son el soporte material de su propia disciplina, no la del vecino. Un tipógrafo conoce la imprenta. Un ceramista conoce el horno. No por eso dejan de ser tipógrafo y ceramista.