Home > User Experience > ¿Qué podemos hacer para que la gente siga leyendo periódicos?

¿Qué podemos hacer para que la gente siga leyendo periódicos?

¿Qué podemos hacer para que la gente siga leyendo periódicos?


Me di cuenta que el hecho de tener limitaciones de tiempo en todas las tareas es uno de los factores que más nos ayudó a seguir avanzando.

Claro que el hecho de trabajar en equipo ayuda a generar una gran cantidad de ideas o soluciones desde diferentes puntos de vista, que una persona por sí sola no podía alcanzar.

Trabajando en equipo surgen muchas ideas

Pero tener un límite de tiempo te obliga a centrarte y no da lugar a empezar a dudar de las decisiones tomadas ni empezar a plantear una idea nueva, que suelen ser las causas de que el proceso sea interminable.

Así en el segundo día fuimos capaces de hacer el benchmarking y las demos rápidas. A partir de allí en dos bloques de 20 minutos hemos tomado notas y anotado ideas, cada uno por separado. En tan sólo 8 minutos hicimos 8 bocetos de nuestras ideas (crazy 8). Media hora más tarde ya cada miembro del equipo tuvo un wireframe con su propuesta trazado.

Generación de Notas e Ideas en dos bloques de 20 minutos.

Tomar decisiones importantes nunca es fácil. ¿O sí?

El tercer día del sprint hemos tomado decisiones en equipo sin apenas darnos cuenta de ello. Fue muy interesante ver cómo el Facilitador interpreta nuestros bocetos correctamente. Y ver la cantidad de soluciones diferentes al mismo problema.

La votación por pegatinas creando el mapa térmico y finalmente la votación silenciosa hacen que el equipo pueda tomar decisiones de una manera mucho más relajada e incluso divertida. La solución elegida fue: el Contrastator.

Wireframe del Contrastator

El Contrastator sería una app con la que se puede contrastar una noticia o un hecho (por ejemplo ataques a Irán) en todas las fuentes del mundo. Sabemos que cada periódico tiñe las noticias de cierto color, y la mejor manera de formarse opinión propia es poder acceder a la misma noticia desde varias fuentes.

La principal funcionalidad de Contrastator sería el buscador o mejor dicho el contrastador de noticias, con posibilidad de filtrar la noticia por idioma, país, fuente o tipo (artículo, audio, vídeo…).

Existe la posibilidad de múltiple selección, por ejemplo, elegir idiomas castellano e inglés, y luego en países elegir España, México, Argentina, EEUU y Canadá. Así en los resultados de búsqueda saldrían todos los artículos que hablen sobre ataques en Irán que se publicaron en los países seleccionados.

Este punto lo considero especialmente importante. Hay que tener muy claro qué aspectos de nuestra propuesta queremos testear con los usuarios, qué es importante y qué no. En esto nos ayuda mucho el guión gráfico. Si no hacemos este ejercicio puede pasar que nos perdamos haciendo un prototipo demasiado realista, perdiendo tiempo en detalles que no aportan, o creando partes que no son necesarias para el testing. Es la única manera de conseguir un prototipo en un día.

El guión gráfico de cómo se va a hacer el testing.

En nuestro caso tuvimos 3 días para el prototipado con el fin de aprender la herramienta Figma sobre la marcha y poder ponerla en práctica.

Gracias a que elaboré el guión gráfico, supe a partir de qué pantalla empezar el prototipo. En el caso de Contrastator, el prototipo empezaría con el usuario ya logueado. No tenía sentido hacer las pantallas de darse de alta, porqué no era importante para el propósito de este testing.

Eso no quiere decir que en el caso de que el proyecto saldría adelante no habría que testear esta parte, claro que sí. Pero al propósito de este Design sprint necesitaba validar la idea de la app, su utilidad y si sería posible monetizarla.

Flujo de pantallas

Recuerda: testea en cuanto puedas (test as early as you can). No esperes a que el prototipo sea perfecto, empieza a validar tu diseño.

Lo que me lleva a mi aprendizaje más importante:

Perdona por haberlo anunciado a lo “buzzfeed” al principio, pero no quería que te lo perdieses.

Con el prototipo listo vamos a empezar el testing, en mi caso hice el testing informal también llamado el test de guerrilla. Antes de empezar, hay que planificar bien el testing. Me hice las siguientes preguntas:

¿Qué quiero testear?

Hay que tener muy claros los objetivos del testing, saber el qué quiero averiguar con el test. Yo necesitaba validar la idea de Contrastator, si la gente lo usaría, probar si es fácil de usar y saber si los usuarios pagarían por este servicio.

¿A quién voy a hacer el testing?

El primer día hemos dibujado 2 mapas de usuario, uno era Ramón de 65 años y otro Ana de 25 años. Pensé en entrevistar estos dos grupos de usuarios acordándome de la frase de Dan Formosa de Smart Design New York en el documental Objectified:

“Si entiendes cómo son los extremos, la media se soluciona sola.”

¿Dónde buscar los candidatos para los tests?

Si haces un test de guerrilla, es bueno si puedes salir “a la calle”. Entrevistar a tus compañeros y familia puede que no te traiga respuestas relevantes, ya que puede pasar que no quieran herir tus sentimientos.

Puedes probar por ejemplo en cafeterías, claro, depende de cómo de bien se te da abordar a la gente desconocida. En mi caso hice el testing en el hostel en el que me alojaba, que me proporcionaba un buen cultivo de muestras para mi experimento.

Según Jakob Nielsen, un test con 5 usuarios revela el 85% de los problemas de usabilidad. Para descubrir todos los problemas de usabilidad de tu diseño hace falta testear con 15 usuarios, pero en grupos de 5 e iterar entre medias.

Cuando tienes varios grupos de usuarios con diferencia muy marcada, no hace falta incluir a tantos usuarios en cada grupo.

En mi caso, para testear 3 grupos de usuarios (65, 30/40, 25) me bastaría con 3 usuarios por cada grupo.

Al final conseguí a 4 usuarios de entre 30 y 40 años y 2 usuarias de 25 años. No era lo que me propuse, pero era una muestra buena para conseguir el feedback que buscaba.

¿Qué preguntar?

Diseñé varios grupos de preguntas:

Primero una serie de preguntas para evaluar si los usuarios entrevistados son los adecuados para el test.

Preguntas de evaluación de usuarios

Después seguí con una serie de preguntas abiertas, combinando la técnica de “escuchar y observar” y empecé a notar la diferencia entre lo que los usuarios me contaban y lo que hacían.

Preguntas abiertas combinando el “escuchar y observar”

Después de hacer los tests con los primeros 2 usuarios me di cuenta de un error en el diseño que llevaba a la confusión (la falsa affordance). Decidí iterar antes de seguir testando con más usuarios. Puedes pensar que quizás fue muy temprano iterar después de 2 tests, pero al observar el comportamiento de los usuarios estaba segura que iba a repetirse lo mismo con el tercer usuario y quise ver si podía solucionarlo. Tenía razón, a partir de la iteración el error no se repitió.

Iteración

Más adelante averigué algunas cosas más. Entre otras, que el último usuario no era válido para este test, ya que resultó que aparte de El País que leía su padre, no conocía los demás periódicos.

Siguiente grupo de preguntas me sirvió para evaluar qué les parecía la idea en general, si usarían la app, y sobretodo si pagarían por ella.

Preguntas para validar la idea

El último grupo de preguntas era para evaluar rápido en una escala de 0 a 5 la estética y diseño, facilidad de uso, utilidad e idea.

Preguntas de evaluación de 0 a 5

Tengo que puntualizar que la evaluación de facilidad de uso de primer usuario puede ser afectada por hacer el testing con el mirror de Figma y los retrasos en cargar. A partir de este usuario decidí hacer los test con el resto de los usuarios en el portátil.

Oportunidades de mejora del diseño que detecté:

Oportunidades de mejora
  • el símbolo de + para leer la noticia no se entendió por dos de los usuarios
  • el símbolo de marcador no se entendió por dos usuarios
  • mejorar el diseño y estética

Algúnos insights de los usuarios:



Source link