Dar forma a la experiencia del usuario en Zivame: un estudio de caso de gestión de productos

Este es un blog invitado de Udit Khandelwal.

“¡El sitio web es increíble y la sesión fue increíble! ¡Me encantaría volver para otra ronda!” – gritó Deepika mientras se iba a casa después de pasar por una sesión de prueba de usabilidad en Zivame. A partir de ese momento, Zivame siempre iba a ser la primera opción para Deepika, una orgullosa ama de casa y empresaria.

¿Qué hicimos para invocar emociones tan surrealistas en las personas que compran con nosotros?

Bueno, involucramos a los usuarios en todos y cada uno de los pasos del diseño del producto. En mi artículo Cómo cambié la forma en que las mujeres compran sostenes en línea, cubrí cómo aprovechamos la investigación de los usuarios para descubrir una nueva forma de comprar sostenes. Aquí, voy a http://notuser.com/how-i-changed-the-way-women-buy-bras-online para guiarte a través del viaje en el que logramos probar el diseño con usuarios reales, obtuvimos información real y Corrección de rumbo implementada.

El plan de juego

Desafío
Los recursos eran limitados, el alcance era enorme y teníamos que seguir produciendo diseños mejorados de forma incremental.

Esfuerzo

Se suponía que todo el sitio web se diseñaría y desarrollaría desde cero en 5 meses. El último mes ya estaba reservado para todas las actividades relacionadas con las pruebas, el despliegue y la estabilidad. Así que no tuvimos más de 120 días para diseñar y desarrollar la nueva experiencia de Zivame. Había escuchado este dicho en alguna parte:

Hoy no hay atajos; Tengo prisa – refrán suizo

… y pensé que era el momento adecuado para seguirlo. Necesitábamos un plan de juego que no implicara atajos porque no podíamos darnos el lujo de ir por el carril equivocado. Por lo tanto, decidimos hacer lo siguiente después de que terminara nuestra investigación inicial:

• Prototipos Lo-Fi: refinar los bocetos hasta que hayamos terminado de descubrir las lagunas y hasta que hayamos arreglado todos los flujos rotos.
• Pruebas formativas: use prototipos de papel para probar con quien pueda, siempre que pueda, incluso si fue en la mesa del almuerzo.
• Prototipos Hi-Fi: Desarrolle un prototipo interactivo de alta fidelidad, lo más cercano posible al producto final.
• Pruebas sumativas: pruébelo con usuarios reales y obtenga información real.
• Pruebas Beta: Una última ronda de pruebas, en el producto real, antes de entregarlo al mundo.
• Iteraciones: cada prueba entregó algunas buenas noticias y algunas malas noticias (que eran buenas noticias). Tuvimos que priorizar la corrección de errores y la realización de mejoras para cada iteración.

Lección

Las pruebas de usabilidad son una actividad continua que necesita una planificación, tiempo y recursos adecuados.

Pruebas Formativas

Desafío
El diseño inicial estaba completamente sin probar y los equipos de desarrollo nos estaban esperando. Teníamos que darles algo sólido, muy rápido.

Esfuerzo

Los prototipos de baja fidelidad funcionan maravillosamente cuando quieres fallar más rápido. Lo ayudan a descubrir fallas en el diseño en una etapa temprana y los propios diseñadores están muy abiertos a realizar cambios en el diseño sin procesar. Hicimos lo mismo en Zivame. Una vez que terminamos con la pizarra, pasamos rápidamente a nuestras herramientas para crear diferentes pantallas en la computadora y tomamos impresiones para crear flujos de pantalla.

Y luego, simplemente le pedimos a algunas personas dentro de la oficina (que coincidían estrechamente con nuestro personaje objetivo, Mahi Agarwal) que realizaran ciertos escenarios. Cada vez que estaban atascados aunque sea por un momento, sabíamos que había un problema. La mayoría de las veces, incluso nos daban sugerencias, de las que tomamos nota. Luego volvíamos y discutíamos por qué los usuarios estaban sugiriendo lo que eran, íbamos a la raíz del problema y encontrábamos nuestra propia solución.

A veces, las pruebas no solo le dicen qué está mal con el diseño, sino que también revelan nuevas oportunidades. Por ejemplo, fue durante las pruebas formativas que descubrimos que los usuarios podían comprender e interactuar con las notificaciones. Tomamos eso como una señal verde y un diseño para una integración más fuerte y profunda de las notificaciones.

Lección

Para las pruebas, no espere el producto final; siga adelante con cualquier prototipo que pueda pagar y pruebe con quien pueda encontrar. Fracasa más rápido.

Prototipos de alta fidelidad

Desafío
El sitio web tenía más de 300 pantallas y estados de pantalla únicos. Armar un click-through fue una tarea gigantesca.

Esfuerzo

Primero establecemos nuestras metas y no metas antes de construir el prototipo. Esto nos ayudó a reducir el alcance de la creación de prototipos. p.ej. Queríamos probar la nueva función de comprar por experiencia, pero estábamos bastante seguros de que habíamos seguido las mejores prácticas para el pago, por lo que decidimos no centrarnos en ese flujo.

A continuación, evaluamos 3 opciones para construir el prototipo:

1. Flash : mi favorito personal, ¡sé que sueno de la vieja escuela!
2. Aplicación Marvel : porque todos van por este camino.
3. Aplicación Invision : el competidor de Marvel.

Ahora Flash se descartó rápidamente debido a los gastos generales involucrados. Marvel funcionó, pero tenía un soporte limitado para superposiciones, y todo mi diseño se basó en superficies y superposiciones. Invision me ofreció una mayor flexibilidad, así que seguí adelante con Invision.

Lección

El alcance es crítico; incluso para un prototipo.

Pruebas sumativas

Desafío
La prueba tuvo que ser optimizada para FALLAR el diseño.

Esfuerzo

Decidimos anotar el script que íbamos a utilizar durante las sesiones de pruebas de usabilidad. La pieza crítica aquí era averiguar exactamente qué probar y cómo. Así que hice una lista de mis objetivos y no objetivos, en función de los cuales descubrí en términos generales lo que iba a probar.

1. Modelo Mental Inicial – Test de Expectativas
2. Uso real : prueba de exploración gratuita
3. Navegación : prueba de rendimiento
4. Asequibilidad : prueba de asequibilidad visual
5. Flujo de tareas : prueba de rendimiento
6. Sentimiento – Proceso Diferencial Semántico

Una vez hecho esto, asigné rápidamente una técnica a cada elemento de línea y luego pasé a los módulos en los que quería centrarme. Después de esto, pasé a definir el flujo de tareas de los escenarios individuales. No escribí el idioma de los escenarios porque no quería sonar rígido. He compartido el guión a continuación en Slideshare.

Lección

Use un martillo para los clavos, pero un destornillador para los tornillos.

Reclutamiento

Desafío
Encontrar mujeres (en la India) que aceptarían participar en la prueba de un sitio web de lencería.

Esfuerzo

Queríamos mujeres que se parecieran mucho al personaje objetivo de Zivame, Mahi Agarwal. Acudimos a las redes sociales e hicimos un anuncio. ¡Les pedimos a las mujeres que ayudaran a Zivame a crear una gran experiencia de compra para las mujeres! Muchas mujeres se presentaron y recibimos un buen número de respuestas. No solo esto, también invitaron a sus amigos a participar. Y felicitaciones a mujeres con visión de futuro como Deepika, Subha y Aastha, que fueron un paso más allá y aceptaron poner cara a nuestras participantes.

Estábamos en una buena posición para seleccionar y reclutar a nuestros participantes. Las mujeres que expresaron interés, tuvieron que llenar el formulario de reclutamiento de participantes. Después de una evaluación rápida, preseleccionamos a los participantes y los llamamos para programar la sesión con ellos.

Lección

Encontrar usuarios reales no es tan difícil. ¡Solo tienes que hacerlo de la manera correcta!

Lectura sugerida

Efecto libélula, Jennifer Aaker & Andy Smith

Sesiones de prueba de usabilidad

Desafío
Hablando con mujeres sobre un sitio web que vende sujetadores.

Esfuerzo

El día D, estábamos bien preparados con los sistemas configurados, copias impresas del guión, el equipo estaba listo para desempeñar sus funciones y los participantes debían ser recibidos calurosamente.
Comenzamos las sesiones haciendo que los participantes se sintieran cómodos. Comenzamos con algunas charlas y breves presentaciones. Hicimos hincapié en la importancia de su contribución y les pedimos que no se preocuparan por herir nuestros sentimientos y que brindaran comentarios honestos. Para evitar que compartan los detalles de su talla de sostén con nosotros, nos aseguramos de decirles que asuman que su talla es 34C. Creo que les gustó la idea. Nos aseguramos de que creyeran:

Usted no está siendo probado, ¡nosotros sí!
Invariablemente, todos los usuarios sonreirían en este momento, y sabíamos que habíamos logrado que se sintieran cómodos. A lo largo de la sesión, nos aseguramos de que la atención se centrara en las tareas (y, por tanto, en el diseño) y no en los productos. Ahí es cuando comenzaríamos el flujo (como se menciona en el PPT).

Descubrimos algunas cosas bastante interesantes durante estas pruebas. Para nuestra sorpresa, ninguno de los usuarios tuvo problemas para descifrar el menú 'comprar' , que fue un gran cambio con respecto a nuestro diseño anterior. Sin embargo, los usuarios estaban confundidos cuando llegaron al submenú y sabíamos que era necesario simplificarlo (lo cual hicimos más tarde).
También descubrimos un problema básico con las barras de título de nuestras superficies. Los usuarios tenían dificultades para regresar y cerrar las superficies. Nuevamente, resolvimos este problema en nuestra próxima iteración.

Uno de los hallazgos clave fue sobre los botones adhesivos en la parte inferior de las superficies. Nos dimos cuenta de que, a veces, el botón solía interrumpir el flujo de usuarios, ya que los usuarios hacían clic en él sin leer las etiquetas o las malinterpretaban. Encontramos alternativas a tales situaciones.
En general, ¡los usuarios demostraron ser muy útiles!

Lección

Los usuarios son humanos, si los tratas bien, serán de mucha ayuda.

La fiesta de insectos

Desafío
Necesitábamos asegurarnos de que el producto final se comportara según lo diseñado y previsto, ¡y nos estábamos quedando sin tiempo!

Esfuerzo

Siempre hay un buen grado de diferencia entre el producto real y la implementación.
Cuando el sitio web del producto beta de Zivame estuvo listo, queríamos asegurarnos de que el producto se comportaba como se esperaba. Queríamos ver si los usuarios se sentían cómodos interactuando con los controles de la interfaz de usuario que habíamos implementado y queríamos verlo funcionar en el mundo real.

Entonces, lo abrimos para todos los empleados de Zivame y llevamos a cabo un maratón de registro de errores de 3 horas, al que llamamos Bug Bash. Emitimos un cupón que funcionaría solo en el sitio web beta durante 3 horas y les pedimos a todos los empleados que hicieran uso del cupón y registraran cualquier error que enfrentaran en el formulario Bug Bash.
Los dividimos en diferentes equipos y anunciamos premios para los 3 mejores equipos. El plan funcionó y recibimos 223 respuestas de diferentes equipos. Nos tomó 2 días revisar la lista completa y determinar cuáles eran genuinos. La mayoría de los errores presentados eran problemas duplicados o conocidos, pero descubrimos 12 errores nuevos (de los cuales 3 estaban relacionados con la interfaz de usuario).

¡Esto nos dio un alto grado de confianza para lanzar la versión beta externamente!

Lección

La prueba nunca está de más y se puede hacer en cualquier etapa.
¡Felicitaciones a las mujeres, que nos ayudaron a lo largo del camino a construir una experiencia de compra tan fantástica en Zivame!

Estudie cursos de gestión de productos en línea de las mejores universidades del mundo. Obtenga programas de maestría, PGP ejecutivo o certificado avanzado para acelerar su carrera.

Programa destacado para usted: Programa de certificación Design Thinking de Duke CE