Tips para mejorar tus procesos de diseño con listas y automatización

¡Vivan las listas! Así como se introdujeron en la aviación para evitar el error humano, usálas en tu día a día ante cada feature request.

Reflexiones luego de una semana de muchos feature requests: Pequeños pedidos, mucho trabajo

En diseño de producto, esto se conoce como “solutioneering” o “solutionizing” y significa resumidamente saltearse, muchas veces inintencionalmente, el descubrimiento y análisis (discovery) de un problema que nos llega o de los usuarixs o del mercado. El resultado es generalmente una feature o cambio que llega sin exploración. Seguramente provenga de buenas intenciones como ahorrarnos tiempo y llevar a producción soluciones para nuestros usuarios más rápido. Pero la mayoría de las veces, el resultado es el contrario.

Como diseñadora de producto, honestamente, más de una vez continué con el cambio sugerido para después recibir feedback como “¿Por qué movieron esto de ahí?”, o “¿adónde se fue mi botón?”. Esos fueron mis errores, es mi responsabilidad como “defensora del usuarix” detectar estos reportes y pedir que sigamos otro proceso de descubrimiento antes de actuar. Pero de allí aprendí, y ya no me toman desprevenida.

¡Qué pasó ahora!

Esta vez reconocí el pedido y para solucionarlo, apelé a la transparencia. Contacté al remitente y le expliqué que es necesario hacer un poco de investigación para saber si esa es la mejor solución, y sobre todo, medir que tan importante es el pedido. Es importante para mí apreciar el interés de todo el equipo en encontrar mejoras, y al ser un equipo de diseño de una, toda ayuda es bienvenida. Le pedí a mi compañero que siga un simple workflow de Slack que responde las siguientes preguntas.

  1. Una descripción de lo que lxs usuarixs experimentan, como actúan y en qué circunstancias sucede. ¿Sabés por qué pasa lo que pasa? Básicamente un punto de partida para los “5 porqués — (5 whys)” desde un lugar más informado que el mío.
  2. ¿Tenés un enlace a la conversación o ticket que recibiste (así no nos basamos en interpretaciones) Si es así, ¡genial! Sino, a la siguiente pregunta.
  3. ¿Es éste un caso aislado? ¿A quiénes afecta el problema?
  4. Datos técnicos: Navegador, sistema operativo, etc… en el que suceden los problemas.
  5. Pasos para reproducir el error experimentado. Si tenés una grabación, screenshot, gif o video, mejor aún.
  6. ¿Cuáles son tus ideas para solucionar el problema?

Todo automatizado y documentado

Esta vez era un caso urgente. Entonces, manos a la obra. A investigar. Durante una breve charla, conseguí feedback extra, restricciones técnicas, y escuché todas las ideas del equipo para solucionar el problema. Proponer soluciones cuando se tiene más información y dejarlas sobre la mesa -pensamiento divergente- hace maravillas para fortalecer el trabajo de todos y sentirnos escuchados. Además ayuda a identificar sesgos ya que todos conocemos las opiniones de todos.

No entraré en detalle sobre la solución final, pero no, no fue un pop up. El problema no se solucionaba con esta idea, solo quedaba en evidencia una falla en la funcionalidad de nuestra aplicación. Después de encontrar los motivos, cambiamos el comportamiento de una validación y fue más efectivo. No teníamos que molestar al lxs usuarix, toda la solución pasaba “por abajo” al nivel del sistema.

Para finalizar la solución (con o sin tests de usuarixs) uso esta checklist. Esto mejora la experiencia de usuarix drásticamente. Si, lleva más tiempo y en algunos casos puede ser overkill, pero sin dudas, los beneficios son más que las desventajas. Acá va:

  1. Con esta solución: ¿Pueden lxs usuarixs cumplir sus objetivos comparando con la versión anterior?
  2. ¿Se ve y funciona correctamente en todos los navegadores y tamaños?
  3. ¿Están todos los estados de los elementos interactivos implementados? Revisar elementos como botones, selectores, menúes desplegables, estados de error, empty states, estados interactivos (hover, activo, presionados, deshabilitados, default)
  4. ¿El copy es el correcto?
  5. ¿La solución cumple con el diseño propuesto (visual)?
  6. ¿La documentación está actualizada?
  7. ¿Es necesario dar aviso activamente sobre esta novedad a soporte, ventas o marketing?

Si la respuesta 7 es SI, se dispara otro workflow donde el marketing de producto se involucra, quizás ventas y soporte también. Una historia de amor para otro día.

Conclusión

  • Soy una fanática de los procesos, las listas, los workflows de Slack. Los procesos que nacen de las necesidades y los fallos son los que se quedan, no parecen forzados.
  • Valorar y agradecer la buena voluntad ajena solo hace a tu equipo más fuerte. No todos saben lo que vos sabés sobre diseño, ni vos lo sabés todo. Escuchar a otrxs profesionalxs y sus puntos de vista te hacen diseñar/resolver mejor.
  • Si una solución te encanta, pero no se condice con todos tus requerimientos, matala. Sin piedad. Aunque te haya llevado tiempo y esfuerzo y se vea elegante, hermosa para el portfolio. Dejala ir.
  • Buscá siempre el caso más difícil: ¿Cómo se verá esta solución en una pantalla de 1024 px si hay más de un error a la vez? ¿Cuántos errores se pueden acumular? ¿Qué patrones usamos en otras partes?

Soy una diseñadora apasionada por encontrar el punto donde la usabilidad y la estética se encuentran. Líder de UX y Diseño @Frontastic

Soy una diseñadora apasionada por encontrar el punto donde la usabilidad y la estética se encuentran. Líder de UX y Diseño @Frontastic