Will Web For Food

Hola. Hoy estamos de cumple, hace 5 años que abrimos este blog. La verdad es que lo único que se me ocurre decir es GRACIAS a toda la gente que me ha enseñado, aguantado, ayudado y leído a lo largo de todo este tiempo y que espero que lo siga haciendo.

Me gustaría tener una reflexión profunda para compartir en este momento, pero la verdad es que no la tengo; a lo más que llego es a una serie de impresiones para lo que creo que está pasando y espero que sea el futuro de la profesión.

• User Experience como disciplina contenedora de múltiples conocimientos. Creo que el User Experience será la próxima gran etiqueta (si es que no lo es ya), pero tiene que ser una etiqueta con sustrato, no como reciclaje de arquitectos de los 80  y consultores de los 90. El UX es territorio natural donde deben confluir el  Service Design, la Analítica, el User Research, el Design Management y el Diseño y Desarrollo de Productos Digitales, y esta convergencia nos obligará a incrementar nuestro arsenal de técnicas y conocimientos a todos.

• Más datos y open source. Datos por todas partes. Datos que hay que procesar, con herramientas para procesarlos y para presentarlos. Aquí creo que cobrarán peso propuestas  como R Project  o Processing. También los análisis estadísticos y las infografías.

• Remote research como gran paradigma de la investigación. Espero que el RR sea la solución a históricos problemas de la investigación con usuarios en los proyectos, ya que reduce costes, agiliza los tiempos e internacionaliza los resultados.

• Equipos in-house con un mayor seguimiento del proyecto, estableciendo planes de explotación que implica en los objetivos de negocio a todas las disciplinas. Llevándonos a una mayor especialización y a nuevas tipologías de proyectos.

Esto es lo que yo creo que está pasando. Si estás buscando cosas nuevas que aprender quizás te sirva.

Me interesan tus impresiones sobre lo que ocurre y a dónde va la profesión. Compártelas y a cambio te daré un pedazo de tarta, que estoy de cumpleaños.

User-centered design, or human-centered design, places the end use at the centre of design process. User-centered design is driven by research. Research during the developmental process provides valuable insight into the needs, behaviours, and expectations of the target audience.

in The information Design Handbook

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