Nell’articolo precedente abbiamo visto che prima di iniziare lo sviluppo di un’app è consigliabile partire da una fase di design del prodotto in cui si concretizza l’idea attraverso un mockup che presenta l’interfaccia utente e magari alcuni esempi di flussi di lavoro.
Esistono molti software che permettono di sviluppare mockup. Il vantaggio principale è che permettono di disegnare le schermate facendo il drag&drop dei componenti nativi degli smartphone e poco più. Sono solo dei disegni, ma si fa in fretta.
Quello che ho visto nella mia esperienza di accompagnamento è che anche partire dal mockup può essere fuorviante: anche a questo livello si tendono ad utilizzare i criteri di progettazione classici e talvolta il risultato assomiglia decisamente ad un’applicazione gestionale vecchio stampo.
Da dove si può partire allora? Nell’articolo precedente indicavo come differenza fondamentale fra app e applicazioni classiche il fatto che le app non sono general purpose, ma si occupano di processi concreti e ben caratterizzati. E questi processi sono voluti, azionati e controllati da persone che ne hanno bisogno.
Per questo il punto di partenza più sicuro nel design di un’app è proprio lo studio delle persone che la utilizzeranno, gli utenti tipo, detti anche Personas.
Ma come si fa a studiare un utente tipo? È come quando ci si vuole fare un amico: la parola chiave è immedesimazione. Immedesimarsi può sembrare un’operazione facile, ma tante volte si rischia di far prevalere la propria idea rispetto alla realtà. Se, ad esempio, devo sviluppare un’app che deve essere usata da giovani mentre sono in discoteca, difficilmente ci riuscirò se non ho frequentato quell’ambiente di recente.
Per aiutarmi nel lavoro di immedesimazione, il metodo che uso consiste nel compilare tre diversi documenti.
Il primo è chiamato User Profiles e contiene la descrizione delle tipologie di utenti ricavata dall’analisi degli stessi a cui accennavo sopra. Per ogni tipo occorre descrivere le caratteristiche umane, le problematiche che deve affrontare (pain) e i vantaggi che ci si propone di offrire tramite l’app (gain).
Il secondo documento contiene le User Stories, cioè i casi d’uso dell’app. Per ogni utente tipo occorre raccontare alcune storielle che descrivono situazioni realistiche in cui si manifestano i problemi che si vogliono risolvere e come l’app avrebbe semplificato la vita.
L’ultimo documento è il Business Model, che descrive come avverrà la vendita dell’app. Questa parte è importante anche per il designer oltre che per il commercialista, infatti sono le funzionalità stesse dell’app che ne devono supportare il business model.
Scrivere questi documenti sembra un lavoro triviale, ma in pratica è piuttosto complicato. Dopo averlo fatto, però, la chiarezza di quale app si vuole è decisamente cresciuta, ed è questo il momento migliore per provare a mockupparla.
Nei prossimi articoli voglio entrare nel merito di questi tre documenti per farvi vedere quali informazioni contengono e come sono strutturati.
Se nel frattempo vi è venuta in mente qualche bella idea di app da sviluppare, sono a vostra disposizione per parlarne insieme.
