Refinando hasta el último pixel codeado

Dentro de Wolox existen diversos procesos para cada una de las fases de nuestra metodología de trabajo y estamos siempre en una constante búsqueda de mejoras. Este es el caso de QA Design, un proceso que surge de la necesidad de un proyecto en el cual estaba trabajando pero también de querer mejorar la calidad de nuestra comunicación como equipo y agregar valor a nuestras tareas del día a día.

¿Cuál es la mejor forma de poder revisar que tus diseños estén bien implementados por el equipo de Front End?

En etapas tempranas de un proyecto aparecen muchas ideas nuevas pero para concretarlas necesitamos la visión del equipo de Front End. Debemos entender qué significa para ellos esas ideas en relación a sus tiempos y cómo poder generar esos cambios a nivel de UI.

En conversaciones con el equipo de Front se llega a la conclusión de cuáles son los tipos de cambios que ellos podrían llegar a abordar y los tiempos de desarrollo. No debemos olvidar que estas revisiones contemplan interacciones — animaciones del usuario con la plataforma (web o mobile). Esto quiere decir que debemos revisar, por ejemplo, transiciones de vistas, interacciones de un input con el teclado o el despliegue de un dropdown. Pero también necesitamos poder representar los tiempos de revisión y de desarrollo dentro de un sprint de trabajo normal y sobre todo dentro de Jira, la herramienta que usamos para el seguimiento de nuestros proyectos.

Para comprender mejor este proceso escribí este post paso a paso para generar estas revisiones y verificar que el Front aplique correctamente nuestros diseños.

Antes de iniciar, debemos dejar en claro que las QA Design se implementan con un sprint de desfase. Esto quiere decir que los diseños implementados por el equipo de Front End en el sprint Nº 3 serán revisados por el diseñador en el sprint Nº 4. De existir modificaciones deberán ser realizadas por Front en el mismo Sprint Nº 4.

Paso 1: Organización del proceso de QA

Para el inicio del proyecto deben reunirse el diseñador o TM (team manager) y el desarrollador Front End. En esta reunión debemos tener en cuenta ciertas consideraciones:

• El proceso de QA Design se debe implementar después que el equipo de Front ya implementó los primeros diseños.
• Si hay más de un desarrollador de Front asignado al proyecto, el TM debe asignar a uno en particular para que pueda revisar en conjunto con el diseñador las vistas (UI) ya implementadas.
• Considerar que cada QA Design realizada en el proyecto puede tener distintas Reviews de parte del equipo de Front. Antes de cada una debemos formalizar quién será el desarrollador responsable para poder generar la card correspondiente en Jira.

Los responsables de este paso 1 son Diseñador y TM. Mientras que el primero debe concretar las reuniones con front, el segundo debe reflejar el trabajo de ambos en Jira.

Paso 2: Creación del spreadsheet

Posterior a esta organización, el diseñador asignado debe usar el template de las QA design. Allí tenemos una columna en donde pondremos el problema de diseño detectado, en otra el nivel de bug, en la siguiente el desarrollador de Front End nos dará aviso cuando el bug esté solucionado y en la última columna el diseñador dará el visto bueno a esa corrección.

Los bugs pueden tener dos niveles: prioridad alta y prioridad baja. Un bug de prioridad alta se refiere a errores dentro del diseño que afecten directamente a la experiencia de usuario. Por ejemplo, si en una aplicación móvil el teclado cubre un botón de acción principal o secundaria de esta manera:

Un Bug de prioridad Baja se refiere a errores que no afectan de manera directa a la experiencia de usuario como, por ejemplo, textos, sombras, etc.

En la creación de este spreadsheet, debemos tener las siguientes consideraciones:

• Separar por pestañas cada una de las revisiones por sprint.
• Asegurarse de compartir el documento con el desarrollador de Front correspondiente.

Paso 3: Reunión QA Design

La creación de reuniones de manera formal se hará con un sprint de atraso en base a lo que el dev de Front realizó en el sprint anterior. En la misma, diseñador y dev de Front End deben revisar los diseños ya implementados por el dev. Ten en cuenta estos consejos:

• Asegúrate de ser súper claro en el bug detectado y separarlo por flujos dentro del spreadsheet.
• La reunión dentro de lo posible debe ser realizada en el inicio del sprint. Se recomienda el mismo día que se realiza la Planning.

Los responsables de esta instancia son dev de Front End y diseñador: el primero debe concertar las reuniones con Front y el segundo debe reflejar el trabajo de ambos en Jira.

Paso 4: Revisión de spreadsheet

A medida que avanzamos y se acerca el final del sprint se debe ir revisando periódicamente que los bugs detectados en la reunión hayan sido resueltos por el equipo de Front.

Cada uno de los bugs detectados deben pasar por 2 revisiones o estados. Primero pasan en la columna de front de “SIN RESOLVER” a “RESUELTO” y después en la columna de diseño deben pasar de “SIN REVISAR” a “REVISADOS”.

El diagrama de flujo de trabajo de todo este proceso quedaría así:

¿Cuáles son los beneficios de implementar este nuevo proceso?

En la implementación de este proceso en proyectos reales vimos el alcance y los beneficios que trae QA Design:

• Constantes revisiones al diseño implementado por parte del equipo de Front. Este es el beneficio más importante de todo el proceso porque nos permite visualizar los problemas en nuestra UI a tiempo y mantener constantemente un alto nivel en la experiencia que le brindamos a nuestros usuarios finales.
• Estado de la revisión. Mediante este spreadsheet de revisiones podremos mantener una buena y fluída comunicación con el equipo de Front End y una visualización del avance de cada uno de los bugs detectados.
• Seguimiento. Mantenemos una visualización del trabajo realizado por parte del equipo de Front End y también del diseñador mediante tareas estimadas dentro de Jira.
• Memoria. La modificación de diseños con solo un sprint (2 semanas) de demora en base a la fecha en la cual este diseño fue creado nos ayuda a tener una mayor claridad de los flujos que estamos revisando y que no olvidemos nada importante del flujo (interacciones, empty state, etc).
• Revisión de interacciones — Animaciones. Posibilidad para revisar que las interacciones — animaciones están bien aplicadas a las vistas, por ejemplo, que el teclado del celular no cubra los campos de input o los botones.
• Conciencia de diseño en los Dev. Con el tiempo los dev de Front comenzarán a incorporar una capacidad más analítica de los diseños implementados por ellos mismos y esto generará que las iteraciones comiencen a ser más rápidas y más claras entre ambos departamentos.

Recapitulando

A lo largo de este post aprendimos paso a paso el proceso de QA Design para detectar bugs por parte del diseñador y realizar un seguimiento de las correcciones que realiza el desarrollador de Front End.

Incorporar un nuevo proceso dentro de una metodología es siempre complicado. Debemos estar dispuestos a errores inesperados y más importante aún a descubrimientos que terminan de complementar y cerrar la nueva metodología.

Estamos en ese camino y por eso los invito a poner en práctica el QA Design y dejarnos su feedback en los comments.