EMT Madrid — Design Thinking (I)

Usando el Doble Diamante para mejorar la Empresa Municipal de Transportes de Madrid

7 min readOct 24, 2018

--

No hay mejor forma de aprender una metodología que usándola, así que para explicar qué es y cómo funciona el famoso Design Thinking, lo aplicaremos a un reto (más o menos) real.

Esta es la primera parte de dos artículos que cubren el reto de aplicar Design Thinking a la Empresa Municipal de Transportes de Madrid. Se puede leer la segunda parte aquí.

Para llevar a cabo esta tarea, nos hemos basado en el modelo del Doble Diamante. Este modelo lo propone en 2005 el British Design Council como una forma gráfica de representar el proceso de diseño, a partir de la investigación que realizaron sobre cómo gestionan estos procesos once empresas punteras en el sector, como Lego, Microsoft y Starbucks (entre otras).

Puede sonar cursi o demasiado moderno para nosotros, pero la metodología del Doble Diamante no significa tener que ponerse fundas brillantes en los dientes para sonreír de cara al público. Como en todo proceso de diseño, hay ciertos momentos en los que el equipo tiende a diversificar las ideas o propuestas sobre las que se podría trabajar, para luego decidir o eliminar aquellas opciones menos interesantes. En esto se basa el Doble Diamante: la idea de divergir para luego converger. Sin embargo, no es un proceso que se realice una sola vez, sino que se produce dos veces y deja siempre la puerta abierta a futuras iteraciones para mejorar el diseño “final”.

Design Research Plan — Doble Diamante

El Doble Diamante nos propone cuatro fases principales de las que partir a la hora de adentrarse en un reto de Design Thinking. Estas fases son:

  • Descubrir
  • Definir
  • Desarrollar
  • Entregar

Y ahora nos adentraremos en cada una de ellas para explicarlas en detalle.

DESCUBRIR

Nos hemos sentado al ordenador, la temida página en blanco aflora ¿Y ahora qué tenemos que hacer? ¿Por dónde empezar a “diseñar”? El primer paso es tener muy claro de qué va esta aventura en la que nos hemos embarcado. Normalmente, tendremos un breve brief que nos aclarará cuáles son los puntos de interés de nuestro cliente. El brief para este reto era el siguiente:

Mejorar la experiencia de los usuarios que van en autobús por la ciudad.

Tras realizar un estudio, la Empresa Municipal de Transportes de Madrid (EMT Madrid), se ha dado cuenta de que cada año hay menos clientes que utilicen el autobús como medio de transporte, y que los clientes en general están más descontentos con el servicio. Así a simple vista, parece una empresa titánica y tendríamos que ser Don Quijote para aceptar llevarla a cabo, así que han decidido establecer dos puntos de enfoque que nos permitan acotar un poco el radio de acción. Los requisitos que establece la EMT para este proyecto son:

  • Potenciar sistemas de información y comunicación con el cliente (el público objetivo son personas mayores, o usuarios con movilidad reducida, invidentes, con problemas de audición, o impedidas)
  • Utilizar la tecnología para mejorar la experiencia

Ahora es más fácil empezar a ver la entrada del túnel (ya no digo la luz al final, aún es demasiado pronto). Nuestra solución debe ser tecnológica en algún grado y debe estar enfocada a personas con movilidad reducida o, en general, que se puedan sentir menospreciadas a la hora de acceder y utilizar el autobús como medio de transporte.

Ya sabemos cuál es el punto de partida. ¿Nos ponemos con las soluciones ya? Aún no, impacientes. En este punto, toca investigar estilo Sherlock Holmes. Una de las mejores formas de encauzar la investigación es comenzando por organizar qué queremos saber. Esto se consigue con las Research Questions, o preguntas de investigación. Esta técnica trata de gestionar todas las preguntas realizadas en el proyecto, dividiéndolas en tres grandes grupos:

  • Preguntas centradas en los usuarios
  • Preguntas centradas en la empresa
  • Preguntas centradas en la competencia
Research Questions — EMT Madrid

Para organizar todas las preguntas que iban surgiendo, decidimos crear focos de atención dentro de cada grupo (por ejemplo, atención al viajero, tecnología usada, comunicación, accesibilidad, características del usuario, información disponible, etc…). A partir de estas preguntas, ya comenzamos con el Desk Research, o lo que vendría siendo el “pregúntale a Google”. Conseguimos gran cantidad de archivos útiles que nos permitieron sentar las bases de lo que sería la investigación total. Otras formas de buscar información interesante, tanto dentro como fuera de la red (sí, existe vida más allá), son:

  • Netnografías: investigación del usuario por redes sociales. Nos dan una visión sobre lo que realmente frustra o condiciona a los clientes del servicio.
  • Benchmarking: tabla comparativa de otros servicios o productos similares (en este caso, de otras empresas de autobuses), que nos permita ver qué mejoras aplican respecto a las que nosotros tenemos
  • Safari: literalmente, salir a la naturaleza y observar fauna en estado puro. En este caso, consistió en subirse a autobuses de la EMT y ver cuáles eran los problemas a los que se enfrentaban los usuarios durante su trayecto.
  • Shadowing: versión algo más creep del safari, que consiste en escoger una presa y seguirla para tener información de primera mano sobre el tema. En este caso, decidimos no arriesgar nuestra vida porque los bolsos de las señoras mayores que te pillan espiando suelen ser armas bastante potentes. Además, el safari nos proporcionó muchos datos útiles, y sin daños personales o materiales.
Ese señor no llevaba bolso, eso siempre ayuda.

Llevamos una cantidad considerable de información: datos sobre otras empresas, ténicas para mejorar la accesibilidad, estándares ya establecidos y hasta planos de autobuses. Sin embargo, y aunque con el safari ya hemos empezado a adentrarnos en ese mundo, nos falta lo más importante: información sobre nuestros usuarios. Para ello, utilizamos dos métodos complementarios: cuestionarios y entrevistas.

  • Los cuestionarios nos dieron información cuantitativa (sí, más datos que analizar) sobre cómo y por qué los usuarios cogían el autobús y cuáles eran los principales problemas que se encontraban a la hora de usarlo. Realizamos un total de 91 cuestionarios.
  • Las entrevistas nos dieron información cualitativa (de la que tiene chicha, opiniones reales de gente real que se aventuró a explicarnos su día a día en un autobús). Realizamos tres entrevistas.

Pero con estas dos técnicas seguimos teniendo muchos datos revoloteando por Trello y Google Drive, y nada concreto con lo que trabajar. Es porque, aunque conocemos un poquito más el público al que debemos dirigirnos, aún no nos hemos presentado con nombres y apellidos. El Design Thinking nos provee de varias herramientas que nos ayudan a trabajar sobre usuarios casi reales. Para ello, tenemos tres herramientas fundamentales que nos ayudan a acercarnos un poquito más a esa persona ideal: los User Persona, los Mapas de Empatía y los User Journey.

User Persona — Marisa García

Esta es Marisa, jubilada y user persona. Marisa tiene una discapacidad visual, y unida a que suele utilizar el carrito para llevar a su nieta, es el perfil buscado para entender los retos a los que se enfrenta en su día a día con el autobús. Los User Persona nos sirven para conocer al usuario creado. Contextualizamos así mejor cómo son, de dónde vienen y qué les interesa. También conocemos su relación con la tecnología (que en este caso es relevante, para poder desarrollar la solución tecnológica más adaptada al público final).

Los mapas de empatía nos sirven para situar a nuestra amiga Marisa dentro del ámbito de los transportes, y de la EMT de Madrid en este caso. ¿Qué ve, qué oye, qué siente y qué le dicen cuando piensa en autobuses?

Mapa de Empatía — Marisa García

Los User Journey, o viajes de usuario, se centran más en entender qué sucede con Marisa durante el trayecto en autobús. Es decir, desde que decide (en este caso) tomar el transporte público, hasta que llega a su destino. ¿Cuáles son los puntos de conflicto y cuáles los de beneficio?

User Journey — Marisa García (antes de poner en práctica nuestra solución)

Ahora ya sí, estamos en posición de sacar algunas conclusiones (y siempre centradas en lo que hemos observado o nos ha comentado nuestro usuario directamente). Estos insights nos ayudan a visualizar dónde está el problema exactamente y a replantear el reto inicial para adaptarlo a la realidad.

  • “Están cambiando la distribución de los asientos en los nuevos autobuses, pero cada vez hay menos sitio para ir sentado”
  • “Los conductores a veces van como locos y tengo miedo a caerme”
  • “A las personas mayores no les da tiempo a sentarse antes de que arranque el autobús”
  • “Los asientos reservados la mayor parte del tiempo no se respetan”
  • “A veces parecemos sardinas en lata”
  • “Si pudiera, evitaría las horas puntas, pero necesito usar el autobús”
Nube de Tags con las frases destacadas extraídas de las entrevistas

Con todo esto, podemos establecer el reto definitivo, también conocido como problem statement.

Problem Statement

Con este apartado cerraríamos la primera parte del primer diamante, la de descubrir a qué nos estamos enfrentando. En la segunda parte, nos centraremos en las tres partes restantes: definir, desarrollar y entregar. ¡Vamos a ello!

--

--

UX UI Designer. Máster en Dirección de Arte en Publicidad y grado en Comunicación Audiovisual. Gatos, piano y jazz.