Prototip d'app: què cal validar abans de desenvolupar una aplicació

Tens una idea aparentment clara: una app perquè els teus clients facin sol·licituds i el teu equip les gestioni sense dependre de trucades, missatges i fulls de càlcul. Però, quan intentes explicar-la, sorgeixen preguntes incòmodes: què ha de veure cada usuari?, quins passos són realment necessaris?, què passa si falta una dada? i cal una app mòbil o n'hi hauria prou amb una altra solució?

Un prototip d'app serveix per respondre aquestes preguntes abans de desenvolupar. Encara no demostra que el sistema funcioni amb dades reals ni substitueix les proves tècniques, però permet revisar com s'utilitzaria, quines funcions justifiquen la primera versió i quines decisions continuen obertes. En acabar aquest article podràs decidir si la teva idea està preparada per prototipar-se i què hauries de validar en aquesta fase.

Situació inicial hipotètica: una empresa vol ordenar les sol·licituds de servei

Imagina, de manera hipotètica, una petita empresa de manteniment. Els seus clients contacten per telèfon, correu i missatgeria per demanar una visita. Una persona de l'equip recull les dades, les anota en un full de càlcul i comunica l'encàrrec al tècnic disponible.

L'empresa planteja una app amb una petició àmplia: “Els clients haurien de poder sol·licitar un servei i consultar-ne l'estat”. La idea sembla senzilla, però inclou diverses decisions diferents:

• El client ha d'identificar l'equip o la ubicació a què es refereix la sol·licitud.
• L'equip intern necessita revisar la informació abans d'assignar una visita.
• El tècnic ha de conèixer la feina pendent i actualitzar-ne l'estat.
• L'empresa ha de decidir quina informació veurà el client en cada moment.

Construir directament aquestes funcions obligaria a prendre moltes decisions durant el desenvolupament. Un prototip permet traslladar-les abans a una pantalla i comentar-les amb exemples concrets.

Problema observable: la idea encara no defineix l'ús real

El problema no és que faltin pantalles atractives. Falta una descripció compartida de les accions i les regles que sostenen el procés.

Per exemple, “sol·licitar una visita” pot significar que el client tria una data, que proposa diverses franges, que adjunta imatges o que només deixa un avís perquè l'empresa contacti més endavant. Cada alternativa modifica la informació necessària, la feina de l'equip i l'abast de l'aplicació.

També convé separar dues qüestions que sovint es barregen:

• L'experiència d'ús: què veu una persona, què pot fer i com avança per l'app.
• El funcionament tècnic: on es desen les dades, com es connecten altres eines, quins permisos hi ha o com es gestionen els errors.

Un prototip se centra principalment en la primera. Pot representar botons, formularis, pantalles i transicions per comprovar si el recorregut té sentit. Les integracions, la seguretat, la gestió de comptes o la disponibilitat d'una eina externa s'han d'analitzar a part abans de convertir una simulació en una solució operativa.

Anàlisi de l'objectiu: definir què ha de canviar

En el cas hipotètic, l'objectiu no hauria de ser “tenir una app”. Es podria formular així: permetre que el client comuniqui una necessitat amb la informació suficient i que l'equip la gestioni amb un estat visible.

Aquesta formulació ajuda perquè permet valorar cada funció segons la seva aportació al resultat. Si una pantalla no ajuda a registrar, revisar, assignar o consultar una sol·licitud, potser no correspon a la primera versió.

Abans de crear el prototip, convé concretar com a mínim aquestes decisions:

1. Qui l'utilitzarà. Un client, una persona de coordinació i un tècnic no necessiten les mateixes pantalles ni els mateixos permisos.
2. Quina és l'acció principal. En aquest exemple, registrar una sol·licitud i conèixer-ne l'evolució.
3. Quina informació és necessària. Ubicació, tipus d'incidència, descripció, imatges o una via de contacte són camps possibles; no tots han de ser obligatoris.
4. Quins estats existeixen. “Rebuda”, “en revisió”, “programada” i “tancada” podrien ser estats hipotètics, sempre que l'empresa pugui explicar què significa cadascun i qui el pot modificar.
5. Com es reconeixerà que el recorregut està ben definit. Per exemple, una persona pot completar una sol·licitud sense necessitat d'instruccions i l'equip entén què ha de fer després.

L'objectiu l'ha de validar qui coneix l'operativa diària. Un prototip fa visibles les suposicions, però no pot decidir per si sol quina regla comercial o operativa convé aplicar.

Abast proposat: representar el recorregut mínim

Per a aquest cas hipotètic, el primer prototip no necessita representar tot el negoci. Es podria limitar al recorregut que permet comprovar la proposta principal:

D'entrada, en quedarien fora elements com ara pagaments, facturació, avisos automàtics, informes complexos, connexió amb programes existents o gestió avançada d'usuaris. No perquè no tinguin valor, sinó perquè afegir-los sense haver validat el flux principal pot dificultar la revisió.

L'abast d'un prototip també ha d'expressar allò que no simula. Una pantalla de calendari, per exemple, pot servir per parlar de disponibilitat i reserva, però no confirma que posteriorment es pugui connectar amb l'agenda que ja utilitza l'empresa. Aquesta dependència requereix revisió tècnica i accés a l'eina corresponent.

Solució i comprovació: passar de pantalles a decisions verificables

Amb l'abast delimitat, es crea una representació navegable de les pantalles principals. La persona que revisa el prototip no s'hauria de limitar a opinar sobre colors o botons. Hauria de recórrer situacions concretes.

En l'exemple, una comprovació útil seria aquesta:

Un client hipotètic necessita comunicar una avaria. Selecciona el lloc, descriu el problema, adjunta una imatge si en té i envia la sol·licitud. Després veu una confirmació i pot consultar que l'avís s'ha rebut. La persona de coordinació obre el detall i hi troba les dades necessàries per assignar la feina.

Aquest recorregut permet detectar preguntes pràctiques:

• El client sap quina informació ha d'aportar abans d'enviar-la?
• Hi ha camps que es demanen però no s'utilitzen?
• L'equip entén quan una sol·licitud està a punt per ser assignada?
• L'estat que veu el client és clar i coherent amb l'operativa interna?
• Què ha de passar si la sol·licitud arriba incompleta o es duplica?

La comprovació té més valor si es fa amb persones que assumirien cada paper. Les seves observacions no obliguen a incorporar qualsevol preferència, però ajuden a distingir un problema d'ús d'una petició secundària.

Després de la revisió, cada troballa s'hauria de convertir en una decisió: mantenir una funció, modificar-la, ajornar-la o excloure-la. Així, el prototip deixa de ser una presentació visual i es converteix en una base per definir requisits, criteris d'acceptació i prioritats de desenvolupament.

Aprenentatges transferibles al teu projecte

El cas és hipotètic, però la lògica es pot aplicar a moltes idees d'aplicació: un portal per a clients, una eina interna, un sistema de reserves o una app per gestionar serveis.

Un prototip d'app és especialment útil quan coneixes el problema, però encara necessites aclarir el recorregut, els perfils d'usuari i el contingut de la primera versió. També pot revelar que una aplicació mòbil no és la solució més adequada: si l'ús es produeix principalment des d'un ordinador d'oficina, una aplicació web podria ajustar-s'hi millor. Aquesta elecció depèn dels usuaris, del context d'ús i de les necessitats reals, no del nom inicial del projecte.

La decisió important no és quantes pantalles tindrà el prototip. És quina incertesa vols reduir abans de desenvolupar: la manera d'utilitzar la solució, les prioritats, les regles de negoci o les dependències amb sistemes existents.

Si necessites convertir una idea encara oberta en un abast revisable, pots explicar el teu projecte d'aplicació a AVSISTEC. El punt de partida serà concretar el problema, els usuaris i les decisions que convé validar abans de triar una solució tècnica.