Navegar con un barco dirigido desde el móvil

El producto es un piloto automático para embarcaciones de recreo: un dispositivo físico, una especie de volante, que gobierna el barco. La app se empareja con él desde el móvil y, una vez emparejada, lo controla. El propietario configura el barco, dibuja una ruta sobre un mapa y el barco la sigue.

Por eso el mapa es el centro de la app. A su alrededor están las rutas, las notificaciones, los barcos, la cámara y la cuenta, y dos modos de uso: explorar y navegar.

Trabajé con otro diseñador, a través de una agencia que llevaba la relación con el cliente. Nos repartimos así: todo lo anterior al diseño visual era mío, es decir, convertir la idea en un producto, organizar sus funciones, definir los flujos y construir los wireframes. Mi compañero marcó la dirección visual, y yo le eché una mano produciendo pantallas.

El trabajo, por orden:

1. 01RequisitosLa lista del cliente y las historias de usuario, agrupadas por función.
2. 02Mapa funcionalPor capas y pantallas, con cada función unida al número de su requisito. Dos versiones en una semana.
3. 03FlujosCinco, cada uno con su código: inicio de sesión, registro, onboarding, emparejamiento y creación de rutas.
4. 04WireframesTrece grupos, del mapa a los ajustes, con notas sobre cómo se comporta cada pantalla.
5. 05Diseño visualDirigido por mi compañero; yo produje pantallas bajo su dirección.

Y las decisiones que le dieron forma:

• Cada función lleva el número de su requisito

  Con el hardware cambiando y el cliente a un intermediario de distancia, necesitaba saber qué tocaba cada cambio. Por eso el mapa funcional une cada función de la app con el requisito numerado del cliente. Cuando llegaban novedades sobre la rueda, el mapa enseñaba qué pantallas dependían de ella. Lo barato habría sido un mapa del sitio normal, que nos habría dicho dónde estaban las cosas, pero no por qué estaban ahí.

• El emparejamiento se diseña desde sus fallos

  El camino previsto es corto: acercas el móvil a la rueda y la app avanza sola. Lo que había que diseñar era todo lo demás: el Bluetooth apagado, el dispositivo fuera del modo de emparejamiento, el móvil que no lo encuentra, la luz que no parpadea. Cada caso tiene su instrucción y su salida, hasta llegar al soporte técnico. Los permisos del móvil, además, se piden cuando una función los necesita y no al abrir la app, con una nota sobre lo que deja de funcionar si se deniegan.

• Tres maneras de crear una ruta, una sola de editarla

  Una ruta se puede importar de un archivo, construir punto a punto o dibujar a mano alzada sobre el mapa. Hicieron falta varias propuestas para que las tres convivieran. Lo que comparten es la edición: una pulsación larga añade un punto, arrastrar lo mueve y pulsar la línea entre dos puntos inserta otro. Un punto también se puede escribir como coordenadas o elegir en una búsqueda de lugares de interés.

• Solo el capitán puede ceder el timón

  La app también es para quien alquila un barco y viaja en grupo. Unirse a un barco como tripulación es sencillo: acercas el móvil a la rueda y el propietario te acepta desde una notificación. Ceder el control no lo es: solo puede hacerlo el capitán. Saber quién más va a bordo antes de salir es además una medida de seguridad, para el día en que el móvil del capitán se vaya por la borda.

La app de un dispositivo físico nunca está más cerrada que el propio dispositivo. Una señal de emparejamiento o un límite de la rueda pueden cambiar varias pantallas, así que el comportamiento del hardware tiene que quedar por escrito antes de dar un flujo por terminado. Si pudimos reabrir cosas sin empezar de cero fue porque cada requisito estaba unido a sus funciones, y cada función a sus flujos.

Por desgracia no pudimos hacer un seguimiento, por lo que no puedo decir cuánto de la app publicada es nuestro, pantalla a pantalla: no las he comparado. Tampoco probamos con navegantes en el agua, y es justo en lo que hoy insistiría.