Luca Manara*

Sviluppare un’App con una User Experience efficace può essere anche molto sfidante. Anche se la tua App passa positivamente tutti i test interni, il complesso mondo della frammentazione dei device, degli operatori telefonici e il continuo mutamento dei sistemi operativi Android e iOS rende difficile creare una UX consistente e piacevole. Alcune aziende, molto insoddisfatte dei risultati delle proprie iniziative mobile, sono costrette a riconsiderare le proprie strategie nell’ambito dello sviluppo per smartphone e tablet. Un recente studio e white paper di Apteligent afferma che il successo nel mondo del mobile è fortemente dipendente dalle metriche utente-centriche misurate nel tempo, dai processi di sviluppo incentrati sulla risoluzione dei defect e dal testing continuo della propria App anche con utenti finali. Le aziende con le migliori performance nel mondo del mobile si focalizzano appunto su queste metriche e creano specifici momenti, all’interno del ciclo di sviluppo software, per analizzare le metriche e riorientare li sviluppo in ottica di miglioramento continuo.

In questo articolo riassumo 7 best practice realizzate dalle migliori aziende in termini di sviluppo mobile. Mettere in pratica questi casi d’uso durante le settimane e i mesi di sviluppo spingono verso applicazioni mobile che appagano gli utenti e, come risultato ultimo, ottenere 5 stelle sugli store.

Per Saperne di più e per verificare subito come ottimizzare le tue App

“Le aziende che rilasciano le App di maggiore successo misurano queste 2 metriche importanti: overall crash rate e il crash rate nei percorsi “core” dell’utente (come per esempio il percorso di pagamento)”

Queste best practice si adattano in particolar modo al mondo dei pagamenti digitali. Infatti gli utenti si aspettano processi stabili e veloci il che genere quel trust importante che necessita questo particolare vertical di prodotto.

Pagamenti digitali: User Experience dalla prospettiva dell’utente

Creare una User Experience perfetta richiede che ogni parte dell’organizzazione metta gli utenti al centro. Questo ce lo ripetiamo da molto tempo. Una frase comune che è possibile sentire dalle aziende che sviluppano App di successo è: “abbiamo messo gli utenti al centro dello sviluppo e guardiamo la User Experience dal punto di vista dell’utente”.

Per partire con l’analisi, partiamo dal perché un utente abbandona l’App, la disinstalla e lascia commenti negativi sugli store.
Possiamo pensare a il processo di abbandono di un utente in maniera gerarchica. Dal livello più alto di abbandono al livello più basso:

1. Fallimento dell’App

· Crash dell’App

· Blocco dell’App (Freeze)

2. Frustrazione dell’utente

· App molto lenta

· Utente sempre in attesa su processi core

3. Fastidio dell’utente

· Consumo eccessivo di batteria

· Consumo eccessivo di dati

Questa gerarchia è uno strumento che permette allo sviluppo prodotto di prioritizzare i problemi legati alla propria App. Partendo da questa classificazione e leggendo le seguenti best practice è possibile guardare i propri sviluppi attraverso una nuova lente che permetta di migliorare sensibilmente l’esperienza degli utenti.

Un aspetto importante è che il processo di ottimizzazione non può considerare solo 1 di questi aspetti e ignorare gli altri perché si rischiano derive negative sul fronte della User Experience (nessuno utente vuole una macchina che non si guasta mai ma che raggiunge una velocità massima di 30km/h).

Livello 1 della gerarchia: evita i crash

Sembra ovvio dirlo, ma il miglior team di sviluppo mobile assicura che la propria App non fallisca in mano ai propri utenti. Prima di tutto.

Questo significa che l’App non deve bloccarsi o andare in crash (chiudersi inaspettatamente e senza apparente motivo) specialmente durante alcuni momenti chiavi di utilizzo da parte degli utenti. Significa inoltre essere sicuri che gli utenti possano completare le azioni “core” (ovvero quelle più importanti) in ogni momento. In un’App di pagamenti digitali è chiaro intendere quali possano essere le 2 o 3 azioni “core” che non devono mai fallire e bloccarsi.

Una delle più importanti metriche quindi da monitorare è il crash rate ovvero la percentuale di sessioni dell’App che si conclude con un crash. Le aziende migliori tracciano 2 differenti crash rate: quello generale e quello legato ai processi core.

Ovviamente è più semplice lavorare solo i crash misurabili ma ne esistono poi diversi che mandano l’App in uno stato bloccato e in cui l’utente non riesce a compiere nessuna operazione (freeze) oppure l’App si chiude inaspettatamente ma il sistema non rileva un vero e proprio crash. Anche in questo caso ci sono tecniche per identificare quali percorsi funzionali portano a determinati problemi e anticiparli prima che siano i tuoi utenti a farlo (tecniche di testing funzionale – bug finding).

Best Practice #1: correggi i top 10 crash o defect ad ogni rilascio

Una delle sfide più importanti nello sviluppo di App mobile può essere quella di decidere quanto tempo dedicare allo sviluppo di nuove feature VS quanto tempo dedicare nel fix dei bug. Mentre è allettante allocare il 100% del tempo nel rilasciare nuove feature, correggere i bug importanti che stanno subendo i tuoi utenti può essere un’attività classificata come value for money. I migliori team allocano il tempo in ogni sprint di sviluppo per sistemare i 10 maggiori problemi che impattano la maggior parte dei loro utenti.

In accordo con i dati di Apteligent, le migliori App hanno un overall crash rate al di sotto del 0.25%. Dato questo aspetto, comunque il 75% delle App Android e iOS non soddisfano questi standard e la domanda è: come ha fatto Groupon ad avere un crash rate al di sotto dello 0.02% e 4.5 stelle nello store? Il loro successo è largamente dovuto a un processo disciplinato, basato sui dati oggettivi e processi di quality assurance costanti. Ogni sprint di sviluppo (ovvero ogni settimana o ogni mese) il team Groupon crea una lista dei 10 peggiori crash o defect che affliggono le loro App e li sistemano rilasciando una nuova versione dell’App. In questo modo, ad ogni release, hanno la capacità di diminuire i defect e incrementare il rating nello store.

Elencare i 10 peggiori crash da sistemare per ogni sprint non è difficile e può essere veramente poco time consuming. Esistono sistemi di tracking che permettono di identificare questi problemi velocemente e metodologie di testing che supportano nella costruzione di processi standard.

Best Practice #2: mantieni un crash rate al di sotto dello 0.25% nei 3 percorsi chiave della tua App

Che sia il login, la registrazione di un nuovo account, il processo di pagamento, ogni App ha dei processi step by step che sono critichi per il successo dell’App. In ambito pagamenti digitali per esempio il percorso di erogazione o ricezione del denaro è sicuramente al primo posto.

Per prima cosa identifica i 2 o 3 percorsi core che nella tua App sono critici per migliorare le metriche di business (utenti attivi mensili, retention, fatturato per utente, etc.). Quindi, per quei percorsi chiave, studia e monitora i problemi di performance che possono causare difetti e bug. Il crash rate in ognuno di questi flow è uno degli indicatori che abbiamo visto misurare dai migliori team di sviluppo mobile. Se il team di sviluppo non riesce ad avere un crash rate pari allo 0.25% overall, il minimo che si può fare è mantenere lo stesso valore su questi 2 o 3 percorsi core (sicuramente meno oneroso che lavorare su ogni sezione dell’App e più efficiente in logica Pareto: l’80% delle azioni degli utenti viene fatto sul 20% dei percorsi).

Prioritizza quindi la top 10 dei bug in questi percorsi e risolvili ad ogni step (sprint) di sviluppo.

Una tecnica molto utile è mantenere questi percorsi core costantemente in test. E’ possibile infatti utilizzare strumenti e tecniche per rilevare velocemente problemi in questi punti chiave che possono emergere anche a fronti di rilasci di feature che teoricamente non impattano gli stessi percorsi (test di non regressione).

Aziende come la BBC, con le loro App rilasciate a livello Worldwide e utilizzate da milioni di utenti, sfruttano lab di device sia interni che esterni su quello che è il loro percorso funzionale più importante: la fruizione dei video.

Sintetizzando, per ottimizzare il numero di crash sui percorsi maggiormente critici, applica il seguente processo:

1. Identifica i 3 percorsi chiave degli utenti nella tua App (per esempio: creazione di un nuovo account, login e processo di pagamento)

2. Lavora per risolvere i 10 top crash che affliggono quei percorsi in ogni sprint di rilascio (ogni settimana o al massimo 2 volte al mese)

3. Mantieni un crash rate al di sotto dello 0.25% nei percorsi utenti più critici

“Ci sono altre 2 metriche che sono critiche da studiare e migliorare: tempo di caricamento dell‘App e tempo di interazione dell’uutente nei percorsi core della tua App”

Livello 2 della gerarchia: previeni la frustrazione

Oltre a monitorare i defect connessi ai crash sui percorsi critici, è anche importante essere sicuri che la tua App non generi frustrazione nei tuoi utenti con tempi di attesa molto lunghi e una sensazione di una User Interface “stanca” e poco reattiva.

Le App mobile sono tipicamente usate in momenti brevi e fugaci mentre, per esempio, gli utenti si spostano per lavoro o sono in coda alla cassa del supermercato. Quindi il tempo di ogni interazione con l’App è importante.

In questo senso, ci sono 2 metriche che sono critiche da misurare e migliorare: tempo di caricamento dell’app e tempo di interazione dell’utente nei flussi chiave.

Best Practice #3: assicurati che la tua App si carichi al di sotto dei 2 secondi

In aggiunta al crash rate, molti dei team che meglio performano in ambito mobile misurano il tempo di caricamento nelle loro App. Il tempo di caricamento è una metrica spesso altamente correlata con l’ingaggio dell’utente nelle App mobile.

Più tempo ci mette la tua App a caricare i contenuti o la pagina successiva, con meno probabilità i tuoi utenti riutilizzeranno la stessa App. infatti, studi hanno dimostrato che il 50% dei consumatori considerano il tempo di caricamento come una dei maggiori motivi che generano frustrazione e il 25% abbandonerebbero un brand se i tempi di caricamento risultano inaccettabili. A parte queste ricerche, quasi la metà (46% per iOS e 53% per Android) impiegano mediamente più di 2 secondi per caricarsi.

I migliori team di sviluppo mobile monitorano e controllano i tempi di caricamento come un KPI chiave tra un rilascio di una versione e la successiva e tra un periodo temporale e il successivo. Il cambiamento di una API interna, l’aggiunta di una SDK di terza parte o il rilascio di un nuovo sistema operativo possono impattare drasticamente su questi tempi e, conseguentemente, le metriche di business. Considerate questo esempio reale: una azienda e-commerce ha identificato che la perdita di ben un 10% di degli acquisti in App è stato causato da 1 secondo di incremento nel tempo di caricamento quando Apple ha rilasciato il nuovo sistema operativo iOS 9.

Per Saperne di più e per verificare subito come ottimizzare le tue App

Best Practice #4: assicurati che la User Interaction dia sensazioni di immediatezza

Ogni volta che un utente interagisce con la tua App, si aspetta che la tua App dia sensazioni di immediatezza e velocità. In un’App mobile ci sono 2 tipi di interazione che un utente può avere: un’interazione in cui l’utente si aspetta una risposta immediata e un’interazione in cui l’utente si aspetta un breve ritardo perché percepisce il fatto che ci sia un’attività di estrazione o elaborazione di dati.

Applicando le ricerche riassunte nell’articolo di Jakob Nielsen sul design delle interfacce, “Nielsen, Jakob. “Powers of 10: Time Scales in User Experience” 2009. Nielsen Norman Group”, se l’interfaccia dell’App impiega più di 0.1 secondi per rispondere a un’interazione, l’utente percepirà una sensazione di ritardo e di risposta non istantanea. Se il tempo sale a più di 1 secondo, gli utenti cominceranno a perdere il filo del ragionamento che li guidava e perderanno anche la sensazione di controllare le azioni che stanno compiendo.

Per creare un’App veloce è necessario sia misurare le interazioni in cui gli utenti si aspettano un feedback immediato sia le interazioni in cui si aspettano un breve ritardo. E’ utile partire dalle interazioni più comuni nella tua App e quelle su cui si basano i flussi core (gli stessi identificati per i crash per esempio). Misura il tempo necessario dall’interazione dell’utente con l’App (per esempio un tap su un bottone) al momento in cui la User Interface fornisce all’utente una risposta valida (per esempio quando la schermata finisce il caricamento e l’App è pronta per accettare un’ulteriore interazione da parte dell’utente). Se una qualsiasi di queste interazioni impiega più tempo di quello atteso, analizza gli eventi e le chiamate di rete che stanno trascinando il processo nel tempo, crea un ticket sul tuo sistema di bugtracking, e avvia un immediato fix.

Se non è possibile misurare questi percorsi, può anche essere applicata una logica crowd per cui viene chiesto a un gruppo di tester di misurare fisicamente questi tempi sui loro smartphone e nel mentre vengono misurati gli eventi e le chiamate di rete. Anche in questo caso esegui il test, crea un ticket sul tuo sistema di bugtracking, e avvia un immediato fix.

Best Practice #5: studia le chiamate di rete durante i flussi core

Molte interazioni su mobile dipendono dalle chiamate di rete per caricare dati o lanciare una query (estrarre dati). I giochi spesso dipendono dalle chiamate di rete per caricare un’immagine o un suono per un livello successivo del gioco. Le App di pagamenti digitali usano tantissime chiamate di rete per verificare che la transazione che l’utente sia consentita e per fare in modo che alla fine il bilancio dell’istituto intermediario sia garantito anche in caso di malfunzionamenti. Tutte le App che consentono un login e una creazione del profilo si appoggiano a queste chiamate di rete per portare a termine queste operazioni.

Dato che il tuo obiettivo è ottimizzare l’interazione con gli utenti di conseguenza risulta chiave studiare e monitorare queste chiamate di rete seguendo queste 2 metriche:

• Latenza: l’ammontare del tempo che è necessario a una chiamata per essere completata (quanto tempo attende un utente)
• HTTP error rate: quanto frequentemente le chiamate di rete falliscono per il fatto che il server ritorna un errore di qualsiasi tipo o l’impossibilità dell’App stessa di connettersi al server

Come primo aspetto assicurati che la latenza delle chiamate di rete su un percorso critico siano minori di 1s. Se una chiamata di rete richiede più tempo, lavora con chi ha realizzato le chiamate di rete su cui ti appoggi (spesso dette API) per ridurre la latenza di quel particolare step. E’ possibile per esempio utilizzare una API differente o cambiare la quantità di dati passata durante la chiamata stessa.

L’error rate di queste chiamate di rete dovrebbe essere trattato in maniera similare al crash rate su tuoi percorsi e flussi utente principali. Di conseguenza dovrebbe essere minore dello 0.25%. Imposta quindi degli allarmi che ti avvisino quando l’ error rate supera questa soglia in maniera tempestiva.

Una volta identificato un trend negativo di errori di questo tipo è molto importante poterli riprodurre correttamente e con tutte le informazioni necessarie per capire dove sta la fonte dell’errore. A questo proposito esistono tecniche di Bug Bounty che permettono di simulare la situazione in cui l’errore viene generato e identificare la causa del problema.

“Le ultime 2 metriche da testare e studiare nella tua App sono la quantità di dati utilizzata e quanta batteria viene consumata. Anche se non c‘è un immediato effetto sull’esperienza utente in-app, è importante misurarle per assicurarsi che gli utenti non dis-installeranno l’App nel tempo”

Livello 3 di gerarchia: previeni i fastidi

“Le ultime due metriche che andremo ad analizzare sono la quantità di dati che vengono consumati e quanto la tua App impatta sull’utilizzo della batteria. Anche se non impattano direttamente sull’esperienza utente all’interno dell’App, è importante governare queste variabile per evitare che gli utenti dis-installino l’App dopo un certo periodo di utilizzo”

Best Practice #6: misura l’utilizzo dei dati e della batteria nel tempo

Nel tempo gli utenti sono diventati sempre più dipendenti dai loro smartphone, hanno subito addebiti extra sull’utilizzo dei dati dai loro operatori telefonici perché hanno superato il numero massimo di dati a disposizione, e sono rimasti a piedi senza batteria in un momento critico della giornata. Di conseguenza sono diventati sempre più attenti al tipo di App che utilizzano e quanto queste App drenino batteria e dati. Gli stessi Google e Apple sono diventati sempre più sensibili alla trasparenza verso gli utenti di quale sia l’App che sta utilizzando più dati o più batteria.

Per esempio Apple offre, nelle sue impostazioni, un modo per tracciare quanti dati vengono utilizzati da ogni App, e la stessa cosa vale per Android.

Se un utente vede un’App che costantemente utilizza gran parte dei dati o usa moltissima batteria, dis-installeranno l’App e tenderanno a utilizzare altri canali. Addirittura Facebook è stata indagata per consumare molta batteria e per causare il rallentamento delle altre App.

La causa più comune che provoca la morte della batteria e del piano tariffario di dati dell’utente sono proprio le chiamate di rete. Il consiglio è quindi quello di, prima di pubblicare un’App sugli store, verificare l’ammontare di dati consumati e di batteria utilizzata dall’App in una sessione tipo.

Tramite tecniche di testing che utilizzano un network di tester è possibile testare l’App per un periodo e secondo casi d’uso ben specifici e verificare che le metriche che abbiamo citato, dopo questo test, siano soddisfatte.

Sommario finale: le metriche mobile che dovresti testare e ottimizzare nel tempo

Best Practice #7: monitora e studia le metriche mobile nel tempo e su diversi rilasci dell’App

L’ultima Best Practice per sintetizzare. Abbiamo identificato che le App migliori sono gestite da team che approcciano gli sviluppi seguendo logiche data driven. Inoltre questi team continuano a testare il livello delle metriche nel tempo. Misurano quelle principali, come per esempio il tempo di caricamento e il crash rate, e assicurano che migliorino nel tempo e ad ogni nuovo update e versione della propria App. Inoltre, ogni qual volta una di queste metriche deriva verso valori non corretti, questi team avviano processi di test e verifica di quale sia la causa scatenante, inseriscono il problema nel processo di pianificazione, aprono un nuovo ticket nel loro sistema di bugtraking, viene prioritizzato, fixato e viene quindi rilasciata un nuova App in cui le metriche tornano a essere quelle desiderate.

Logiche di sviluppo data driven, testing continuo, rilasci frequenti sono 3 fattori chiavi per chi vuole creare e gestire App mobile che raggiungono livelli di qualità top e una soddisfazione degli utenti massima.

Per prioritizzare su cosa lavorare in ogni rilascio, si concentrano sullo studio dei percorsi core e non dimenticano di verificare, di volta in volta, quanto l’App sta consumando in termini di dati e batteria. Lo fanno anche, e soprattutto, a valle dell’inserimento di una nuova SDK o quando vengono implementate nuove chiamate di rete.

Per chiudere quindi ecco gli indicatori sintetizzati:

1. Evita i fallimenti

a. Crash rate < 0.25%

b. Crash rate su percorsi core < 0.25%

2. Previeni la frustrazione

a. Tempo di caricamento dell’App < 2 secondi

b. Tempo di risposta sui percorsi critici < 2 secondi

c. Gestione delle API su percorsi critici: latenza < 1 secondo; Error rate < 0.25%

3. Previeni il fastidio

a. Studia e esegui test sul consumo eccessivo di batteria e il consumo eccessivo di dati

Credit: 7 Best Practices Apteligent – ROB KWOK, CTO and Co-Founder Aptelligent

Per Saperne di più e per verificare subito come ottimizzare le tue App