EMT Madrid
CLIENTE
Personal Case Study
ROL
Ux Design
Ui Design
Prototype
PROYECTO
App EMT Madrid
La Empresa Municipal de Tranportes ha realizado un estudio donde se refleja que cada año hay menos clientes que usan este medio de transporte y los usuarios están cada vez más descontentos.
EL BRIEF
Contamos de inicio con un briefing cuyo objetivo principal es mejorar la experiencia de los usuarios con diversidad funcional que utilizan este medio de transporte público.
DESCUBRIENDO EL PROBLEMA
Antes de ponernos a investigar sin un fin concreto, elaboramos las Research Questions. Una serie de preguntas que convergen en una matriz sobre nuestro cliente (EMT Madrid), nuestros usuarios y la competencia en torno a las cuales centraremos nuestra investigación.
Una vez focalizada la investigación realizamos un Research Design Plan donde planteamos las técnicas cuantitativas y cualitativas que vamos a utilizar.
- Benchmarking y Netnografía.
- Safari.
- Entrevistas y cuestionarios.
MAPEANDO USUARIOS
Nos centramos más en los aspectos referentes a personas con diversidad funcional y movilidad reducida para cubrir todos los aspectos que nos interesan conocer de la problemática de este colectivo a la hora de planificar/realizar sus trayectos.
Estos fueron alguno de los findings que encontramos de boca de nuestros usuarios:
“Que me cambien una parada es un problema para mí”
“Utilizo distintas apps para ayudarme en el día a día”
“Me fío más de la información de la gente que de la EMT”
“La culpa de todo la tiene el tráfico”
“Nunca se qué clase de autobús voy a coger”
DEFINIENDO EL PROBLEMA
La creación de un panel POV (Point Of View) nos ayudó a visualizar a los usuarios, su problema y la causa de este problema. A su vez, también nos ayudó a sintetizar los insights y crear un posterior discurso lógico a la hora de idear una solución a la cuestión planteada.
- Necesidad de una herramienta que unifique distintas apps que utilizan en su día a día.
- Necesidad de autosuficiencia de las PMR.
- Necesidad de inclusión frente a los sistemas diferenciales.
- Necesidad de información del estado del tráfico y del tipo de autobús.
Generamos diferentes preguntas bajo la estructura HMW? y los miembros del equipo votamos según las posibilidades de las preguntas planteadas cruzadas con los objetivos del brief. Finalmente pudimos formular una declaración concisa del reto.
Crear una herramienta inclusiva que unifique las necesidades de una persona con diversidad funcional para viajar en transporte público.
GENERACIÓN Y PRIORIZACIÓN DE IDEAS
Cada miembro del equipo propusimos posibles soluciones al reto. Las ideas propuestas por cada uno fueron posteriormente priorizadas bajo el método MoSCoW, agrupándolas y clasificándolas en función del potencial que tuvieran para solucionar el problema y los objetivos del brief.
- Concepto inclusivo y no diferenciador.
En nuestra investigación detectamos que la mayoría de los usuarios con diversidad funcional prefieren la normalidad y la inclusión. Quieren sentirse parte de la sociedad y utilizar en la medida de lo posible las mismas herramientas. - Mapa GPS con función de trayecto “puerta a puerta”.
La actual aplicación de la EMT de Madrid solo ofrece la localización de las paradas pero no contempla la posibilidad de planificar rutas “puerta a puerta” como otras aplicaciones que utilizan en su día a día. - Comunidad colaborativa y gamificación.
Las alertas o incidencias que puedan ocurrir en el trayecto/parada/bus son generadas por los propios usuarios en tiempo real. Se premiará la actividad mediante una gamificación y posterior bonificación.
ARQUITECTURA DE LA INFORMACIÓN
Realizamos un blueprint para visualizar sobre el papel todas las partes implicadas en el servicio, desde el usuario, la empresa y la propia API de Geolocalización que utilizaremos como piedra angular de nuestro diseño. La utilización de esta API nos brindará, a su vez, un valor añadido en nuestro modelo de negocio como la gestión de flotas y la trazabilidad de los datos.
DÁNDOLE FORMA A LA IDEA
El blueprint nos ayudó a comprender mejor la mecánica de los distintos servicios y cómo actuaban terceras partes, pero no terminaba de explicar la mecánica de la comunidad colaborativa. En este caso tendríamos dos clases de usuarios:
- Activos: Usuarios registrados que aportan información en tiempo real.
- Pasivos: Usuarios no registrados que solo visualizarán información pero no podrán aportar, es decir, estarán fuera del sistema de gamificación y bonificación.
El diagrama de flujo nos ayuda a explicar la dualidad de nuestro producto y dimensionar cuántas pantallas se deberían generar para explicar correctamente la aplicación. Antes de diseñar en alta fidelidad realizamos los wireframes en baja fidelidad.
APP | EMT MADRID
Funcionalidad GPS “puerta a puerta”
Necesidad de una herramienta que unifique distintas apps.
El usuario podrá saber la ruta completa desde que sale de casa hasta el destino final. En todo momento tendrá información relevante sobre el bus/parada proporcionada por la geolocalización y las contribuciones de los usuarios de la comunidad.
Alertas
Necesidad de autosuficiencia.
El usuario podrá configurar las alertas que reciba en el trayecto. Información del tráfico, Comunidad EMT, de la Línea elegida y el Autobús en camino.
Comunidad EMT
Mapa colaborativo de información.
Cruzamos la necesidad de autosuficiencia de las personas con diversidad funcional con el objetivo de lograr aumentar el porcentaje de utilización del bus mediante la gamificación y bonificación.
