Will Web For Food

¿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

Iniciarse en una profesión siempre es difícil.
En la mayoría de las profesiones hay una formación reglada que más o menos unifica el conocimiento de los integrantes. Pero el diseño de interacción carece de esta formación reglada*. Así que si estás iniciándote, o hace poco que ejerces y te sientes un poco perdido, no desesperes. No estás solo.
Si lo que quieres hacer es conceptualizar y diseñar productos digitales,  productos y servicios Web en su mayoría, bienvenido: estás en el camino adecuado.
Ahi van algunas ideas que tal vez te sean de utilidad para lograrlo.

#1 Ábrete un blog. Mejor. Ábrete un blog y escribe para ti, tómatelo como tus apuntes, lo que aprendes, lo que opinas, lo que crees que puedes aportar al resto de la comunidad. Para mí un blog es una de las herramientas más útiles para aprender, además te permite entrar en contacto con gente con intereses o inquietudes similares.

#2 Libros. Hay muchas lecturas básicas de la profesión, pero no todas te habilitan para ejercer. Mis recomendaciones son:
> Diseño de interfaces de Usuario de Shneiderman y Plaisant. Está disponible en castellano y es un muy buen punto de inicio para ejercer profesionalmente. Es un libro grande. Piensa en él como el libro de clase de IxD.
¿Más referencias?
> Interaction Design, de Preece, Rogers y Sharp.
> Human-Computer Interaction. 3era edición. Dix, Finlay Abowd y Bealey.
Ambos en inglés. Muy recomendables, te darán una buena visión de los procesos dentro de un proyecto, cómo hacer bien las cosas y de qué manera.
Al iniciarse en cualquier campo de conocimiento uno de los problemas más frecuentes que se tiene es el vocabulario especializado.  Para afianzar conceptos te puede ser de utilidad:
> Principios universales del diseño de Lidwell Holden y Butler.

#3 Cacharrea. Hazte con una copia del software de moda de prototipar y dale vueltas hasta que le hagas saltar chispas.
Lo malo de los wireframes es que dentro de la profesión  no solemos mostrarlos abiertamente, pero si buscas un poco encontrarás modelos de documentación.
¿Dónde mirar? En wireframes.linowski o Ilovewireframes o busca en flickr.

#4 Ingeniería inversa.  Toma un ejemplo de alguna web de éxito o algún catalogo de patrones. Analizalos y diagramatiza wireframes y sitemaps.
¿Dónde encontrar ejemplos para practica? Pattern tap y Welie

#5 Pide ayuda. Hay listas, asociaciones, foros, correos. Ante un problema o duda pide ayuda.
¿Dónde pido ayuda? En Cadius, en Domestika en Uxchange  …

Y animo, la profesión necesita de ti.

* Con matices. Haberla hayla,  pero no es sencillo ni barato acceder a ella.

I have thought about the main skills that would make a good IxD professional.

And the first thing I found is that there are several types of skills.

You need a series of basic skills to begin in this business.

For me, the main skill is Imagination. I believe than people without imagination never will get a “wow factor”, without imagination you ever can do innovation products or new interaction interfaces.

Social Research skills are other useful skill for you professional life. You need to understand data and methodology to take part in a user research or user centered design process.

Visual Communication skill is good for you to share, show, and explain your ideas.

Secondary skills are the type of skills that make of you a good candidate for different responsibilities inside a design team.

Some good secondary skills are:

• Curiosity to learn and research.
• Statistic analysis to know what to do with data.
• Kindness to make life easier for the rest of the team.
• Stay cool in emergencies.
• Negotiation skills for a project’s surprise.
• Passion for your job.
• Innocence, you must believe that you can really make the world a better place with your job.

Recientemente se ha reactivado el debate con un par de post (para referencias ver final) que ponen el dedo en la llaga sobre el despropósito que es tomar la etiqueta del “diseño centrado en el usuario” sin interiorizar la filosofía o el proceso.

Me parece interesante y correcto para la profesión señalarlo, pero hecho en falta que no se erradiquen los prejuicios que supone no investigar con usuarios.
Para una acción asepsia debemos enfrentarnos a las siguientes cuestiones.

Una de las posturas que más daño nos hace como profesión, es en mi opinión, la lógica perversa de que la mayoría de nuestras competencias son “de sentido común”.
Si fuera así una reunión de proyecto se reduciría a la evaluación del índice de sentido común de los asistentes, dejarían dentro de la sala a los mejor dotados y el proyecto iría como la seda. Pero no es así. Necesitamos de la investigación para poder tomar decisiones de diseño, de otra forma hacemos “bonitas fantasías” pero no es muy serio.

También tenemos un grabe problema de discurso, no somos el abogado del usuario. Lo siento chicos, pero estamos dentro de un proceso productivo cuya finalidad ultima es ganar dinero. Es crudo, pero es así. Ellos no son malos y nosotros buenos. Pero no desesperemos, tratar bien al usuario de nuestro producto hace que sea más fácil lograr el objetivo empresarial.
Pero ocurre que “el usuario” es la bala de plata, es el súper ataque pokemon contra la que no se puede hacer nada, ante un “eso no lo va a entender el usuario” en cualquiera de sus versiones (esto no es usable o no es accesible) se suele recular. Como suele funcionar, nos tienta usarlo (para el bien), pero nos puede llevar a “debates religiosos”, esto se evita con datos que hacen que nuestros argumentos sean más sólidos. Para tener datos hace falta investigar.

Por ultimo, las disciplinas como pegatinas. Experiencia de usuario, Ux, Usabilidad, Diseño de interacción o Arquitectura de la información, son conceptos que dentro de las profesiones relacionadas con el desarrollo web tienen ciclos y responden a modas, esto se nota en dos cosas, los curriculums y las ofertas de empleo.
El que no estén claramente definidas nos lleva a situaciones de “busco: astronauta-bailarina-contable”
La oferta y la demanda tienden a adecuarse, y en este proceso, el astronauta puede llegar a suponer que solo necesita unas mayas y una calculadora y ya esta… la quinta posición no puede ser tan complicada y cuadrar asientos es que de cero. Total yo hago volar naves espaciales. Pues no.
No tengo nada en contra de la reorientación profesional, los perfiles multidisciplínales son los más deseables en una organización, pero si estoy en contra de que eso signifique cebar de siglas un Cv porque si.

Esta situación nos lleva a degradar el tejido profesional, que hace que los sueldos sean más bajos, haya menos respeto por nuestro profesión y que se incremente la creencia de que la practica es por sentido común. Esto nos lleva a  más prototipado extremo y menos investigación, se valora menos la disciplina, se invierte menos. Y la investigación no es cara.

Referencias:

• En tentandote.
• En torresburriel.

Some people refer to human-centered product and service design as experience design, but I would agree that this term is presumptuous; we can design every aspect of the environment to encourage an optimal experience, but since each person brings her own attitudes, behaviours and perceptions to any situation, no designer can determine exactly what experience someone has.

For this reason, I prefer to product and service design, or simply product design.

In Designing for the digital age.