La Sua idea per un'app mobile può già essere chiara: i clienti prenotano, ordinano o seguono i propri servizi dallo smartphone. Poi si aggiungono alla lista punti fedeltà, chat, campagne e report avanzati. Dopo un po', l'obiettivo iniziale può finire per sparire di vista.
Per le aziende che vogliono sviluppare un'app mobile, la decisione più importante è quale problema dell'utente la prima versione risolverà completamente. Uscire prima sul mercato non deve significare risolvere questo problema solo in parte. Questo articolo tratta l'ambito della prima versione; le decisioni tecniche come l'uso offline, i permessi e i test sui dispositivi reali le abbiamo affrontate nell'articolo quali decisioni prendere per prime nello sviluppo di un'app mobile.
01Definisca prima il percorso utente fondamentale
Prendiamo come esempio un'app di prenotazione appuntamenti. Se l'utente non riesce a scegliere il servizio, non vede gli orari disponibili o non ha la certezza che la prenotazione sia stata creata, una schermata promozionale ben disegnata non risolve il problema. Nella prima versione vanno pensati insieme i passaggi fondamentali: scelta, conferma, modifica e cancellazione.
In questo esempio l'esperienza del cliente ha anche un lato aziendale. Il dipendente deve poter vedere l'appuntamento, gestire la disponibilità ed essere avvisato delle modifiche. Progettare soltanto le schermate lato smartphone lascia fuori metà del lavoro.
02Divida le funzionalità in tre gruppi
Il primo gruppo comprende le funzioni indispensabili perché il servizio sia utilizzabile. Il secondo gruppo riguarda funzionalità che migliorano sensibilmente l'esperienza d'uso ma non bloccano la prima pubblicazione. Il terzo gruppo è costituito da idee su cui decidere solo dopo aver osservato il comportamento reale degli utenti.
Questa suddivisione Le permette di tenere sotto controllo il budget. Invece di dedicare mesi a una funzionalità che l'utente non desidera, può offrire l'esperienza fondamentale e procedere in base ai feedback. I confini della prima versione devono essere chiari nel preventivo e nel design. Il modo per tenere visibili le attività escluse dall'ambito lo abbiamo spiegato nell'articolo come lanciare prima un'idea software con un MVP.
03Il numero di schermate da solo non determina i tempi di sviluppo
L'uso offline, la geolocalizzazione, le notifiche, i pagamenti e le funzionalità del dispositivo richiedono lavorazioni diverse. Anche lo scambio di dati con un sistema esistente incide sui tempi. Una base di codice condivisa può ridurre, nei progetti adatti, lo sviluppo ripetuto; non elimina però i test su dispositivi e piattaforme.
Anche gli account sugli store, le descrizioni dell'app e le informazioni necessarie per la pubblicazione non vanno lasciate all'ultimo giorno. Il completamento dello sviluppo e la fine della revisione da parte dello store sono fasi distinte: poiché i tempi di revisione esterna non sono sotto il nostro controllo, non promettiamo una data precisa per questa fase.
04Visibilità anticipata per una consegna rapida
In Paradigma7 l'obiettivo non è farLe vedere il risultato del progetto solo il giorno della consegna. Affrontiamo le decisioni di design e le funzionalità fondamentali per fasi, per individuare per tempo eventuali fraintendimenti. Portare avanti insieme sviluppo e collaudo aiuta a ridurre le correzioni che si accumulano nell'ultima fase.
Scopra il nostro servizio di sviluppo di app mobili: trasformiamo insieme la Sua idea in una prima versione realizzabile, definendo fin da subito l'ambito e i passaggi per la pubblicazione.
05Da preparare prima di richiedere un preventivo
- Chi utilizzerà l'app e quale attività dovrà svolgere
- L'unico percorso utente fondamentale che deve essere completo nella prima versione
- Chi, lato azienda, gestirà questo flusso
- I sistemi esistenti da collegare e lo stato di accesso a questi sistemi
- Chi possiede gli account sugli store e se le informazioni per la pubblicazione sono pronte
- Con quale comportamento degli utenti valuterà il successo della prima versione
Scritto da
Il team Paradigma7
Prodotto, ingegneria e operations
Siamo un team con base a Ankara che sviluppa software per l'Europa. Qui non c'è teoria: sono i processi che usiamo davvero nei progetti dei clienti.
Chi siamo