UX QA – Un punto de encuentro entre UX y Desarrollo

Publicado por Camila Ortega el 5 noviembre 2020

Construir un producto digital, sea cual sea el marco, contexto o necesidad, no es una tarea sencilla. Desde un primer momento, comprender la visión que quiere llevar a cabo el dueño del producto e identificar las correlaciones con las necesidades de las audiencias puede ser una tarea extremadamente compleja. Si a eso le sumamos tener que definir el entramado tecnológico más apropiado para garantizar una óptima performance, el desafío se multiplica. Por eso, queda en nosotros, diseñadores y desarrolladores, encontrar un proceso que sea tanto flexible como riguroso (por más contradictorio que pueda parecer) de forma tal que garantice que lo que se haya diseñado se ejecute durante el desarrollo con el mayor nivel de fidelidad y exactitud posible, manteniendo y explotando al máximo los insights y los beneficios para los usuarios. Nuestro trabajo es justamente eso, encontrar el punto exacto para que la tecnología satisfaga la necesidad del usuario de la mejor manera posible.

Para eso, aparece un concepto clave que nos acompaña en cada trabajo, y es el de QA, o Quality Assurance, rol central que se encarga de garantizar la calidad de lo desarrollado.

UX Debt, una problemática entre sombras

Dentro de las muchas virtudes del diseño y desarrollo a través de la implementación de metodologías ágiles, sobresale la priorización y velocidad en el lanzamiento de nuevos productos al mercado a través de la postergación de features o funcionalidades que, aunque beneficiosas para el producto, terminan siendo un nice-to-have que no limitan ni reducen la posibilidad de éxito, por lo que significan una inversión que nos hace perder valioso tiempo. En teoría, hermoso. En realidad, complejo. ¿Quién y cómo define qué es un nice-to-have? Teoría sobre eso hay a montones, el problema aparece cuando, en la vorágine por salir a producción, se postergan inconsistencias entre lo desarrollado y lo diseñado, que en algunos casos puede afectar a la tan valiosa primera impresión del usuario. Ahí, es cuando aparece la terrorífica UX Debt, el cual implica básicamente que los costos relacionados a salir al mercado con una versión incompleta. Desde el lado de la experiencia del usuario conlleva una larga ida y vuelta para solucionarlo con costos más altos que los que se hubiese tenido si se hubiese priorizado y solucionado en una primera instancia.

Por qué ocurre esto? Por muchas razones, como ser saltearse pruebas de usuario, obviar estilos de marca y lineamientos estéticos, mala alineación con los objetivos de negocio, y un insuficiente testeo.

QA vs QC. Dónde entramos nosotros?

Antes de que la gente de QA nos aniquile, no se preocupen, no estamos haciendo una lectura superficial. Entendemos la diferencia entre QA y QC, y lo importante que resulta, por un lado, definir las técnicas y actividades necesarias para cumplir con los estándares de calidad, y por el otro, la implementación de las actividades sistemáticas que se implementarán para asegurar la calidad. Reducir la UX Debt necesita de ambos frentes. De QA y de QC, de proceso y producto, de proactividad y reactividad, de prevención e identificación. El problema es que, en muchas oportunidades, esta sistematización de procesos e implementaciones no incluye la contemplación de accesibilidad, usabilidad, funcionalidad, y performance.

Ahora, ¿quién se debería encargar de que lo desarrollado coincida con lo diseñado? ¿Quién debería velar por el cumplimiento de todo detalle visual e interactivo alineado tanto con las necesidades estratégicas del negocio/producto como por la visión del diseñador? ¿Existe un rol de Design QA?

Design QA – Workflow tradicional

En nuestra experiencia trabajando con diferentes clientes y proyectos, hemos encontrado infinidad de maneras de implementación de un proceso de verificación de cumplimiento estético de lo desarrollado. Tanto a nivel de herramienta de comunicación como de metodología de integración, lo único que ha caracterizado a todos las situaciones es la falta de concordancia o coherencia transversal. Podemos por ejemplo enumerar los siguientes ejemplos:

UX/UI con rol de QA. El diseñador trabaja en conjunto con el equipo de desarrollo para levantar aquellos aspectos donde el producto desarrollado carece de consistencia con lo diseñado. Esta devolución se hace posterior a que se desarrolle por completo, no involucrándose en sprints ni en procesos de desarrollo. La documentación suele ser informal y agrega otra tarea más al UX/UI.
UX/UI da criterios al QA. Hay ejemplos donde el diseñador al entregar lo que se va a desarrollar plantea criterios por los cuales el QA se rige al momento de evaluar lo implementado por desarrollo. En este tipo de proyectos el diseñador no es quien da la devolución de puntos a mejorar, sino que instruye al QA sobre los aspectos esenciales que deben estar considerados. Esta guía puede ser formal o informal. En nuestros proyectos se ha utilizado la plataforma de gestión y seguimiento de user stories (por ejemplo, Jira).

¿Por qué ocurre eso? ¿Por qué una tarea que todos podemos coincidir que debería ser clave en el proceso de trabajo no se encuentra formalizada? Las razones pueden ser varias, desde la falta de especificaciones claras y en detalle sobre cómo debería implementarse el diseño (un handoff “in extremis”), poca minuciosidad en el proceso de QA implementado a nivel visual, ausencia de involucramiento del equipo de diseño en la verificación de calidad, y muchas más, pero en resumen, uno podría pensar que los puntos de contacto entre perfiles y especialidades diferentes siempre son conflictivos. A fin y al cabo, a nadie le gusta decir quién debería hacer algo, y quién no.

Pero ese no debería ser el objetivo necesariamente. El objetivo es crear un proceso colaborativo que permita mantener los mejores intereses de negocio y complementar el trabajo de desarrollo. Para eso estamos.

Necesitamos un Design QA?

La respuesta es no. No necesitamos el rol de una persona que sea Design QA, porque ya existe ese rol y es responsabilidad de todo el equipo. Contemplamos y apuntamos a un design control como parte del proceso de QA. Nuestro trabajo como diseñadores, en este caso, es complementarnos al trabajo de ellos y potenciarlo. Sistematizarlo y estandarizarlo para que sea replicable en diferentes contextos, y asegure una buena conexión entre los actores.

Creemos que corresponde a todo el equipo asegurarse de traer un producto con la calidad que se requiere. Para esto se necesitan instancias de demos que detallaremos más adelante, donde todo el equipo participa activamente en revisiones del producto. Cuando el trabajo es colaborativo, la calidad no depende de una persona o un sector, sino del equipo.

La colocación de un rol específico dentro del equipo de diseño a ejecutar acciones de QA conllevaría la superposición de tareas, además de que quitaría el foco del diseñador en otras tareas donde su valor agregado es mayor.

Una propuesta

Los diseñadores necesitan estar más involucrados en el proceso de desarrollo, con un proceso claro y estandarizado que ayude al equipo a reducir la brecha entre el diseño y la aplicación en desarrollo:

Establecer reuniones frecuentes con devs donde se les explique cómo funciona la interacción. Establecer expectativas a los devs y específicamente a los QC. En uno de nuestros proyectos, mantenemos reuniones semanales donde el equipo de desarrollo y el de diseño alinean el estado de su trabajo e intercambian perspectivas. De esa manera, la curva de aprendizaje sobre las complejidades del diseño se reducen y el equipo entiende las expectativas con las cuales deberá cumplir el desarrollo según el diseño.
Definir un estándar en la documentación que se compartirá a todo el equipo, de forma que cuente con las especificaciones necesarias de donde basarse para la construcción y verificación de la funcionalidad. Básicamente, consiste en asegurar un handoff, tanto compartiendo los diseños a través de una herramienta de diseño que permita inspeccionarlo (Axure, Adobe XD, Zeplin), o construyendo un documento de especificaciones visuales y con una mayor descripción de cómo funciona la interacción. Por otro lado, nuestros proyectos se apalancan en la construcción previa de un design system, lo cual permite trabajar con un conjunto acordado de estilos visuales y patrones de comportamiento. Dado que todo el equipo sabe que hay un sistema de diseño, los desarrolladores podrían extenderlo a una biblioteca de patrones y clases que admitan cada elemento del sistema. Agregar una nueva función se convierte en una cuestión de elegir los ladrillos de lego correctos, no inventar nuevos. Una vez que esta configuración esté en su lugar, el equipo tendría que esforzarse mucho para introducir inconsistencias. Diseñe las cosas que cambian, no las cosas que deberían ser consistentes.

Guiar a los QC sobre qué ver y qué considerar al hacer el relevamiento. Como dijimos previamente, es una etapa clave el seteo de expectativas con los QC, lo cual permita definir qué elementos visuales deberá tener en cuenta al momento de corroborar la calidad del desarrollo. Ese seteo de expectativas forma parte de la guía al QC, lo cual nos permitirá que el QC pueda testear que todos los elementos de la interfaz se vean y comporten como fueron pensados para la interacción del usuario, así como que la rotulación de los elementos sea acorde al modelo mental y lenguaje de usuario que fueron propuestos y testeados por el diseñador UX. Testear flujos de los diferentes roles de usuarios que interactúan con la aplicación, y verificar mensajes de error y feedback pertinentes, para resolver o sugerir soluciones a los obstáculos que puedan tener con la aplicación. Se le deja al QC una checklist a seguir, la cual debería ser parte de los criterios de aceptación. Un ejemplo de una checklist podría ser:

Visibilidad del estado del sistema: Puede verificar que los elementos estén presentes y tienen el texto que los defina.
- El diseño: tiene total fidelidad con las especificaciones planteadas (color, espaciado, estilos de tipografía, etc), interacciones y comportamientos, casos que puedan llegar a variar de alguna manera (idioma por localización, moneda local).
Relación entre el sistema y el entorno de la vida real: se puede establecer un sistema con labels que respetan el idioma del usuario.
Consistencia y estándares: Puede evaluarse si se respetan los elementos estándar, por ejemplo, el texto para los botones primarios debe de ser “Aceptar”.
Prevención de error: El texto puede ser testeado y los mensajes en línea de formularios o modales parecen confirmar acciones relevantes.
Ayuda y documentación: Puede ser verificado que la ayuda proveída en un producto es congruente con lo definido por el UX.

Demo con desarrollo: Los devs deberían hacer una demo, idealmente presencial, para recibir feedback. Estas demos deberían incluir a todo el equipo (BA/QA/Devs/UX), pueden ser de caracter informal dependiendo de la complejidad de lo presentado. Al estar todos involucrados las diferentes miradas ayudan a revisarlo más íntegramente y llegar a puntos de acuerdo.

Definir un canal de comunicación claro y uniforme donde realizar el requerimiento. Los bugs de diseño son más efectivos cuando se presentan con imagenes. Cualquier descripción escrita de una funcionalidad rota, cualquier error de código o discusión extensa de un aspecto de diseño terminará por no ser tan efectivo como una imagen clara del problema a resolver, y posiblemente traiga retraso al proceso de corrección del problema. Mostrarlo de manera gráfica es probablemente más efectivo que hablar y escribir sobre el bug, ya sea en un ticket de Jira, un archivo, o un canal de Slack. Establecer específicamente lo que se espera de la solución de un bug va a ayudar a llegar a la meta, trabajar con líderes de diferentes disciplinas en establecer un flujo de trabajo claro con los caminos correctos para ese proyecto en particular. Herramientas, vocabulario y normas necesarias deben de establecerse para ayudar a que el feedback por parte del equipo de diseño sea claro para el equipo de desarrollo. Contar con la documentación correcta desde el principio ayuda a reducir la brecha entre lo que se entrega en los diseños y lo que termina desarrollándose. Hemos sido testigos de cuánto ayuda a evitar conflictos cuando se reduce la cantidad de emails y mensajes internos para tratar correcciones. Todos los cambios deben de ser mandados en formato de ticket, en plataformas como Jira y deben incluir:
1. Documentación clara donde se provee el mayor contexto posible al momento de dar devoluciones.
2. Capturas de pantallas cuando sea posible, URLs, y cualquier tipo de información que aporte a proveer mayor información (navegador, tamaño de dispositivo, etc).

La importancia del trabajo en equipo es clave para evitar que lo diseñado difiera de aquello desarrollado. Si esto ocurre, es de suma importancia el trabajo en equipo para la resolución de esta inconsistencia lo más pronto posible. Los UX son parte del proceso de desarrollo desde el principio, por ende también son responsables desde el comienzo de involucrar al resto del equipo en procesos de diseño, siendo este aporte constante la clave hacia el producto final deseado.