Cómo Sincronizar un Equipo de Desarrollo y Diseño y no Morir en el Intento
Cuatro pasos fundamentales para sincronizar con éxito un equipo de producto
Los equipo de desarrollo y de producto trabajan habitualmente mano a mano con diseñadores de UX/UI; crear un flujo de trabajo óptimo es una tarea que requiere de una serie de procedimientos para garantizar que en las iteraciones no se pierda tiempo y que se obtenga el mejor rendimientos de los equipos de diseño y de desarrollo.
Por regla general, el equipo de desarrollo y el equipo de diseño tienen concepciones distintas sobre como debería ser su trabajo y como debería ser el trabajo del otro. Esto deriva en frustraciones; todos hemos oído frases como:
“ Esta animación no tiene ningún sentido y es imposible hacerla.”
“El desarrollador no ha respetado los márgenes.”
“Este diseño no es el que yo propuse.”
“Es la quinta vez que me cambian el border-radius de un botón.”
Uno de los principales problemas al que nos enfrentamos dirigiendo un equipo de producto es la gran diferencia entre la forma de pensar que existe entre desarrolladores y diseñadores:
A los diseñadores se les pide que sean creativos y generen interfaces vistosas y siguiendo las mejores tendencias de UX/UI. Esto provoca que durante las iteraciones de diseño prueben, experimenten y hagan evolucionar el UX/UI a una velocidad que no siempre se ve correspondida por el equipo de desarrollo.
Por otro lado a los desarrolladores se les pide ser óptimos, conseguir un código con buen rendimiento y sacar código a la mayor velocidad posible, haciendo que no sean precisos a la hora de implementar diseños y antepongan la funcionalidad y el performance al pixel perfect.
En ambos casos, tanto diseñadores como desarrolladores están haciendo bien su trabajo y por eso no se puede culpar a unos de no hacer el desarrollo pixel perfect ni a otros de crear animaciones y diseños de complejidad elevada.
Para solucionar esta situación y generar un espacio donde diseñadores y desarrolladores sean capaces de mantener una conversación fluida y coherente es, desde mi punto de vista, necesario revisar 4 pasos o puntos fundamentales a tratar para obtener un buen desempeño:
- Definir límites
- Crear un sistema de documentación
- Definir intermediarios
- Crear un ciclo de trabajo.
Definir los límites
Definir los límites y cuáles son los parámetros de intercambio de información es fundamental para no caer en frustraciones y conseguir que ambos equipos sean conscientes del scope del trabajo y para evitar malos entendidos entre los equipos. Una de las herramientas mas utilizadas para conseguir esto es el Design System.
Un design system es una guía de reglas y acuerdos a nivel de empresa o de producto. El objetivo es llegar a un acuerdo entre desarrollo y diseño acerca de los elementos fundamentales del diseño de un producto: botones, input, colores, márgenes, elementos concretos…
Definir estos elementos base obliga a diseñadores a mantener una coherencia en el diseño y reutilizar componentes y por otro lado obliga a desarrolladores a crear esos componentes una sola vez y de forma óptima, para luego no tener que plantearse nada más, salvo usarlos y colocarlos.
En definitiva, los nuevos diseños salen mas rápido y se implementan más rápido.
Por supuesto, este design system puede evolucionar, siendo muy importante hacer entender al equipo de diseño que una iteración en el design system es una nueva actualización de una parte core de la empresa y ha de hacerse con cautela.
Todo tiempo invertido en llegar a una guía de estilos que satisfaga tanto a desarrollo como a diseño es tiempo que ahorraremos en la generación de nuevas funcionalidades.
Algunos de ejemplos de design system son:
Crear un design system se puede conseguir aceptando una biblioteca gráfica como estándar dentro del diseño o creando tu propia biblioteca de componentes.
Algunos ejemplos de implementación de un design system son:
Queda a la decisión del product manager decidir, en función del presupuesto y del tiempo, si se debe usar una biblioteca ya existente o crear una propia.
Crear un sistema de documentación
Otro de los parámetros fundamentales es cómo se documenta y dónde. Este punto va a ser muy relevante para intentar reducir los tiempos y hacer que los equipos estén sincronizados.
Si la documentación solo está compuesta por diseños , da igual que sean muy high Fidelity; el desarrollador no va a poder entender el contexto y los detalles del desarrollo al que se enfrenta, así que se producirán entonces muchas iteraciones y conversaciones entre diseño y desarrollo que distraerán a diseño de sus nuevas propuestas y a desarrollo de centrarse en el código.
Generar una documentación tiene múltiples ventajas: por un lado diseñadores y técnicos de producto se ven obligados a repasar sus ideas y propuestas de forma escrita, lo cual deriva a revisiones que suelen completar las primeras versiones de esa documentación.
Por otro lado, una buena documentación evita que, desde desarrollo, tengan que detenerse durante la implementación por estados no contemplados o por situaciones no expresadas correctamente en los diseños.
Un buen documento debe incluir una serie de puntos:
- Contexto sobre por qué esta nueva iteración tiene sentido y en qué contexto se engloba; añadir algunas métricas que lo justifican suele ser muy útil.
- Una explicación de cómo debe solucionar la necesidad del cliente.
Dar al desarrollador una explicación sobre el contexto y las decisiones tomadas en la solución le obliga a ser consciente del problema a solucionar de tal forma que durante el desarrollo pueda empatizar con las necesidades del cliente y se pueden detectar problemas en el diseño que se le hayan escapado al equipo de diseño. Tendemos a pensar que el desarrollador solo debe pensar en la lógica de implementación y no en la lógica de negocio y esto es un grave error.
- Los mockups o diseño en high fidelity y el enlace a sketch, figma o el entorno que uses.
- Una explicación del comportamiento de cada pantalla.
- Los posibles estados asociados a cada pantalla.
- Una referencia a los recursos utilizados, indicando cuál es su referencia en el Design System o en la guía de estilos que hayamos definido.
- Es importante definir las funcionalidades dependientes o que deben implementarse en una misma actualización; es decir, si el documento tiene un desarrollo extenso, podemos dividirlo en varios documentos o definir los sprints mínimos a desarrollar.
Definir intermediarios
Otra de las piezas fundamentales son aquellas personas que entienden tanto al equipo de desarrollo como al equipo de diseño. Suelen tener distintos nombres según la empresa ( Product owner, product manager…)
Durante el ciclo de creación de la documentación, debe ser la persona encargada de asegurar que se cumplen los criterios definidos y acordados y que los diseños no se salen de las capacidades en cuanto a tiempo de trabajo.
Es importante que además de que esta persona tenga una buena comunicación con el responsable del equipo de desarrollo, dado que debe ser con él con quien negocie los tiempo del equipo técnico, consiga que los diseños o las funcionalidades se ajusten a estos tiempos.
Tenemos por tanto 3 componentes fundamentales: una serie de principios y acuerdos entre los equipos , un documento y un intermediario. Es el momento de jugar con estos 3 pilares para definir una metodología de trabajo.
Metodología de trabajo
Es importante definir un método que permita ahorrar tiempo en la ejecución de nuestros objetivos, pero esto no significa que este proceso se haga de forma rápida. Añadir cierta redundancia en los procesos es clave para obtener los mejores resultados.
El proceso ideal podríamos definirlo así:
El equipo de producto decide que es necesario implementar una nueva funcionalidad o mejorar una existente. Tras hacer las mediciones oportunas el equipo de diseño se pone manos a la obra.
1. Se genera el documento siguiendo el índice indicado en el punto de la documentación.
2. El product owner revisa junto al responsable de diseño que el documento cumpla con todos los puntos y que sea válido para ser pasado a desarrollo. En el caso de tener que modificar algo se devuelve a diseño.
3. Cuando el product owner acepta la propuesta, se reúne junto con el responsable de diseño con el equipo técnico o los desarrolladores que vayan a estar involucrados. Aquí se les explica el documento en voz alta, de tal forma que los desarrolladores puedan hacer preguntas. Esto es importante para contextualizar a los desarrolladores y es cuando suelen aparecer dudas no contempladas anteriormente.
4. Una vez aclarado y, si todos están de acuerdo con el documento, se le pasa al tech lead o la persona encargada de organizarlo en tareas de desarrollo.
5. En función de la duración del rediseño es importante hacer unas breves reuniones de forma habitual en las que el tech lead, el product owner y el lead designer intercambien dudas o necesidades de desarrollo y que se sincronicen sobre el estado de la nueva funcionalidad.
Conclusiones
Conseguir un buen resultado en un equipo de producto, de diseño y desarrollo implica generar una estructura de trabajo que involucre a todas las partes permitiendo que se cumplan los objetivos mientras se mantienen la creatividad y las buenas practicas.
