“Las reglas matan mi creatividad”

El debate “un diseñador, ¿debe o no aprender código?” lleva abierto casi desde los inicios de Internet y parece haber experimentado un nuevo repunte en los últimos años. ¿Por qué?, quizás la irrupción de los frameworks, basados en javascript (Angular, Vue o React entre otros) tiene mucho que ver con este repunte.

Estos frameworks han difumado los roles entre Front-End y Back-End, hasta el punto de perder cierto sentido de identidad, incluso para los propios profesionales, y añadiendo a su vez un posible efecto colateral, alejar a los diseñadores del código.

Es posible que para algunos/as profesionales, más orientados a UI, esta circunstancia pueda verse como una ventaja. Es tentador enfocarse únicamente en lo visual y olvidarse “de una vez”, del maldito código que tantos quebraderos de cabeza suele conllevar, sin embargo en el largo plazo esto solo añade más problemas, no soluciones.

Un diseñador no puede alejarse del código, al menos no en su totalidad, por una sencilla razón, el renderizado de un navegador o una app implica código, por tanto, si desconoce sus principios, reglas, potencialidades, ventajas y limitaciones no sabrá crear el puente necesario para trasladar el trabajo visual al usuario, lo cual en última instancia resulta una forma de trabajar ineficiente y por lo tanto costosa, en tiempo y dinero.

Imaginemos que un diseñador se le ocurre una idea y sin conocimiento o consulta previa al departamento Front, es presentada al cliente, le encanta y es aprobada. El equipo Front recibe la tarea de codificarlo para que el navegador pueda renderizarlo, sin embargo, al no haber formado parte del proceso inicial, observa carencias, imprevistos u otra serie de problemas de base. A partir de aquí surgen varios escenarios, o bien el equipo Front devuelve los diseños, para que estos sean refinados y corregidos, lo cual conlleva costes en tiempo y dinero, o bien se fuerza al equipo Front para que resuelva estos problemas, aumentando la carga de trabajo, los tiempos de ejecución, entregando un producto deficitario o directamente no pudiendo resolverlo debido a los problemas iniciales, por tanto inclusive más costes que en el anterior escenario.

En cualquier caso, si en ambos casos, no se ha tenido en cuenta las viabilidades o coyuntura tecnológica del departamento Back, puede darse el caso de presentar un desarrollo, que ha implicado esfuerzo, tiempo y dinero, en algo inexistente en producción y en manos del usuario. Más trampas al solitario, aún mayores costes.

Inicio de las hostilidades, sálvese quien pueda

Una vez que ocurre cualquiera de los escenarios antes descritos, la caza de brujas da comienzo. Se buscan chivos expiatorios, se ponen en duda los conocimientos, profesionalidad o esfuerzo de unos u otros. El ambiente sufre un fuerte desgaste y el problema de comunicación aumenta la brecha entre departamentos.

A partir de aquí lo importante es poner en valor el trabajo individual, no el colectivo, cubrir expedientes y descargar responsabilidades.

Más y más trampas al solitario. Más y más costes en el trayecto.

Los sistemas de diseño

Los sistemas de diseño son ya una realidad en muchas empresas y no son más que una evolución de “atomic design“. A medida que cada vez más agentes, tecnologías y complejidades toman partido, más necesario resulta crear patrones y fórmulas de trabajo comunes que ayuden a optimizar el proceso, faciliten la coherencia o solidez y minimicen errores.

Curiosamente los sistemas de diseño parten, en gran medida, del propio Front, cuya dinámica de trabajo ha ido desarrollando poco a poco la necesidad de crear procesos de trabajo más óptimos.

Por tanto, una vez más, el trabajo tiene forma de círculo, no de línea recta.

El diseño es otra parte del engranaje

Con los sistemas vienen las definiciones, los patrones y por supuesto las reglas. Si un diseñador, por poner un ejemplo, no encuentra sentido al uso de un grid, como fundamento de diseño básico, interpretando que limita su creatividad; este diseñador puede carecer del motivo por el cual necesita trabajar con grid: responsive design, mobile first, etc.

Pero también puede desconocer otras indicaciones, como por ejemplo la accesibilidad, el rendimiento, la diferencia entre una app y un navegador. Cierto, no tiene por qué ser un experto, pero el diseñador sí debe ser consciente de su existencia, estableciendo un diálogo permanente con Front y Back para la consecución de cualquier desarrollo.

¿Qué ocurre si como diseñador planteo el uso de una librería o plugin y éste provoca un aumenta los tiempos de carga de la página?, ¿o si la ubicación visual de elementos resulta estética pero afecta a la semántica de la página o la navegación por tabulación?. ¿De quién es competencia?.

Por tanto, las reglas no son limitaciones o problemas, sino una parte natural de todo el proceso y aislarse del código puede incrementar esa percepción.

Deja un comentario