¿Cómo Entrenar a Tu Diseñador?

Hola, así es como entrenar a tu diseñador. Soy Dora Moxie, y soy una diseñadora UX. Comencé mi carrera en una empresa de software de navegación para automóviles como desarrolladora de UI.

Desarrollamos y diseñamos soluciones de software para PDA de diferentes tamaños de resolución, lo que significaba muchos componentes. Así que, sin siquiera notarlo, estaba creando mi primer sistema de diseño mucho antes de que fuera popular. También me ocupaba de las operaciones de diseño, que es algo similar a lo que los desarrolladores tienen con DevOps. También probé como gerente, pero ahora he vuelto al diseño. Y me di cuenta de que esta especie de mezcla de conocimientos podría interesar a la gente.

Así que comencé a enseñar a la gente, a educar y compartir artículos y hablar sobre este tipo de colaboración entre desarrolladores y diseñadores. Actualmente, estoy felizmente empleada en Element Logic, que es una empresa de desarrollo de software de automatización de almacenes. Así que veamos de qué hablaremos hoy. Tendremos una especie de iniciación. Miraremos dentro de la cabeza de los diseñadores. Veremos qué está pasando con el gerente. Resaltaré cómo los diseñadores perciben a los desarrolladores. Descubriremos cómo construir puentes si es necesario. Y habrá algunos puntos clave. ¿Por qué alguien querría capacitar a un diseñador? Supongamos que somos egoístas.

Así que la gente quiere capacitar a su diseñador para sí mismos. Porque si un diseñador entiende qué y cómo entregar, entonces toda la entrega, todo el desarrollo será fluido. Cuando se trata de evolución en la naturaleza, las especies intentan adaptarse a cada cambio. Porque si se adaptan, no se extinguirán. Si no se adaptan, bueno, tengo malas noticias para ellos. ¿Qué sucede en una empresa liderada por ingenieros? Si los ingenieros quieren involucrar a un diseñador, vendrá con cambios, y la organización tendrá que adaptarse. Al principio, ralentizará todo, porque todos, cada participante intentará adaptarse a los cambios. Y de esta manera, no podrán concentrarse en sus rutinas diarias. Pero esto es una inversión. Porque durante la segunda etapa, que es la integración, este ya será un proceso más largo. Habrá resultados mejorados. Todos intentarán encontrar sus nuevos lugares.

Se adaptarán a los cambios. Y podrán estabilizar todo el sistema, sus rutinas. Y finalmente, la fase de entrega llegará con rutinas muy bien engrasadas, para que el equipo tenga tiempo para innovar.

¿Qué está pasando en la mente del diseñador? Conoce al diseñador. El dragón es el diseñador. Los dragones, no sé si lo sabías, pero específicamente en la película How to Train Your Dragon, tienen un punto de vista muy, muy distinto. Son curiosos, al igual que los diseñadores, y escuchan mucho, al igual que los diseñadores, y piensan mucho, al igual que los diseñadores. Cuando escuchamos, intentamos procesar lo que oímos, e intentamos ya conectar los puntos, y encontramos nuevas formas de resolver diferentes problemas. Por lo tanto, para eso, necesitamos datos. Nos encantan los datos. Una vez que analizamos los datos, podemos priorizar los problemas, y para poder señalar la perspectiva de viabilidad, nos gusta discutir esto con los ingenieros. Nos encanta involucrar a los ingenieros, ingenieros de QA, porque tenemos que probar cada solución en la que trabajamos.

Hay un caso de uso que quería compartir contigo. Hace unos años, era nuevo en una empresa, y no existía tal cultura de comunicación entre diseñadores y desarrolladores. Una vez que sentí que estaba listo con mis archivos de diseño, me acerqué al Jefe de Desarrollo y le pedí que comentara sobre mi archivo de diseño en cuanto a viabilidad. Esto vino con el gran beneficio de que una vez que llegamos a la fase de entrega de la documentación de diseño, todo el equipo de front-end ya estaba al tanto de qué entregar y cómo, y podían contactarme siempre que tuvieran una pregunta. El diseño exitoso consiste en un enfoque estructurado. Cuanto más fácil sea la comprensión, más rápida será la entrega. Si tú, como diseñador, documentas tu trabajo adecuadamente, de manera transparente y clara, los desarrolladores tendrán cada vez menos preguntas, porque podrán encontrar su camino en el archivo de Figma y estarán seguros de entregar todo. La otra parte importante aquí es cómo ser efectivo. Si se comunican entre sí sin problemas, entonces el proyecto será un éxito. Si hay muchos malentendidos que no se aclaran, el proyecto será un desastre. Así de simple. Por ejemplo, otro ejemplo de un desarrollador real. Estaba trabajando con un diseñador, y el diseñador entregó el archivo de Figma. Y los desarrolladores, sin mencionar a mi amigo, no preguntaron nada. Y esto debería haber sido sospechoso para el diseñador. Si un desarrollador no tiene una pregunta, significa que no están escuchando. Así que, diseñadores, desconfíen cuando no tengan preguntas de los desarrolladores.

Bien. ¿Cuál es el proceso de diseño? Primero, los diseñadores empatizan con el cliente, el problema, el requisito del negocio, con todo. Quieren entender todo. Esta es la fase de análisis de datos. Segundo, basándose en sus aprendizajes, definirán las prioridades y elaborarán flujos de trabajo, flujos de usuario, mapas de empatía, todo lo que ayude a entender y analizar las prioridades junto con los interesados del producto. La tercera fase es cuando el diseñador crea wireframes y prototipos de baja fidelidad. Esta es la etapa de fallar rápido. Todo lo que el diseñador entregue, debe ser probado. Y este es el punto en el que los desarrolladores pueden señalar problemas de viabilidad. También se aconseja involucrar a personas de soporte, personas de marketing e ingenieros de QA en esta fase, porque aportarán sus diferentes perspectivas. Y cuanto antes tenga el diseñador todas las diferentes perspectivas, mejor.

Prototipo. Los diseñadores crean maquetas y prototipos de alta fidelidad, para que se vea como el verdadero producto, y este es el punto en el que realmente pueden identificar los posibles callejones sin salida que no funcionarán en absoluto. Y todo lo que crean, deben probarlo en todos los sentidos. Bien. En la película, How to Train Your Dragon, Hiccup descubre que Toothless no podía volar porque le faltaba una aleta. Así que entendió el problema y comenzó su propia investigación. ¿Cómo puede ayudar al dragón? Creó wireframes de baja fidelidad, y luego probó las soluciones de baja fidelidad en la cola de Toothless. Una vez que terminó con el prototipo de baja fidelidad, creó las maquetas de alta fidelidad y probaron el prototipo real. Una vez que estuvo listo, hubo una documentación y entrega, y Toothless finalmente pudo volar.

¿Qué está pasando en la cabeza del gerente? Este es el gerente. Los gerentes se ocupan de las tres T. Herramientas, equipo, tecnología. Si algo es problemático de estas tres, entonces el equipo tiene un problema. La responsabilidad del gerente es averiguar cuál es el problema, pero no es responsabilidad del gerente resolver el problema. La solución del problema es entre las partes problemáticas. Y siempre tenemos que plantear la pregunta, ¿qué podemos aprender de esto? Porque si abordamos un problema con una actitud de qué podemos aprender de esto, entonces ya estamos evolucionando y adaptándonos a los cambios. Mi anterior gerente, Jonathan Gahl, decía, escucha a la gente, cierra la boca, no intentes resolver el problema. La gente tiene que hablarlo. Tan simple como eso.

Mientras entregaba diferentes archivos de diseño, con el objetivo de lograr una experiencia del desarrollador al 100%, uno de mis excolegas favoritos, David Kroll, me dijo que no debería intentar resolver todos los problemas para los desarrolladores. Los desarrolladores no pueden mejorar como profesionales si les proporciono todo. Básicamente, me animó a desafiar a los desarrolladores a encontrar sus propias soluciones. Los diseñadores no deberían adoptar los sesgos de los ingenieros. Las preocupaciones tempranas de viabilidad de los ingenieros pueden impactar negativamente en la solución. Lo que significa que, sí, es importante obtener retroalimentación de los desarrolladores sobre la viabilidad, pero no es necesariamente una tarea resolver cada problema de viabilidad. Porque si los desarrolladores pueden resolver ese problema, ya han mejorado como profesionales.

Y ahora, finalmente, la perspectiva del diseñador, cómo los percibimos a ustedes como ingenieros. Debemos establecer las bases para las críticas de diseño. Debemos involucrar a los desarrolladores en nuestro mundo para que tengan la oportunidad de dar retroalimentación. Los desarrolladores deben involucrarnos viceversa cuando se trata de la revisión de diseño. Una vez que comiencen a desarrollar el producto, la característica, deben involucrar a los diseñadores para tener revisiones de diseño. Porque si un diseñador puede señalar un problema potencial o un error o algo que no encaja con el archivo inicial de Figma, entonces ya han ahorrado mucho tiempo y debate con el ingeniero de QA. Así que involúcrense mutuamente en las sesiones de prueba.

Bogoslav Vojcik comenzó su carrera como psicólogo y terminó como desarrollador. Y me dijo, comparte todo tu conocimiento del dominio, explica las complejidades a fondo y mantente de mente abierta. Esto podría ser cierto para todos en este grupo. Kristof Viznad es un líder de equipo móvil. Y me dijo que los diseñadores no deberían solo mostrar el diseño, debería ser una discusión. Es una comunicación de ida y vuelta entre desarrolladores y diseñadores. Este es un esfuerzo conjunto común entre estas personas. ¿Cómo podemos construir puentes? En ElementLogic, utilizamos el llamado trío de producto.

La ingeniería es responsable de la viabilidad. UX y diseño son responsables de la usabilidad. Y juntos, estos tres como socios iguales, aportan el valor del negocio. Es muy importante que el diseño no esté bajo la ingeniería o bajo la gestión de producto. Todos somos iguales.

En la película, Hiccup y Toothless identifican los puntos de colaboración. Y esto es exactamente lo que deben hacer los desarrolladores y los diseñadores. Una vez que lo hicieron, pueden trabajar juntos. Pueden dar oportunidades para la contribución. Y pueden tener un esfuerzo conjunto con mucha paciencia, especialmente al principio. Una vez que conoces a tu diseñador en tu equipo, ya es más fácil. Pero una vez que piensas que, oh, este diseñador querrá decirme qué hacer y cómo. Es un poco diferente. Y sentirás la diferencia. Si no puedes participar en el trabajo de diseño, al menos no lo bloquees. Porque el proceso de diseño realmente funciona. Aportará mucho valor a la organización y al equipo. Pero si no puedes aportar ningún valor, al menos no lo bloquees, por favor. Los beneficios vendrán.

El diseño iterativo viene con el beneficio de aprender juntos, crecer juntos, entender mejor el uno al otro. Te convertirás en un socio igualitario con el diseñador, lo cual es genial cuando se trata de desarrollo. ¿Cuáles son las conclusiones clave? En resumen, la diversidad conduce a soluciones más sólidas. La participación en el proceso de diseño vale la pena. Conocerás nuevos aspectos. Y crecerás profesionalmente, porque serás desafiado. Te enfrentarás a tantas nuevas soluciones que no habías escuchado, que tendrás la oportunidad de probar, experimentar incluso. Y te convertirás en un mejor profesional. Pero esto solo puede suceder si hay apoyo de abajo hacia arriba y de arriba hacia abajo. Desafía los prejuicios y respeta las disciplinas. Créeme, los diseñadores quieren entenderte, pero han aprendido mucho.

Ellos son personas inteligentes, al igual que tú. Así que, si tienes algún sesgo, solo intenta enfocarte en diferentes perspectivas y entender por qué el diseñador sugiere algo de una manera diferente. Comparte el conocimiento e involucra a otros. Sé amable. Encuentra a tu nuevo compañero en el crimen.

Pero espera, nos perdimos algo. Este es el usuario. Tenemos que preguntar al usuario. Tenemos que involucrar al usuario. Y tenemos que entender qué está pasando con el usuario. Si entendemos sus puntos de dolor, resolveremos los problemas reales. Y una vez que involucramos al usuario, se comprometerán más. Y estarán más satisfechos, lo que resultará en un ingreso mucho mayor para la empresa, lo que significa un salario estable para ti.

En la película, Hiccup dice que no hay nada que un dragón no haría por ti cuando has ganado su lealtad. Para ser honesto, es completamente cierto también para el diseñador. Así que, te sugiero que capacites a tu diseñador. Valdrá la pena. Muchas gracias. Puedes encontrarme en LinkedIn. Contáctame. Tengamos una buena discusión. Y si tienes alguna pregunta o comentario, no dudes. Contáctame. ¡Nos vemos!