Clase 07 Wireflows _ Treetest (Guión de Clase)

Vista previa del material en texto

Clase 07. Wireflows & Tree Test
Wireflows
¿Por que wireflows?
Nos ayudan a pensar en términos de flujos, no de pantallas. Con wireflows, no trabajamos pantalla por pantalla, sino con todo el flujo. Por ejemplo, imagina un flujo de reserva de entradas en el que el objetivo del usuario es reservar una entrada; pensamos en el flujo completo e intentamos identificar la mejor manera para que nuestro usuario complete la acción.
Los Wireflows son útiles en proyectos con interacciones complejas y una pequeña cantidad de páginas únicas o secciones de sitios web que contienen muchas interacciones. Sin embargo, no son tan útiles para sitios web o aplicaciones estáticas donde al hacer clic o tocar un botón o enlace se navegará a otra página estática. Dado que habrá interacciones mínimas para mapear, los wireframes son más adecuados para estos casos.
Los diagramas de flujo son una herramienta para documentar de manera exhaustiva los flujos de trabajo complejos y las interacciones con múltiples pasos o rutas, pero normalmente dejan fuera el contexto de las interacciones y su impacto sobre los usuarios.
El caso de uso clásico de wireflows es documentar el proceso de un usuario que trabaja en una tarea común en el producto (por ejemplo, "enviar un mensaje directo a alguien en su red" en una aplicación de redes sociales). En cada paso del flujo de trabajo, una simple maqueta de pantalla de estructura alámbrica o de alta fidelidad muestra la pantalla disponible para los usuarios.
Cuando se utilizan en el momento adecuado en proyectos, ambos pueden incrementar la velocidad de las iteraciones y mejorar la comunicación en todo el equipo de producto. A pesar de que se utilizan con mayor frecuencia para aplicaciones móviles, los wireflows también son útiles para documentar flujos de trabajo complejos en aplicaciones de escritorio y aplicaciones web. Dado que mostrar una estructura alámbrica de escritorio de pantalla completa para cada paso de un proceso puede desperdiciar mucho espacio si la mayor parte del diseño de la pantalla permanece sin cambios en cada paso, mostrando solo la parte de la pantalla que cambia (como un cuadro de diálogo, modal, filtros o facetas) en cada paso puede ser suficiente para documentar partes relevantes y cambiantes de la interfaz, sin dejar de proporcionar suficiente contexto.
Niveles de desarrollo de los flujos
Objetivos de los usuarios
Es un buen comienzo para plantear los flujos en el recorrido de los usuarios. Nos ayuda a no perder el foco.
Flujo de Tareas - Task Flow
El Task Flow (diagrama de tareas) se enfoca en las tareas que tiene que realizar el usuario en cada paso para llegar a un objetivo. Se centra en cómo los usuarios viajan a través de la app o web mientras realizan una tarea específica. Por lo general, sólo muestran una ruta y no incluyen múltiples ramas o rutas como lo haría un flujo de usuario tradicional. Cuando se utilizan flujos de tareas, se supone que todos los usuarios compartirán un punto de partida común y no tendrán variabilidad en la forma en que se lleva a cabo la tarea.
Se debe tener en cuenta:
1. Entrada: por donde comienza la tarea.
2. Acciones: lo que debe seleccionar, tocar, elegir el usuario.
3. Éxito: la acción con la que se da por finalizada la tarea.
Flujo de Pantallas - Wireflow
Combinación de wireframes con el formato Flow Chart para representar las interacciones del usuario. Utilizan el diseño de pantallas individuales como elementos dentro del diagrama. Los wireframes por sí mismos ayudan a transmitir el diseño y el diseño en cada página individual, pero carecen de la capacidad de comunicar el flujo de página a página de interfaces muy dinámicas. 
Flujo de usuarios - User Flow
Nos ayudan a comprender mejor los pasos que realiza un usuario a través de un servicio, aplicación o sitio web completo. Se centran en la forma en que su público objetivo interactúa con el producto. Enfatizan que todos los usuarios pueden no realizar las mismas tareas y pueden viajar en diferentes caminos. Combina el flowchart, wireflow.
Algunas preguntas que debemos hacernos:
· ¿Qué sucede cuando las cosas no siguen el ' camino feliz '?
· ¿Qué lógica o caso conduce a un camino alternativo?
· ¿Se están moviendo datos ? (¿Y lo estoy usando accidentalmente para perseguir a mis usuarios por Internet con anuncios)?
· ¿Algún cambio de estado en sus interfaces? ¿Qué los provocó?
Anatomia
Veamos cada uno de ellos:
1. Punto de Entrada: Los puntos de entrada son los medios por los que un usuario accede al producto inicialmente. Los sitios web pueden tener muchos puntos de entrada, mientras que las aplicaciones a menudo tienen puntos de entrada limitados y distintos. Los sitios web suelen ser visitados mediante una búsqueda en Google o haciendo clic en anuncios de productos e hipervínculos compartidos. Las aplicaciones, por otro lado, se ingresan comúnmente desde la tienda de aplicaciones o la versión descargada en el teléfono de un usuario.
2. Pasos para completar la tarea: Recuerda mantenerlo simple, asegurándote de que cada paso sea vital para la tarea.
3. La interacción final: La interacción final es la pantalla final que verá el usuario cuando realice la tarea deseada. ¿Qué pantalla aparece en último lugar para informarles que la tarea está completa? Un ejemplo de una interacción final para comprar un artículo podría ser una pantalla de confirmación para informarle que su pedido ha sido recibido. Otro ejemplo de una interacción final es cuando se completa el registro de una cuenta. ¿Es mejor que tu producto termine con acceso inmediato a la página de inicio, o la página de inicio de sesión sería un mejor último paso?
¿Cómo pasar de un flujo de tareas a un flujo de usuarios y flujo de pantallas?
Los pasos a seguir son:
1. Wireframes: Genera tus wireframes en el programa de prototipado que estés trabajando figma o adobe xd. Te recomiendo que trabajes en una página nueva bajo el nombre “wireflows”.
2. Definir puntos calientes. Conéctese para crear diagramas de flujo de usuarios: El punto caliente es el elemento que iniciará la interacción de la pantalla. Es importante que las flechas indiquen claramente los "puntos calientes" (u objetivos) en los que se puede hacer clic y que conducen al siguiente paso del flujo, para reducir la ambigüedad en el flujo.
3. Plugins en Figma y Adobe XD: Para generar las relaciones usaremos autoflow (plugins de Figma y Adobe XD) para relacionar las pantallas. 
4. Caminos alternativos y escenarios: Piense en posibles caminos alternativos o atajos para que el usuario logre su objetivo (el destino final siempre debe ser la pantalla final), y comience a diseñar conexiones y pantallas para estos caminos. Piense en escenarios que podrían ocurrir durante el viaje (errores, internet desconectado, campos vacíos) y diseñe lo que sucederá en estos casos.
5. Estilos de caja y conectores: Para generar los wireflow deberemos usar algunas de las formas del flowchart (diagrama de flujo). Se utiliza una flecha para indicar el componente específico de la interfaz de usuario en el que el usuario realiza una acción (como tocar un botón, hacer clic en un enlace, etc.) y apunta a otra imagen de estructura alámbrica de lo que sucede como resultado de la interacción. El segundo "nodo" de esa interacción no necesita ser una página o pantalla separada; más bien, puede mostrar la misma página con el resultado de esa interacción, como el contenido que ha cambiado o los comentarios que muestra la interfaz como resultado de la interacción (por ejemplo, una ventana emergente de confirmación, un cambio de color o un mensaje de error). Repasemos algunas de ellas:
a. Rombo: El rombo simboliza las decisiones. Define, con flechas, dos caminos posibles. Es una decisión binaria (sí o no / a o b)
b. Error: El círculo se relaciona íntegramente con la caja “decisión” la misma muestra la posible falla o error. Flechas y Anotaciones: En el caso de que incorporamos los flujos que no son del “camino feliz” podemos usar conectores que nos ayuden a entender visualmente que estápasando. Puedes usar diferentes iconos que representan y clarifican que es lo que sucederá en el flujo de los usuarios. Sirven para marcar cuál será la acción que une a cada frase del wireflow. Para las anotaciones usaremos un recuadro donde colocaremos el nombre de la acción que se debe realizar.
Tree Test
Nos ayuda en la validación de una estructura de contenidos dentro de un producto digital. Evalúa una estructura jerárquica de categorías haciendo que los usuarios encuentren las ubicaciones en el árbol donde la tarea puede completarse. El Tree Test va un paso más allá ya que nos permite validar dos conceptos claves de un proyecto web: La estructura de clasificación de contenidos de un sitio web. Los rótulos que determinan a través de qué enlaces se localiza un contenido determinado. Se encarga de evaluar la categorización jerárquica de un árbol de contenidos, haciendo que los usuarios encuentren categorías específicas dentro de él donde determinadas tareas deben ser completadas. 
Permite validar, en etapa temprana, las hipótesis de organización y jerarquías que definiste para el proyecto. Este test de árbol ahorra tiempo y dinero porque sometes las ideas de jerarquización e indización que tienes con usuarios representativos y permite sostener un buen ejercicio de taxonomía que profundizamos con el Card Sorting y que termina expresado en el Mapa de Navegación, expresión final de la Arquitectura de la Información.
Para realizar una prueba de árbol (tree test), no es necesario esbozar ningún wireframe ni escribir ningún contenido. Solo necesita preparar dos cosas: el árbol o menú jerárquico de contenidos y las tareas o instrucciones que explican a los usuarios del estudio lo que deben intentar encontrar.
Simplificando con un ejemplo, en un tree test se le ofrece una narrativa al usuario objeto del test, donde debe encontrar algo en un árbol de contenidos. Ese usuario tendrá que ir navegando por esa jerarquía hasta que encuentre lo que se le pide y haga clic en un botón que finalice la tarea. La tarea puede completarse correctamente, parcialmente correcta o incorrectamente, dependiendo de si el usuario la ha acabado satisfactoriamente según lo esperado, con dudas/problemas durante el proceso o ha fallado/no la ha completado.
Nos ayuda a:
· Evaluar una jerarquía de contenidos utilizando tareas similares a una prueba de usabilidad.
· Explorar y ajustar las categorías y jerarquías mucho antes de diseñar la página o las pantallas.
· Obtener información de usuarios de forma objetiva, ya que aporta datos concretos, no susceptibles de ser interpretados.
· Comprobar la eficacia de un árbol de contenidos existente. A través de la serie de tareas que realiza el usuario se puede ver cómo se comporta el árbol. Es decir, en qué medida esa estructura de contenidos es capaz de guiar a un usuario para localizar un determinado contenido que se le haya solicitado.
· Validar la construcción de un árbol de contenidos, ya sea en el proceso de creación o para comprobar la validez de indicaciones de terceros. Cuando por ejemplo por parte de la dirección o, simplemente, por el capricho de algún elemento de poder se requiere incorporar cierta estructura o cierta forma de organizar los contenidos, el tree test es una excelente herramienta para aportar datos objetivos para validar (o para descartar) una propuesta de navegación determinada.
Encontrabilidad
Es la capacidad de encontrar un contenido determinado en un sitio web. La finalidad de un árbol de contenido es el de hacer que un usuario pueda acceder a un determinado contenido sin dificultad. Algunos proyectos presentan una arquitectura web pensada desde una perspectiva puramente SEO en la que se busca posicionar determinadas categorías y no se piensa en el usuario, en sus flujos de navegación o en la manera que tiene de categorizar los productos o servicios.
Métricas
Las métricas que medimos en un Tree Test son:
1. Eficiencia: velocidad de consecución de la tarea.
2. Eficacia: el número de errores que se producen en su realización.
3. Satisfacción: el grado de emociones por parte del usuario.
¿Cómo hacerlo?
1. Categorizar: La forma es plasmar la categorización sobre un papel (donde es fácil corregir y añadir cosas) y después pasarla a un hoja de cálculo (que es lo que luego se inserta directamente en la mayoría de herramientas de software que permiten ejecutar un tree test). Es conveniente empezar por las categorías superiores en la primera columna, luego las subcategorías en la segunda columna y así sucesivamente, intentando que no haya más de cuatro columnas o niveles de profundidad.
2. Treejack - Optimal Workshop: Treejack es una herramienta disponible en Optimal Workshop que nos permitirá generar la actividad para poder hacer con los usuarios. Lo primero que deberás hacer es importar tus categorías y jerarquías de contenidos o generar uno nuevo tal como muestra la imagen de la izquierda.
3. Definir las tareas: La definición de las tareas son la parte más importante del texto. Estas tareas deben estar enfocadas en validar si los usuarios acceden con facilidad a la información que necesitamos. El texto de las tareas no debe ofrecer información ni términos exactos sobre dónde se encuentra la categoría en cuestión. Es decir, no debe ser un ejercicio de búsqueda literal, se le pueden dar pistas y que el usuario elija donde lo encuentra. Para cada tarea que escriba, también debe definir las respuestas correctas, correspondientes a dónde se encuentra realmente la información dentro del árbol. Esta información permite que la herramienta de prueba calcule automáticamente las tasas de éxito de cada tarea. Las tareas deberían comprender:
a. Áreas claves del negocio y las tareas del usuario: es decir, tanto las áreas que sean claves ahora como aquellas que queremos que lo sean. Si un usuario no puede encontrarlas, difícilmente podrá acceder a ellas. Lo mismo ocurre para las tareas de usuario que se consideran claves, el usuario debe poder acceder a ellas con facilidad.
b. Áreas donde hay (o puede haber) potenciales problemas: secciones donde los usuarios comentan que no pueden acceder correctamente (o les resulta muy complejo) , nuevas categorizaciones extraídas de un ejercicio de card sorting o añadidas por algún stakeholder.
4. Realiza la prueba y saca tus conclusiones: Puedes enviar la url de la actividad del mismo modo que hemos hecho con el cardsorting. Esta actividad suele dejar mejores resultados cuando es guiada por un moderador pero de todos modos se pueden hacer sin él. La herramienta TreeJack ofrece una serie de diagramas que nos permitirán evaluar los resultados y sacar nuestras conclusiones para construir nuestra arquitectura de información.
Fraseo de tareas
Cada tarea debe probar una etiqueta de categoría pidiendo al usuario que encuentre algo contenido dentro de esa categoría. Al igual que con las tareas de prueba de usabilidad, las instrucciones de la tarea de prueba de árbol deben evitar el uso de términos que revelen las respuestas . En ocasiones, se puede evitar la preparación mediante la descripción de un escenario y una motivación, pero también hay que tener en cuenta que los usuarios pueden no leer las instrucciones con atención y fácilmente pueden pasar por alto detalles importantes si están enterrados en una historia extensa.
A modo de ejemplo, aquí hay algunas posibles frases diferentes para evaluar la categoría Iniciar una empresa en el árbol del gobierno del estado de Nuevo México (que se muestra arriba):
1. Encuentre información sobre cómo iniciar un negocio.
2. Se mudará a Santa Fe el próximo año y, una vez que llegue, le gustaría complementar sus ingresos abriendo un negocio paralelo que brinde servicios de cuidado del césped. Descubra qué normas deberá seguir.
3. Está pensando en abrir un servicio de cuidado del césped. Vea si hay algún recurso en este sitio que pueda ayudarlo a comenzar el proceso.
El primer ejemplo revela la respuesta utilizando el término de etiqueta exacto, Apertura de una empresa ; mientras que elsegundo es largo y está repleto de palabras extrañas que un usuario podría confundir fácilmente con el punto principal de la tarea si estuviera escaneando rápidamente. La tercera opción evita tanto la terminología de la etiqueta como los detalles engañosos.
TreeJack - Optimal Workshop
Una prueba de Treejack, ayuda a eliminar conjeturas sobre la arquitectura de información y demuestra si la estructura es válida antes de entrar en la fase de diseño UI o diseño de la interfaz.
Gracias a este tipo de prueba podremos cerciorarnos de:
1. Si está bien estructurada la jerarquía de contenidos dentro del sitio.
2. Si el etiquetado o nombre de los enlaces son apropiados.
3. Si los usuarios pueden encontrar lo que están buscando.
Paso a Paso
Realizar un Tree test con Optimal Workshop es realmente sencillo. Comparándolo con el sistema tradicional ayuda a ahorrar muchísimo tiempo tanto en la preparación como en el análisis posterior. Permite obtener datos cuantitativos fácilmente con pruebas de usuario remotas y sin moderación. Arroja muchos datos para reforzar los resultados cualitativos.
1. Introduce el árbol de navegación: El árbol de navegación es la estructura del sitio web o app. Puedes generar primero tu árbol en papel y luego realizarlo en una hoja de cálculo que pasaremos importando al treejack.
2. Definir las tareas: Para comprobar si los usuarios son capaces de encontrar en la web lo que estaban buscando, es necesario definir las tareas comunes. Es importante que en las narrativas no se les incluya los nombres de los enlaces ni ningún tipo de ayudas complementarias.
3. Encontrar participantes: Esta herramienta proporciona un enlace de la prueba que se puede enviar por correo electrónico a los usuarios y clientes, publicarla en una web o lanzarla a través de las redes sociales.
4. Análisis de datos:
a. Desglose por tarea: Las estadísticas de cada tarea muestran cuántos usuarios participantes encontraron la respuesta correcta, el recorrido que realizaron para llegar hasta la respuesta elegida y cuanto tiempo tardaron en hacerlo.
b. Detallado por la ruta: La herramienta de análisis de ruta detallada muestra a dónde fueron los usuarios participantes en la prueba en cada cruce y dónde seleccionaron todos sus respuestas finales.
c. Tabla de Destinos: La tabla de destinos ofrece una visión general y rápida del árbol de navegación, destacando las respuestas correctas y las áreas problemáticas en las que los usuarios participantes de la prueba encontraron la respuesta incorrectamente.
Las pruebas de árboles se enfocan exclusivamente en evaluar etiquetas de categorías. Ésta es tanto su gran fortaleza como una debilidad significativa. Dado que el menú con el que los usuarios interactúan está completamente desprovisto de estilo visual y contenido, la experiencia es significativamente diferente a la de interactuar con el diseño completo. Por ejemplo, un diseño con mega menús proporciona una experiencia de navegación bastante diferente a la que se probó en una prueba de árbol, ya que muestra simultáneamente el contenido de varias subcategorías.
Sin embargo, incluso estas limitaciones inherentes a menudo se pueden superar o minimizar con un análisis de datos cuidadoso, por ejemplo, centrándose en si el usuario selecciona la categoría de nivel superior correcta, en lugar de en las tasas de éxito de los sitios con mega menús.
En general, estas limitaciones son un pequeño precio a pagar por el beneficio de poder iterar y evaluar rápidamente cambios estructurales importantes en una jerarquía de información al principio del proceso de diseño. Puede crear un árbol completamente nuevo para probar simplemente editando su hoja de cálculo, sin absolutamente ningún diseño o codificación requerida.