App mòbil o webapp: com decidir el format del teu producte

Una webapp s’utilitza a través d’un navegador. Una app mòbil instal·lada té una presència pròpia al dispositiu i un procés de distribució i actualització que cal gestionar. Per comparar-les, dibuixa el primer accés: des d’un correu, un cercador, un codi o una indicació de l’empresa. Decideix quants passos són raonables abans que la persona pugui completar la seva tasca.

La freqüència també pesa. Imagina un servei que es consulta una vegada per preparar una sol·licitud i una eina que s’obre cada dia per registrar feina. El valor de tenir una aplicació instal·lada pot ser diferent en cada cas. Anota per què l’usuari tornaria, com trobaria el producte i què necessitaria conservar entre sessions.

Si el producte necessita càmera, fitxers, ubicació o avisos, descriu l’acció exacta. Fer una fotografia puntual i mantenir una captura continuada són requisits diferents. Per a cada funció, identifica els dispositius previstos, els permisos necessaris i què ha de passar si la persona no els concedeix. Aquesta llista permet investigar les opcions amb un objectiu concret.

Les capacitats disponibles depenen del dispositiu, del sistema i de l’entorn d’execució. Evita triar a partir d’una afirmació general com ara que un format pot fer de tot. Demana una prova petita del requisit que més condiciona el projecte. Si una tasca essencial no funciona com esperes als dispositius previstos, cal saber-ho abans de desenvolupar la resta.

Treballar sense connexió implica decidir quina informació queda disponible, què es pot modificar i quan es sincronitza. En una aplicació de visites, per exemple, pot ser suficient consultar una adreça guardada. En una eina de registre, pot ser necessari crear anotacions i enviar-les després. Són comportaments que s’han de descriure i provar, sigui quin sigui el format escollit.

Pensa també en els conflictes. Si dues persones modifiquen el mateix registre abans de recuperar la connexió, algú ha de decidir què es conserva. La interfície ha d’indicar si una acció està guardada al dispositiu, pendent d’enviament o confirmada. Acordar aquestes situacions evita que una demostració amb bona connexió amagui una dificultat important del producte.

El format visible per a l’usuari és una part del sistema. Pot haver-hi un servei que guarda dades, un panell de gestió, continguts que algú actualitza i integracions amb eines existents. Identifica qui farà cada tasca i des de quin dispositiu. Una app per als usuaris pot conviure amb un panell web per a l’equip, amb necessitats diferents.

Demana com es prepararan les actualitzacions, quins entorns s’hauran de revisar i qui gestionarà els accessos. En una app distribuïda a través de botigues, preveu les tasques de preparació i seguiment del procés de publicació. Una data desitjada no substitueix aquests passos. L’equip ha de distingir el producte preparat per presentar del producte disponible per als usuaris.

Abans d’escollir, prepara un recorregut que inclogui accés, acció principal i resultat. Prova’l amb contingut semblant al real i amb la persona que l’haurà d’utilitzar. Observa on dubta, què necessita consultar i què espera que quedi guardat. Un prototip ajuda a revisar la comprensió; una prova tècnica resol les incerteses sobre dispositius, connexió o integracions.

Deixa escrita la decisió amb els seus motius i les condicions que la podrien fer canviar. Potser la prioritat inicial és facilitar l’accés per enllaç; potser és completar una tasca recurrent amb requisits específics del dispositiu. Escollir el format per aquesta necessitat permet acotar una primera versió i revisar l’evolució sense haver de justificar una tecnologia escollida per costum.

• Com arribarà l’usuari al producte per primera vegada?
• Què farà sovint i què farà només puntualment?
• Quina funció exigeix una prova al dispositiu?
• Què ha de continuar funcionant sense connexió?
• Qui gestionarà continguts, accessos i actualitzacions?