Prima decisione: serve davvero un'app?
È la domanda che fa risparmiare più soldi dell'intero progetto. Un'app richiede che qualcuno la installi, e convincere qualcuno a installare qualcosa è la parte difficile: se non avete già un pubblico che vi cerca, il costo di far installare l'app supera quello di svilupparla.
- 01
L'utente la aprirà almeno una volta a settimana?
Se la risposta è no, l'app verrà disinstallata. Nessuno tiene sul telefono qualcosa che usa una volta all'anno.
- 02
Servono funzioni del dispositivo?
Fotocamera con elaborazione, posizione continua, notifiche affidabili su iPhone, uso offline prolungato, lettura di codici o sensori. Se sì, l'app si giustifica.
- 03
Lo store è un canale di acquisizione?
Se le persone vi cercheranno negli store, la presenza lì ha valore. Se i vostri utenti sono clienti o dipendenti che già conoscete, no.
- 04
Se hai risposto no a tutte e tre
Ti serve una web app installabile o un sito responsive, e risparmierai gran parte del budget senza rinunciare a nulla di ciò che ti serve.
Seconda decisione: chi la userà, e in quali condizioni
È la domanda che determina più scelte tecniche di qualsiasi altra, e viene quasi sempre saltata. Un'app per tecnici in cantiere e una per clienti che ordinano dal divano non hanno nulla in comune, nemmeno nelle fondamenta.
| Chi la usa | Cosa cambia radicalmente |
|---|---|
| Tecnici sul campo | Funzionamento offline, guanti, luce diretta, batteria |
| Agenti di commercio | Dati aggiornati, uso in mobilità, inserimento rapido |
| Clienti abituali | Semplicità estrema, nessuna formazione possibile |
| Dipendenti in ufficio | Probabilmente non serve un'app: usano un computer |
| Clienti occasionali | Difficilmente installeranno: valutare altre strade |
Terza decisione: cosa mettere nella prima versione
La regola è la stessa di qualsiasi progetto software, ma nelle app è più stringente: un'app che fa cinque cose a metà viene disinstallata, una che ne fa una benissimo resta.
Il criterio per decidere cosa entra
- Qual è l'unica cosa senza cui l'app non ha senso? Quella entra.
- Cosa fa risparmiare tempo dal primo giorno? Entra.
- Cosa è stato chiesto «perché prima o poi servirà»? Non entra.
- Cosa richiede dati che non avete ancora? Non entra.
- Cosa si può fare altrettanto bene dal sito? Non entra nell'app.
Vale la pena aggiungere una verifica: se l'elenco delle funzioni della prima versione supera le cinque voci, quasi certamente ne state mettendo troppe. La seconda versione arriva prima di quanto si creda, e arriva con le priorità corrette perché imparate dall'uso.
Quarta decisione: l'approccio tecnico
| Approccio | Costo relativo | Quando conviene |
|---|---|---|
| Web app installabile | Il più contenuto | Strumenti interni, aree riservate, uso prevalentemente connesso |
| Cross-platform | Intermedio | La scelta corretta per la maggior parte delle app aziendali |
| Nativo | Il più alto | Prestazioni estreme, hardware particolare, novità di sistema immediate |
Cross-platform significa una sola base di codice per iOS e Android: gli utenti non distinguono il risultato dal nativo nella maggior parte dei casi d'uso aziendali, e i tempi e i costi sono sensibilmente inferiori.
Cosa succede dopo la pubblicazione
È la parte che quasi nessuno mette a budget, ed è quella che decide se l'app sarà ancora funzionante tra due anni. A differenza di un sito, un'app vive dentro un sistema operativo che cambia ogni anno.
- iOS e Android rilasciano una versione maggiore all'anno: l'app va adeguata, o smette di funzionare correttamente.
- Gli store aggiornano i propri requisiti: informative, dichiarazioni sui dati, formati delle immagini.
- Un'app non aggiornata può essere rimossa dallo store.
- Ogni correzione passa da una revisione che richiede giorni: le urgenze vanno pianificate diversamente da un sito.
- Gli utenti restano su versioni vecchie: vanno supportate o forzate all'aggiornamento.