Come scrivere il brief della tua app

Elenca chi usa il sistema e che cosa può vedere o modificare. Distingui almeno l'utente principale, eventuali operatori e l'amministratore. Se esistono responsabili di sede, fornitori o clienti aziendali, chiarisci se condividono dati oppure vedono soltanto quelli del proprio gruppo. I ruoli determinano schermate, permessi, notifiche e test: non sono un dettaglio da aggiungere alla fine.

Descrivi il percorso più importante dall'inizio alla fine, usando verbi semplici. Per esempio: l'utente crea un account, trova un servizio, sceglie una disponibilità, conferma e riceve un riepilogo; l'operatore vede la richiesta e la gestisce. Indica anche gli esiti alternativi: disponibilità terminata, pagamento rifiutato, connessione assente, autorizzazione mancante. Un elenco di schermate non sostituisce il flusso, perché non spiega come una persona raggiunge il risultato.

Dividi le richieste in quattro gruppi: necessarie al primo rilascio, importanti ma rinviabili, idee da verificare ed escluse. Scrivere cosa non entra evita che una parola ampia, come «chat» o «report», venga interpretata in modi diversi. Per ogni funzione necessaria aggiungi la ragione: se non sostiene l'obiettivo o un requisito obbligatorio, probabilmente può aspettare.

Specifica chi usa iPhone, Android, tablet o browser e in quale contesto. Segnala se servono fotocamera, QR code, posizione, Bluetooth, file, biometria o calendario. Per l'offline, elenca cosa deve restare consultabile, cosa può essere creato senza rete e come gestire eventuali modifiche in conflitto. Per le notifiche push, indica evento, destinatario, tempi e alternativa quando il consenso non viene dato. Per i pagamenti, chiarisci se sono una tantum, ricorrenti o legati a beni digitali e chi emette documenti e rimborsi.

Nomina CRM, gestionale, e-commerce, provider di pagamento, calendari o dispositivi che l'app deve usare. Indica chi possiede gli account, se esiste documentazione e chi può fornire credenziali di test. Un'integrazione dipende spesso dalle API messe a disposizione dal sistema esistente: se non esistono, il preventivo deve contemplare un'alternativa o un'attività preliminare di verifica.

Elenca le categorie di dati realmente necessarie, chi può accedervi, per quale scopo e per quanto tempo devono restare disponibili. Evidenzia dati sanitari, documenti, posizione, minori o informazioni finanziarie. Descrivi cancellazione dell'account, esportazione, backup e tracciamento delle azioni amministrative. Il brief non sostituisce l'analisi GDPR, ma consente di progettarla prima che il database e le schermate siano già stati costruiti.

Spiega chi aggiorna contenuti, cataloghi, prezzi o disponibilità e quali report servono davvero. Aggiungi lingue, accessibilità, paesi, scadenze legate a eventi, sistemi già acquistati e un intervallo di budget sostenibile. Se la data è rigida, indica cosa può essere ridotto per rispettarla. Chiudi con materiali disponibili: identità visiva, testi, processi, fogli dati, wireframe e referente autorizzato a prendere decisioni.

Questo caso è inventato esclusivamente per mostrare come compilare un brief. Il Centro Sportivo Aurora usa già un gestionale per soci, abbonamenti e corsi, ma riceve le prenotazioni anche per telefono. L'obiettivo della prima versione è permettere ai soci attivi di consultare i corsi e gestire autonomamente una prenotazione, lasciando allo staff il controllo delle disponibilità.

• Socio: accede con email e codice socio, vede soltanto corsi compatibili con il proprio abbonamento, prenota o annulla e consulta il riepilogo.
• Reception: vede elenco e stato delle prenotazioni, può inserire una persona e bloccare un posto.
• Responsabile: configura regole di prenotazione e consulta un report operativo essenziale.

Il flusso principale è: accesso, scelta del giorno, apertura del corso, conferma, sincronizzazione con il gestionale e riepilogo. Se il corso è completo, la prima versione informa il socio senza creare una lista d'attesa. Se l'abbonamento non è valido, mostra il motivo e invita a contattare la reception.

Nel primo rilascio sono necessarie autenticazione, calendario dei corsi, prenotazione, annullamento, pannello staff e sincronizzazione con il gestionale. Le notifiche push ricordano un corso prenotato; se sono disattivate, il riepilogo resta visibile nell'app. Il QR della tessera può essere consultato dopo una sincronizzazione, mentre nuove prenotazioni richiedono connessione. Pagamenti in-app, lista d'attesa, community e programmi di allenamento sono esplicitamente esclusi e potranno essere valutati dopo l'uso reale.

L'integrazione con il gestionale è una dipendenza: prima del preventivo si verifica che le sue API consentano di leggere abbonamenti e disponibilità e di scrivere prenotazioni. Gli account degli store e del provider cloud devono poter essere intestati al committente. I dati previsti sono anagrafica minima, stato dell'abbonamento e storico delle prenotazioni; il brief richiede regole concordate per accesso dello staff, conservazione, esportazione e cancellazione.

• Dato un socio autenticato con abbonamento valido, quando conferma un corso disponibile, allora la prenotazione appare nel suo riepilogo e nel pannello della reception.
• Dato un corso senza posti, quando il socio prova a prenotare, allora il sistema non registra la richiesta e comunica che il corso è completo.
• Dato un socio che annulla entro il limite configurato, quando conferma l'annullamento, allora il posto torna disponibile e l'operazione resta tracciata.
• Data una sincronizzazione non riuscita, l'app non mostra una conferma definitiva e offre un'azione chiara per riprovare, evitando prenotazioni fantasma.

Questo esempio non decide l'architettura e non promette un risultato commerciale. Rende però visibili perimetro, dipendenze e condizioni di collaudo: sono gli elementi che consentono di stimare il lavoro senza inventare ciò che manca.