Método RITE: Fácil, útil, y apenas utilizado

El método RITE permite extraer mayores resultados de los tests con usuarios, y de forma más rápida. Es especialmente útil en las primeras fases del desarrollo, y pero no se utiliza todo lo que se podría. Y es una lástima, porque puede acelerar el proceso de prototipado en fases muy tempranas, con el consiguiente ahorro de costes que supone…

Al grano: ¿Qué es RITE?

Método RITE: fácil, útil y apenas utilizado

Correcaminos explicándole al coyote que haciendo iteraciones más rápidas siempre acaba antes sus desarrollos ;-)

RITE son las siglas de Rapid Iterative Testing and Evaluation (algo así como Evaluación y testeo rápido e iterativo). Como tantas otras mejoras en el campo de la usabilidad, proviene del mundo de los videojuegos (en concreto, de Microsoft). Consiste en realizar tests con usuarios, y a medida que se van detectando campos de mejora, implementarlos inmediatamente (o tanto como sea posible).

En el campo de los videojuegos, su utilidad es obvia: Por ejemplo, vamos a testear la dificultad de un nivel: Hacemos tests con unos pocos usuarios, ajustamos, volvemos a testear, ajustamos de nuevo…

Pero también puede ser de gran utilidad creando cualquier aplicación, en especial en las fases de prototipado, o para probar varias alternativas en una interacción.

Los tests con usuarios son útiles para encontrar fallos y áreas de mejora en una interfaz, pero a priori no dan soluciones a los problemas detectados, por lo que cuando se deciden estas soluciones, toca testear otra vez (en esto consiste el diseño iterativo).

Pero si estos tests se realizan con versiones muy simples del prototipo, hacer cambios y testear de nuevo puede ser muy rápido. Esto significa que podemos llegar a hacer varias iteraciones sobre un prototipo en el mismo día (lo que es una gran ventaja a la hora de acortar plazos de desarrollo).

Dicho de otro modo, si lo que se va a testear es prácticamente la aplicación final, no tiene mucho sentido intentar este método, porque probablemente implementar cambios tome varias horas como mínimo.

¿Y por qué apenas se utiliza?

Esto es mi experiencia personal, por lo que no tienes por qué estar de acuerdo. Pero a menudo me encuentro con lo siguiente: En empresas que ya tienen ciertas nociones sobre usabilidad y diseño centrado en el usuario, entienden la necesidad de hacer tests con usuarios. Wireframes, prototipos y tests ya forman parte de su modus operandi.

Pero su idea de hacer tests suele ser sobre una versión avanzada del prototipo, o incluso cuando la aplicación ya está casi lista. No se plantean la idea de hacer un test, por ejemplo, sobre un wireframe en papel. De hecho, a menudo se ve con cierta condescendencia, como si se tratara más de un juego, que de algo que puede ahorrarles muchas horas y dinero en desarrollo. Es como si al no tener una funcionalidad real, no sirvieran para hacer tests.

Y nada más lejos de la realidad: realizar tests sobre estos prototipos requiere un poco más de imaginación, y dar alguna explicación más a los sujetos del test, pero el ahorro en horas de desarrollo merece ampliamente la pena. Esto no ocurre sólo en la administración pública, también en empresas, especialmente las más grandes. Pero también he visto startups (por suerte aquí este error se comete menos) que no se preocupan de la usabilidad y los tests hasta que están casi para lanzar.

Contar con una persona experta en usabilidad, o en diseño centrado en el usuario, es especialmente útil al principio de los proyectos, cuando está todo por definir. Además, como suelen ser perfiles senior, están capacitados para identificar otros problemas que de otro modo aflorarían en fases más avanzadas (problemas de logística, atención al cliente, modelo de negocio, etc).

La interfaz no es una commodity

Aún se ven muchos sitios donde el desarrollo de una aplicación comienza con la creación de las tablas que compondrán la base de datos. En estos casos, la interfaz suele verse como una commodity (algo prescindible o de importancia secundaria) que puede comenzarse a mitad o incluso al final del desarrollo.

Lo cierto es que esta percepción está obsoleta. Ahora la interfaz lo es todo. Gracias al auge de las aplicaciones móviles, nadie quiere un manual de uso para entender cómo funciona una aplicación. El usuario espera una interfaz simple y fácil de usar. Que una aplicación funcione correctamente, es lo mínimo que admite. Lo que hará que elija entre una u otra, es cómo le haga sentir (competente, ágil, útil, sorprendido, deleitado…).

Para saber más:
Enlace en inglés Resumen del Método RITE en wikipedia
Enlace en español Artículo en UserZoom
Enlace en inglés Definición y caso de estudio por los autores originales

Si te ha gustado, recuerda compartir ;)

curso Divi actualizado y en español