La ejecución de RITE es incorrecta. La investigación del usuario es ciencia – No lo hagas … | Joe Bernstein | Diciembre de 2021

La investigación del usuario es ciencia: no pase por alto el método científico

Joe Bernstein
Imagen estándar de una mujer con una bata de laboratorio pipeteando una sustancia coloreada en viales

La investigación de usuarios toma muchas formas, pero las más populares son RITE, o Pruebas iterativas rápidas y Ev.alucia. El método RITE no es solo una forma popular de hacer investigación, sino que su estado de palabra de moda parece resonar en los ejecutivos que de otro modo no querrían invertir en investigación. Tanto es así que me he encontrado con sesiones de prueba de usuarios llamadas exploraciones RITE cuando no eran rápidas ni iterativas, solo pruebas y evaluación de rutina, como con los métodos de investigación más tradicionales. También participé en la investigación de RITE, que fue precisamente rápida e iterativa, pero mal aplicada, degradó la calidad de los datos de prueba y alargó el proceso de diseño de manera exponencial. Antes de poder explicar qué salió mal y qué deberíamos haber hecho mejor, necesito considerar por qué RITE es tan popular: cuando se hace correctamente, no solo es más eficiente, sino que también tiene sentido.

El método RITE fue delineado por primera vez en 2002 por Michael Medlock y su equipo en Microsoft Games Studios mientras desarrollaban Age of Empires II… Las pruebas iterativas rápidas “dan como resultado una alta proporción de problemas encontrados y arreglados, y luego validan empíricamente la efectividad de los arreglos”, como se indica en la anotación del documento técnico del grupo. Esto se debe a que la idea principal detrás del método RITE es que usted prueba una pequeña cantidad de usuarios al mismo tiempo, identifica problemas de usabilidad desde los primeros estudios, toma algo de tiempo para solucionarlos y luego prueba a algunos usuarios más nuevamente con su nivel superior. producto de calidad. … La investigación de usuarios tradicional implica probar el mismo prototipo en un gran número de usuarios, del orden de 100 o más, por lo que los problemas de usabilidad pueden confirmarse mediante el análisis estadístico de una muestra grande. En comparación, los estudios RITE son esbeltos, económicos y brindan casi la misma calidad de retroalimentación que los métodos tradicionales más inertes.

Esto se debe a que el método RITE se basa en una de las pautas fundacionales de Nielsen Norman Group: solo necesita probar con 5 usuarios. Según un informe de NNG publicado por Jakob Nielsen en 2000, el rendimiento disminuye a medida que aumenta el número de participantes en un estudio. Básicamente, no encontrará ningún problema de usabilidad si prueba cero usuarios. Su primer examinado encontrará una cierta cantidad de problemas de usabilidad, y cada examinado subsiguiente encontrará aún más, pero muchos de estos problemas se superpondrán con los anteriores. Trazar los rendimientos decrecientes muestra que puede identificar más del 80% de los problemas de usabilidad del producto con solo los primeros cinco usuarios de prueba. Y si ese es el caso, entonces no vale la pena perder tiempo y dinero probando a más usuarios si, en cambio, puede solucionar el 80% de los problemas de usabilidad. arreglalosy luego pruebe el producto con otro pequeño grupo de usuarios. Si bien la prueba de 15 usuarios puede revelar casi todos los problemas de usabilidad de su prototipo v1, la prueba de cinco usuarios en tres rondas revelará la mayoría de los problemas con su prototipo v3.

Por lo tanto, el método RITE recomienda limitar las pruebas a 4-5 usuarios a la vez, dando tiempo al equipo de diseño o desarrollo para solucionar los primeros problemas que encuentren y luego volver a probar después de algunas iteraciones.

Al principio de mi carrera, participé en un proyecto que ya estaba siendo probado por usuarios. Los gerentes de marketing realizaron las pruebas de usuario y, aunque no necesariamente llevaron a cabo la investigación RITE del libro, configuraron la investigación de tal manera que probaron el mismo grupo de cinco clientes una vez a la semana durante tres semanas consecutivas. La idea era aumentar el número de mejoras en función de los comentarios cada semana y luego volver a probar a los mismos usuarios con un prototipo mejorado. El primer ministro que conducía las entrevistas creó un prototipo para la Ronda 1, algunos bocetos dibujados a mano con muy pocos detalles, y procedió a realizar la primera ronda de pruebas.

Fue entonces cuando me involucré en el proyecto. Dado que las pruebas de la Ronda 1 estaban en su mayoría completas, necesitaron mi ayuda para tomar los bocetos dibujados a mano, recrearlos en Figma y, al mismo tiempo, corregir algunos de los primeros defectos descubiertos en la primera ronda de rondas. En teoría, esto era bastante simple; El desafío era configurar las pantallas recreadas antes del cierre de la primera ronda el viernes por la mañana y elaborar la lista de mejoras a tiempo para implementar la segunda ronda el lunes por la mañana.

La Ronda 2 nos trajo más comentarios, pero los comentarios fueron claramente diferentes de los comentarios de la Ronda 1. Dado que pasamos de los bocetos a Figma, y ​​por conveniencia, los diseños de Figma se crearon utilizando botones y controles de biblioteca de alta calidad. los clientes esperaban que la funcionalidad coincidiera con estas pantallas de mayor calidad.… En lugar de probar los cuellos de botella que se destacaron en los bocetos a mano, el facilitador asignó tareas abiertas y permitió que los clientes las exploraran libremente. Como resultado, la retroalimentación se ha reducido principalmente a preguntas como “¿A dónde conducirá este botón?” o “no debería [irrelevant] cuadro de texto para marcar [this] en lugar de? “Sin embargo, pasamos cinco pruebas de usuario con una lista de reseñas aún más larga.

Como fui invitado a este proyecto, no me sentía cómodo resistiendo cuando pasamos a la Ronda 3. Después de escuchar comentarios sobre flujos de productos más realistas, el equipo de desarrollo me pidió que complementara la variedad de rutas de transición que los clientes pudieran tener. tomar durante su investigación. Con un suspiro y pintura sobre los ojos que me escondí, hice maravillas al crear un prototipo con más de 20 marcos que anticipaban muchos clics por los que un participante podría preguntar.

Pasamos a la tercera ronda, donde los clientes notaron inmediatamente lo profesionales que se veían las pantallas. Pero después de que los dos primeros clientes no pudieron resolver las tareas, se hizo evidente que el propósito real de este producto no era tan claro como nuestro equipo esperaba. Antes de la tercera prueba, hice varios ajustes (que ahora debían reproducirse en más de 20 pantallas) y comenzamos a probar nuevamente. Ahora hemos cambiado la redacción de algunas de las características como se sugirió en pruebas anteriores, pero los participantes posteriores parecían más confundidos por el hecho de que la dirección del producto cambiaba cada vez que lo veían. Las dos últimas pruebas se frustraron por completo con intentos de tareas desenfocados y los únicos comentarios relacionados con los detalles de la interfaz de usuario en lugar de la usabilidad de las funciones.

La dirección del producto, y estas pruebas, parecían estar fuera de mi control. Debido a los cambios importantes que decidimos hacer entre las pruebas, las pruebas posteriores se retrasaron, lo que hizo que esta aventura de tres semanas fuera una de cinco. Y dado que recibimos comentarios deficientes de la Ronda 3, ampliamos algunos de los participantes a las Rondas 4 y 5.

Estas fueron las únicas pruebas de usuario que terminamos haciendo para este producto, pero terminamos pasando otros seis meses iterando en el diseño. La viabilidad técnica dictó una serie de cambios de dirección, así como una puerta giratoria de características agregadas y eliminadas por el equipo de desarrollo, y mi archivo Figma terminó conteniendo 14 versiones de prototipos adicionales. El producto finalmente se lanzará, pero se veía muy diferente de lo que presentamos a nuestros interlocutores.

Este estudio RITE comenzó siendo muy prometedor, pero perdimos una oportunidad de mantenernos en línea con la metodología RITE y no pudimos aprovechar la efectividad que promete el método. Realicé una autopsia y determiné que un estudio RITE exitoso requiere:

  • Desarrolle una hipótesis para probar. Como todos los experimentos con métodos científicos, está bien si la hipótesis es incorrecta, pero si no tienes algo concreto que probar, no probarás nada.
  • Reducir la prueba. Las pruebas rápidas son las mejores para pruebas de concepto de alto nivel. Se necesita mucho tiempo para desarrollar interfaces de usuario sólidas en las que cada botón tenga una función y una secuencia de operaciones, pero la mayoría de estas funciones no son esenciales para las pruebas. Permitimos a los usuarios explorar haciendo preguntas abiertas y terminamos identificando periféricos sin terminar en la página en lugar de validar el producto en sí.
  • Mantenga un diseño coherente para todas las personas con las que está hablando. Al rediseñar significativamente la interfaz de usuario a medio camino entre los examinados, obtuvimos datos menos consistentes y menos confiables, ya que algunos de los comentarios de los participantes fueron para el diseño anterior y otros para el nuevo diseño. Sin embargo, nuestro grupo de encuestados fue bastante diverso y fue útil recibir comentarios de todo el espectro. En el futuro, si un equipo realmente necesita probar dos opciones, se puede realizar una prueba A / B. consistentemente para todos los participantes
Previous post Vista previa de 2022: 5 tendencias de contenido que no querrá perderse
Next post Tendencias que necesitarás en 2022

Deja una respuesta