Testing de la web: el empirismo al servicio de la calidad

Acabamos la racha de artículos que hemos dedicado a conceptos básicos de analítica web con una de las partes más divertidas y apasionantes: El testing. Testear es algo que hacemos todos. En la Administración el desarrollo de grupos piloto para hacer evaluación prospectiva de un programa de cambio es algo bastante usado (o al menos, pregonado). Sin embargo esta disciplina es tradicionalmente costosa y las políticas públicas y los programas no se realizan con tanta asiduidad como para poder estar haciendo pruebas constantemente. El testeo de acciones y cambio  es algo inherente al funcionamiento racional de la Administración, que se ha potenciado con la evaluación de las políticas, la planificación y los estudios de calidad. La cosa se pone interesante cuando entramos en un medio en el que la elaboración de ensayos no es ni mucho menos tan cara, no requiere tanto tiempo y, sobre todo, no precisa de etapas concretas para realizarse. La navegación web ofrece, por lo tanto, condiciones idóneas para realizar este tipo de experimentos. Pero ¿Cómo se hacen? ¿En qué se diferencian del testeo tradicional? ¿suponen algún riesgo inopinado?

El testeo tradicional en la analítica web es el test A/B y se aplica para ver qué diseño tiene mejor funcionamiento respecto a la consecución de un objetivo. Evidentemente, todo análisis a poco proactivo que sea, supone hacer pruebas, y por lo tanto, en realidad todo análisis es un testeo menos concreto, por así decirlo. Decidir cuándo publicar algo, cambiar un contenido, modificar la estructura del sitio, todo son tests implícitos en los que, a lo largo del tiempo, validamos o no una hipótesis. Lo que nos permite el test A/B en términos diferenciados, es controlar el entorno en el que realizar el estudio, y un muestreo aleatorio que debe validar el resultado. Esto se hace de una manera sencilla de explicar: decidimos la página sobre la que podemos hacer el testeo, generamos las dos variantes de la página, y esperamos a que los datos de tráfico nos faciliten suficiente fiabilidad como para excluir conclusiones válidas.

Tenemos un medio para plantear dos alternativas de una misma web y que la herramienta de analítica segregue las visitas aleatoriamente para saber si el comportamiento es sustancialmente distinto. Esto supone una gran oportunidad para realizar estudios sobre:

• El diseño del sitio: ¿Son mis colores los mejores? ¿Se ve todo bien? ¿La gente va a dónde yo querría que fueran? ¿Se despistan?
• Contenido: Está claro lo que digo y lo que ofrece la página. Si cambio, por ejemplo, la redacción de un texto, o lo simplifico, ¿bajará el abandono del sitio?
• Arquitectura: Los menus que tiene mi página ¿facilitan las opciones al visitante? ¿Les ofrecemos medios para seguir a dónde le interesa?
• Experiencia: Dentro de ese magma conceptual que es la experiencia del usuario ¿hacemos más positiva la visita a nuestro sitio? ¿Dejamos un peor recuerdo?

Sin embargo, pese a todas las posibilidades que nos ofrecen las herramientas de testing, todo buen analista de cualquier tipo, sabe que la utilidad de un análisis se debe a lo acertado y no por la herramienta. Es por ello, que antes de lanzarnos como un pollo sin cabeza, tenemos que tener claro lo siguiente:

• Un plan. Un análisis debe obedecer a un plan, a una táctica y a una estrategia. Es decir, la web no deja de ser un soporte en el que podemos hacer varias lecturas de un mismo fenómeno. Para que un análisis tenga que tener sentido necesitamos saber qué es lo que queremos medir, y para qué. ¿Creemos que no se solicitan permisos de obras on-line porque la normativa genera incertidumbres? Quizá debamos simplificar el lenguaje.
• Un objetivo. Como para cambiar muchas cosas es necesario seguir un orden, es preciso que el análisis y el testeo tengan un objetivo enclavado en ese plan. Por ejemplo, logremos que más gente use la web del sevicio de obras para pedir licencias on line en vez de venir a la oficina.
• Una hipótesis: Para saber qué debemos mejorar, tenemos que tener claro qué es lo que podemos mejorar. En el caso que nos ocupa podemos pensar que reducir el tamaño de la página y crear menús que permitan identificar claramente qué tipo de obra desea solicitar el visitante puede hacer que más gente prosiga en la navegación.

• Un plan de pruebas. Muy importante, porque salvo para cuestiones extremadamente simples, un sólo test no bastará, o, en cualquier caso, tendremos que tocar varios elementos. Aunque los test A/B ya permiten de por sí valorar distintos elementos de cambio, es lógico pensar que el número de combinaciones viables para probar algo mínimamente complejo precisa distintos ensayos para llegar a un resultado. A esto hay que sumar que, aunque el tráfico sea lo bastante alto para tener una muestra representativa en poco tiempo, comprobar algo de la complejidad de una hipótesis precisa varias pruebas y, por lo tanto tiempo y una lógica secuencial entre ellas. Así que hay que tener un plan no solo de cada prueba, sino del conjunto de ellas y de a dónde queremos que llegue nuestra hipótesis.

informe de resultados de un test A/B en google

Así pues, una vez que tenemos todo esto, hay que empezar a realizar las pruebas. Dado que lo que esperamos lograr es un planteamiento que sea más eficaz para conseguir nuestro objetivo (sea este cual sea), lo lógico es crear modelos alternativos que nos permitan validar la hipótesis y encontrar fórmulas integrales que respondan a ella. Es decir, no es lógico hacer un test para medir el tamaño de los cuadros de diálogo, y otro para su posición además de un tercero acerca de los botones de envío. Si creemos que tenemos un problema con un formulario por su tamaño, lo lógico sería hacer distintos encajes entre estos tres factores para reducir el tamaño e ir probando las reacciones de los usuarios. Es decir, la lógica de la hipótesis debe ser también el armazón del experimento.

Si esto no fuera bastante complicación (y apasionante) por sí mismo, tenemos otro elemento a considerar: el enfoque holístico de la interacción web. Un formulario, por seguir con el ejemplo, puede ser un cuello de botella, pero la evaluación que realiza en términos operativos el visitante es su itinerario en la web. Es decir, el testeo debe considerar el contexto del usuario y, de hecho, la base de la batería de pruebas debe ser esa experiencia completa. Por ejemplo, aunque mejoremos un formulario, si en la navegación los usuarios se han podido distraer por una mala política de menús, o se sienten intimidados por las instrucciones o los términos de uso (pongamos el ejemplo de pagar un impuesto, lo que levanta respeto a cualquiera), la hipótesis debe considerar todo el ciclo y lo lógico, es que el testeo trate de realizarse sobre cada una de sus etapas. De lo contrario el resultado será marginal.

Por último hablemos de los peros, que en el tema público tienen algunas particularidades. Por un lado, y a mi juicio el más interesante, es la duda acerca de hasta qué punto este tipo de experiencias puede ir contra una parte de los ciudadanos. Si empleamos un testeo en el que los visitantes de una de las pruebas ven dañados sus derechos (de información o de acceso) a un servicio, estamos haciendo un flaco favor. Aunque en buena lógica es un trabajo para mejorar, y es lógico encomendarse a la paciencia, estas pruebas deben controlar su entorno normativo para no dañar al usuario. La página de un test no deja de ser la página de un servicio público. En el sector privado, un mal enfoque o forzar la salida del visitante para probar una teoría es un coste que asume una empresa. En el sector público, quien paga este extremo es el ciudadano. Es por ello que las pruebas deben de construirse y circunscribirse a la lógica del servicio público. Otro problema es que se trata, a fin de cuentas, de un escenario tan grande y barato de realizar, que es fácil perder el enfoque y enfrascarse en pruebas sucesivas que no nos lleven a nada. Ese es el motivo por el que la definición concreta de objetivos debe ser absolutamente nítida. 

En resumen, la Administración desarrolló desde los años 70 el testeo para evaluar la eficacia de sus políticas y sus programas. En la actualidad este testeo debe aplicarse también al servicio digital, para lo que existen medios y condiciones. A esta oportunidad hay que sumarle un último giro transformador: el coste reducido de las purebas permite hacer lo que no hemos hecho hasta ahora: una evaluación continua y constante de toda la población. A fin de cuentas, Google siempre está comprobando la longitud de su barra de búsqueda, y es que no hay detalle pequeño para mejorar el uso de nuestro servicio. 

Hacer de los ciudadanos conejillos de indias, perderse en el sandbox.