Cómo hacer el handoff UX al equipo de desarrollo

3 pasos para un buen handoff de diseño a desarrollo

Si el momento del handoff del diseño al equipo de desarrollo es la primera vez que hablas con ell@s, ya vas tarde.

Que exista una buena coordinación entre ambos equipos es crucial para que el proyecto llegue a buen puerto. Un buen proceso de handoff incrementa la alineación dentro del equipo y permite obtener productos de más calidad.

En este artículo te cuento lo que he aprendido trabajando en diferentes empresas, dividendo el proceso en tres etapas. Léelo todo o salta a la parte que más te interese 🌝

  1. Antes de diseñar: reunión inicial
  2. Mientras diseñas: coordinación y comunicación
  3. Al final el diseño: seguimiento y acompañamiento
  4. Conclusiones

Antes de diseñar: reunión inicial

Sin lugar a dudas, el equipo de desarrollo tiene que estar presente cuando el equipo de diseño empieza a trabajar en un proyecto nuevo.

¿Por qué?

Pues porque si bien el equipo de diseño es quien lo “crea”, el equipo de desarrollo es quien lo implementa. Un diseño sin desarrollar no sirve para nada, igual que tampoco sirve un diseño que no pueda implementarse o una implementación hecha sin ningún diseño previo.

Lo más recomendable al inicio del proyecto es crear un documento de handoff en el que quede claro:

  • El alcance (scope) del proyecto
  • Las limitaciones técnicas, las de diseño, las del propio producto y otras adicionales que pueda haber
  • Lo que es obligatorio que exista y lo que sería buen tener (nice to have). En estos casos, es muy útil el ejercicio de priorización MoSCoW.

En mi opinión, el equipo de desarrollo tiene que estar avisado de que se está trabajando en esa funcionalidad o en ese producto. De este modo, cuando se realice el handoff, sabrán de qué va y qué ha estado pasando.

Mientras diseñas: coordinación y comunicación

Con el tiempo me he dado cuenta de que la organización del archivo de Figma o Sketch es vital. Para ti está claro dónde está cada frame, pero es importante que lo prepares como para que cualquier persona sin contexto pueda entenderlo.

Páginas y capas con sentido

Ya escribí en detalle sobre los secretos de un buen archivo de diseño, así que aquí solo haré un resumen breve.

Un archivo de Figma bien organizado facilita el trabajo de todo el mundo, ya sean perfiles de diseño como de producto o desarrollo. Además, también haces que cualquier persona pueda continuar tu trabajo cuando tú no puedas.

La estructura de un buen archivo de Figma

Me gusta incluir una página específica de handoff por tres motivos:

  • Es más fácil compartir un enlace directo a esa página
  • El equipo de desarrollo no se despistará al ver una página llena de frames, reflexiones e ideas propias del trabajo de diseño. Si quieren verlo, puede navegar a cualquier página, pero por lo menos que la “suya” esté limpia y sea clara
  • Incluye datos propios del handoff, como especificaciones técnicas y otro tipo de enlaces, que no suele ser necesario en la fase de diseño

Comparte esta página de forma periódica con el equipo de desarrollo, aunque estén trabajando en otros proyectos: tarde o temprano tendrán que desarrollarlo y cuanto antes puedas contestar a sus dudas, antes podrás corregir aquello que no podría implementarse o explicar mejor alguna parte en concreto. Pide revisiones o feedback sobre aquellas partes en concreto sobre las que tengas dudas.

Sistema de diseño, user journeys, empty states y prototipos

En mi caso, la página de handoff suele tener este aspecto: contiene cuatro bloques con una descripción del proyecto, un listado de los componentes del sistema de diseño que ya existan, otra con los nuevos (con especificaciones técnicas) y el diseño en sí mismo:

La parte superior es la que me permite dar contexto sobre el proyecto de forma concisa y clara y también me da pie a enlazar documentos que sean específicos para una buena implementación:

Cuando diseñes, sé consistente si el proyecto lo requiere, asegúrate bien de que la retícula se mantiene a lo largo del proyecto y que los espaciados son los adecuados: si utilizáis la retícula de 8pt, todos los elementos deben seguirla.

Y no te olvides de los empty states, que es un clásico 🥲

Al final el diseño: seguimiento y acompañamiento

Tu trabajo como diseñador/a no termina cuando te dan la aprobación final. Justo en ese momento empieza la última parte del proceso de diseño: la de asegurarte de que se implementa correctamente.

Si al inicio del proyecto habéis creado un documento del handoff y el archivo de Figma contiene todo lo necesario, ya tienes mucho ganado.

El handoff es un proceso en sí mismo: se trata de compartir todo lo necesario, pero también de hacer un seguimiento.

Comparte todo lo necesario

Envía todo aquello que el equipo de desarrollo necesita:

  • Material que no esté en Figma: las fotografías optimizadas, vídeos, audios, infografías… todo ello exportado y comprimido al tamaño que se necesita
  • Los assets (aquí te cuento cómo exportarlos en Figma y en Sketch)
  • Los textos: seguramente ya los tendrás en Figma (espero que no diseñes con lorem ipsum 😬), pero no está de más enviar un documento de texto que sea más fácil de copiar y pegar: el panel de inspección de Figma, Sketch y otras herramientas no pone muy fácil copiar textos, requiere muchos clics.

Caza bugs y observa

Si cuando diseñabas eras tú quien compartía partes del archivo de Figma con el equipo de desarrollo, ahora es al revés.

Cuando mejor he trabajado es cuando el equipo de desarrollo me enviaba periódicamente enlaces con el desarrollo para que yo pudiera revisarlo. El objetivo es el de siempre: detectar problemas lo más pronto posible, para tener margen para corregirlos.

En Twitter organizábamos unas sesiones llamadas Bug Bash 🐛 , que podría traducirse como “fiesta de bugs”:

  • Se utilizaba el documento del handoff original como base
  • Todo el mundo revisaba en su propio equipo si se cumplen lo que sí tiene que estar y si funciona bien
  • Se compara con el diseño en Figma

Al final obteníamos un listado con lo que estaba bien y lo que había que corregir. Idealmente en esta sesión participaban personas del equipo de desarrollo y del de diseño.

Apuntes finales

Como habrás deducido a estas alturas, se trata de un camino de doble sentido: ambos perfiles debemos trabajar juntos, entendiendo el proceso como un “todo” en el que debemos trabajar mano a mano como un equipo. Te dejo con esta charla que dio Marina Aísa en el T3chfest, en la que habla de la relación entre desarrolladores y diseño y de cómo podemos colaborar mejor entre nosotros:

 

Entiendo que a veces da pereza: cuando tú has terminado un diseño ya te has puesto con el siguiente, y el equipo de desarrollo está desarrollando algo que tú ya diste por cerrado hace semanas. Pero… ¿de qué sirve cuidar mucho un diseño, si justo en la parte del proceso en la que se construye lo dejamos de lado?

Si no lo haces ya, trata de implementar algunos de los puntos que te he explicado en tu próximo proyecto. Es posible que encuentres ciertas reticencias, pero a la larga será positivo tanto para los equipos como para el producto en sí.