Una vez concluída la primera release lo primero que hicimos fue testearla con usuarios. Esta vez teníamos un prototipo funcional y podríamos descubrir y aprender más cosas acerca de como mejorar la web.
Test UX
Antes de probarla con usuarios estábamos tan inmersos en el proyecto que pensábamos que nuestra página era sencilla, perfecta y muy clara para cualquier persona. Pero decidimos seguir los consejos de Steve Blank y hacer un “get out the building”. Pues sí, estábamos confundidos: muchos usuarios que veían por primera vez la página no eran capaces de describir que ofrecíamos, en concreto tardaban en discernir que los eventos tenían lugar en casas particulares. Además de esta conclusión, que fue la más dura de aceptar para el equipo, también observamos:
- Los usuarios reservan un evento sin ningún problema.
- Eran capaces de llegar al formulario de crear evento sin muchos problemas.
- Algún usuario más “early adopter” nos sugirió el uso de algún tipo de categorización de eventos para poder elegir más fácilmente.
- Apreciamos que no distinguían muy bien cuando estaban en la landing y cuando en la página de “crea tu evento”.
- Pese a hacer la reserva del evento con facilidad, no eran conscientes de datos importantes como: cuando se paga, cómo saber la dirección, como funciona el proceso.
- El formulario de creación de evento les generaba bastante extress, y les confundía en algunos puntos.
Historias de usuarios
La segunda release se presentaba con bastantes aspectos a mejorar, sobre todo tenía que quedar claro de qué iba la plataforma, y debíamos ofrecer al usuario creador un trato diferenciador, casi exclusivo. Por lo que volvimos a repetir las historias de la primera release:
- Ver lista de eventos
- Ver ficha de evento
- Reservar Evento
- Crear Evento
Además añadimos las siguientes historias de usuarios.
- Compartir en redes sociales.
- Ver categorías de eventos.
- Registro/login.
- Ver perfil de usuario.
Las nuevas historias de usuarios influían en las antiguas de la primera release. Intuímos que a medida que avanzásemos el proyecto se volvería más complejo y con más detalles a tener en cuenta. Si queríamos ser productivos debíamos organizarnos con alguna herramienta: probamos con basecamp, lo desechamos y empezamos a usar trello.
Objetivo de la release
Nos habían comunicado que iríamos a un laboratorio a hacer test de usuarios, y nos pareció una buena oportunidad que debíamos aprobechar al máximo. Hasta ahora habíamos hecho muchos test de guerrilla, y algunos más cualitativos con amigos, pero no habíamos hecho una planificación más detallada de las pruebas. Nos propusimos tener finalizado el prototipo para testearlo en el laboratio. Esta vez haríamos guión para las pruebas y pensaríamos mas detalladamente que funcionalidades queremos probar.
Workflow
De nuevo necesitábamos un camino a seguir. El rediseño de la página, añadir las nuevas historias de usuarios y corregir las que ya teníamos suponía una gran tarea. Necesitábamos un esqueleto que nos mostrase qué podía hacer el usuario en cada lugar en el que se encontraba. Necesitábamos un mapa para no perdernos en el diseño, un mapa que se hizo mucho más complejo de lo que pensábamos al añadir la funcionalidad de registro/login de usuario.
Nos planteamos añadir nuevas secciones: ¿qué es ROOOF?, y dar más protagonismo a la lista de eventos.
Wireframes
El porqué de este wireframe era testear lo que sería la nueva distribución de la página, y ver si el registro de usuario iba por buen camino.
Incluímos una lista de eventos más elaborada que luego nos serviría como página de búsqueda de eventos, y en la landing reservamos un espacio privilegiado para eventos destacados, con el fin de atraer a los usuarios y generar interés.
Con el wireframe, hicimos un prototipo muy simple con Marvelapp, para comprobar si nuestra estructura funcionaba a nivel de navegación.
.
Nuestra preocupación por hacer saber que era ROOOF nos llevó a plantear una nueva página en la que el usuario podía informarse qué podía hacer en la plataforma "¿qué es ROOOF?", le daríamos el máximo protagonismo poniendo un botón en el header de la landing que llevara a los usuarios hasta esta sección.
En esta página también mostramos otras funcionalidades que siempre deberían estar presentes: lista de eventos y como asistir a un evento.
Además con el wireframe sacamos estas conclusiones:
- Tenemos que añadir un botón "qué es ROOOF” en el header, para que en todo momento se pueda acceder a esta información.
- Ok a la nueva estructura de la landing:
- Foto con copy y call to action.
- Sugerencia de eventos destacados.
- Como asistir a un evento.
- Call to action a "Crear eventos".
- Cambios al orden de información de la sección “que es”:
- Slide informativo, con imágenes y textos cortos.
- Explicación de qué es ROOOF.
- Como asistir a un evento.
- Call to action a "Crear eventos".
Nuevas propuestas de diseño
Empujados por el “jarro de agua fría” que supuso el que los usuarios no supiesen de que trataba nuestra web decidimos realizar diferentes bocetos en busca de alguno que no proporcionase más claridad en el mensaje.
Probamos con ilustraciones en vez de fotografía. Pero los dibujos nos alejaban del universo humano, cálido y real que transmitían las imágenes fotográficas.
También empezamos a probar con otros copies. Antes era “ROOOF es una nueva forma de disfrutar de la cultura en casa” y ahora es “quedadas culturales en casas de Barcelona”.
Propuesta Gráfica
En esta release cambiamos el grafismo de la página por motivos anteriormente comentados. A partir del wireframe desarrollamos un nuevo layout, más simple con menos artificios y más claro. Estos fueron cambios más significativos que realizamos:
- Color: simplificamos color, ahora solo usamos grises, blanco y rosa.El rosa será nuestro color corporativo y ayudará al usuario a navegar a través de la página. Intercalando blanco, gris y fotos separamos secciones dentro de una misma página, y jugamos más con los módulos creando layouts diferentes. Con esto resolvemos el problema que se nos presentó en las entrevistas: los usuarios les costaba distinguir entre la home y las páginas interiores.
- Botones: Les damos más protagonismo: usamos más y más grandes y los unificamos.
- Simplificamos logotipo
- Añadimos roll overs
- Mantenemos la tipografía pero la usamos de forma diferente para los títulos y los subtítulos, jerarquizando más la información.
- Damos más protagonismo a la fotografía, en especial en módulos importantes: call to action para crear evento y buscar eventos.
Comunicación con el usuario
Siguendo con el problema de comunicar bien lo que era ROOOF, y guiar al usuario a través de la página, decidimos hacer una revisión de nuestro tono de comunicación.
Cambiamos los copies, les bajamos el tono informal. Los usuarios que crean eventos ceden su casa a desconocidos por lo que no nos hacía ningún favor ser tan informales. Teníamos que mostrarles que es lo que podían hacer con la plataforma y animarles a ello mediante conceptos positivos: conectar con gente nueva, compartir tu pasión por la cultura y atraer a público.
Antes:
Después:
Además hicimos los copies más directos y claros. Los usuarios no sabían que los eventos eran en casas particulares y debíamos poner remedio. La frase del header, la que comunica qué es ROOOF, la cambiamos varias veces. Al final la que mejor funcionó fué esta:
"Conciertos, teatro y gastronomía en casas de Barcelona"
Creación del evento
El formulario para crear evento lo habíamos planteado a través de un typeform, y pese a que nos aportaba funcionalidad, se presentaban algunos problemas. El primero era que salias de la propia plataforma: otra gráfica y otra comunicación a nivel visual, y tiempo de carga. También los usuarios se frustraban bastante, no sabían que información debian poner en cada caso.
Decidimos crear un formulario propio para crear un evento. Estamos de acuerdo con que el typeform ya cumplía en parte con su función y también estamos de acuerdo con que no era muy lógico dedicar tanto tiempo a estas alturas del proyecto a realizar el formulario. Además, nuestros conocimientos de programación backend hacían imposible tener totalmente operativa esta funcionalidad. Resumiendo iba contra los principios agile y seguro que íbamos a malgastar mucho tiempo haciéndolo. Pero, por otra parte, consideramos que estamos en un contexto académico y queríamos aprender, queríamos enfrentarnos al diseño de un formulario distinto y con una gráfica propia, y adpatarlo totalmente a las necesidades del usuario.
El resultado fue este:
Reserva del evento
Etiquetas
En esta release añadimos una categorización por etiquetas, de momento sin interacción, tan sólo las nombrábamos y las destacamos por registro de color. Este cambio respondía a las necesidades de algunos usuarios a los que les hicimos el test. Y con ello aportábamos un filtro visual por categorías, de fácil implementación para nosotros, y necesario para muchos usuarios.
Casuísticas
También habíamos previsto diferentes soluciones gráficas en caso de que el evento tuviese el aforo completo. En este caso consideramos oportuno ofrecerle al usuario la posibilidad de apuntarse a una lista en la que, si hubiese alguna vacante, podría acceder al evento.
En general las fichas de los eventos cambiaron bastante, añadimos más espacio, destacamos el contenido de las mismas y a la vez las hicimos más simples y con más espacio. Y siempre con acceso a información acerca del creador y del precio.
Facilitando información al usuario
Durante los test con el primer prototipo observamos que el usuario tenía problemas para saber si había conseguido reservar evento, o como se pagaba éste. Por ello, en la página donde está la ficha del evento, junto al botón de “reservar entrada” añadimos una información intentando solucionar este problema:
Más tarde nos daríamos cuenta de que no funcionaría del todo, y que la solución era bastante ineficaz.
Respecto a esta acción de reservar entrada siempre nos han hecho una pregunta:
¿Porque +2 voy con un amigo y no +20?. Para responder a esta pregunta tenemos que hacerlo desde dos puntos de vista:
- Por el usuario creador: A través de las entrevistas con los usuarios entendemos que el creador del evento realiza un esfuerzo para preparar su espectáculo. Dedica tiempo a ensayar y deja de hacer otras cosas para que el día señalado su público vaya a su casa. Además, su casa no es un escenario donde haya un gran aforo. Por ello, si algún usuario pudiese reservar 20 plazas y , por cualquier motivo, no pudiese ir, el creador del evento se vería frustrado en su casa y sin público.
- Por la plataforma: Si el usuario que va a disfrutar del evento quiere ir con más amigos es necesario que estos se registren, tener más usuarios registrados es positivo para la plataforma.
Login de usuario
Nos planteamos la historia de "crear perfil de usuario", pero lo cierto es que ni por asomo llegamos a realizarlo. Lo único que podías hacer como usuario era loguearte, pero no creabas tu perfil. Esto, pese a ser contradictorio y totalmente irreal, lo iríamos mejorando en las siguiente releases, y también nos resultaba válido para hacer un primer testeo con los usuarios, y para ver como respondían a los perfiles ficticios que fuimos creando.
Prototipo testeable
El prototipo con el qué fuimos al laboratorio es éste. Aunque ya subido con algunas correcciones que hicimos posteriormente. Para hacer el prototipo continuamos usando html y css, cambiando los estilos que ya teníamos e incorporando nuevos.Algunos de los cambios propuestos para esta release seguirán cambiando en las siguientes. En esta estábamos tan ofuscados por que algunos usuarios no llegaban a entender que ofrecíamos que priorizamos en muchos sentidos información errónea, dando prioridad a qué es ROOOF cuando en realidad, teníamos que facilitar el acceso a los eventos. En esta release aprendimos a tener en cuenta la opinión de los usuarios y no obsesionarnos con su opinión sino usarla como es debido, con mesura.