Diseño para apps IoT: lo que aprendimos construyendo Nexo Go

Las apps de IoT tienen un problema de diseño que la mayoría de frameworks de UX no contemplan: el estado del sistema no está en el servidor — está en el mundo físico. Un botón que debería estar activo puede estarlo o no dependiendo de si el dispositivo tiene señal, si está en rango Bluetooth, si la batería del hardware llegó al mínimo.

Diseñar Nexo Go — la app de tracking y seguridad para bicicletas eléctricas de la misma marca — nos hizo entender que el diseño IoT es fundamentalmente diseño de estados de incertidumbre. Cada pantalla tiene que funcionar cuando el dispositivo está conectado, cuando está en proceso de conectarse, cuando perdió señal y cuando el hardware está offline.

El mapa de estados como primer entregable

En un proyecto convencional de app, el mapa de navegación suele ser el primer entregable estructural. En Nexo Go, lo primero que construimos fue el mapa de estados de conectividad. Definimos cuatro estados base del dispositivo y cómo cada pantalla de la app debía comportarse en cada uno.

• Conectado y activo: todos los features disponibles, mapa en tiempo real, alertas funcionando.
• Conectando: skeleton states en lugar de spinners genéricos, con el último estado conocido visible para no dejar al usuario sin información.
• Señal perdida: la app muestra el último estado conocido con timestamp claro, y el mapa congela la última posición registrada. No se muestra error — se muestra información.
• Hardware offline: modo histórico automático con datos de los últimos 7 días, sin que el usuario tenga que cambiar de vista manualmente.

En IoT, el error más caro de diseño es mostrar "sin conexión" cuando deberías mostrar el último estado conocido.

El reto del onboarding con hardware físico

Emparejar un dispositivo IoT es el primer punto de fricción. El usuario tiene la app, tiene la bicicleta, tiene el rastreador GPS en la mano, y tiene que hacer que todo se comunique. Si ese flujo falla o confunde, el usuario desinstala antes de ver el valor del producto.

Diseñamos el onboarding de Nexo Go con una regla: cada paso debe tener retroalimentación visible de que el sistema está progresando. Nada de pantallas estáticas que el usuario no sabe si están "cargando" o "esperando". Animaciones sutiles de progreso, confirmaciones de cada etapa completada, y un fallback explícito si el emparejamiento falla.

Diseño de alertas bajo estrés

Nexo Go tiene un sistema de alertas de robo. El momento en que un usuario recibe una alerta de movimiento sospechoso no es el momento en que puede analizar una interfaz compleja. Está en estrés, posiblemente en movimiento, con el teléfono en la mano y quizás poca luz.

El diseño de la pantalla de alerta tiene una sola acción primaria: ver ubicación en tiempo real. Las acciones secundarias (notificar a contacto de emergencia, marcar como falsa alarma) están accesibles pero no compiten visualmente. El mapa ocupa el 70% de la pantalla. El resto es mínimo.

El resultado que validó el diseño

Desde el lanzamiento de Nexo Go, los usuarios activos que tienen el rastreador instalado tienen cero robos reportados. No es solo el hardware — es que la app les da suficiente visibilidad y suficiente rapidez de respuesta para actuar antes de que el robo se complete.

El UX de IoT no es difícil por razones técnicas. Es difícil porque el mundo físico introduce variables que el diseño convencional de apps no contempla. Una vez que tienes ese modelo mental, el diseño se vuelve más honesto — y más útil.