2. Problema 17
2.3. Actividades de Dise˜ no Centrado en el Usuario
2.3.4. Etapa de ideaci´ on
En esta etapa, se comparti´o todo lo aprendido por el equipo y se identificaron oportunidades para poder crear un posible dise˜no. Se generaron diferentes ideas las cuales se validaron o refutaron. Luego, se crearon los prototipos para las ideas gene- radas y se obtuvo retroalimentaci´on del mismo con diferentes usuarios. Se iter´o hasta obtener una soluci´on la cual estuviese apta para salir al mercado. A continuaci´on, se describen brevemente las actividades realizadas durante esta etapa:
Bajar a tierra los aprendizajes
La segunda etapa comenz´o reuniendo las notas, fotos y entrevistas realizadas durante la etapa de inspiraci´on. Una vez recolectada la informaci´on, el equipo pro- cedi´o a capturar las ideas e historias en Postits, utilizando la herramienta Miro.
El objetivo de esta actividad fue poder compartir los insights de cada uno de los miembros.
Figura 2.10: Actividad con el equipo para bajar a tierra los aprendizajes Mapa de trayecto (Customer journey)
Una vez procesada la informaci´on recolectada, se procedi´o a realizar un mapa de trayecto, para empezar a reconocer patrones y entender la perspectiva de las personas a las cual se le est´a dise˜nando a la hora de alquilar o comprar una propiedad.
Para construir dicho mapa, durante la etapa de ideaci´on se le realizaron dife- rentes preguntas a personas interesadas en alquilar o comprar una propiedad con la finalidad de sondear las experiencias negativas y positivas de ese trayecto.
Figura 2.11: Customer Journey Tormenta de ideas
Se ejecut´o una tormenta de ideas con los miembros del equipo con la finalidad de poder generar ideas nuevas y creativas.
Figura 2.12: Tablero resultante de la tormenta de ideas
Se generaron 31 ideas nuevas, las cuales fueron a votaci´on. Una vez culminada la misma, se analizaron las ideas m´as votadas para filtrar las que se podr´ıan llegar
Matriz de 2x2
Luego de la actividad de tormenta de ideas, se realizo un matriz de 2x2, en donde se agrupaban las ideas generadas anteriormente dentro de una matriz, separadas por el esfuerzo que una idea conlleva y el impacto que le proporciona al usuario.
Figura 2.13: Matriz 2x2
Esta actividad ayud´o a priorizar que ideas podr´ıan ser m´as factibles que otras.
Por ejemplo, “Seguimiento de visitas” es una tarea que tiene gran impacto para el usuario final y el esfuerzo de realizar dicha tarea es bajo, por lo que se consider´o que al estar bajo esas caracter´ısticas, ser´ıa agradable poder tenerla en cuenta a la hora de dise˜nar una posible soluci´on.
Card Sorting
El card sorting es una t´ecnica usada para evaluar un ´arbol de categor´ıas, es decir la estructura de la informaci´on de un sitio web. Es una prueba que brinda informa- ci´on sobre la opini´on de los usuarios acerca del rotulado de los nombres que van a dar a la estructura jer´arquica del mismo.
Figura 2.14: Card Sorting realizado
Para analizar los resultados de los nueve card sorting realizados, se cre´o una matriz de similitud y un dendograma que se detallar´an a continuaci´on.
Matriz de similitud
Se gener´o la matriz de similitud, utilizando la herramienta Optimal Workshop, con la finalidad de detectar los grupos de datos que los usuarios emparejaron con mayor frecuencia.
Figura 2.15: Matr´ız de similitud
Se pudo detectar que hay algunas similitudes entre elementos que en cierta parte era probable que as´ı sucedieran, lo cual contribuy´o a validarlo. A su vez, esta herra- mienta sirvi´o para encontrar otros que no eran tan esperables, como por ejemplo, los elementos “N´umero de referencia” con “Fotos de la propiedad”. De no haberse realizado la matriz de similitud, no se hubiese concluido que el n´umero de referencia de una propiedad deber´ıa ir cerca de las fotos de la misma.
Dendograma
Una vez analizada la matriz de similitud, se cre´o un dendograma con la mis- ma herramienta utilizada anteriormente. A trav´es del mismo se pudo destacar con diferentes colores que elementos fueron agrupado entre s´ı. Al haberse realizado un card sorting de tipo abierto, en otras palabras, que los participantes sean libres de escribirl el t´ıtulo a la agrupaci´on, se pudo visualizar tambi´en con que r´otulo estos ir´ıan asociados.
Figura 2.16: Dendograma
Una de las conclusiones detectadas a trav´es de este dendograma fue que el listado de propiedades, el buscador de propiedades y el mapa de propiedades deber´ıan ir agrupados en una p´agina bajo el nombre de “Propiedades”. Adem´as, se detect´o una nueva p´agina rotulada “Contactar”, la cual abarca los elementos de redes sociales, escribir una consulta e informaci´on de la inmobiliaria.
Arquitectura de informaci´on
A trav´es de los resultados obtenidos a trav´es del card sorting y analizando la matriz de similitud y dendograma, se llev´o a cabo la arquitectura de la informaci´on del sitio web para usuarios. El mismo consiste en organizar, jerarquizar y rotular el contenido brindado para dicho sitio, para poder identificarlo y comunicarlo en los futuros prototipos.
Figura 2.17: Arquitectura de la informaci´on realizado en Whimsical
Sin entrar en gran detalle, la arquitectura de informaci´on del sitio web ser´a conformada por seis nuevas p´aginas. Las mismas son “Homepage”, “Propiedades”,
“Propiedad”, “Blog”, “Contacto” y “Empresa”.
Flujo de tareas
Una vez realizada la arquitectura de la informaci´on, se realizaron los flujos para las tareas mas importantes. Estos flujos reflejan todas las acciones que el usuario debe realizar para hacer una tarea espec´ıfica. A continuaci´on se muestra un flujo de tarea para buscar una propiedad:
Figura 2.18: Flujo de tarea de buscar una propiedad
El mismo tiene la finalidad de tener una idea de cuales ser´ıan las acciones que el usuario debe realizar para llevar a cabo una tarea concreta.
Diagrama de flujo de usuario
Asimismo, tambi´en se crearon diagramas de flujo de usuario para las tareas m´as importantes. En los mismos, se puede ver tanto los trayectos m´as comunes como aquellos trayectos que resulten un poco m´as conflictivos, por ejemplo, cuales son los pasos a seguir si se quiere utilizar varios filtros en simult´aneo, o que ocurre si ya se hab´ıa realizado una b´usqueda similar antes.
Figura 2.19: Diagrama de flujo de usuario de buscar una propiedad
La finalidad de este diagrama es poder reconocer los puntos m´as conflictivos de las tareas para poder reducir la fricci´on, es decir, como poder mejorar la experiencia de usuario para reducir la dificultad para realizar una tarea concreta.
Crazy eight
Para comenzar con la prototipaci´on, se utiliz´o el m´etodo Crazy eight. Es un ejercicio de dibujar ocho ideas en ocho minutos.
Figura 2.20: Dibujos generados a partir del crazy eight
El objetivo fue poder generar una variedad de posibles primeros dise˜nos para el sitio web de usuarios.
Wireframes de baja fidelidad
Luego de realizar el m´etodo de Crazy Eight, se realiz´o una votaci´on y a partir del dise˜no m´as votado, se comenz´o a realizar el wireframe de baja fidelidad, con la finalidad de poder hacer un prototipo del mismo y ponerlo a prueba con usuarios.
Tanto los wireframes como prototipos fueron realizados con la herramientaUizard.
Figura 2.21: Wireframe de baja fidelidad Obtenci´on e integraci´on de feedback
Luego de crear el primer prototipo, el mismo fue sometido a pruebas de usa- bilidad para obtener feedback. El detalle de las pruebas realizadas con usuarios se encuentra posteriormente en el documento, en el cap´ıtulo 8.Usabilidad. Por lo que a continuaci´on, se realizar´a un breve resumen.
Los resultados obtenidos en las primeras pruebas realizadas no fueron exitosos:
el resultado del puntaje de esfuerzo del cliente fue promedio “Dif´ıcil” y las m´etricas de eficiencia y eficacia fueron altas, ya que las tareas a realizar llevaron m´as de un minuto de diferencia con el promedio estimado y la cantidad de pasos se sobrepas´o por el doble de la cantidad m´ınima de pasos por cada tarea, por lo que fue una se˜nal que el dise˜no no se entend´ıa correctamente.
Debido a esto, se volvi´o a iterar para dise˜nar un nuevo wireframe de baja fideli- dad, para luego someterlo a otra prueba con usuarios. La misma fue llevada a cabo luego de realizar el segundo prototipo y su resultado fue exitoso, ya que el tiempo de las tareas a realizar disminuy´o, acerc´andose al promedio estimado y la tasa de esfuerzo fue “Sencilla”, por lo cual, se avanz´o a crear wireframes de media fidelidad.
Wireframes de media fidelidad
Una vez decididos y validados con los usuarios los primeros flujos de navegaci´on, se procedi´o a dise˜nar los wireframes de media fidelidad. En los mismos se comenz´o
a trabajar m´as sobre los detalles, en las funcionalidades y el contenido final.
Figura 2.22: Wireframes de media fidelidad
Estos wireframes ayudaron a brindar con m´as claridad el posible dise˜no del sitio web, permitiendo a´un realizar cambios r´apidos.
Una vez que los mismos fueron validados, se comenz´o con la fase de aplicaci´on del dise˜no visual, es decir, aplicar colores, fotograf´ıas, tipograf´ıas, entre otros, para culminar con el dise˜no final.