Will Web For Food

Teóricamente una prueba de test con un cuestionario, un diseño muestral y un análisis estadístico es investigación cuantitativa de libro.

El problema reside en el contraste de investigación.

No hay suficientes (esto quiere decir, yo no he encontrado…aun) investigaciones sobre el tema. Pero J. Nielsen parece que si cuenta con esos datos como se ve en su letter “Outliers and Luck in User Performance” del 6 de marzo de 2006.
Siguiendo con esta lógica la distribución debería seguir una curva normal y el comportamiento del usuario debería ser tratado como un modelo probalístico que siga la ley de los grandes números y el teorema del límite central. (O sea > 30 casos, y una distribución concentrada entrono a la media).
Es cierto que en ningún momento Nielsen afirma que entre User Performance y 5formula estén relacionados, pero creo que ello se sobreentiende y hay que justificar el uso de muestras pequeñas.
Creo que 5formula no es correcto por que para que sea operativa su lógica hay que presuponer el total de fallos que tiene el diseño (100%) es conocido de antemano por el evaluador, cuando la naturaleza del test es exploratorio, no descriptivo (el 100% serán los errores acumulados de todo los usuarios y aun así seria el 100% de los errores de nuestra muestra, no un total del diseño).
Aunque CUE 4 es una apuesta arriesgada para los costes de un proyecto (o no? Tengo que comprobarlo, por que este argumento se repite como dogma de fe)

Por otro lado, si enfrento la distribución normal a algún otro modelo continuo (pienso en una distribución de Pareto) ¿qué pasa?

Aunque como dice Jacobo, toda esta situación desaparece si optamos por un análisis de tipo cualitativo (Entrevista en profundidad, Grupos de discusión, Cognitive walkthrought (como metodología no como técnica) principalmente)
Pero no es cuali lo que me esta desquiciando.

Referencias

• Outliers and Luck in User Performance en J. Nielsen
• Why You Only Need to Test With 5 Users en J.Nielsen
• The User Is in the Numbers en J. Sauro
• When 100% Really Isn’t 100%: Improving the Accuracy of Small-Sample Estimates of Completion Rates en J.Sauro y J.R. Lewis

A la hora de comunicar estos dos asuntos se nos presenta un sin fin de modos de lograrlo.

Lo principal, vamos a intentar explicar una solución web a alguien que no tiene por que saber lo que sabes tú, como diseñador del producto web y que posiblemente no sea un HeavyUser. Recuérdalo. ( A mi me funciona!)

Si este “personaje” (en términos de modeling user) no tiene problemas con la documentación todo debería marchar bien.

Esta observación resulta capital cuando el workflow es extenso y deslocalizado.

Ok. Compro tu idea. Y ¿ahora que hago?

Hay varias opciones, pero en los últimos proyectos me he decantado por prototipos interactivos y parece que funciona muy bien, en múltiples escenarios.

• Escenario Validación, Cuando el faseado de la solución contempla múltiples encuentros con cliente, un prototipado interactivo es auto-explicativo, de este modo se reduce la necesidad de abstracción necesaria para enfrentarse a un prototipo, y permite separar la capa de interacción, de la capa de diseño grafico (aunque el color tiene su propia interacción, y condiciona la experiencia de uso, eso otro día.)

• Escenario Implementanación, en este escenario es aconsejable un documento en soporte físico, donde se detalle el diseño de interacción de los distintos elementos (flujo de interacción), la modularización de los mismos (prototipado), y la posición en la solución (site map).

En este escenario los prototipos interactivos facilitan infinitamente las tares de diseño grafico, permite absorber el “look & feel” para pasar de prototipo a maqueta interactiva, y regresar a validación o continuar con su implementación.

El campo teórico de las disciplinas suele poseer una metodología, que en ocasiones, carece de contraste empírico. Con un diseño sobresaliente, bien documentado y que resulta difícil de extrapolar a las tareas de campo.

En el rincón opuesto, y por paralelismo se suele encontrar la situación contraria.
Las “técnicas de Guerra y Guerrilla” del dia-a-dia, con una metodología ligera, que resulta fácilmente adaptable a una realidad polimórfica y cambiante.

No obstante, y aunque esta introducción pueda dar la sensación de mundos alejados, ambos son facetas de una única realidad.

Dentro del hci/e resulta habitual el enfoque más macro y de largo alcance, con metodologías estructurados y concadenas. ( ejemplo, WaterFall Method), mientras que el hci/d sigue diseño de patrones.

Un punto intermedio puede resultar muy interesante. Para mi, el punto intermedio es lograr trasmitir y comunicar 2 cosas:

• el diseño de interacción y

• el prototipado del producto.

Flota como una mariposa, pica como una avispa.

Las Métricas de Evaluación Usabilistica (Usability Evaluation Metrics o UEM) son consideradas como las técnicas más populares para medir la usabilidad.

Las técnicas principales de UEM son los Usability Evaluation Methods
(UEMs) que agrupan a:

• Cognitive walkthrought
• Heuristic evaluation
• Think-aloud

Aunque presentan diferencias en el grado de detección, y de selección de la muestra como muestra el CUE-4, así como una severa tendencia a acumular una desviación provocada por el entrevistador (evaluator effects).

Ya hemos comentado una serie de pautas importantes de cara a los test de usuario, desde la perspectiva del diseño de cuestionario.

El incumplimiento de estas pautas, suele acarrear errores, en este caso de diseño, que comprometerán el resultado de nuestro análisis.

Pero no solo el diseño de cuestionario es un punto delicado.

Los errores pueden vivir en muchas de las fases del análisis, (y en ocasiones, en todas ellas.)

Así, nos podemos encontrar:

• Con errores de diseño de cuestionario.
• Con errores selección de muestra.
• Con errores de pase y recopilación de información.

Una alternativa a tener en cuenta para evitar estos errores son las técnicas de analítica Web.

¿Por qué las técnicas analíticas evitan los errores?

En esencia, por que no trabajamos con muestras, sino con universos de usuarios.
Así, cosas como selección muestral (tanto en número, como en tipo de usuario… esto es un tema clásico, similar a la disputa Usabilidad y tecnología Flash) desaparecen.

Además, por que evitamos el encorsetamiento de las tareas, pasando de un análisis controlado de las tareas, a un análisis aséptico, sin inferencia del investigador, (en ocasiones el análisis de test de usuario se estructura como una justificación de cierto aspecto no usable en el site)

¿Cuando usar analíticas?

Debido a que necesitas datos reales, es útil para rediseños de site ya lanzados, en los que la web ya esta publicada.
De otro modo nos encontramos ante algún tipo de simulación que puede sufrir los mismos errores que los test.

Y esto, ¿cuanto cuesta?

Existen versiones lowcost test, basadas en herramientas de tags como google analytics, crazyegg y clicktale .

La idea de pruebas de bajo coste tiene una larga tradición en J. Nielsen, no dejes de visitar useit.

Una de las técnicas más importante a la hora de recabar información de la interacción de usuario-sistema es el test de usuarios

Dentro de los test de usuario, una técnica muy empleada es la encuesta.

Habitualmente se habla de encuesta como sinónimo de cuestionario. Y esto no es así.

La encuesta es el proceso de investigación, mientras que el cuestionario es la herramienta de la que nos servimos para esta investigación.

Así, la encuesta es, de forma estricta, la forma de recopilar la información, mientras que el cuestionario es el documento estandarizado con el cual se realiza esta recopilación.

Esta diferencia es básica.
Y conlleva implícitamente ciertas necesidades que debemos recordar.

Tipos de encuesta:
Tradicionalmente se estructuran en:

• Encuesta Personal
• Encuesta Remota (Telefónica/ Postal / Internet)

(Aunque existen distintas tipologías en función del alcance temporal y geográfico, del modo de administración, y múltiples modelos mixtos)

Mientras que el cuestionario tiene más enjundia.

Si por paralelismo, con lo expuesto aquí, para la encuesta, quisiéramos establecer una pequeña tipología, habría que considerar, que según el tipo de preguntas y según el tipo de respuesta, según la información que detectan y según la función que cumplen los items en el cuestionario, tendriamos un tipo u otro.

Sin necesidad de entrar en estas especificaciones. Lo fundamental, básico, recordar,

el cuestionario “No son preguntas dictadas por el sentido común en bruto”, y se tarda un poco más de 10 minutos en tener algo a lo que llamar cuestionario.

Si tienes que crear uno, tal vez te sea útil la siguiente receta para confeccionar cuestionarios.

• Consideraciones previas, pararnos a pensar que queremos saber, de quien, donde, para que.
• Decidir la redacción de las preguntas, sobre los ítems creados, siempre existe un proceso de “afinado”, que nos lleva a trabajar con los literales para lograr una semántica precisa.
• Decidir el formato de respuestas, el tipo de formato de la respuesta condiciona de forma poderosa la respuesta, hace falta tener en cuenta lo que se busca para saber como encontrarlo.
• Decidir la secuencia de las preguntas, no todos los cuestionarios resultan operativos, se suele hacer una introducción, empezando por lo general para pasar a lo particular, y cerrar con los datos personales, pero si consultas bibliografía veras que existen otros formatos. Aquí lo principal es que logres un proceso fluido y amigable.
• Decidir las características físicas del cuestionario, en la misma línea que las anteriores consideraciones, el formato del cuestionario influye en sus resultados.
• Pretest, revisión y borrador final, hazte un favor a ti mismo, antes de nada pruébalo, testar la prueba no resulta muy caro, en principio cualquiera te sirve para eso, no necesitas un muestreo significativo, y te dará una serie de pautas para detectar donde esta fallando tu cuestionario.

Referencias:

• 20 trucos para crear cuestionarios
• Recopilación de cuestionarios de usabilidad

Diseño Centrado en Usuario ( DCU o UserCenter Design) se basa en la Usabilidad a través de la Experiencia y la Participación, como método para potenciar esta cualidad.

Posee 3 factores Principales ESTRUCTURA, FOCO y METÁFORAS.

Debido a su naturaleza empírica, la mayoría de las metodologías de evaluación usabilisticas se ven referenciadas en este modelo.Hay dos grandes líneas dentro UCD, el Diseño Participativo (Participatory Design) y el Diseño Contextual (Contextual Design).

Referencias:

• SMD 157
• La Ingeniería de la Usabilidad y de la Accesibilidad aplicada al diseño y desarrollo de sitios web

Los chicos de la UOC han creado un toolbox con pinta de juego de mesa.
La idea es convertir la metodología UCD en una serie de fichas, que describen las tareas a lo largo de 4 fases, que agrupan las tareas de diseño del interface, selección, analisis, diseño y evaluación.

Es Simpático.

En fin, un poco mas allá de la impresión y  ya más a nivel evaluación.
El apartado dedicado a la selección de la muestra resulta  más bien “las fichas de los datos sociodemograficos de la muestra” y todo el paquete tiene más de juego que de investigación, ya que la metodología se limita a la enumeración de las tareas en el documento de análisis de la fase 2.

Pero no se debe perder la perspectiva de  lo que se busca con esta iniciativa, que es la concienciar de la importancia que tiene la participación del usuario (UCD) en la conceptualización de un buen diseño de  producto para que se  logre una gratificante experiencia de uso.

Y en esa línea es una idea genial.

Las Greek Pages son paginas de contenido dummies cuya finalidad es servir de soporte para un test de usuario, en el que se evalua, que los elementos del site son identificables .

can be used to provide insight into whether a particular Web page design and layout will be effective in helping users to navigate the site and find content

Y es una técnica de evaluación de la metodología del diseño centrado en usuario.

Refencias:

• En Usability and the Web: An Overview De George Murray and Tania Costanzo
• Una herramieta para “griegizar” tus sites
• Y la siempre interesante opinión de Jacobo.

yo siempre había creído que loren ipsum era Latin…?

Sobre la tecnología de prototipado se esta hablando últimamente mucho en muchos sitios.

Hechos como el lanzamiento hace unos meses de una de las referencias imprescindible sobre el tema, como es “Effective prototyping for maker software” han avivado el debate entorno a uno de las tares principales de la profesión.

En esa línea, he estado investigando sobre herramientas específicas orientadas a la tarea “prototipista” y me he topado con un hilo de IxD donde se referencia positivamente la herramienta Altia.

Básicamente es un plugin para photoshop, y no se ha adaptado desde el principio a lo que estoy buscando, una herramienta funcional y agil, que me permita precisar funcionales e interacción, y en el caso de altia, la capa de diseño es excesivamente densa.

La siguiente referencia que he testado es ConcepDraw, progama multiplataforma, publica xml, capea los diagramas y promete, servir, salvo por el pequeñísimo detalle de que el trial viene sin las librerías de diseño web, y que la orientación mas que a pantallas es a sitemap.

Tras las pruebas, creo que por muchos problemas que tenga Visio, (principalmente el de visualización, que no es muy grave y se solventa en maquinas con Windows con el Visor Visio , o exportando a html y haciendo navegables los protos.) va a seguir siendo la opción.
(Y en Mac Omnigraffle)
¿Las razones?, es vectorial,( eso es bueno, por que quiero estructuras, no diseño) pero hay muchos programas vectoriales en el mercado, la ventaja de Visio es que tiene un gran numero de stencils y templates adaptados a las tareas de diseño de prototipos, es sencillo, carga rápido, no consume muchos recursos y genera maquetas html.