Lunora è un mio progetto in cui ho percorso l’intero ciclo: un sondaggio, un’analisi desk, un’ipotesi, scenari, stati, un UI kit, quattro test di usabilità del prototipo e un piano di metriche. Il focus è su ciò che nei progetti di studio di solito si salta: errori, timeout e nuovi tentativi.
Cosa ha mostrato la ricerca
L’analisi delle app bancarie e dei gestori di abbonamenti ha mostrato lo stesso: l’elaborazione è spesso «vuota» e un errore senza un passo successivo mina la fiducia. Da qui l’ipotesi: spiegare lo stato, il motivo e l’azione successiva dà alle persone un maggiore senso di controllo.
Hanno visto un addebito per un abbonamento che avevano dimenticato
8 su 9 usano due o più carte o contiVogliono un’unica app per abbonamenti, bollette e spese
Quattro di loro – se l’interfaccia è sempliceSono cauti verso l’AI: «dipende dalla sicurezza»
Nessuno è contrario. 6 si fiderebbero di più se le funzioni si potessero disattivareHanno scelto un tono neutro: «La tua spesa è aumentata del 10%»
4 su 9 indicano lo stress come la parte più difficile della gestione del denaroHanno indicato i consigli finanziari come bisogno principale
Per questo l’AI è una spiegazione contestuale, non un chatbot centraleVogliono evitare addebiti inattesi
9 su 9 gestiscono i soldi tramite app bancarieIl campione è piccolo e omogeneo: tutti e nove lavorano, otto hanno tra i 21 e i 40 anni. Dà una direzione per le decisioni, non una verifica dell’ipotesi.
Dagli insight alle decisioni
| Cosa è emerso | Decisione |
|---|---|
| Più fonti finanziarie | Una dashboard unica e la scelta del portafoglio |
| Abbonamenti dimenticati | Panoramica degli abbonamenti, data del prossimo pagamento, promemoria |
| Richiesta di semplicità | Le informazioni principali prima, una gerarchia sobria |
| I consigli non sono la priorità principale | Una spiegazione AI contestuale invece di un chatbot centrale |
| Incertezza sullo stato del pagamento | Stati separati con spiegazioni e azioni adeguate |
Stati del pagamento
Ogni stato risponde a tre domande: cosa sta succedendo ora, perché è successo e cosa fare dopo.
Stato, prossimo pagamento, metodo di pagamento
Una spiegazione al posto di un loader vuoto, azioni in background bloccate
Una breve conferma e una chiusura rapida
Nessuna colpa: Retry payment o Change payment method
Separato da Failed: lo stato non è ancora definitivo, non pagare di nuovo
Retry / Change method → di nuovo a Processing
Stato aggiornato e data del prossimo pagamento
Processing spiega cosa sta succedendo
- Perché
- Due dei quattro partecipanti al test del prototipo hanno detto che l’elaborazione del pagamento durava troppo. Questo mi ha fatto guardare non solo al tempo di attesa, ma a come l’interfaccia comunica lo stato dell’operazione: quando non capisci cosa sta succedendo, l’attesa sembra più lunga e crea incertezza.
- Cosa ho fatto
- Prima i passaggi «Checking card → Confirming payment → Almost done» erano solo testo. Ho aggiunto un anello di avanzamento e le spunte sui passaggi completati, e ho evidenziato il passaggio successivo. Non ci sono percentuali: la durata dipende dai sistemi di pagamento esterni.
- Risultato
- Si vede a quale passaggio è il pagamento e che sta andando avanti, non è bloccato.
StatoLe modifiche sono nel prototipo. Un nuovo test non ne ha ancora confermato l’efficacia.
Prima dei testDopo i testTimeout non è Failed
- Perché
- Durante un timeout le persone non sanno se i soldi sono stati addebitati e non sono sicure di dover ripetere il pagamento. Se il timeout viene mostrato come un errore, rischiano di pagare due volte.
- Cosa ho fatto
- Due stati diversi. Failed – un messaggio senza colpe e due azioni: Retry o Change payment method. Timeout – un neutro «We’re still processing the payment».
- Risultato
- Un timeout non sembra più un errore, quindi non c’è motivo di pagare due volte.
StatoUn pattern comune nell’UI kit con la stessa logica delle CTA.
Un passo successivo in ogni stato
- Perché
- Quando un pagamento non va a buon fine, le persone non vedono un passo successivo chiaro e non sanno quando l’abbonamento tornerà attivo.
- Cosa ho fatto
- I dettagli dell’abbonamento mostrano stato, importo, data e metodo del prossimo pagamento. Dopo il successo – una breve conferma e il ritorno ad Active con la nuova data.
- Risultato
- Dopo qualsiasi esito del pagamento, le persone sanno se l’abbonamento è attivo e quando è previsto il prossimo pagamento.
StatoNel prototipo con Smart Animate.
Onboarding e wallet senza pressione
- Perché
- Le app finanziarie spesso mettono pressione, e 4 intervistati su 9 indicano lo stress come la parte più difficile della gestione del denaro.
- Cosa ho fatto
- L’onboarding chiede cosa la persona vuole monitorare, la richiesta di notifiche ne spiega il vantaggio e un wallet si può collegare o saltare.
- Risultato
- Le persone scelgono cosa collegare e quando, senza passaggi obbligatori.
StatoNel prototipo.
Nella finanza le risposte giuste spesso sono due. Ecco tra cosa sceglievo e cosa ha vinto.
| Tra | Cosa ho scelto | Dove |
|---|---|---|
| Velocità e sicurezza | Attrito intenzionale dove un errore costa caro: durante l’elaborazione le azioni in background sono bloccate | Processing |
| Chiarezza e carico cognitivo | Le informazioni si rivelano gradualmente | Dettagli dell’abbonamento, onboarding |
| Automazione e controllo | Le azioni critiche restano esplicite e visibili | Retry, Change payment method |
| Dettaglio e chiusura rapida | Uno stato di successo minimale per chiudere rapidamente lo scenario | Success |
L’AI è un aiuto, non la fonte di verità
L’AI è pensata come aiuto contestuale: una breve spiegazione della situazione attuale e le azioni disponibili in un bottom sheet. Non decide da sola se un addebito è avvenuto: gli stati devono arrivare da un’infrastruttura di pagamento affidabile, e nel concept questa integrazione non c’è.
Indicatori di avanzamento
In Lunora ho separato due tipi di processi: la configurazione iniziale del prodotto e l’elaborazione delle transazioni finanziarie.
- Configurazione del portafoglio – avanzamento determinato
- La schermata Setting things up usa un indicatore 0–100%, che nel prototipo mostra il comportamento atteso dell’interfaccia durante la configurazione. Nel prodotto reale questo indicatore deve essere legato al completamento effettivo dei passaggi. Se il backend non può fornire dati affidabili sull’avanzamento, è previsto un indicatore senza percentuali.
- Elaborazione del pagamento – avanzamento indeterminato
- Durante l’elaborazione di un pagamento la durata dipende da sistemi di pagamento esterni. Un indicatore in percentuale potrebbe quindi creare una falsa aspettativa sui tempi di completamento. Per questo scenario ho scelto un’interfaccia di stato che spiega il passaggio in corso, senza percentuali artificiali.
Il principio: un indicatore di avanzamento deve mostrare informazioni affidabili, non creare un’illusione di controllo.
L’accessibilità è parte del sistema: alto contrasto nell’interfaccia scura, una gerarchia tipografica chiara, aree di tocco ampie e messaggi brevi «cosa è successo → cosa fare». Non ci sono ancora stati test con tecnologie assistive – i prossimi passi sono una revisione WCAG e i flussi con screen reader.
Come misurare
Sono metriche proposte, non risultati misurati: il prodotto non è lanciato. Il prossimo passo è un test di usabilità del prototipo sugli scenari di pagamento fallito, timeout e cambio del metodo di pagamento.
| Metrica | Cosa mostra |
|---|---|
| Status comprehension | Se le persone distinguono Failed e Timeout |
| Time to resolve | Tempo da quando nasce il problema a quando viene risolto |
| Payment recovery rate | Quota di pagamenti riusciti dopo un errore |
| Retry drop-off | Quota di persone che abbandonano il flusso di nuovo pagamento |
| Duplicate attempts | Frequenza dei nuovi tentativi prima che il risultato sia confermato |
| Decisione di design | Effetto atteso |
|---|---|
| Stati di pagamento separati | Meno panico, meno abbandoni del flusso |
| CTA chiare in ogni stato | Decisioni più rapide, meno tentativi caotici |
| Timeout separato da Failed | Meno pagamenti doppi, più fiducia |
Prototipo
Onboarding e collegamento del portafoglio
Schermate e animazioni dal prototipo in Figma: l’intro con una pila di carte, la registrazione, il primo portafoglio e l’avanzamento della configurazione. Il prototipo scorre da solo; passa a «Provalo tu» per cliccarlo.
- Splash
- Intro: tre passaggi
- Registrazione e preferenze
- Primo portafoglio
- Tipo di portafoglio
- PayPal
- Configurazione
- 01
Il sondaggio ha mostrato interesse per un unico posto per le finanze, ma anche cautela verso l’AI – quindi ho puntato su stati trasparenti, e l’AI è rimasta un concept di assistente.
- 02
Volutamente fuori dal perimetro: integrazioni bancarie, scenari legali, monetizzazione e implementazione del ML.
- 03
Il prossimo passo – testare con le persone il nuovo Processing e il Timeout (nessuno dei due è ancora stato ritestato) e misurare il tasso di recupero dei pagamenti e l’abbandono durante il retry.
