Cómo mejoramos los productos en Automattic
Siempre se nos dice, y yo me incluyo, que “no somos nuestros usuarios”. Recientemente, he descubierto que esto es una verdad a medias.
Si bien no podemos diseñar asumiendo que nosotros somos los usuarios y diseñar sin preguntarles, sí tenemos que experimentar nuestro producto. Del diseño al desarrollo hay un trecho, y cuando algo que has diseñado en Figma llega finalmente a manos de tus usuarios, puede haber cambiado.
Te cuento cómo lo hacemos en Automattic.
El diseño en Automattic
Automattic tiene muchos productos. Quizás conoces WordPress.com, pero también tenemos WooCommerce, Tumblr, Simplenote, Jetpack, Day One, Pocket Casts y Gravatar, entre muchos otros.
Cada equipo funciona diferente, y lo que te contaré a continuación atañe al que formo parte, WordPress.com. Somos siete perfiles de diseño repartidos en dos squads diferentes y trabajamos diseñando nuevas funcionalidades y mejorando las que ya existen.
Lo que diseñamos lo compartimos en las sesiones de diseño, pero también con el equipo de desarrollo que tenemos asignado y con copywriters. Todo lo que diseñamos está relacionado entre sí, y aunque por ejemplo yo diseñe algo que formará parte del Gutenberg (el editor), es fácil que también impacte a otro equipo.
En los equipos de diseño (no solo en Automattic, en general) se habla muchas veces de tener una high bar, que vendría a ser diseñar productos de alta calidad. Recientemente me he dado cuenta de que esto implica dos tipos de diseño:
- El que haces en Figma
- El que acaba formando parte del producto digital
Y no siempre coinciden. Por esto es muy importante hacer llevar un registro y analizar detalladamente lo que acaba llegando a las manos de tus usuarios.
Cómo llevar un registro de las interfaces
No descubro nada nuevo si digo que diseñar y desarrollar productos digitales es muy complejo. Se suele decir que “del dicho al hecho, hay un trecho” y, en este contexto, podríamos decir que “de diseño a producción, hay un trecho”. No rima, pero ya me entiendes 😄
Suele suceder porque la tecnología que hay es antigua o no permite desarrollar exactamente lo que se ha diseñado. O que el diseño es demasiado complejo para los tiempos que maneja el equipo. O que hay varios equipos implicados en un solo producto. Cada uno de estos aspectos añade complejidad e incrementa la posibilidad de que el diseño que llega a producción no tenga nada (o poco) que ver con el que hay en Figma.
Por esto hay que repasar constantemente con qué interactúan nuestros usuarios.
En Automattic esto lo aprendí de la mano de Pablo Honey, co-Head of Design.
Registra tu pensamiento
Para seguir el ejemplo, imagínate que vas a repasar el flujo que sigue un usuario cuando se registra en tu producto digital (es decir, el flujo de onboarding). Tienes que hacerlo desde la perspectiva de alguien que no conoce nada de ese producto. Escribe sobre:
- Cómo llegan al flujo: ¿Es desde la web principal?, ¿siguiendo un anuncio en redes sociales?, ¿mediante un artículo del blog?
- Este paso te permite identificar si llegan con suficiente información y si la que reciben tiene sentido o si se repite
- Analiza el flujo paso a paso: habitualmente, un flujo de onboarding consta de diferentes pasos e interacciones. En este caso, se trata de observar al detalle la interfaz (¿hay cambios en los márgenes?, ¿en el tamaño de la tipografía?, ¿en las animaciones?) y si realmente tienen sentido los pasos y tal y como están
- Te permite identificar inconsistencias en la interfaz y en las interacciones. Es útil anotar qué vas pensando durante todo el proceso y las preguntas que te vas haciendo.
Dónde registrarlo
En el caso de Automattic, utilizamos un blog interno (P2). De esta manera, podemos enlazar publicaciones anteriores, issues en GitHub, mencionar a otras personas e incluir imágenes y enlaces.
Puedes utilizar Notion, Google Docs o cualquier otra herramienta que te sirva para compartirlo después con el resto del equipo.
Ventajas de llevar un registro periódico
A estas alturas seguramente habrás intuido para qué sirve hacer todo esto:
- Mantienes la perspectiva de tus usuarios
- Mejoras la calidad del producto, porque te permite detectar pequeños errores
- Puede generar ideas de mejora
- Te mantiene conectado/a al flujo entero y no solo a la interfaz concreta que estás diseñando
- Si lo haces de otra parte del producto de la que no tengas contexto, podrás ayudar a otras personas del equipo 🙂
Apuntes finales
Puede que pienses que “no tienes tiempo”, que ya bastante trabajo tienes con tu día a día. Lo entiendo. Pero el tema es que eso también es parte de tu trabajo. No solo se trata de diseñar, se trata de intentar asegurar que lo que se produce sea lo mejor posible (o que se va mejorando).
Stripe también tiene esta filosofía: ellos lo llaman Friction Log (¿registro de fricción?) y tienen una estructura más estandarizada y cerrada. David Singleton (CTO de Stripe) describió la cultura de excelencia de Stripe en esta entrevista y Mike Bifulco (ex Staff Developer Advocate en Stripe) escribió sobre los Friction Logs.
Te propongo que lo pruebes la próxima semana, seguro que verás algo que arreglar o mejorar 😉