Fran Rosa

22 Septiembre 2016

Diseño

Bloqueo de diseñador: Para diseñadores que escriben código

English: Designer's Block: For Designers Who Code

Parece que hemos topado contra un muro así que para este proyecto de ahora en adelante yo me ocuparé del diseño.

Apartar a alguien de un proyecto nunca es agradable y es aún peor cuando se trata del diseño. Cuando diriges a otros diseñadores nunca quieres quitarles su independencia para tomar decisiones y su orgullo en su trabajo, pero para ser un responsable de diseño — o director de arte — hay que saber cuando intervenir y cambiar la dirección de un proyecto o empezar de nuevo. Apartar a un diseñador del proyecto es siempre el último recurso pero a veces es necesario.

El problema en este proyecto en concreto no era que el diseñador hubiera tomado una dirección equivocada — el concepto estaba claro y él había hecho buenas propuestas iniciales — o que no tuviera el talento o la capacidad necesarios para completar el proyecto. El problema era que había llegado a un punto en que parecía ser incapaz de avanzar incluso teniendo críticas claras y específicas e instrucciones sobre qué necesitaba mejorar y cómo. El diseñador tenía limitaciones que era incapaz de superar.

Lo sé porque yo también he pasado por lo mismo.

El proyecto era el diseño para un sitio nuevo con una estructura conocida — ya tenemos sitios similares — y que empezaba de cero permitiendo un amplio margen para la libertad creativa. El proyecto no era tampoco un reto a nivel técnico ya que era comparativamente más pequeño que los otros sitios similares existentes. Sin embargo sí necesitaba destacar visualmente y tener encanto, porque su principal objetivo era ayudar a construir la marca de la compañía.

El diseñador es además desarrollador front end y está acostumbrado a trabajar con tiempos ajustados. Y ese fue parte del problema — al discutir la jerarquía visual él se refería a la reutilización de HTML o el rendimiento del CSS. Y ese no era el tema.

Cualquier diseñador acostumbrado a trabajar bajo presión con calendarios ajustados sabe que eso mejora su capacidad de responder rápidamente equilibrando la unicidad y la originalidad con adoptar soluciones que ya se han usado en otros proyectos, y eso lleva a desarrollar un tipo de pragmatismo que puede ser contraproducente cuando uno tiene todo el tiempo y recursos a su alcance ya que está acostumbrado a saltarse algunos pasos en el proceso siempre que tiene ocasión aunque no haya necesidad.

Eso es particularmente malo cuando la misma persona se encarga del diseño y el front end de un proyecto porque las posibilidades que actualmente ofrece el front end — y el diseño asociado a éstas — son infinitas. Desde usar diferentes versiones de un logo para una identidad responsive a tener animaciones sutiles en algunas interacciones, cualquier diseñador podría estar diseñando y desarrollando el front end de cualquier proyecto el resto de su vida. Así que es importante construir de abajo a arriba y saber qué partes requerirán un desarrollo posterior.

Pero si intentas trabajar en las primeras fases del diseño de un nuevo sitio, e intentando imaginar cómo desarrollar el front end, y tratando de reducir la fricción en fases posteriores del proyecto condicionando su toma de decisiones, todo al mismo tiempo, tus opciones se reducen a un estrecho margen de maniobra. Y lo peor es que puede que ni siquiera seas consciente de ello.

A mi me ocurrió en el pasado y le ocurrió al diseñador. Hablando con colegas — tanto diseñadores y desarrolladores front end como quienes los dirigen — parece que es un problema bastante común.

En mi caso trabajar con diferentes organizaciones del equipo — trabajando en proyectos como diseñador sin involucrarme en el front end o a la inversa — o en proyectos con objetivos específicos distintos — sitios enormes con el foco puesto en el rendimiento y la escalabilidad, y microsites publicitarios con una vida muy corta — solventó el problema. Si notas que puedes tener ese tipo de limitaciones porque trabajas en proyectos muy similares o en un equipo con una organización fija, tener proyectos propios al margen del trabajo o haciendo cambios en tu proceso puede ayudar. Y si diriges diseñadores y desarrolladores de front end, plantéales retos fuera de su zona de confort.

¿Cómo esperas obtener diferentes resultados haciendo lo mismo una y otra vez?