Com superar els obstacles a l’hora de crear aplicacions mòbils per gestionar dispositius Bluetooth

Desenvolupar aplicacions mòbils compatibles amb Bluetooth és una tasca complexa, especialment quan l’aplicació envia i rep dades contínuament al dispositiu Bluetooth. Quins reptes hem de superar els Product Managers, els desenvolupadors i els dissenyadors per aconseguir una bona experiència d’usuari?

Com a Product Manager (PM), estic acostumada a treballar amb productes digitals complexos. Tot i això, fa poc he treballat en la creació d’una aplicació que suporta una funcionalitat “intel·ligent” habilitada per Bluetooth. Aquest projecte va resultar ser un repte especialment difícil; desde aconseguir que l’usuari tingui una bona experiència; fins a l’estructura de les preses de decisions de l’aplicació per a presentar la informació que necessita l’usuari, de la millor manera possible i en el moment adequat.

Aquesta experiència m’ha ensenyat com evitar errors durant el desenvolupament d’aplicacions creades per comunicar-se amb dispositius Bluetooth; especialment quan l’aplicació no només rep dades del dispositiu Bluetooth, sinó que també els envia contínuament. A continuació us detallo les meves principals recomanacions pels Product Managers, desenvolupadors i dissenyadors que es puguin trobar algun dia treballant en un producte com aquest:

1. Unificar la definició de terminologies bàsiques per facilitar la comunicació entre els membres de el projecte.

Un dels reptes als quals em vaig enfrontar a l’inici del projecte, va ser la confusió causada per la terminologia relacionada amb la tecnologia Bluetooth. Tot i que el Bluetooth existeix des de fa anys, no tothom està familiaritzat amb els termes que s’utilitzen per aquest tipus de tecnologia o els utilitzem de la mateixa manera. Per exemple: aparellament davant connexió, BLE, UUID, configuració obligatòria vs. permisos necessaris per al correcte funcionament de l’aplicació, recerca de perifèrics enfront de connexió, etc.

Després de veure alguns dels problemes de comunicació a l’inici del projecte, vaig crear un glossari per estandarditzar el llenguatge utilitzat per a tot l’equip. D’aquesta manera, tots els integrants vam aconseguir comunicar-nos millor i evitar malentesos.

Amb aquest primer pas, es va ajudar a disminuir la fricció, vam crear una comunicació més fluida i també vàrem tenir els requisits del projecte més clars i, el més important, vam estalviar temps! En futurs projectes de gran complexitat, el primer que faré serà escriure un glossari de termes relacionats amb el projecte per a l’equip.

2. Identificar el que l’usuari realment necessita saber i quan

El gran desafiament relacionat amb l’administració de dispositius amb Bluetooth a una app, és sens dubte l’experiència d’usuari. Si alguna vegada has utilitzat Bluetooth com a usuari, segurament t’has fet les següents preguntes: Està connectat el dispositiu? Per què no puc activar aquesta funcionalitat? Què va anar malament? L’estat que estic veient en l’aplicació és el més recent o hi ha un problema de sincronització?

Vam decidir afrontar primer els desafiaments de UX, identificant el que l’usuari necessita saber en els moments clau de l’aplicació, i el que no. Com a PM, necessitava traduir la complexitat del sistema de manera clara i senzilla per ajudar els usuaris a comprendre el funcionament de l’aplicació amb el seu dispositiu. Identificar i alinear la informació important per avançat, va permetre que l’equip treballés d’una manera més eficient. D’aquesta manera, els dissenyadors d’UI tenien una idea més clara de la lògica i l’arquitectura de les interaccions de l’usuari, cosa que els va permetre centrar-se primer en les coses principals i desenvolupar un disseny que funcionés bé, independentment de les limitacions tecnològiques o de connectivitat. A més, els desenvolupadors podrien reconèixer els requisits de l’API i prioritzar-los en conseqüència.

Un cop vam saber el que necessitàvem explicar-li a l’usuari i quan, vam establir quina era la informació que els usuaris necessiten conèixer en tot moment. Per exemple, imagina que un usuari està administrant el sistema de seguretat de la seva llar des d’una aplicació mòbil. Les dades confidencials que voldran saber seran: Està activada l’alarma ara mateix? Estan gravant les càmeres de seguretat? Quan es van apagar / encendre les càmeres? En identificar les dades més importants per a l’usuari, també podem establir quines dades han de provenir del hardware (i que només estan disponibles quan s’està connectat a l’aplicació) vs. les de les que poden gestionar-se en un backend / plataforma i, per tant, que es poden fer accessibles directament en l’aplicació amb una connexió a Internet.

Un altre exemple, imagina un dispositiu intel·ligent que necessita un nivell de bateria del X% per funcionar bé. El nivell actual de la bateria només és visible per a l’usuari quan el dispositiu i l’aplicació estan connectats. Però si fos una prioritat per als usuaris veure els patrons d’ús de la bateria, llavors amb el dispositiu connectat, podria enviar contínuament informació sobre el nivell de la bateria a l’aplicació i al backend. Posteriorment, podria veure un gràfic d’ús en l’aplicació, independentment de si estava connectat en aquell moment o no.

3. Deixar clar què es pot fer segons l’estat de l’aplicació: connectat vs. desconnectat

Una aplicació que depèn de Bluetooth només pot comunicar-se amb el hardware quan està connectada, de manera que necessitàvem identificar la funcionalitat que hauria d’estar disponible pels usuaris tant com si estiguessin connectats com desconnectats. També necessitàvem fer que aquests estats i capacitats fossin intuïtius i fàcils d’interpretar.

D’aquesta manera, vaig decidir comparar els estats “en línia” i “fora de línia” amb certes aplicacions web, com la manera bàsica sense connexió de “només lectura” o d’“edició” en un document de Google. La manera de “només lectura” és similar a quan Bluetooth està desconnectat, i només podem mostrar a l’usuari l’estat actual del dispositiu. L’estat d’“edició”, equival a quan Bluetooth està actiu, permetent que l’usuari pugui realitzar accions des de l’aplicació fins al dispositiu intel·ligent.

Considera ara com seria aquesta experiència si Google no deixés clar les funcionalitats que tenen els usuaris quan estan connectats o no. L’usuari podria tocar els botons i no entendre per què no funcionen les funcionalitats o per què s’han desactivat certes opcions. Potser llegeix el contingut mostrat sense adonar-se’n que no és el més recent i, sens dubte, això causaria una experiència d’usuari frustrant. Per tant, és igual d’important considerar com gestionar els estats quan no hi ha cap dispositiu extern connectat. Hem d’animar els usuaris que es connectin immediatament o hi ha una funcionalitat important que l’usuari pot fer sense connexió? (Mai has de permetre que els usuaris se sentin “bloquejats” per no estar connectats). En general, assegura’t de marcar els passos a seguir de forma intuïtiva i afegeix comentaris en temps real sobre què està passant a través de missatges i animacions. Quan sigui necessari, ofereix accés a ajuda o tutorials.

També és important definir què està disponible per a l’usuari i en quins moments. Això és especialment important en els casos en què l’aplicació pot connectar-se i gestionar diversos equips de hardware. Assegura’t de dissenyar el sistema de manera coherent, deixant clar quina és la peça de hardware que s’està utilitzant, els seus estats actuals i funcions disponibles. A més a més, és important presentar les funcionalitats clau i el seu estat actual d’una manera que minimitzi la necessitat de l’usuari de parar més atenció. Això ajuda a reduir la frustració davant les limitacions de Bluetooth, i permet comprendre el que està passant, quim és l’estat més recent i el que han de fer a continuació.

4. Fer que les limitacions tecnològiques no tinguin tanta importància

L’últim punt, però no per això menys important, és el de l’aprenentatge.

Diuen que “si no pots guanyar contra ells, uneix-te a ells”; el mateix passa amb la tecnologia complexa. Les restriccions de Bluetooth inclouen límits com l’abast, la complexitat d’administrar diversos dispositius connectats a la vegada i els temps de connectivitat llargs. Com a PM d’una app que depèn de la tecnologia Bluetooth, cal acceptar la realitat, veure aquestes limitacions i trobar la millor manera per abordar-les de forma intel·ligent.

És important aprofitar les eines de UX disponibles perquè aquestes limitacions siguin menys rellevants. Per exemple:

  • Segueix les convencions establertes de la plataforma per tal que els elements principals de l’app es puguin reconèixer fàcilment. Per exemple, gairebé tothom està familiaritzat amb la icona de Bluetooth, de manera que els dissenyadors no necessiten crear la seva pròpia versió del mateix icona. Canviar-ho només aconseguiria confondre els usuaris.

  • Si l’aplicació necessita permisos, assegura’t d’explicar el motiu d’aquests permisos a l’usuari. Informa’l per avançat, així t’asseguraràs que tingui una millor experiència.

  • Considera l’experiència d’usuari amb diversos escenaris, com el temps de càrrega, la recerca de dispositius en l’abast, una possible pèrdua de connectivitat o un altre telèfon “robant” el control (quan un altre usuari o aplicació es connecta a aquest dispositiu i, com a resultat, desconnecta al primer usuari).

  • Utilitza una senyalització clara per les interaccions entre dispositius / usuaris i la sincronització de dades / contingut. Evita que els usuaris s’enduguin sorpreses desagradables, així que recorda mantenir-los informats, especialment amb actualitzacions de dades importants.

  • Troba formes creatives de gestionar les dades i el contingut, com proporcionar informació de l’”última sincronització”. Has de trobar un equilibri entre la transparència de dades i l’explicació excessiva del contingut. Donar detalls massa complexos sobre com funciona el sistema probablement és més confós per l’usuari. D’altra banda, si no expliques els retards o una mala execució d’una ordre, pots donar lloc a idees incorrectes i com a resultat, una mala experiència.


La complexitat tècnica variarà molt entre projectes, però espero que aquests consells t’ajudin a gestionar els desafiaments de desenvolupar productes per Bluetooth. Recorda crear un glossari de termes comuns amb el teu equip, identificar el que l’usuari necessita saber i quan, definir la funcionalitat necessària per cada un dels diferents estats i, el més important, aprendre a treballar dins de les limitacions tècniques de la tecnologia Bluetooth.

Si estàs interessat a llegir més sobre aquest tema, aquí hi ha alguns articles interessants que pots consultar (lectura en anglès):