High Mobility

Conectando apps con autos inteligentes

2020. Berlin, Alemania

Sobre el proyecto

En el año 2017 decidí viajar a Berlin, en búsqueda de nuevas experiencias. Me quedé a vivir allí y trabajé por casi 4 años para High-Mobility.

High-Mobility es un startup que ofrece una API universal para autos conectados a internet. El mercado de autos conectados a internet es algo reciente y se encuentra en crecimiento exponencial. High-Mobility permite desarrollar aplicaciones que pueden conectarse de manera universal con todos los fabricantes de autos del mercado. Es decir, que si un equipo quiere desarrollar una app para seguros de autos, en donde puedan trackear la información del mismo, no necesitan desarrollar para cada fabricante y modelo disponible, ya que con High-Mobility pueden realizar un solo trabajo que funciona con todo el mercado. Junto a esto, provee una serie de herramientas para el testeo sin necesidad de tener un auto real.

El desafío

Inicialmente el proyecto era un entorno de testeo en un emulador virtual. Los desarrolladores solamente podían testear sus desarrollos realizados con la Auto API en un emulador que simulaba el comportamiento de un auto real.

Con el crecimiento del proyecto, el avance de la tecnología y el lanzamiento de regulaciones europeas como GDPR, High-Mobility logró asociarse con los fabricantes de automóviles líderes del mercado alemán. Este gran paso para el proyecto planteó un nuevo desafío, permitir que los desarrolladores no solo testeen en un ambiente virtual, sino que además, puedan publicar sus aplicaciones, y conectarlas con diferentes marcas y modelos de autos. El proyecto comenzaba a tener vida.

¿Qué implicaba esto? Que el usuario debía poder realizar un proceso de presentación y verificación de la aplicación, para su posterior publicación. Nos encontramos con la necesidad de reestructurar la plataforma, de agregar nuevos features y crear nuevos roles de usuarios.

En el relevamiento inicial, nos encontramos con la diversidad de costos, requerimientos técnicos y legales que ofrecía cada fabricante. Algunos lo manejaban por cantidad de requests, otros por cantidad de autos conectados, otros tenían descuentos por volumen, otros requerían una validación manual, otros ofrecían una validación automática… Muchísimas variables, que debíamos agrupar en un solo canal de comunicación para nuestros usuarios.

Investigación

Al ser un producto innovador y nuevo en el mercado, no teníamos posibilidad de hacer un benchmark de competencia. Sin embargo, tomamos como referencia el proceso de publicación de apps de AppStore y Google Play. El proceso, como concepto, era bastante similar.

En cuanto a nuestros usuarios, realizamos una serie de entrevistas con algunos integrantes de equipos de desarrollos que utilizan High Mobility. Pudimos obtener información de buenas prácticas de procesos similares, del uso de nuestra herramienta y opiniones de necesidades ausentes en este nicho de mercado.

User goal

Publicar una aplicación para su vinculación con autos conectados

De parte del equipo de negocio, tuvimos un brief detallado acerca del objetivo a alcanzar. De esa sesión y de un análisis posterior, identificamos las siguientes user stories que el usuario debería realizar:

Crear una aplicación o importarla del entorno de desarrollo.

Seleccionar los permisos que la aplicación requiere tener acceso del auto, con posibilidad de ver fabricantes disponibles y costos.

Agregar información sobre la aplicación, como una descripción, links, imágenes, video.

Agregar métodos de pago y facturación.

Poder estar informado del estado del proceso de verificación y publicación.

Acceder a un canal de comunicación para recibir feedback.

Éste planteo de funcionalidades, nos permitió definir una arquitectura para la nueva sección, que en adelante sería llamada “Producción”.

User roles

Ante las user stories definidas anteriormente, descubrimos que existía la necesidad de un user administrador, que verifique y modere las aplicaciones publicadas por los usuarios. Pero debido a los requerimientos de algunos fabricantes, la revisión debía ser realizada también por ellos mismos. Por lo tanto, no solo High Mobility debía moderar lo publicado, sino que luego necesitabamos obtener la aprobación del fabricante.Es así que identificamos tres roles de usuarios: Desarrolladores, Superteam (admin) y Fabricantes. Cada uno de ellos tendría diferentes objetivos y funcionalidades.

User stories en Airtable

Ante la gran cantidad de user stories por cada usuario, y el impacto que cada uno de estas acciones tiene en los otros roles de usuario, decidimos organizar cada user story por cada user role en Airtable. A esto le sumamos las diferentes prioridades de publicación, no todos los features serían publicados en el primer release, por lo tanto, eso fue también tenido en cuenta para la organización.

La selección de permisos

Los permisos o “data points” son todos los puntos de datos posibles de obtener información o editar. Así como un celular requiere permisos para acceder a la ubicación, a la cámara, contactos, etc., los autos requieren permisos para obtener la ubicación, nivel de combustible, velocidad, apertura de puertas, nivel de aceite, entre otros 140 más.

La selección de permisos fue uno de los desafíos mas dificultosos del proceso. Teníamos muchos requisitos definidos, como por ejemplo:

Organizar y agrupar los 140 puntos de datos en sus diferentes grupos

Ofrecer selecciones rápidas de casos de usos, como puede ser aplicaciones para seguros, para mantenimiento, parking, etc

Informar al usuario cuales están disponibles para testeo y cuales están disponibles para producción

Informar qué fabricantes están disponibles para la selección

Informar cual es el precio, descuentos y otra información técnica por cada fabricante

Adaptar los requisitos de cada fabricante en una subscripción de pago unificada

Para poder identificar un orden de lectura y de acción, realizamos un storytellingdel cual concluimos el siguiente orden:

  1. Selección de preset
  2. Selección de permisos o data points
  3. Ver fabricantes disponibles
  4. Ver costos
  5. Ver detalle

Flujo y prototipo final

Finalmente logramos dar con un prototipo final para el primer release. Se realizaron pruebas con usuarios internas en el equipo, lo que permitió ajustar algunas funcionalidades, y quitar otras que identificamos que en este momento del proceso generaban más ruido que soluciones.