Desafíos a superar cuando creamos Aplicaciones móviles para manejar Dispositivos Bluetooth

Desarrollar aplicaciones móviles compatibles con Bluetooth es una tarea compleja, especialmente cuando la aplicación recibe y envía datos continuamente al dispositivo Bluetooth. ¿Qué desafíos tenemos que superar los Product Managers, desarrolladores y diseñadores para conseguir una excelente experiencia de usuario?

Como Product Manager (PM), estoy acostumbrada a trabajar con productos digitales complejos. Sin embargo, recientemente he estado trabajando en la creación de una aplicación que soporta una funcionalidad “inteligente” habilitada por Bluetooth, que resultó ser un reto especialmente difícil; desde conseguir la experiencia de usuario perfecta; hasta cada toma de decisiones sobre cómo estructurar la aplicación para presentar la información que necesita el usuario, de la mejor manera posible y en el momento adecuado.

Esta experiencia me enseñó cómo evitar errores durante el desarrollo de aplicaciones creadas para comunicarse con dispositivos Bluetooth; especialmente cuando la aplicación no solo recibe datos del dispositivo Bluetooth, sino que también los envía continuamente. Aquí están mis principales recomendaciones para los PM, desarrolladores y diseñadores que se puedan encontrar algún día en mi situación:

1. Unificar la definición de terminologías básicas para facilitar la comunicación entre los miembros del proyecto.

Uno de los desafíos inesperados con los que me enfrenté durante este proyecto, fue la confusión causada por la terminología relacionada con la tecnología Bluetooth. Aunque el Bluetooth existe desde hace años, no todo el mundo está familiarizado con los términos relacionados o los utiliza de la misma forma. Por ejemplo: emparejamiento frente a conexión, BLE, UUID, configuración obligatoria vs. permisos necesarios para el correcto funcionamiento de la aplicación, búsqueda de periféricos frente a conexión, etc.

Después de ver algunos de los problemas de comunicación al comienzo del proyecto, creé un glosario para estandarizar el lenguaje utilizado en el proyecto para todo el equipo. De esa manera, todos los integrantes consiguieron comunicarse mejor y evitar malos entendidos.

Este primer paso ayudó a reducir la fricción, crear una comunicación más fluida y tener los requisitos del proyecto más claros y, lo más importante, ¡ahorrar tiempo! En futuros proyectos tecnológicos de gran complejidad, lo primero que voy a hacer será escribir un glosario de términos relacionados con el proyecto para el equipo.

2. Identificar lo que el usuario realmente necesita saber y cuándo

Si hay un desafío único relacionado con la administración de dispositivos con Bluetooth en una app, este es sin duda la experiencia de usuario. Si alguna vez has utilizado Bluetooth, seguramente te has hecho las siguientes preguntas: ¿Está conectado el dispositivo? ¿Por qué no puedo activar esta funcionalidad? ¿Qué salió mal? ¿El estado que estoy viendo en la aplicación es el más reciente o hay un problema de sincronización?

Decidimos abordar primero los desafíos de UX, identificando lo que el usuario necesita saber en los momentos clave de la aplicación, y lo que no. Como PM, necesitaba traducir la complejidad del sistema de forma clara y sencilla para ayudar a los usuarios a comprender la comunicación de la aplicación con su dispositivo. Identificar y alinear la información importante por adelantado, facilitó que el equipo trabajara de una manera más eficiente. De esta manera, los diseñadores de UI tenían una idea más clara de la lógica y la arquitectura de las interacciones del usuario, lo que les permitió centrarse primero en las interacciones principales y desarrollar un diseño que funcionara bien, independientemente de las limitaciones tecnológicas o de conectividad. Además, los desarrolladores podrían reconocer los requisitos de la API y priorizarlos en consecuencia.

Una vez que supimos lo que necesitábamos contarle al usuario y cuándo, establecimos la información que los usuarios necesitan conocer en todo momento. Por ejemplo, imagina que un usuario está administrando el sistema de seguridad de su hogar desde una aplicación móvil. Los datos confidenciales que querrán saber serán: ¿Está activada la alarma ahora? ¿Están grabando las cámaras de seguridad? ¿Cuándo se apagaron / encendieron las cámaras?. Al identificar los datos más importantes para el usuario, también podemos establecer qué datos deben provenir del hardware (y solo están disponibles cuando se está conectado a la aplicación) frente a qué datos pueden gestionarse en un backend / plataforma y, por lo tanto, accesibles directamente en la aplicación con una conexión a Internet.

Otro ejemplo, imagina un dispositivo inteligente que necesita un nivel de batería del x% para funcionar bien. El nivel actual de la batería solo es visible para el usuario cuando el dispositivo y la aplicación están conectados. Pero si fuera una prioridad para los usuarios ver los patrones de uso de la batería, entonces, mientras el dispositivo estuviera conectado, podría enviar continuamente el nivel de la batería a la aplicación y al backend. Por lo tanto, más tarde se podría ver un gráfico de uso en la aplicación, independientemente de si el hardware estaba conectado en ese momento o no.

3. Aclarar qué se puede según el estado de la aplicación: conectado vs. desconectado

Una aplicación que depende del Bluetooth sólo puede comunicarse con el hardware cuando está conectada, por lo que necesitábamos identificar la funcionalidad que debería estar disponible para los usuarios tanto cuando están conectados como desconectados. También necesitábamos hacer que esos estados y capacidades fueran intuitivos y fáciles de interpretar.

Decidí comparar esto con la forma en que podría pasar en los modos “en línea” y “fuera de línea” con ciertas aplicaciones web, como el modo básico sin conexión de “solo lectura” o de “edición” en un documento de Google. El modo de “solo lectura” es similar a cuando Bluetooth está desconectado, y solo podemos mostrarle al usuario el estado actual del dispositivo. El modo de “edición”, equivale a cuando Bluetooth está activo, permitiendo que el usuario pueda realizar acciones desde la aplicación hasta el dispositivo inteligente.

Ahora considera cómo sería esa experiencia si Google no dejara claro las funcionalidades de un usuario cuando éste está o no conectado. El usuario puede tocar los botones y no entender por qué no funcionan o por qué se han desactivado ciertas opciones. Puede que lea el contenido mostrado sin darse cuenta de que no es el más reciente y, sin duda, eso causaría una experiencia frustrante para el usuario. Por lo tanto, es igual de importante considerar cómo gestionar los estados cuando no hay ningún dispositivo externo conectado. ¿Debemos animar a los usuarios a que se conecten de inmediato o hay una funcionalidad importante que el usuario puede hacer sin conexión? (nunca debes permitir que los usuarios se sientan “bloqueados” por no estar conectados). En general, asegúrate de marcarles los pasos a seguir de forma intuitiva y añade comentarios en tiempo real sobre lo que está sucediendo a través de mensajes y animaciones. Cuando sea necesario, ofrece fácil acceso a ayuda o tutoriales.

También es importante definir qué está disponible para el usuario y cuándo. Esto se vuelve especialmente importante en los casos en los que la aplicación puede conectarse y gestionar varios equipos de hardware. Asegúrate de diseñar el sistema de forma coherente, dejando claro cuál es la pieza de hardware que se está utilizando, sus estados actuales y funciones disponibles. Además, presenta las funcionalidades clave y su estado de activación actual de una manera que minimice la demanda de atención del usuario. Esto ayuda a reducir la frustración ante las limitaciones de Bluetooth, lo que les permite comprender lo que está sucediendo, el estado más reciente y lo que deben hacer a continuación.

4. Hacer que las limitaciones tecnológicas sean menos relevantes para el usuario

Para finalizar, el último punto, pero no por eso menos importante, es el del aprendizaje.

Dicen que “si no puedes vencerlos, únete a ellos”; lo mismo ocurre con la tecnología compleja. Las restricciones de Bluetooth incluyen límites en el alcance, complejidad de administrar varios dispositivos conectados a la vez y los que pueden parecer tiempos de conectividad terriblemente largos. Como PM de una app que depende de la tecnología Bluetooth, tienes que aceptar la realidad de lidiar con estas limitaciones y encontrar la mejor manera para abordarlas inteligentemente.

Es importante aprovechar las herramientas de UX disponibles para que estas limitaciones sean menos relevantes. Por ejemplo:

  • Sigue las convenciones establecidas de la plataforma para que los elementos de la aplicación sean reconocibles. No es momento de reinventar la rueda. Por ejemplo, casi todo el mundo está familiarizado con el icono de Bluetooth, por lo que tus diseñadores no necesitan crear su propia versión. El cambiarlo sólo conseguiría confundir a los usuarios.

  • Si la aplicación necesita permisos, asegúrate de explicar el motivo al usuario y hazlo por adelantado para asegurar que tenga una mejor experiencia. No quieres que tus usuarios usen la app dependiente de Bluetooth sin la capacidad de hacer nada debido a la falta de permisos.

  • Considera la experiencia del usuario para varios escenarios, como tiempos de carga, búsqueda de dispositivos dentro del alcance, posible pérdida de conectividad u otro teléfono “robando” el control (cuando otro usuario o aplicación se conecta a ese dispositivo y, como resultado, desconecta al primer usuario) .

  • Utiliza una señalización clara para las interacciones entre dispositivos / usuarios y la sincronización de datos / contenido. Los usuarios no quieren llevarse sorpresas desagradables, así que recuerda mantenerlos informados, especialmente con actualizaciones de datos importantes.

  • Encuentra formas creativas de manejar los datos y el contenido, cómo proporcionar información de cuándo ocurrió la “última sincronización”. Debes encontrar un equilibrio entre la transparencia de datos y la explicación excesiva. Brindar detalles demasiado complejos sobre cómo funciona el sistema probablemente confundiría al usuario. Por otro lado, si no explicas los retrasos o una mala ejecución de un comando activado, puedes dar lugar a suposiciones incorrectas y como resultado, una mala experiencia.


La complejidad técnica variará mucho entre proyectos, pero espero que estos consejos te ayuden a abordar los desafíos de desarrollar productos habilitados para Bluetooth. Recuerda establecer un entendimiento compartido de términos comunes con tu equipo, identificar lo que el usuario necesita saber y cuándo, definir la funcionalidad necesaria para diferentes estados y, lo más importante, aprender a trabajar dentro de las limitaciones técnicas de la tecnología Bluetooth.

Si estás interesado en leer más sobre este tema, aquí hay algunos artículos interesantes que puedes consultar (lectura en inglés):