Algunas herramientas para el prototipado

Este artículo había quedado pendiente de publicar tras nuestra I noche temática sobre prototipado, ahora que he podido encontrar un hueco lo pongo a disposición de todos.

Algunas herramientas para el prototipado

Pizarra blanca y rotuladores
Si lo tenemos a mano resulta muy útil para dibujar sobre la marcha y aclarar conceptos e ideas. Con grupos de trabajo pequeños se pueden valorar rápidamente diferentes modelos de interacción, maquetas, etc. Por contra, requiere de cierto espacio físico y carece de las ventajas de los modelos "digitales".
Lápiz y papel
Es más manejable que la pizarra, su elaboración suele requerir poco esfuerzo obteniendo, como método de trabajo, muy buenas respuestas en las evaluaciones. Sigue siendo un formato "analógico" (no está digitalizado; no se puede enviar por correo sobre la marcha, hacer y deshacer, copiar y pegar…).
Herramientas de dibujo vectorial (Illustrator, Corel Draw, Freehand…)
Herramientas de dibujo basada en vectores. Rápido para dibujos sencillos, fácil de modificar, posibilidades de edición de texto, muchas formas y figuras predefinidas, flexible y exportable a otros formatos digitales.
HTML
Si se hace correctamente, en etapas tempranas del proyecto, se puede aprovechar parte del código para el producto final. Nos permite utilizar tantas características del código como deseemos; las páginas pueden enlazarse para crear la navegación, que las consultas a las posibles bases de datos sean funcionales (teniendo en cuenta la interacción, la validación de los datos, los mensajes de error, etc.), añadir estilos y la "capa gráfica" para lograr prototipos de alta definición… como desventajas; puede suponer mucho esfuerzo y tiempo que a lo mejor no se reutiliza, no suele ser un proceso rápido, tal vez requiera contar con mucho personal técnico: programadores, maquetadores, diseñadores… en ocasiones, la versión en pantalla no se puede pasar fácilmente a un formato de papel.
Herramientas de diseño y retoque fotográfico (Photoshop y similares)
Muy interesantes para valorar propuestas, bocetos de diseño y, en general, el aspecto gráfico del prototipo (colores y "sabores"). Es útil para realizar versiones estéticamente elaboradas y visualmente ricas. No es aconsejable para recrear la interacción puesto que la modificación es más costosa que con las herramientas de dibujo vectorial.
Herramientas para dibujar gráficos y diagramas de flujo (Microsoft Visio y OmniGraffle)
Son herramientas similares (Visio es algo más completo) pero una para la plataforma Windows y la otra para MacOS respectivamente. Ofrecen múltiples plantillas y formas específicos para el prototipado, muchos de ellos configurables y editables por el propio usuario. Son muy flexibles y fáciles de modificar, además, permiten añadir información útil a los diagramas, explicando la interacción, el flujo de datos, etc. Es posible añadir vínculos para simular la navegación entre pantallas, aunque, tal vez, para estos casos es mejor recurrir a prototipos en HTML.
Herramientas para presentaciones (Microsoft PowerPoint, Apple Keynote…)
Su uso fundamental no es el del prototipado, no obstante, permiten crear presentaciones con diapositivas que pueden simular diferentes situaciones, estados de la aplicación o interacciones. Las formas y figuras que incluyen son mucho más limitadas que las de Visio y OmniGraffle. Se pueden editar rápidamente y no necesitan demasiados conocimientos técnicos para su uso. Puede ser bastante tedioso para páginas complicadas (y largas) que no pueden mostrarse con una simple pantalla.
Herramientas específicas para el prototipado
Me gustaría destacar Axure y Denim. La primera es una aplicación comercial, específica para crear prototipos HTML y wireframes con cierta funcionalidad y con la capacidad para ser comentados (vean un ejemplo). Por su parte, Denim, es un curioso proyecto, multiplataforma y gratuito, de la Universidad de Washington. Como lo definen sus autores: "una herramienta informal para sitios Web y diseño de la interfaz de usuario en las etapas tempranas". Puede resultar interesante para hacer un prototipo rápido (a mano alzada sobre una tableta gráfica o similar) y añadirle "navegabilidad". Su uso es un poco enrevesado al principio, no obstante, no deja de ser un concepto muy curioso.

Pueden encontrar más información en Diagramming Tools (30 de diciembre de 2008: lástima, desde noviembre de 2007 parece que la página ha dejado de existir).

Actualización del 5 de ocubre de 2007: Adobe Labs está desarrollando una aplicación con el nombre en clave de Thermo (ahora Adobe Flash Catalyst), según su descripción, es un producto que facilitará a los diseñadores crear interfaces RIA que se pueden poner rápidamente en producción y desarrollo.

Actualización del 18 de diciembre de 2007: en la lista Cadius hacen algunas aportaciones interesantes:

Actualización del 26 de diciembre de 2007: La diagramación en la arquitectura de información, excelente artículo de Rodrigo Ronda León.

Actualización del 5 de marzo de 2008: Sergio Sánchez Mancha (Usolab) realiza una buena recopilación de enlaces sobre prototipos de papel.

Actualización del 2 de junio de 2008: el diseñador web Christian Watson nos habla de más herramientas en A Better Way to Create Information Architectures, Wireframes and Prototypes.

Actualización del 22 de julio de 2008: Olga Carreras explica con detalle qué son los wireframes.

Actualización del 31 de octubre de 2008: Prototyping with XHTML.

Actualización del 9 de marzo de 2009: Herramientas online para hacer prototipos.

Actualización del 1 de septiembre de 2009: Cameron Chapman publica en Smashing Magazine 35 Excellent Wireframing Resources.

Actualización del 27 de enero de 2010: otra completa recopilación en Gui Prototyping Tools.

Crónica-resumen de la I Noche temática: Prototipado

La primera noche temática, celebrada el pasado 22 de junio de 2006 en la oficina de IT7 y coincidiendo con el primer aniversario de los Cócteles Cadius en Canarias, la dedicamos al prototipado, tal como habíamos anunciado. Antes de sentarnos, decidimos que cada uno expondría aquello que le llamara atención sobre el asunto, y que iríamos interrumpiendo cuando tuviéramos algún punto que comentar.

Empezó José R. Quevedo rompiendo el hielo, y, posteriormente, Aritz Suescun, Domingo Cabrera y Ruymán Ferrera fueron interrumpiendo, aportando ideas y opiniones.

La idea principal de José es que hay tanta disparidad en la forma de concebir, plantear y llevar a cabo el prototipado que hacer un repaso exhaustivo a las teorías sobre él origina más dudas que certezas. Unas justificaciones al respecto:

  • En cada caso depende de lo que se desee evaluar (diseño gráfico de la interfaz, parte de interacción…) y de la fase en la que se plantee el protipado; si es inicial, generalmente se usan prototipos muy esquemáticos y más abstractos para el cliente, si es en las fases finales, es conveniente emplear prototipos más elaborados y detallados.
  • La enorme diversidad de formas de llevar a cabo el prototipado (desde el lápiz y papel a la denominada High-Fidelity; desde el prototipo que representa interfaces completas al que se limita a mostrar la disposición de una información determinada) tampoco ayuda a fijar ideas en torno a esta práctica.

Entendemos que los fundamentos del prototipado es filtrar posibles errores, depurar los diseños, tener un feedback directo con el cliente (reduciendo las malinterpretaciones) y, en definitiva, ahorrar costes en la fase del proyecto a la que se aplique.

En ese punto, todos planteamos nuestras dudas sobre la utilidad real de elaborar prototipos, la viabilidad de hacerlo con cierto tipo de clientes y para proyectos pequeños. La idea aportada por Aritz es que cada prototipo debe servir para una fase del proyecto determinada y debe adecuarse al cliente con el que se trabaja. Citamos a Eduardo Manchón:

"Un prototipo sólo vale la pena si se puede tirar a la basura".

Sobre eso, Mingo apunta que, a pesar de nuestras opiniones dudas sobre el uso de esta técnica, debe haber oportunidades para el uso de prototipos de alta calidad.

Comentamos que en el caso concreto de IT7 no utilizamos las técnicas de prototipado en el sentido estricto. Los principales motivos:

  • La mayoría de nuestros proyectos son para sitios web pequeños.
  • El origen de los encargos suele basarse en una propuesta de contenidos (y Arquitectura de la Información) que en normalmente contiene propuestas de navegación básicas y nos sirve de prototipo.
  • Nuestros clientes suelen tener una escasa capacidad de abstracción: es frecuente que cuando presentamos bocetos de diseño, reparen en las imágenes colocadas como ejemplo y en "ese extraño idioma" de los textos de prueba (el famoso Lorem ipsum). Imaginen cómo reaccionarían si les presentáramos prototipos de baja definición.

Nos paramos en la concepción del diseño como concepto global, el llamado diseño con mayúsculas, que agrupa todas las escalas del trabajo web, no sólo la estética.

Los prototipos no miden el tiempo

Enlanzando con el punto anterior, comentamos la idea de Javier Cañada de que en la experiencia de los usuarios importa el diseño de interacción; y que éste se diferencia del resto de diseños en que tiene una cuarta dimensión: el tiempo.

Los prototipos, sin embargo, casi nunca miden tiempos reales. Cuando se usan prototipos, la respuestas suelen ser inmediatas, no importa cuán compleja sea la hipotética consulta realizada, ni lo que tarde el servidor en procesarla, ni las dificultades que pueda tener el usuario en el contexto real de uso.

Prototipos reutilizables y modulares

Prototipo reutilizable.
También denominado como evolutionary prototyping; no se pierde el esfuerzo efectuado en la construcción del prototipo, pues sus partes o el conjunto pueden ser utilizados para construir el producto real.
Prototipo modular.
También conocido como prototipado incremental; se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.

En ambos casos la idea básica consiste en aprovechar el trabajo realizado en el prototipo para las fases posteriores. Casi todos vemos un planteamiento demasiado optimista y, bajo nuestra experiencia, no vemos rentable esta técnica para elaborar prototipos. Aritz comenta que a veces no se pierde el trabajo, un ejemplo es el desarrollo ágil que realiza el equipo de 37signals, ellos comentan que no trabajan con bocetos en papel y crean directamente los prototipos con HTML y CSS que se usan en la versión final del producto (Actualización: dos años después siguen defendiendo su postura). Claro que la mayoría de sus proyectos son desarrollos propios que no dependen de la opinión de terceros.

Prototipado para aplicaciones de escritorio

También se abordó las diferencias entre elaborar prototipos para aplicaciones de escritorio y para sitios web. De hecho, hablamos de la experiencia de usuario en términos más generales, no nos limitamos al prototipado. Nos planteamos que, en la práctica, es muy habitual que los usuarios aprendan a utilizar la interfaz con sus posibles defectos sin cuestionarla.

Es evidente que la importancia de los estándares en este campo (es decir, de los sistemas operativos más utilizados) es muy grande y el desarrollo intenta imitar su funcionamiento casi siempre. Además, Aritz -que es quien más experiencia tiene en proyectos en este tipo- comenta que Microsoft establece parámetros muy claros (The Microsoft Windows User Experience, 1999 o Windows XP Visual Guidelines, 2001) para el desarrollo de aplicaciones de escritorio. Apple también hace lo propio (Apple Aqua Human Interface Guidelines, 2002).

Baxley, Morville, Brown y otros ejemplos

José presentó algunos conceptos, relacionados con el prototipado y bastantes distintos a los que habíamos comentado hasta el momento: el "Modelo Universal de la Interfaz de Usuario" (PDF) propuesto por Bob Baxley y comentó el "panal" de la experiencia del usuario de Peter Morville.

Hablamos un poco de Dan Brown, que cuenta en Boxes and Arrows su experiencia de cómo llegó a la idea de diseñar prototipos de baja definición, así como de sus comentarios sobre la posibilidad de diseñar prototipos que coarten la creatividad de los diseñadores. Vimos algunos de los prototipos que empleaba y comentamos su sencillez, tirando a rudeza. También comentamos su esquema de representación de datos (PDF) en "wireframes".

Asimismo, comentamos otros ejemplos, como los de Nelson Rodríguez-Peña o los mencionados por Torres Burriel, especialmente el que trata del artículo de Andres Zapata sobre wireframes para aplicaciones de Internet enriquecidas (Rich Internet Aplications, RIA) que hacen uso de storyboards para definir lo que pasa en la aplicación. Curiosamente, esta técnica se había aplicado en IT7 en 2004 para un soporte multimedia.

Durante la exposición de José, nos entretuvimos hablando de la importancia y relevancia que cobraban ciertos artículos por los esquemas o imágenes que incluyen. Dos ejemplos sobre lo mencionado fueron los hexágonos de Morville de los que hablamos antes o la superposición de planos en "los elementos de la experiencia del usuario" (PDF) de Jesse James Garret. Al respecto, Mari Carmen Marcos apunta que Garrett habla de cinco capas que definen un sitio web al mismo tiempo como una interfaz de software y como un sistema hipertextual. De abajo a arriba:

  • Estrategia: necesidades del sitio y objetivos del usuario.
  • Alcance: especificaciones funcionales y requisitos de contenido.
  • Estructura: diseño de interacción y arquitectura de la información.
  • Esqueleto: diseño de la información, diseño de la interfaz y diseño de la navegación.
  • Superficie: diseño estético.

Entonces comentamos las obras de Edward Tufte sobre el "vocabulario visual" y la presentación gráfica de la información. Hablamos también de otros libros y autores de referencia: el propio Morville y varios de Don Norman.

Actualización del 22 de julio de 2006: para justificar los dos párrafos anteriores nos viene al pelo la reciente anotación de Javier Cañada en la que comenta la importancia del diseño de información con el ejemplo de Hans Rosling y Gapminder. También hay buenos ejemplos sobre el tema en Information aesthetics.

Cuestiones al margen del prototipado

Se comentó la expansión del uso de PowerPoint para presentaciones con gran carga visual (estética) y acabamos derivando en lo inadecuado que resultan las exposiciones y conferencias que se limitan sólo a leer o comentar lo proyectado sin aportar nada más. Citamos la anotación de Luis Villa sobre el @media 2006, en la que alabó a aquellos que en sus ponencias sólo usan las imágenes a modo de apoyo y se centran en contar con sus palabras lo que pretenden.

Enlazando con la exposición de Luis Villa, hablamos de las ideas planteadas sobre la colaboración: todos estamos de acuerdo en que la concepción de desarrollar proyectos en secreto es algo antiguo y muchas veces ineficaz; y que el avance en el desarrollo web (y en la sociedad de la información) sólo se conseguirá a través de la colaboración, de exponer claramente cuáles son las ideas y técnicas con las que se trabaja y debatirlas.

Casi al terminar, comentamos un par de cuestiones sobre las relaciones entre los equipos de desarrollo. Solemos ver con frecuencia empresas en las que todo está bien delimitado; cada sección se dedica a una parte del desarrollo, sin una visión global, o con la visión global de una o dos personas. Coincidimos en que, en la práctica, es difícil separar la arquitectura de la información, el resto de aspectos de contenido, el diseño y la programación, por lo que esa delimitación de tareas, normalmente, ocasiona pérdidas de la calidad del trabajo. En todo caso, volvemos a citar a Eduardo Manchón (se nota que lo tuvimos hace poco en Gran Canaria), quien cree que son necesarias las personas con una visión global del proyecto.

Guías Prácticas para Profesionales Web: Pruebas de usuarios en la Web

Esta vez abandonamos la presentación habitual de las Guías Prácticas para Profesionales Web y las integramos en este formato por dos razones: unificar la información y aprovechar las ventajas tecnológicas que ofrece el blog (búsquedas, comentarios, sindicación…). En esta ocasión haremos una introducción a las Pruebas de usuarios en la Web, espero que lo disfruten.

Introducción

No existen dogmas inamovibles en el campo del diseño Web. Dos desarrolladores que se enfrentan a un mismo problema pueden encontrar soluciones diferentes. De igual forma, dos consultores Web pueden tener opiniones distintas ante una misma cuestión. Entonces, ¿quién puede ofrecernos datos fiables de que nuestras páginas están funcionando correctamente? La respuesta es clara: los usuarios de nuestro sitio.

La mejor forma de conocer las opiniones de los usuarios de nuestras páginas es hablando directamente con ellos y realizando pruebas de usuarios (user testing).

¿Qué es una prueba de usuarios?

También llamado test de usuarios, es una medida empírica de la usabilidad de una herramienta, sitio Web o aplicación, tomada a partir de la observación sistemática de usuarios que realizan unas determinadas tareas. Estas pruebas nos permiten:

  • Comprobar la existencia de problemas de usabilidad.
  • Buscar posibles soluciones para los problemas que se detecten.
  • Obtener una medida concreta inicial de la usabilidad que nos permitirá comparar los resultados ante competidores, una modificación o rediseño, futuros desarrollos, etc.

La usabilidad

Por si a alguien no le suena a estas alturas la palabra usabilidad, me gustó la definición que hizo Javier Cañada: "la usabilidad es la cualidad de los objetos o sistemas interactivos que pueden ser usados con comodidad y satisfacción". También pueden ver una definición más completa de Juan Carlos García.

¿Cuándo hacer las pruebas?

La situación ideal es que, previamente a las pruebas de usuarios, nuestras páginas hayan pasado una evaluación heurística por expertos. Un profesional experimentado de la usabilidad puede detectar de forma rápida y eficaz muchos problemas de usabilidad de un sitio Web, sin tener que recurrir a una prueba de usuarios y evitando sus costes, pudiendo eliminar los errores graves y dejando a los usuarios a que nos ayuden a resolver problemas de usabilidad más sutiles, errores imprevistos, depurar el diseño, etc.

Las pruebas con usuarios pueden ser de gran utilidad en varias fases: durante las primeras etapas del desarrollo de un nuevo sitio, antes de un proceso de rediseño o como revisión periódica de un sitio ya publicado. Realmente sólo hay que tener en cuenta que cuando se hagan las pruebas debemos escuchar lo que los usuarios nos van a decir y ser consecuentes con sus opiniones. Si lo que queremos es simplemente oír lo maravillosas que son nuestras páginas es mejor que no malgastemos nuestro dinero y el tiempo de nuestros usuarios.

Planificación

Todo lo que necesitamos para comenzar a realizar las pruebas de usuarios es, obviamente, un usuario, un ordenador donde probar el sitio Web, papel y lápiz para tomar las anotaciones necesarias y a un consultor que se encargue de tutelar la experiencia.

Algunos consultores de usabilidad utilizan, además, otros recursos tecnológicos como videocámaras, cuartos de observación separados por cristales espejados por una cara (como los utilizados en las salas de reconocimiento policial), etc. Estos recursos no son estrictamente necesarios. Sólo hay que tener en cuenta que debemos prestar más atención a la conducta y opiniones de los usuarios que a si la cámara está o no funcionando.

¿Dónde realizar las pruebas?

Básicamente tenemos dos opciones, en nuestras oficinas o en el lugar habitual de nuestros usuarios. En el primer caso es más cómodo para nosotros y nos permite planificar mejor las pruebas, en el segundo, obtenemos una información adicional que hace más precisa y enriquecedora la experiencia: el entorno del usuario, es decir, el ordenador y monitor que realmente usa, si el ambiente es relajado o ruidoso…

¿Cuántos usuarios deben participar?

La mejor forma de realizar las pruebas es de uno en uno: un usuario con un consultor. No es necesario contar con muchos usuarios para que las pruebas sean efectivas. Al respecto, estudios realizados por Jakob Nielsen establecen que la mayoría (entre el 65 – 85%) de los problemas de usabilidad pueden detectarse con tan sólo 5 usuarios. En cualquier caso siempre podemos realizar una segunda prueba con más usuarios. Quince parece ser una cifra suficiente para detectar casi la totalidad de los posibles problemas de usabilidad.

Elegir al consultor

El consultor, también denominado como evaluador, entrevistador, moderador o facilitador en algunos manuales, es la persona que hará las pruebas con los usuarios, los observará, registrará los resultados y presentará un informe con las conclusiones finales. Lo lógico es contar con un consultor profesional para estos menesteres; sin embargo, en determinadas ocasiones, los consultores pueden ser una solución demasiado cara. Si no se tiene dinero para contratar a un consultor en usabilidad, nosotros mismos podemos intentarlo, siempre que se cumplan una serie de requisitos y cualidades.

Cualidades de un consultor

La más importante es que tiene que ser capaz de ser objetivo e imparcial, además de utilizar buenos métodos, tareas bien diseñadas, medidas significativas, etc.. Ninguna implicación con el desarrollo del sitio debe afectar a la neutralidad de las pruebas, es lo que Richard Saul Wurman, consultor y arquitecto de la información (creador, entre otras cosas, del término "arquitectura de la información") define como "la enfermedad de la familiaridad".

El test es básicamente observación y, si esta es honesta, puede hacerlo tanto el creador del sitio, como un consultor ajeno al proceso. Normalmente, las compañías de desarrollo Web contratan a un consultor de usabilidad, o equipo de usabilidad, externo para estas tareas. En este caso lo importante es que los profesionales que se contraten se impliquen con todo el equipo de desarrollo para evitar pérdidas en el traspaso de la información y para que, juntos, aprendan a crear una mejor experiencia de uso de su producto.

Otra cualidad a considerar es la experiencia y conocimientos. El consultor debe tener la experiencia y conocimientos necesarios para realizar las pruebas de forma sencilla y efectiva. Las pruebas con usuarios no forman parte de una ciencia exacta, pero esto no quiere decir que no se deba conocer y elaborar cuidadosamente la metodología, estrategias y la planificación. Hacer una prueba con usuarios tiene cierta complejidad y requiere el dominio de ciertos conocimientos teóricos y metodológicos que eviten conclusiones erróneas.

Por último, el consultor debe ser una persona tranquila, abierta, cordial, que inspire confianza y empatía hacia el usuario.

Los usuarios

Llega una de las partes clave: encontrar a los usuarios que van a participar en las pruebas. El primer paso a seguir consiste en conocer a la audiencia a la que se dirigen nuestras páginas. Normalmente, el público objetivo es definido en las primeras fases de la planificación del sitio Web. Una vez tenemos claro el abanico de usuarios, es el momento de buscar a los participantes.

¿Dónde encontrarlos?

Los participantes potenciales de las pruebas pueden encontrarse a través de listas de consumidores, organizaciones o asociaciones relacionadas con la temática de nuestro sitio, listas de discusión en la Red, en determinados eventos o conferencias, etc. Algunas empresas especializadas en el estudio de la usabilidad cuentan con diferentes grupos de usuarios (panelistas) que se pueden ajustar a nuestras necesidades, lo que nos puede ahorrar bastante tiempo, no dinero, en la búsqueda.

Condiciones

Los participantes han de ser completamente honestos y sinceros en las pruebas. Es aconsejable que tengan cierta experiencia y se desenvuelvan con soltura en el uso del Web.

¿Pagar o no a los participantes?

No es, ni mucho menos, obligatorio, pero, dado el caso, este hecho podría ayudar a acelerar el proceso de selección de los participantes, si tenemos que establecer una cuantía, parece ser que entre 20 a 50 euros por persona son cifras que funcionan muy bien para captar la atención del público objetivo. El incentivo no tiene por qué ser necesariamente económico, también puede servir, por ejemplo, ciertas ventajas o descuentos en los servicios que se pretenden evaluar, en empresas asociadas, etc.

Debemos dejar claro a los participantes que se les compensa por su tiempo y su honestidad y no para que digan sólo cosas favorables de las páginas que evalúan.

Las preguntas

Durante una prueba de usuario, el objetivo principal debe ser la observación pasiva, pero antes de comenzar con la prueba propiamente dicha debemos conocer algunos aspectos básicos sobre nuestros participantes. Para ello no necesitamos realizar un cuestionario exhaustivo con toda la información sobre sus gustos y hábitos, unas pocas cuestiones servirán, por ejemplo: nombre del usuario y nivel de experiencia en la Web.

En este punto, es importante dejar claro qué es lo que se espera del participante y cuáles son las "reglas del juego". Se debe intentar explicar que estamos interesados en descubrir qué opinan sobre el sitio Web que vamos a analizar, tanto lo bueno como lo malo. La prueba no es un concurso, así que no hay respuestas erróneas. Deben decir en voz alta todo lo que piensen, vean o experimenten con el sitio mientras lo están usando.

Para obtener medidas fiables, debemos pedir a los usuarios que completen diferentes tareas que simulen su comportamiento real, por ejemplo, buscar una determinada información, comprar un determinado producto, comparar información, etc.

Una vez finalizada la prueba (unos 30 minutos suele ser suficiente) podríamos preguntarles sobre aspectos más generales, como la opinión general del sitio, la valoración sobre la empresa (imagen de marca)…

Analizar los resultados

Después de realizar las pruebas, se deberán poner en orden las observaciones tomadas. Lo mejor es hacerlo cuanto antes; cuanto más se tarde en pasar a limpio nuestras apreciaciones más probable será que olvidemos detalles no escritos sobre las pruebas o que se malinterpreten ciertas anotaciones.

¿Qué se busca en los resultados?

Recordemos que las pruebas de usuarios no son una ciencia exacta. Las mejores pistas se encontrarán en los patrones de conducta, es decir, en aquellas observaciones y comentarios que se han repetido en los diferentes usuarios. Así pues, no deberemos dar la misma importancia a un comentario aislado sobre nuestro sistema de navegación que a si la mayoría de usuarios han tenido dificultades en ese aspecto, lo que indicaría claramente que nuestra navegación está mal planteada.

Será de gran utilidad registar nuestros resultados en alguna base de datos, esto nos permitirá ordenarlos y filtrarlos por determinados factores de manera más cómoda, ágil y eficiente.

Para finalizar se preparará un informe que resuma las áreas problemáticas de nuestro sitio. Los descubrimientos deberán ser expuestos y discutidos con todo el equipo implicado en el desarrollo del sitio Web para buscar las soluciones pertinentes.

Algo más

Coincidiendo con las fechas en la que preparaba este artículo, Nelson Rodríguez, realizó unas anotaciones sobre la evaluación de la usabilidad en las que definía el laboratorio portátil y una simplificación del mismo, sin duda, unos buenos complementos a esta lectura.

Actualización del 9 de febrero de 2006: se han incluido una serie de comentarios realizados por Humberto Matas. Gracias Humberto.

Actualización del 7 de julio de 2008: Preparing for User Research Interviews: Seven Things to Remember.

Actualización del 28 de julio de 2008: Silverback, una gran aplicación de la gente de Clearleft; simple, barata y efectiva, desarrollada para hacer test de usabilidad de guerrilla sin complicaciones en Mac.

Actualización del 9 de octubre de 2008: Consejos para presentar los resultados de un test de usabilidad, por Iván Marnet (DeInterfaz).