Will Web For Food

Desambiguazión: Este post no habla de sitemap en XML para posicionamiento en buscadores.

Los Sitemaps son diagramas que representan los contenidos del site.
Vale, parece sencillo, este es nuestro Sitemap, un diagrama que dice aquí van “los servicios”, aquí “quieres somos”, aquí el “blog”…
Pero esta idea se complica cuando se incluye la variable “navegación”.  El Sitemap puede dar una idea de cómo se llega a un sitio, cual es la relación entre las distintas pantallas (¿páginas del site? ¿contenidos?). Pero la navegación se debe resolver en otro documento que se llama Task Flow. Llevar a cabo un Task Flow nos obliga a identificar objetivos de los usuarios (Investigación) y que diseñemos para lo probable y no para todo lo posible.
Volviendo a los Sitemap. Para iniciar el Sitemap hay que tomar una decisión. Y esa decisión responde a ¿Cómo se va a enfrentar el equipo al proyecto?.
Podemos elegir entre a un nivel muy alto de detalle, donde se van a modelar todas las pantallas y todas las interacciones y microinteraciones, vamos a llamar a esto Enfoque A.  O un enfoque modular, donde vamos a descomponer los componentes de las pantallas en módulos reutilizables. Vamos a llamar a este otro Enfoque B.

Estas consideraciones pueden influir mucho sobre como se va a desarrollar el proyecto, y se suelen dejar al gusto del “prototipador” que las puede tomar de una forma inconsciente. (Además de que no le compete a él tomar estas decisiones).

El enfoque A consume mucho más tiempo en prototipar, y se suele emplear en proyectos pequeños. Tiene como punto negativo que hace que lo importante se diluya entre la cantidad y genera la sensación de documentación al peso.

El enfoque B es mucho más participativo y esta más orientado a equipos de desarrollo,  se suele emplear en proyectos grandes donde hay varias personas implicadas en el diseño de los wireframes. Como punto negativo tiene un nivel de abstracción mucho más elevado que dificulta su consumo por el cliente, pero permite una ejecución mucho más ágil.

Algo tan asumible como en principio es un Sitemap puede determinar como se va desarrollar el proyecto.

Para leer más sobre Sitemap (y entregables)

• Information Architecture (2nd Ed.) de Rosenfeld and Morville.
• Communication design de Brown.
• A Project guide to UX design de Unger y Chandler.
• Modular web design de Curtis.

User research is often neglected in web project, sitting pretty somewhere between usability and market research. But it can be invaluable tool in defining and structuring a site.

In .Net Magazine

¿Qué son?

Test remotos de usabilidad o Remote Research (RR) es una forma de aplicar test usabilidad* con usuarios sin que el evaluador se encuentre físicamente en el mismo espacio que el participante.
Los test de usabilidad se pueden agrupar en dos grandes grupos en función de la localización del participante y evaluador.
Si el participante y el evaluador se encuentran en el mismo lugar, los test son presenciales o de laboratorio.

En cambio si el participante y el evaluador se encuentran en lugares diferentes son test  remotos o remote reseach.
Los RR pueden así mismo agruparse en distintas categorías**, por ejemplo en función de la participación del moderador podemos tener test moderados y test automatizados por una herramienta. Además, los moderados son de corte más cualitativo, mientras que los automatizados son más cuantitativos.

En función de la captación del participante y la forma de hacerlo podemos hablar de captación en vivo, mediante un layer, captación por perfil y mediante agencia de captación, contactos personales  o paneles de investigación.

E incluso en función de la tecnología empleada en las herramientas de captación remota podríamos agrupar en función de las que usan JavaScript y las que usan tecnologías Html.

Ventajas de RR vs Laboratorio

La ventaja principal entre los RR y lo test de laboratorio son los costes, entorno a un 42% más barato mediante RR. Este ahorro viene de reducir el tiempo de ejecución y el tiempo de captación de los participantes.
Además los RR poseen una mayor variedad en la procedencia de las muestras, ya que los RR son virtualmente aplicables a cualquier persona del mundo con una conexión.
Algunos caso de estudio otorgan unos valores de éxito mayores a los RR. Si se realiza el test en Laboratorio y en Remoto suelen detectarse entorno a 15 resistencias al uso con el RR que pasan desapercibidas en el laboratorio. Pero estas tasa de éxito no son valores concluyentes, así que no vincules tu elección a ello.

Inconvenientes de RR vs Laboratorio

Para mí el principal inconveniente está en la falta de especialización en las herramientas y en la técnica. Los RR aun no forman parte del arsenal metodológico de los profesionales, aunque muchas de estas herramientas son gratuitas.

Si estas interesado en potenciar tus conocimientos en RR y probar alguna herramienta consulta el fantástico el documento de Liz Bacon en referencias.

Referencias:

* Diga Test de Usabilidad, NO test de usuarios
** Otras categorías sobre las herramientas de investigación en Remote Usability

• Pros y contras del RR en Jhonny Holland
• Evaluación de herramientas. Usabilia VS Loop,   Quick and dirty, y el gdocs de Liz Bacon
• Alert box sobre RR
• Libro: Remote Research de El Presidente y Tony Tulathimutte y A practical guide to usability testing de Dumas y Residh.

La literatura sobre wireframing es muy limitada, y la mayoría de las referencias suelen ser blog, lo que atomiza este conocimiento, que ademas se suele adquirir mediante la experiencia.

En la mayoría de los casos estas referencias se suele centrar en el uso de un determinado software, más que en ciertos principios básicos de la técnica.

Se acepta dentro de las profesiones relacionadas con el diseño de productos digitales en mayor o menor medida que wireframe* y prototipo son sinónimos. De forma absoluta esto no es correcto. Wireframe toma su nombre de las estructuras alambicas que se emplean en el diseño industrial y mecánico. Mientras que el prototipo es una versión alfa de un producto que presenta múltiples finalidades, como es analizar costes antes de su producción, servir para testeó y evaluación o la captación comercial y financiación.

Cuando yo me tengo que enfrentar a un proyecto en el cual debo realizar wireframes sigo una serie de acciones que creo que me simplifican la vida.

Mis pasos durante el wireframing:

#1. Papel. Empezar realizando la composición del producto en papel. Esta idea supongo que no es nueva para nadie, pero creo que es bueno decirlo porque tengo la sensación de que hay prejuicios sobre hacerlo porque se percibe como una actividad no-seria el dedicar una mañana a dibujar interfaces.

¿Qué gano haciendo esto? En primer lugar tomar conciencia de los posibles enfoques y necesidades de la solución. Te permite tener en mente un foto a gran nivel de lo que quieres hacer. De esta forma es más sencillo que elijas la herramienta con la que vas a realizar el entregable y como hacerlo y que preveas el tiempo y esfuerzo que implica.

#2. Unifica las pantallas. Una vez que sabes lo que quieres hacer, una forma cómoda de trabajar es creándote componentes y re-utilizándolos a lo largo de todo el documento. Esta re-utilización puede ser creándote una página maestra o varias, en función de tus necesidades, o creándote galerías de componentes.

Por página maestra me refiero a un fondo de Visio, un lienzo de OmniGraffle o un master de Axure que puedas necesitar en múltiples paginas de tu documento.

Existen muchas galerías de componentes. Lo normal es que partas de alguna popular, la adaptes a tus necesidades y se acabe convirtiendo en tu galería.

¿Qué ganas haciendo esto? Al usar paginas maestras evitas que los elementos constantes te “bailen” en el PDF, que los cambios estructurales sean mucho más ágiles, por ejemplo cambiar un disclaimer en el pie en un documento de 40 páginas puede ser un poco pesado si hay que hacerlo 40 veces.

#3. Poner titulo al documento nada más empezar. Y configurar los settings de tu programa con auto-salvado cada 15 minutos. A veces una mañana de trabajo se pierde de forma accidental y resulta muy frustrarte.

¿Qué ganas haciendo esto? Paz mental, hay veces que tiraría el ordenador por la ventana, pero saber que en el peor de los casos pierdo 15 minutos me ayuda a mantener la calma. La contrapartida a la seguridad es la libertad, y se hace pesado en según que programa las pausas para que se salve, pero eso es un tema muy personal.

#4. Guárdate un día para que brille. Por definición un trabajo te lleva lo que crees que vas a tardar, más lo que no sabes que vas a tardar por lo que se pone un tiempo de margen. El diablo esta en los detalles y los detalles consumen mucho tiempo.

No se si estas tácticas son comunes, supongo que cada maestrillo tiene su librillo. Seguramente parte de esta situación se deba a la ausencia de una metodología proyectual. Espero que estos pasos sean de utilidad para alguien.

*Wireframe: A wireframe is a visual illustration of one Web page. It is meant to show all of the items that are included on a particular page, without defining the look and feel (or graphic design). It’s simply meant to illustrate the features, content and links that need to appear on a page so that your design team can mock up a visual interface and your programmers understand the page features and how they are supposed to work.

En usability.gov

El jueves 28 de octubre a las 19:30 en el centro de postgrados de la UAX de Madrid se celebrará la  conferencia “Metodologías de Investigación de Usuarios”.
Esta conferencia esta organizada por UPA Madrid.

La asistencia es gratuita pero requiere inscripción.

Toda la información y el registro lo puedes encontrar en http://tiny.cc/upamadrid

Una buena ocasión para ampliar tus conocimientos sobre el user research y su practica.

Hastag: #upamad

… the visions of the users are based only on the designers’ own experiences. The danger with stereotypes is that they are not real people and ageing neighbours or relatives form a too narrow interpretation of the heterogeneous group of people. When working in teams, the design team must form a solid common understanding of these users.

One of the roles of user studies done prior to concept design is to probe for phenomena and opportunities. The aims include getting designers to learn to understand the people they are designing for, their motivations and actions and the context of these actions.

In the Proceedings of Include Conference on Designing pleasurable products and interfaces. Helen Hamlyn Research Cente