La falta de entendimiento que afecta al bienestar del equipo y a la calidad del proyecto final debe acabar. Desahoguémonos, os invito a confesar la rabia y echar en cara todas nuestras frustraciones. Peleemos una última vez. Y después, avancemos sin mirar atrás.
El sector del diseño digital está pasando por un momento dulce. Los diseñadores hemos abierto nuestro abanico de influencia, estamos más presentes en todo el proceso de producción y hemos llegado a ocupar puestos relevantes en las empresas. Es evidente que existe mayor conciencia en cuanto a la indispensabilidad del diseño en el mundo que estamos creando.
Por fin hemos podido dejar atrás ciertos prejuicios limitantes y superar algunos complejos. Porque ser diseñador no es solo lo que parece. Para llegar hasta aquí algunos hemos aprendido ilustración, publicidad, marketing, negocio; otros, neurociencia, psicología, filosofía, estética, historia, etc. Y es que el sistema está admitiendo el verdadero significado de la palabra diseño, cuya definición en Wikipedia reza así:
Proceso creativo previo de configuración mental en la búsqueda de una solución en cualquier campo, que involucra variadas dimensiones que van más allá del aspecto, la forma y el color, abarcando también la funcionalidad, la operatividad, la eficiencia, la vida útil y la interacción de un objeto con el usuario.
Llegados a este punto, solo falta que como diseñadores asumamos desde la más profunda humildad la responsabilidad de un significado tan amplio, decidir cada uno hasta dónde está dispuesto a llegar (especializarse o no…) y seguir ensanchando nuestras capacidades.
Pero desafortunadamente, arrastramos un problema que, aunque quizá para algunos cuantos afortunados esté ya superado, sigue afectando a diseñadores de todos los ámbitos incluso independientemente de su experiencia. Y por alguna extraña razón tendemos a ocultarlo. Por la propia empresa, donde la «paz social» en la oficina prevalece, en lugar de identificar, reconocer y atajar el problema de frente a él. Y por los propios trabajadores, que o bien lo entienden como un fracaso profesional del que prefieren no dar cuentas o bien lo niegan porque no le dan la importancia que realmente tiene. Para corroborar que así es y que se trata de un tema de actualidad, me he permitido hacer una pequeña encuesta entre algunos de mis contactos. Y los datos, aunque no sorprendentes, evidencian que tenemos que seguir esforzándonos.
Preguntando a diseñadores de diferentes empresas, edades y grados de responsabilidad, he podido comprobar que más del 80% reconoce haber tenido algún problema con compañeros de desarrollo. Soy la total falta de sorpresa de Jack. Lo curioso es que en la misma encuesta, encontramos el mismo porcentaje de programadores que denuncian haber tenido problemas con diseño. Por lo que el victimismo que nos caracteriza a los diseñadores en este asunto se ve en cierto modo desmantelado. Se acabó la tradicional pataleta afterwork.
Así pues, si se me permite el atrevimiento y salvando las distancias, me he propuesto montar una especie de club de la lucha cuyo proceso catártico nos libere en cada combate, derribando nuestras frustraciones, para dejar atrás el problema de una vez. Solo así podremos estar a la altura de la profesión y seguir avanzando. Sé que esto afecta tanto a los diseñadores y programadores noveles como a los más experimentados, así que adelante, estáis todos invitados.
En la película de David Fincher, solo después de despojarse de sus miserias en cada combate, los personajes son capaces de reconocer que no son enemigos entre sí y empezar a trabajar en equipo bajo un objetivo común. En nuestro caso, cada combate consistirá en dar visibilidad a uno de los problemas que se han visto reflejados en la encuesta, analizarlo y grabarnos a fuego la solución. Esto es una quemadura química.
1. «Programadores y diseñadores somos tan distintos que nunca llegaremos a entendernos»
📊 El 40% de los diseñadores está de acuerdo en mayor o menor medida con esta afirmación. Mientras que un 20% de los programadores está solo en parte de acuerdo y ninguno de ellos lo está en su totalidad. Por otro lado, 1 de cada 5 diseñadores confiesa que piensa que la mayoría de los programadores son «un poco frikis y antisociales», y algo más del 17% de los programadores piensan que gran parte de los diseñadores son «unos gafapasta que van de guays.»
Dado que aún hay algunos que comulgan con los estereotipos más tópicos de cada profesión, me gustaría hacer una breve reflexión. En cierto modo es cierto que, dado que nuestra formación y trayectoria es diferente, muy probablemente tengamos que hacer un esfuerzo por congeniar; por eso estamos aquí, ¿no?. Pero no podemos pensar que estamos todos cortados por el mismo patrón, los profesionales no respondemos a ningún molde. Existen diseñadores con una mente mucho más analítica que la de un programador, del mismo modo que existen programadores tan creativos como cualquier diseñador o más. Aún contando con que dichos ejemplos sean extremos, debemos tener en cuenta todos los estados intermedios, por lo que segregar nuestras capacidades es tan insultante como afirmar que, por definición, un hombre cocina peor que una mujer. Por consiguiente, vamos a dejar los prejuicios a un lado, para siempre. No somos iguales, pero las diferencias que podamos detectar entre un perfil y otro no son mayores que las que se encuentran con cualquier otra persona. You are not your job.
2. «Diseño pide cosas imposibles» 🆚 «Desarrollo dice que algo no se puede hacer y no es verdad»
📊 Aproximadamente el 40% de los programadores alega que lo que diseño solicita no es factible. Y el 80% de los diseñadores denuncia que desarrollo miente en este asunto.
¡Oooh, dios mío! Este es un clásico. Nos ha pasado a todos. Para bien o para mal, los diseñadores somos unos soñadores. Y creo firmemente que debemos serlo. La creatividad nos impulsa a proyectar ideas, concebir cosas que aún no existen. Y es que poner las miras más allá de lo conocido genera progreso. Si abordásemos todos los problemas que se nos presentan con la misma solución conocida hasta el momento, nunca terminaríamos de resolverlos realmente. Copia de una copia de otra copia. Un diseñador comprometido con su trabajo siempre intentará innovar de algún modo con la ilusión de conseguir el mejor resultado final posible. Ese no es el problema. El conflicto deriva de otras circunstancias muy variadas:
- A veces dicho impulso creativo nos juega malas pasadas. La euforia nos hace olvidar las limitaciones del proyecto. Y entonces, efectivamente, diseñamos cosas “imposibles”. Independientemente de si el diseñador conoce lo suficiente o no la tecnología con la que se va a llevar a cabo el trabajo, la mayoría de las veces no se trata de si es posible en el sentido técnico y más estricto de la palabra. Marla, maldita embustera. Lo más seguro es que sí se pueda hacer, pero no bajo las circunstancias específicas del proyecto. Los tiempos estimados, el presupuesto, los recursos disponibles, los requisitos técnicos, las APIs y librerías, incompatibilidades varias y demás variables también forman parte del reto del diseñador y deberá poner a prueba su ingenio para someterlas al servicio de los objetivos. La creatividad aflora cuando nos encontramos con problemas o limitaciones. Aprovechémoslo.
- Otras veces sí se trata de cierto desconocimiento. La gran mayoría de diseñadores no saben programar. ¿Es necesario? No. No lo es. Olvidémonos ya del «designers should learn to code», por favor. De tanto repetirlo hay quien hasta se lo cree. El oxígeno te coloca. Pero es que maquetar no es programar, amigos. Por lo que me pregunto, tal y como he apuntado antes, si no hemos tenido ningún recelo en aprender un sinfín de materias para crecer como profesionales, deberíamos tenerlo en aprender cómo funcionan determinados lenguajes involucrados en nuestro cometido. Ciertamente, no. En su día no tuvimos ningún reparo en aprender sobre técnicas de impresión, tintas, materiales, tipos, etc. Así que hay que asumir que conocer el funcionamiento de HTML, CSS, JavaScript o XML ayuda muchísimo a desempeñar de una manera más eficiente nuestra tarea. No es necesario picar código, pero sí dominar sus fundamentos. El esfuerzo por aprenderlo se verá recompensado con creces.
- También es posible que no hayamos explicado a desarrollo con la suficiente claridad nuestra maravillosa idea para la funcionalidad de turno. No podemos esperar que los demás se metan en nuestra cabeza. Analiza tu idea y antes de lanzarla al mundo, asegúrate de que sabrás transmitirla a tus compañeros. Haz bocetos, pequeñas animaciones, infografías, lo que haga falta para que se entienda. Adapta también el vocabulario, evitando tecnicismos propios de la profesión. Si el programador no entiende bien tu planteamiento, no esperes un sí por respuesta.
- Has estado trabajando todo el diseño durante días basándote en una idea que no has contrastado con tus compañeros y cuando llega el momento de implementarlo, ¡zas! no se puede hacer. No esperes al momento de la entrega. Consulta con tus compañeros cuando te pongas a trabajar sobre un concepto. Mantente en constante comunicación con ellos a lo largo de todo el proceso. Desarrollo agradecerá que cuentes con ellos y vuestra relación ganará confianza. Ya no te dirán que algo no se puede hacer sin más y como buenos profesionales, investigarán alternativas para poder llevar a cabo tu idea, te propondrán otras opciones que quizá desconocías y, al estar aún en fase de diseño, no estarán tan agobiados con la implementación. Si no lo hacen motu proprio, pídeselo. Prototipa y garabatea mucho sobre papel, es rápido, barato y altamente efectivo. Solo así podrás construir tu diseño sobre seguro y no perderás el tiempo ni se retrasará el proyecto. Además, de esta manera, no te harás ilusiones con una idea a la que posteriormente tendrás que renunciar. Descartarla desde un principio, cuando aún no está desarrollada en tu cabecita, te permitirá olvidarla más fácilmente y trabajar más contento y despreocupado en una alternativa.
3. «Diseño no facilita las especificaciones adecuadas» 🆚 «El programador no respeta las especificaciones»
📊 Casi el 80% de los diseñadores se lamenta de que los programadores no respetan sus diseños a la hora de implementarlos y aproximadamente el 50% de los programadores denuncia no recibir los recursos y especificaciones adecuadas, así como que el diseñador considera que su trabajo se explica solo.
Hace tiempo los diseñadores nos veíamos obligados a realizar las especificaciones de nuestros diseños “a mano”, pintando flechas y cotas sobre ellos. Otros pasaban el .psd directamente a desarrollo para que pudieran ver los detalles. Y también había que exportar todos los recursos uno a uno. Luego llegaron los plugins o extensiones que dibujaban automáticamente las especificaciones en una capa sobre nuestro diseño y los que exportaban de un solo plumazo todos los recursos desde Photoshop o Sketch. Después Avocode, Zeplin, Sympli, Inspect de Invision, etc. dando un paso más hacia nuestra comodidad y un empujoncito a la colaboración entre departamentos. Lamentablemente, cualquier tipo de automatización sufre una desvirtuación. Lo sé porque lo sabe Tyler. Y es que desde que han irrumpido en nuestras vidas dichas herramientas, hemos descuidado algunos detalles importantes:
- No basta con sincronizar nuestros archivos con Sympli o Zeplin sin más. Para que este tipo de herramientas resulten útiles de verdad, el diseñador debe ser muy metódico:
- Con la organización, la agrupación y la nomenclatura de los artboards y de las capas en el programa de origen. Asegurarse de hacer exportables todos los recursos gráficos necesarios de la forma adecuada. Saber cuándo optar por un recorte en una capa independiente (slice) y agruparlo cuando lo queremos con fondo transparente, activando la opción correspondiente. Por ejemplo, para que todos los iconos de un mismo tipo respeten la proporción cuadrática que les corresponde e independientemente de su forma tengan las mismas medidas. Además, hay que ser escrupuloso con los nombres de las capas y de los grupos. “Group Copy” no dice nada. Pacta una nomenclatura consistente y descriptiva con el resto del equipo desde el principio y así nadie se llevará sorpresas ni perderá el tiempo buscando un recurso.
- Con los colores y las tipografías: Quizá haya una semibold por ahí o un color con otro matiz que habías desechado. ¿Residuos? Haz limpieza. Confirma que las especificaciones solo recogen los colores y tipografías definitivos. El programador no tiene por qué saber discriminar entre todo ese maremagnum de datos. ¡Y adjunta las fuentes en todos los formatos necesarios!
- Con los componentes: Reúne en un solo artboard los diferentes estados de un mismo componente. Botones, formularios, tarjetas…
- Hay especificaciones indispensables que no se generan automáticamente y no quedan reflejadas en ningún sitio. Estas herramientas están muy bien, pero de momento no son todo lo inteligentes que nos gustaría. Así pues, en determinados diseños, se hace necesario matizar algunos datos que hay que comentar directamente con desarrollo:
- Las medidas: ¿Cuáles deben ser relativas y cuáles absolutas? Refléjalo en algún otro documento que compartas con desarrollo o coméntalo con ellos directamente. Cuidado con las unidades de medida porque cambian entre plataformas. No infundirás ninguna confianza en un programador de iOS si le hablas de las medias en dp o px en vez de en pt.
- Las animaciones: Es probable que además del diseño estático, hayas preparado algún prototipo con animaciones entre pantallas o algún otro tipo de microinteracción animada. Es indispensable que las revises con desarrollo en persona para asegurarte de que las han interpretado como tú esperas. Coteja con ellos cualquiera que sea el efecto visual.
- Los recursos gráficos: ¿Cuáles deben descargarse en SVG y cuáles en PNG o JPG? Es posible que el programador ignore las recomendaciones a este respecto y como el formato SVG es muy popular en su sector, tenderá a utilizarlo indiscriminadamente. Comenta con él tus preferencias, por ejemplo: iconos en SVG, ilustraciones en PNG y fotografías en JPG. Algunas veces los diseñadores hacemos correcciones en los iconos en función de su tamaño, de tal manera que la exportación automática no sirve. Avisa al programador de que has preparado unos iconos especiales para la ocasión.
- Las tipografías: Examina en persona los estilos que has utilizado y asegúrate de que el programador los identifica. Consulta con él también en qué formatos necesitará las fuentes.
- La comunicación: Aprovechad las opciones de colaboración que aportan dichas herramientas. Explica brevemente sus opciones a los que van a trabajar contigo. Invítales a hacer zoom, inspeccionar las capas y revisar los comentarios. Tanto si estás trabajando en remoto como si no, es interesante dejar constancia de la conversación relativa al diseño. Dado que existen varias alternativas (comentarios de la propia herramienta, integración con Slack, etc), lo más importante es decidirse por una y mantener el diálogo centralizado.
De esta manera, la maquetación será más fácil, desarrollo no tendrá problemas con nuestros recursos y podremos comprobar que el proyecto se va pareciendo cada vez más a nuestro diseño.
4. «El diseñador ha hecho un cambio que me obliga a repetir el trabajo» 🆚 «El programador me pide cambios que no encajan con mi diseño»
📊 Más del 70% de los programadores acusa los cambios de diseño de última hora. Y el 60% de los diseñadores confiesa no encajar bien del todo las modificaciones que propone desarrollo. Paralelamente, el 30% de los programadores dice que el diseñador no acepta bien las críticas y el 20% de los diseñadores se queja de que el programador dice que no le gusta el diseño. Además, el 70% de los diseñadores acusa a desarrollo de cambiar el diseño sin consultar.
Como diseñadores, tenemos que aceptar que, en cierto modo, un trabajo nunca está terminado, evoluciona e iteración tras iteración, irá transformándose como si fuera un ente con vida propia. Y un buen sistema de diseño será escalable y flexible, para poder adaptarse a cualquier situación. Por lo que no sirve de nada encariñarnos con un trabajo tal y como fue concebido inicialmente porque por una u otra razón, cambiará con el tiempo. Así nos costará menos aceptar modificaciones. Únicamente cuando se pierde todo somos libres para actuar.
Todos debemos estar abiertos a los cambios. Pues hay veces que a pesar de haber hecho un esfuerzo por mantener el contacto constante con desarrollo, desde diseño nos vemos obligados a realizar una modificación de última hora. Generalmente por petición del cliente. No nos lo tengáis en cuenta. Lo que sí podemos hacer en una situación así es intentar que sea lo menos traumático posible para todos sin repercutir en el resto del desarrollo. Es en estos momentos críticos cuando la relación sale fortalecida si existe colaboración y empatía entre departamentos. Aún así, hay veces que los cambios no sientan bien, ni por un lado, ni por otro.
También es verdad que las novedades de última hora no siempre surgen por exigencia del cliente. Hay que reconocer que a veces no sabemos prever determinado comportamiento de una web o app. ¿Cuántas veces el programador ha tenido que improvisar una pantalla que no había sido contemplada? A este respecto podemos hacer al menos tres cosas:
- Cultivar la relación con desarrollo para que, llegado el momento, no tengan reparo en consultar con nosotros lo que haga falta. No deben vernos como los que les generan problemas, sino como solucionadores.
- Diseñar un sistema consistente, modular y predecible, de tal manera que, si en algún momento extremo hay que improvisar una pantalla o extrapolar algún comportamiento, sea lo suficientemente obvio y prácticamente se componga solo sin necesidad de movilizar a todo el mundo.
- Adelantarse a los acontecimientos. Contemplar toda la casuística posible desde un principio y aportar soluciones a todas las situaciones: empty states, contenedores sin contenido, placeholders, textos de longitud variable, mensajes de error, notificaciones, etc.
Por otro lado, no olvidemos que de diseño opina hasta ritalacantaora. Cuando alguien dice que algo “le gusta” está expresando que coincide con sus preferencias personales. ¿Es esto un objetivo del proyecto? No. Con lo cual, evita e ignora cualquier comentario, propuesta o crítica formulada desde el verbo “gustar” en primera persona, incluso cuando sean positivos. Establecer esta norma en el equipo desde un principio ayuda muchísimo a centrar cualquier tipo de comentario en dirección a los objetivos, al margen de cualquier gusto particular. Los 👍🏻 y los 💕 se pueden dejar para Facebook o para la birra de después de currar, también se agradecen. Las relaciones profesionales se construyen desde el respeto y la confianza. Del mismo modo en que nadie aceptaría que un arquitecto opinase sobre el diagnóstico de un médico, resulta totalmente inadmisible emitir juicios de valor sobre el trabajo de un compañero sin la potestad necesaria para hacerlo. Dicho esto, no es difícil comprender que los diseñadores nos mostremos irascibles a ciertos comentarios, pero no hay razón para no aceptar las críticas que sean oportunas, siempre que se ajusten a las pautas del proyecto. Me has conocido en un momento extraño de mi vida.
5. «No me gusta que diseño me diga lo que tengo que hacer» 🆚 «Desarrollo hace caso omiso de mis indicaciones»
📊 El 70% de los diseñadores tienen la sensación de que a desarrollo le molesta recibir indicaciones de su parte. Mientras que solo el 30% de los programadores confiesa que así sea. Además, al menos el 30% de los diseñadores se quejan de que en desarrollo no entienden lo que se les dice y el 90% opina en mayor o menor medida que al programador solo le interesa que lo suyo funcione.
Una vez que el canal de comunicación entre un departamento y otro está abierto, es muy posible que nos demos cuenta de que no nos estamos entendiendo del todo. Se llama cambio de proyector, la película sigue rodando y nadie del público se ha enterado de nada. ¿Cuántas veces te han enseñado la maquetación “terminada” y no se parecía en absoluto a tu diseño? Que no cunda el pánico, no es porque el programador no respete tu trabajo, es porque no está preparado para distinguir las diferencias entre un estilo y otro. Como diseñadores, ya hemos hablado de explorar otros territorios, pero podemos hacer algo más: invitar al programador a tomar un té en nuestro propio territorio. Ellos también quieren aprender y en un equipo todos deben poner de su parte. Propón a la empresa realizar pequeños talleres de “diseño aplicado a programadores” o de “principios de diseño para trabajar en equipo”. Cuando te acerques a ellos para explicar tu diseño, hazlo en parte como labor didáctica. No bastará con que enfatices la presencia de un texto en itálica, por ejemplo; háblales por encima de tipografía básica, pesos tipográficos, jerarquía, etc. Háblales también de branding, color, iconografía, ilustración, fotografía, design systems (¡chupito!), del usuario… Es muy importante que, una vez que les has pasado las especificaciones y explicado el comportamiento de un diseño, sepan interpretarlo adecuadamente.
Los beneficios de hacer partícipe al programador de nuestro mundo son incontables:
- Comprenderá el por qué de nuestras indicaciones.
- Será capaz de implementar los diseños con más detalle.
- Dejará de sentir que diseño se inmiscuye en su terreno.
- Respetará más nuestra actividad y sus tiempos.
- Las modificaciones que solicite a diseño serán más razonables.
- Se implicará en el proyecto más allá de su cometido individual.
Somos afortunados de trabajar con talentos tan diversos en un sector en constante crecimiento y tan apasionante como este. Creo que deberíamos disfrutarlo más superando cualquier circunstancia disfuncional que no nos permita mostrar lo que somos capaces de hacer.
Pues bien, después del combate toca lamerse las heridas. Si a partir de ahora somos capaces de pasar página, prometo no volver a hacerlo. Mañana será el día en que lo único que no nos permita lograr nuestras metas profesionales sean las limitaciones tecnológicas. No quiero morir sin tener cicatrices.
Finalmente, nuestras reglas del club serían:
- La primera regla del club es: hablar del club a todo el mundo.
- La segunda regla del club es: hablar del club a todo el mundo.
- La tercera regla del club es: abordar cualquier relación laboral sin prejuicios confiando en la profesionalidad de todos.
- La cuarta regla del club es: aprovechar las limitaciones del proyecto para desarrollar soluciones creativas.
- La quinta regla del club es: aprender otras disciplinas que comprometen nuestro trabajo.
- La sexta regla del club es: estar en constante comunicación con los compañeros.
- La séptima regla del club es: estar abiertos a las críticas.
- La octava regla del club es: compartir conocimiento.
- La novena regla del club es: si esta es tu primera noche en el club, tienes que pelear.
¿Cambiaríais o añadiríais alguna otra?