Respirando UX
Cuando comencé a trabajar en PedidosYa creía que tenía una buena base de conocimientos de UX. La realidad es que estaba errado. Allí realmente empecé a respirar el real oxígeno de la experiencia de usuario.
Humanizando la experiencia
Una de las filosofías que aplicamos apenas ingresé a la empresa fue ‘experimentemos al infinito (y más allá)’. Esto implicó tener todo tipo de metodologías, desde entrevistas con usuarios, paper prototyping y AB testings hasta jugar a ser 'Gran Hermano' y entrar en la casa del usuario para ver con nuestros propios ojos cómo es su atmósfera al usar nuestra app, sus alegrías, frustraciones y un sinfín de emociones.
Spotify personalizado
En PedidosYa el modelo de trabajo en equipo dentro de Producto se llama ‘PedidosYa Squadification’ y está basado en el modelo de Spotify, aunque acoplado a nuestras necesidades y objetivos. Está compuesto por tribus categorizadas por tópico del negocio (por ejemplo: ‘Delivery’, ‘Growth’, ‘Partners’, ‘Shopping’) que, a su vez, contienen squads (‘NCR’, ‘Restaurants’, ‘Payments & Checkout’, etcétera).
Estos squads están formados por un equipo multidisciplinario con roles definidos: cada uno tiene un product owner, iOS developers, Android developers, Web frontenders, QA y un UX Designer. Esto permite que cada squad sea autónomo y no dependa de otro equipo. Transversalmente están los Chapters, equipos de personas de una misma disciplina: hay un Design Chapter (que yo lideraba), un iOS Chapter, un Android Chapter, entre otros. Se trabaja con objetivos por sprint de tres semanas que, obviamente, están basados y alineados con los objetivos estratégicos de la empresa (OKRs).
Desde la perspectiva de diseño, tenemos que estar más adelantados al resto del squad. Es decir, para que en el sprint se trabaje en determinado feature, el diseñador debe tener pronto, testeado y validado con los usuarios antes de que se pase a la etapa de desarrollo. Por supuesto que en la etapa de validación está todo el squad involucrado para comprender, empatizar y tomar un rol activo en lo que se va a trabajar.
Para la entrevista siempre hay dos personas del equipo de PedidosYa: una que mantiene la charla y otra que saca apuntes y que casi no interactúa (salvo para saludar). Estas personas van cambiando de acuerdo a los integrantes del correspondiente squad para que tengan su vivencia y ver todo de cara al usuario final, y a su vez, le den continuidad a su proyecto. Generalmente el diseñador es el que entrevista pero si otro integrante quiere tomar ese rol, puede hacerlo. Siempre el foco de la entrevista es ameno. Al principio recordamos que no es una evaluación de la persona sino que es una instancia para analizarnos a nosotros mismos. Por supuesto que no damos opiniones ni percepciones ni corregimos nada, ni preguntamos el clásico ‘¿cómo te sentiste?’ ;)
Se filma y, en algunos casos (también con previa autorización), se transmite en otra oficina para que puedan vivirla quienes estén interesados, sin invadir al entrevistado. En caso de que sea una entrevista de user testing, también se graba todo lo que ocurre en el dispositivo y una cámara frontal toma las expresiones del usuario.
Al final de la entrevista se le ofrecen al invitado algunos souvenirs de la empresa y algo de mayor valor que fuimos modificando: al principio era un objeto/regalo, luego lo cambiamos por entradas al cine, luego por vouchers para usar en la app (nunca fue dinero en efectivo, no estábamos de acuerdo con esa opción).
Luego del research de las entrevistas viene el análisis. En caso de que sea un testing, se evalúa el paso a paso y se reporta en un spreadsheet (rainbow spreadsheet), evaluamos el user journey con sus etapas y sus correspondiente emociones, la búsqueda de patrones, métricas y demás.
Dependiendo de lo que se esté evaluando, llegamos a la definición del journey map, outcomes y lo que sigue si amerita: iterar y validar nuevamente. Y recién ahí pasa a desarrollo con las correspondientes etapas ya descritas.
El proceso ‘tipo’ desde la perspectiva de diseño
Para simplificar un caso ‘tipo’, el proceso de diseño de cada feature (o validación de una hipótesis) es siempre en equipo, y está formado por las siguientes etapas (la realidad es que es bastante más complejo pero quiero dar una idea en líneas generales):
-
Llega una necesidad estratégica (del negocio) o se investiga algo que surge en el equipo y que le agrega valor al usuario.
-
Se valida si esta hipótesis es real (con métricas, datos cualitativos, usuarios).
-
Se comienza el proceso de ideación (post-its, brainstorming, iteraciones, wireframes).
-
Se llega a una idea definida.
-
Se prototipa.
-
Se valida con usuarios de acuerdo a la metodología que amerite.
-
Se itera y, en caso de cambios, se valida de nuevo (ciclo que puede repetirse varias veces).
-
Entra en desarrollo.
-
Se pasa a la etapa inicial de validación y hacer QA, y se itera.
-
Se pasa a la etapa Demo (PedidosYa Demo app), se valida y se itera.
-
Se pasa a la etapa Night (PedidosYa Night app, que es la previa a Producción), se valida y se itera.
-
Pasa a Producción, se valida y se itera.
Entrevistas con usuarios
Una de las cosas que nos obligamos a hacer todas las semanas es tener entrevistas con usuarios, ya sea para validar algo, testear o simplemente para tener una charla de conocimiento. Generalmente esta instancia es los viernes, por lo que la bauticé TGI Fridays (en alusión a la cadena de restaurantes americana, sigla que significa 'Thanks God It's Friday'). Esto da una idea del entusiasmo que generan esas charlas con usuarios o potenciales usuarios.
La persona con la que conversaremos es minuciosamente seleccionada: dependiendo de lo que se quiera evaluar o validar (y también basándonos en nuestras user personas y los jobs to be done), pasamos las características deseadas a Operaciones para que nos pasen perfiles reales: si deben ser usuarios nuevos, usuarios que dejaron de usar la app hace más de un año, usuarios de 80 años, o lo que fuere. Una vez contactada la persona y acordada la cita, todo está pronto para organizar la entrevista.
En equipo delineamos el brief de la entrevista, es decir que dejamos claro y por escrito qué queremos evaluar o testear (manifiesto), definimos el job to be done si amerita ese caso, acordamos qué preguntas debemos hacer para llegar a ello y demás. Nuestra filosofía para las entrevistas es ser flexibles; las hacemos basadas en el hilo conductor previsto pero si se va un poco de libreto no hay problema, siempre y cuando volvamos a encaminarla hacia donde necesitamos focalizarla.
Generalmente, horas antes de que llegue la persona para tener la charla, ordenamos una oficina para que se sienta 100% cómoda, jugamos con la iluminación y la atmósfera, decoramos con plantas agradables para dar un aire oxigenado, dejamos a disposición ciertos alimentos, gaseosa y agua, organizamos la cámara que filma (previa aprobación de la persona), preparamos los dispositivos (en caso de ser una entrevista de testing), etcétera. Se trata de crear una escenografía ad hoc para la ocasión.
Entrevistas contextuales
A través de service design hemos realizado entrevistas contextuales (en mi caso, en Colombia) para ver el comportamiento de las personas en su entorno a la hora de pedir delivery de comida. De esta forma podemos vivir y entender la realidad del usuario en situación cotidiana; lograr analizar y captar sus ansiedades, saciedades, frustraciones.
AB testings
Desarrollamos un sistema interno que permite probar lo que queramos en la web y mobile para realizar AB testings, eligiendo el porcentaje de destinatarios que deben verlo y configurando distintas características. Todo queda documentado y trackeado, y tenemos libertad absoluta de probar lo que sea a demanda.
A modo de anécdota: en el refreshed brand actualizamos los colores del rate del partner. Pero quisimos hacer una prueba para validarla. El rate se basaba en una fila de 5 estrellas en la que el usuario marcaba el nivel de satisfacción del servicio: la estrella número 1 era una experiencia mala y la número 5 significaba experiencia perfecta. Originalmente los colores de las estrellas iban del rojo al verde, y, a pedido de la estrategia de la empresa, se quiso ‘suavizar’ este mensaje y probar cómo respondía el usuario frente a un cambio de paradigma: que vaya de verde claro a verde oscuro. Los resultados fueron los que habíamos previsto: no funcionó y volvimos a la versión original.
Con AB testings también probamos íconos con distintos conceptos para ver si funcionaban mejor, cambios en el copywriting (títulos, labels), cambios en el color del CTA, e infinidad de experimentos más.
Card sorting
Cuando lanzamos Supermercados, logramos categorizar los productos a través de workshops de card sorting para llegar a patrones comunes que fuimos encontrando en la agrupación.
Service Design
Pude vivir instancias muy enriquecedoras con equipos de Alemania, Argentina y Uruguay para estudiar cómo hacer que usar la app de PedidosYa sea una experiencia increíble.
Ver más información
Casos reales validados a través de entrevistas:
-
One page checkout
Antes para hacer el pago tenías que realizar 3 pasos (con eso ya lo dije todo ;).
-
Vertical launcher
Probamos infinidad de launchers con las distintas verticales para resaltarlas hasta llegar a la mejor versión.
-
Payment method error
El alerta de que hubo un error en el pago con tarjeta de crédito no era del todo entendible ni claro (parecía que había ocurrido correctamente). Lo resolvimos a través de estas entrevistas cualitativas.
-
Log in y Sign up
De los testings y pruebas que más estudiamos e iteramos.
-
Swimlanes para Groceries
Probamos distintos layouts para los swimlanes, disposiciones, tamaños y demás.
-
Definición de user Personas
Logramos definir 4 tipos de user personas (validando si las proto-personas que teníamos estaban alineadas).
-
Notification center
Testeo de centro de notificaciones y promociones.
-
Up-selling
Identificar la mejor forma de implementar upselling con la condición de no ser invasivos.
-
Referral program
Evaluación de la mejor forma de implementarlo y hacerlo visible en su lanzamiento.
-
Y la lista sigue indefinidamente
Heuristics evaluation
Design Sprint
Invitamos al equipo de diseño de Alemania para realizar una evaluación heurística de toda la experiencia de delivery a supermercados.
Realizamos un design sprint (liderado por un mentor de diseño de Alemania) para generar nuevas ideas de nuestro self-service flow llamado Alan (bot), dado que la experiencia de usuario no era buena y era donde se hallaba el mayor problema en el flow principal.
Un día en mis zapatos…
Para poder entender las experiencias de los demás y empatizar con otros departamentos y sus necesidades y problemas, decidimos inaugurar ‘Un día en mis zapatos…’
Una de las experiencias más enriquecedoras fue ‘un día en el call center’, es decir, ocupar el rol del que atiende las llamadas, contesta los chats y los e-mails. Previamente tuvimos un workshop de inducción para entender los procesos y metodologías con que trabajan y conocer sus herramientas.
Gracias a esto pudimos ver no solo el otro lado del mostrador sino también ‘nuestro lado’: los pain points que tenía nuestro equipo, mejoras para hacer en la experiencia de la llamada con el cliente, en el procedimiento, en la gestión de llamadas, chats y e-mails, en las técnicas de integración de herramientas,. Y, sobre todo, pudimos empatizar para entender.
Como parte del proceso de service design incluimos lo que llamamos 'diarios': les pedimos a determinados usuarios, a través de mensajes de texto o de WhatsApp, que escriban cómo iba su día (una especie de diario íntimo) y que lleven a cabo algunas tareas tales como comprar productos que precisen, al tiempo que describen su paso a paso realizando esa tarea, con fotos y documentación, y focalizando en sus problemas y percepciones.
