Will Web For Food

Con la proximidad del inicio del nuevo curso, podíamos plantearnos la revisión de los planes de estudio para el 07/08.

A mi me gustaría que dentro de la carrera no reglada de hci se incluyera un curso de “Introducción al prototipado”.

Me parece una muy interesante materia, pero no he logrado aun concretar, por más que rebusco.

Y es que por un lado, parece que existe una importante cantidad de literatura respecto a “tecnologías aplicadas al prototipado” pero casi ninguna sobre que es prototipar.

Y además estas dos cosas (técnica y proceso) se usas como sinónimos, sin que ello sea del todo cierto.

Así, discutimos que herramienta resulta más conveniente e idónea frente a tal necesidad, cual no responde a determinada situación, sin abordar en que consiste el proceso de prototipo.

Bien, para los interesados en la las técnicas, ( you have so many tool!) hay varias interesantes referencias.

Un libro muy bonito y que hay que ojear de modo general es effective prototyping y que en la bibliografía recomendada de “tecnologías aplicadas al prototipado” se cita y recomienda. Y para el applepeople una referencia interesante es omni group.

Ahora, sobre el noble y antiguo arte del prototipado.

Yo desde mi humilde experiencia creo que de cara a integrar prototipos en la capa de diseño y presentación es conveniente que el prototipo trate una serie de puntos y los cumplimente.

1. Diseño estructural de la pantalla.(Que elementos configuran las pantallas, a máximo número de elementos, tu maquetador te lo agradecerá…) El prototipo propiamente dicho, tanto en un enfoque macro (hi-fi) como RAD, y tanto como para soluciones dinámicas con cms modulares, como para ese discreto promoweb de micropyme.
2. Diseño de interacción de la solución.(Como se comportan los elementos respecto a la interacción del usuario, concretando, como se produce la navegación, como se comportan los botones, como responden los formularios.)
3. Sitemap. (Donde va cada cosa dentro del site, y que relaciones presenta entre ellos, definimos aquí también los path de navegación, trasversal y horizontal, primaria y secundaria, recurrente.)

Si la documentación del prototipo cumple estos 3 puntos no debería presentar ningún problema, la idea generatriz para formular estos 3 puntos, es la de crear una documentación capaz de permitir desarrollar toda la aplicación, sin dirigir, ni obstaculizar el resto de disciplinas, (visión amplia del Hci = [Ai +InteractionDesign + Comunicación Visual + FrontBack]).

De este modo, con una documentación de prototipado e interacción completa, o completada, logramos que los prototipos por un lado estén contextualizados al producto, tanto a nivel funcional como gráfico, y puedan presentar un ciclo de vida mucho más amplio, reduciendo los costes de desarrollo.

El problema de todo esto reside en que no se suelen ver prototipos por ahí.
Yo no se como prototipas tu, con lo cual no puedo aprender. Y creo que esto debe ocurrir a nivel mundial.

Por eso, ver ejemplo podría ser de utilidad, pero claro eso no puede ser así de sencillo, esta suscrito a ciertos compromisos profesionales que hacen que los perfiles de los Ai sean sesgados.

¿A nadie le llama la atención que las listas profesionales de temas afines al desarrollo web se vean líneas de código, piezas gráficas, y que la comunidad ai resuelva sus dudas verbalizando?

Esta claro que yo tendría ahora que poner unos protos por aquí…

Y que la mesa, sea de madera de pino, o de estructuras tubulares de latón , no deja de ser mesa.

Referencias

• Datos al respecto
• Definición y reflexión
• Técnica con omnigraffle
• Sobre wireframes
• El saber universal sobre la cuestión
• Ejemplos de prototipo
• Glosario de terminos

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.