“Tener empatía es una habilidad importante como diseñador porque al final del día estamos diseñando algo para mejorar la vida de alguien. Para hacer esto, es necesario empatizar con las personas para las que estamos construyendo.”
Hablar de empatía y hablar de diseño nos resulta una obviedad, lo asumimos como algo natural y lógico. Sabemos que para ser diseñadores de experiencias tenemos que tener empatía, necesitamos empatizar con nuestros usuarios, sus necesidades y sus dolores.
El problema radica en que, a la hora de pensar en nuestro usuario, solemos hacer foco en el usuario final, es decir, para quién va a ser el producto y no nos damos cuenta de que nuestros primeros primerísimos usuarios, aquellos que primero se enfrentan con nuestro trabajo, son los devs.
Entonces tenemos que pensar en ellos, tenerlos en cuenta, asumirlos como usuarios, trabajar con y para ellos y considerar el proceso y no solo el resultado final. Ahora, al cambiar el enfoque, tenemos que considerar nuevos aspectos de la situación a enfrentar.
¿Qué esperamos nosotros de los Devs?
Nosotros sabemos muy bien que esperamos de ellos: queremos que construyan lo que nosotros diseñamos, que respeten nuestro trabajo, nuestro esfuerzo, el tiempo que invertimos y las decisiones que tomamos con criterio y que, si surge algo, se lo pueda charlar, que nos pregunten y podamos debatirlo en conjunto.
¿Qué esperan los Devs de nosotros?
En la otra cara de la moneda: ellos esperan que seamos claros y consistentes, que les pasemos todos los entregables y assets que fueron pactados, sin necesidad de tener que reclamarlos. También es útil y necesario que ellos participen de nuestras reuniones, especialmente para poder pensar la funcionalidad y la lógica, más allá de la UI y poder dar feedback sobre cuán posible es realizar nuestras ideas, especialmente considerando los deadlines particulares de cada proyecto.
Entonces… ¿Qué falla?
Porque hay que ser honestos y decirlo, algo falla en esta relación y debemos cambiarlo. No tenemos una relación particularmente fácil con los devs, por muy bien que nos llevemos con ellos cuando no hablamos de trabajo. Entonces, ¿dónde está el problema? A los devs les molesta que nosotros no pasemos todo listo para usar, a nosotros, en cambio, nos molesta que ellos no sigan tal cual nuestros diseños. Todos esperamos que el otro haga bien su trabajo y nos frustra encontrarnos con que el otro no está a la altura de nuestras expectativas. Pero el problema está, mayormente, en la comunicación. Son estos los que llevan a malinterpretaciones o incluso diferentes interpretaciones del mismo objetivo, implican un debate y pérdida de tiempo innecesarios de cosas que no se comprendieron o aclararon antes, problemas que se podrían haber anticipado y resuelto en menos tiempo, por solo nombrar algunos inconvenientes. Y la realidad es que, si resolvemos los problemas de comunicación, vamos a estar resolviendo indirectamente, el resto de nuestros problemas. A mayor y mejor comunicación en el proceso, mejor va a ser el resultado final.
¿Qué podemos hacer nosotros?
Acá es donde empieza a entrar en juego la idea de ser proactivos. La pregunta es entonces: ¿De qué manera nosotros podemos mejorar nuestra relación con ellos? ¿Cómo nos ganamos un espacio en su corazón para conseguir que colaboren con nosotros de buena voluntad y con entusiasmo?
- Acordarnos que el dev es nuestro primerísimo primer usuario.
- Organizar un kick off al comienzo de cada proyecto para pactar objetivos, plazos, herramientas a utilizar y entregables, y luego hacer mini reuniones para pasar los entregables, esto es ideal especialmente para despejar dudas que puedan surgir en el proceso.
- Pasar los entregables y assets de manera prolija, con los comentarios necesarios y reuniones pertinentes para su correcta interpretación.
- Pensar nuestros diseños de forma modular, para que el código pueda ser reutilizable y genere un sistema consistente, lo que además ahorrará tiempo y trabajo.
- Conocer qué tecnología se va a implementar y cuáles son sus limitaciones. Cuanto más sepamos sobre cómo trabaja el otro, más fácil es saber qué le estaremos pidiendo y qué le implicará. Cómo diseñadores no tenemos la obligación de saber sobre programación, pero el hecho de tener conocimientos básicos sobre HTML y CSS ya ayudan un montón, y cualquier otro conocimiento extra que podamos incorporar, nunca va a estar de más.
- Cuidando la comunicación y fomentando el intercambio de ideas y opiniones (especialmente cuando hay entregables complejos). A veces, el mayor impedimento es no comprender el trabajo del otro. Los diseñadores planteamos cosas que implican demasiado código complejo. Inversamente, los devs no comprenden por qué algo técnicamente posible no es usable para el usuario. Es justamente en estos casos donde el diálogo es imprescindible para entender las limitaciones, delimitar el proyecto y llegar a resultados óptimos desde ambos puntos de vista. Lo ideal es que el intercambio pueda ir más allá de lo que abarca el proyecto, y fomentar el intercambio de conocimientos y tendencias, para poder trabajar cada día más en sintonía.
- No esperar a llegar a la última etapa para pasarles las cosas. Incluirlos en el proceso desde el principio, consultarles su opinión, indagando cuán posible es lo que estamos proponiendo (sobre todo por el tiempo que tenemos disponibles, porque tal vez posible es, pero no para los plazos que se fijaron previamente).
- Debemos estar abiertos a que el otro influya en nuestro trabajo. De nada sirve que la comunicación sea en un solo sentido.
“Si querés que la gente se involucre, necesitás asegurarte que se sientan incluidos en la conversación.” — Kristina Halvorson
La frase habla justamente de la importancia de apropiarse del proyecto para que la gente se involucre y colabore. Y no colaborar por el simple hecho de cumplir con sus tareas, sino colaborar de buena gana, aportando ideas, conversando, iterando, alcanzando así mejores resultados. Porque de eso se trata, de generar diálogo, que la gente pueda conversar, aportar su punto de vista, sus conocimientos, trabajar en conjunto, que sea un ida y vuelta constante, diario. Porque al final del día lo importante es eso: trabajar en equipo.
