Pattern per wizard multi-step "salva e riprendi" per ridurre l'abbandono

Perché i wizard multi-step hanno bisogno di salva e riprendi

Un wizard multi-step spezza un form lungo in passaggi più piccoli, come dati del profilo, fatturazione, preferenze e revisione. È utile quando il compito è lungo, i dati sono complessi o le persone devono seguire un ordine chiaro. Fatto bene, sembra più leggero rispetto a una singola pagina infinita.

Le persone abbandonano comunque perché la vita le interrompe. Possono avere bisogno di un documento che non hanno, aspettare un responsabile, perdere la connessione o passare dal telefono al laptop. Alcuni smettono perché il wizard sembra rischioso: un errore o un refresh potrebbe cancellare tutto.

Salva e riprendi cambia le regole. Gli utenti possono mettere in pausa senza timore, tornare dopo e continuare dal passo corretto con il progresso intatto. Anche i team ne beneficiano: meno invii abbandonati, conversazioni di supporto più chiare (“apri la tua bozza e continua”) e migliore visibilità su dove gli utenti si bloccano.

Per mantenere la promessa che il progresso non si perda (anche tra dispositivi), la maggior parte dei wizard ha bisogno di alcune basi:

• Salvare le bozze automaticamente mentre l'utente digita, o almeno quando passa al passo successivo.
• Permettere la compilazione parziale senza bloccare per campi di passi successivi.
• Rendere facile ritrovare la bozza (area account, promemoria via email o un token di ripresa).
• Mostrare progresso chiaro e cosa manca, senza rimproverare.

Bozze e stati in termini semplici

Un wizard salva-e-riprendi è più semplice da progettare se lo tratti come due cose diverse: una bozza e un record inviato.

Una bozza è temporanea e modificabile. Un record inviato è ufficiale e dovrebbe seguire regole più rigide.

Lo “stato” è solo l'etichetta di cosa è quel record in questo momento. Stati comuni includono draft, submitted, approved, rejected e archived. Se ti servono solo due, inizia con draft e submitted. Tenere questa linea netta semplifica molto reportistica, permessi e supporto.

Cosa memorizzi a ogni passo dipende da ciò che ti serve veramente per riprendere dopo. Salva solo gli input dell'utente per quel passo, più metadati base come chi ne è il proprietario e quando è stato aggiornato l'ultima volta. Evita di conservare extra sensibili “per sicurezza” (per esempio, dati completi della carta, documenti non richiesti ancora, o note interne che potrebbero emergere e confondere l'utente).

Il tracciamento del progresso dovrebbe essere noioso ed esplicito. Due campi coprono la maggior parte dei casi:

• current_step (dove l'utente arriva quando riprende)
• completed_steps (cosa è già fatto)

Alcuni team memorizzano completed_steps come lista di ID dei passi. Altri usano un semplice conteggio.

Un modello mentale pratico:

• Dati bozza: le risposte finora (possibilmente incomplete)
• Status: draft vs submitted
• Progresso: passo corrente più passi completati
• Ownership: user ID o account ID
• Timestamp: created_at, updated_at, submitted_at

Quando dovresti creare la bozza?

Se il tuo flusso è anonimo o vuoi link riprendibili, creala appena si apre il wizard così hai un ID su cui salvare. Se l'utente è autenticato e vuoi meno bozze vuote, creala alla prima vera azione “Avanti” o “Salva”.

Modelli di dati backend che funzionano per le bozze

Un buon modello bozza fa due cose bene: salva input parziali senza rompersi e rende la submission finale prevedibile. Se il modello dati è confuso, il wizard sembrerà inaffidabile anche con una UI ottima.

Opzione A: un record che evolve (status più current_step)

Questo è l'approccio più semplice. Memorizzi tutto in una tabella (o in una singola entità) e aggiungi campi come status (draft/submitted) e current_step (1-6). Ogni salvataggio aggiorna lo stesso record.

Funziona meglio quando il form mappa pulitamente a una “cosa” (una candidatura, un ordine, un profilo).

Opzione B: Draft e Final separati

Qui tieni una tabella Draft per dati parziali e disordinati e una tabella Final per dati puliti e validati. Al submit crei il record Final dalla bozza, poi blocchi o archivi la bozza.

Questo pattern brilla quando i dati finali devono essere rigidi (fatturazione, compliance, reporting), ma la bozza può essere flessibile. Rende anche più sicuro il “cancella bozza” perché non tocca i record inviati.

Opzione C: snapshot o eventi (audit-friendly)

Se hai bisogno di sapere chi ha cambiato cosa e quando, conserva la storia. Due modi comuni:

• Snapshot: salva una copia completa dei dati della bozza ogni volta (semplice da ripristinare).
• Eventi: salva piccoli record di “cambio” (più compatto, ma più difficile da leggere).

Usalo quando sono coinvolti approvazioni, dispute o dati regolamentati.

Sezioni ripetibili (come voci di riga o allegati) sono dove le bozze spesso si rompono. Modella questi elementi come tabelle figlie legate alla bozza (e più tardi al record finale). Per esempio, un wizard di onboarding potrebbe avere molti “membri del team” e “documenti”. Salva ogni elemento indipendentemente. Evita di infilare array in un solo campo a meno che non sia veramente inutile interrogarli, ordinarli o validare per elemento.

Validazione parziale senza frustrare gli utenti

La validazione parziale è la differenza tra un wizard che sembra utile e uno che sembra un muro. Lascia che le persone vadano avanti quando hanno fatto abbastanza, ma non permettere che input chiaramente errati finiscano nella bozza.

La maggior parte dei wizard ha bisogno di entrambe le cose:

• Validazione a livello di passo: verifica ciò che è necessario per il passo corrente.
• Validazione finale: eseguita alla submission e verifica tutto attraverso i passi.

Per permettere campi incompleti senza salvare dati scorretti, separa “mancante” da “non valido”. Mancante può andare bene in una bozza. Non valido dovrebbe essere bloccante o segnalato chiaramente perché crea confusione in seguito.

Esempio: un numero di telefono vuoto può andare bene in una bozza. Un numero di telefono con lettere dovrebbe essere rifiutato o evidenziato chiaramente.

Cosa validare subito vs più tardi:

• Validare subito: formato e parsing base (forma email, formato data, intervalli numerici, campi obbligatori per quel passo).
• Validare più tardi: regole di business che dipendono da altri passi (limite di credito che dipende dalle dimensioni dell'azienda, opzioni di spedizione che dipendono dall'indirizzo, controlli di unicità username).
• Validare in modo asincrono: controlli che chiamano sistemi esterni (verifica partita IVA, autorizzazione metodo di pagamento).

Gli errori devono essere specifici e locali. Invece di “Correggi errori per continuare”, indica il campo, spiega cosa non va e come sistemarlo. Se un passo ha avvisi (non errori), lascia che l'utente proceda ma mantieni un badge chiaro “richiede attenzione”.

Un pattern pratico è restituire una risposta strutturata dal server con:

• Errori bloccanti (da correggere per procedere)
• Avvisi (si può procedere, ma evidenzia)
• Percorsi dei campi (così la UI focalizza l'input giusto)
• Un breve messaggio riassuntivo (per la parte alta del passo)

Passo dopo passo: implementare un flusso salva-e-riprendi

Un buon wizard salva-e-riprendi inizia a funzionare dalla prima schermata. Non aspettare il passo 3 per creare un record. Appena l'utente inserisce qualcosa di significativo, vuoi una bozza da aggiornare.

Un flusso pratico che puoi copiare

1. Crea una bozza quando il wizard inizia o alla prima azione reale. Salva il minimo: proprietario (user ID o email), status = draft e i campi del passo 1 (anche se incompleti).
2. Salva dopo ogni passo e autosalva per i passi più lunghi. Su “Avanti”, persisti il payload del passo. Per pagine lunghe, autosalva su blur o dopo una breve pausa così un refresh non cancella il progresso.
3. Carica la bozza corrente al ripristino. Recupera la bozza per ID (e proprietario) e precompila l'interfaccia così gli utenti riprendono da dove hanno lasciato.
4. Gestisci indietro, avanti e salta in modo sicuro. Salva l'ultimo passo completato e i percorsi consentiti. Se il passo 4 dipende dal passo 2, non permettere di saltarlo anche se la UI ci prova.
5. Finalizza con un'azione di submit unica. Esegui la validazione completa attraverso tutti i passi, blocca il record e imposta status = submitted.

Validazione che non punisce gli utenti

Durante la stesura, valida solo ciò che serve per il passo corrente. Salva i dati parziali con flag chiari come “missing” o “needs review” invece di trattare tutto come errore grave.

Link riprendibili: come funzionano e quando usarli

Un link riprendibile è un URL che contiene un token monouso (o a breve durata). Quando qualcuno lo apre, la tua app cerca la bozza a cui il token punta, conferma che è ancora valida e riporta l'utente al passo giusto. Questo può rendere l'esperienza molto fluida, specialmente quando le persone cambiano dispositivo.

Un flusso tipico è: crea bozza -> genera token legato a quella bozza -> memorizza una copia hash del token -> mostra o invia il link -> riscatta il token per riprendere -> ruota o invalida il token.

Regole sui token che mantengono affidabilità

Decidi poche regole in anticipo così il supporto non debba indovinare dopo:

• Lifetime: ore o giorni, basato sulla sensibilità e su quanto normalmente dura il wizard.
• Rotation: emetti un token nuovo dopo ogni ripresa riuscita (buon default), oppure mantieni un token fino al submit.
• Step targeting: memorizza l'ultimo passo completato così il link riprende alla schermata giusta.
• Consegna: supporta sia “copia link” che “invia per email” così gli utenti possono passare dal telefono al desktop.

Un esempio pratico: qualcuno inizia una domanda sul telefono, tocca “Inviami il link per riprendere via email” e poi continua sul laptop a casa. Se ruoti i token a ogni ripresa, il link vecchio smette di funzionare dopo un uso, riducendo la condivisione accidentale.

Quando le bozze vengono inviate o scadono

Sii esplicito.

• Se la bozza è già stata inviata, apri una schermata di conferma in sola lettura e offri di iniziarne una nuova.
• Se la bozza è scaduta, spiega cosa è successo in una frase e fornisci un'azione chiara “Inizia di nuovo”.

Evita di creare silenziosamente una nuova bozza. Gli utenti potrebbero presumere che i loro dati originali siano ancora lì.

Sicurezza e privacy per bozze e token di ripresa

Salva e riprendi aiuta solo se le persone si fidano.

Non mettere mai dati personali o aziendali nell'URL. Il link dovrebbe contenere solo un token casuale che di per sé non significa nulla.

Tratta i token di ripresa come password. Generali con sufficiente casualità, rendili abbastanza corti da incollarli, e memorizza solo una versione hashed nel database. L'hashing limita i danni se log o backup vengono divulgati.

I token riutilizzabili sono comodi ma più rischiosi. I token monouso sono più sicuri perché muoiono al primo uso, ma possono infastidire se l'utente clicca due volte su una vecchia email. Un compromesso pratico è un token riutilizzabile che scade presto (ore o giorni), più un'opzione facile “invia un nuovo link”.

Impostazioni sane per la maggior parte dei prodotti:

• Memorizza hash del token, tempo di creazione, tempo di scadenza e ultimo uso
• Scadenzia automaticamente i token ed elimina le bozze vecchie secondo una pianificazione
• Ruota i token dopo la ripresa (anche se la bozza rimane la stessa)
• Logga i tentativi di ripresa (successo e fallimento) per indagini

Il controllo accessi dipende dal fatto che gli utenti debbano essere autenticati.

Se il wizard è per utenti autenticati, il token dovrebbe essere opzionale. La ripresa dovrebbe inoltre richiedere la sessione account e la bozza deve appartenere a quell'utente (o alla loro organizzazione). Questo previene i problemi di “link inoltrato”.

Se il wizard supporta la ripresa anonima, limita cosa la bozza contiene. Evita di memorizzare dettagli di pagamento completi, documenti governativi o qualsiasi cosa dannosa se esposta. Considera la cifratura dei campi sensibili a riposo e mostra solo un riepilogo mascherato al ripristino.

Aggiungi anche protezioni base contro gli abusi. Limita le richieste al controllo token e agli endpoint di ripresa, e blocca i token dopo fallimenti ripetuti.

Pattern UI che riducono l'abbandono

Salva e riprendi fallisce più spesso nella UI che nel backend. Le persone se ne vanno quando si sentono perse, insicure su cosa succede dopo o preoccupate di perdere il lavoro.

Comincia con un senso chiaro di posizione. Mostra un indicatore di progresso con nomi di passo riconoscibili dagli utenti, come “Dati azienda” o “Metodo di pagamento”, non etichette interne. Tienilo visibile e lascia che gli utenti rivedano i passi completati senza punizioni.

Fai sembrare reale il salvataggio, ma non troppo invasivo. Un piccolo stato “Salvato” vicino all'azione primaria più un timestamp “Ultimo salvataggio 2 minuti fa” costruisce fiducia. Se il salvataggio fallisce, dillo chiaramente e indica cosa fare dopo.

Offri una via d'uscita semplice. “Salva e finisci dopo” deve essere normale. Se l'utente chiude la scheda, ricordagli dove era e mostra una schermata semplice di ripresa al ritorno.

Il mobile è dove l'abbandono spesso aumenta, quindi progetta i passi per schermi piccoli. Preferisci passi brevi con pochi campi, target di tocco grandi e tastiere appropriate per il tipo di campo (email, numero, data).

Una checklist UI rapida che di solito aiuta:

• Usa titoli dei passi riconoscibili e mantienili coerenti
• Mostra stato salvato e ultimo salvataggio vicino al pulsante principale
• Offri “Finisci dopo” accanto a “Avanti”, non nascosto in un menu
• Mantieni ogni passo focalizzato su una decisione
• Permetti di correggere errori inline senza bloccare tutto il passo

Errori comuni e come evitarli

Il modo più rapido per aumentare l'abbandono è trattare un wizard come un esame finale. Se blocchi il progresso al passo 1 perché il passo 6 è incompleto, le persone mollano. Un wizard salva-e-riprendi dovrebbe essere indulgente: lascia andare avanti e salva spesso.

Errori di validazione

Una trappola comune è sovravalidare troppo presto. Fai controlli a livello di passo (questo passo è utilizzabile?) e riserva controlli rigorosi per la revisione finale.

Se hai bisogno di paletti senza bloccare, usa avvisi soft (“Puoi finire dopo”) e evidenzia cosa sarà richiesto alla fine.

Errori di dati e workflow

Molti team creano bozze troppo tardi. Se crei la bozza solo dopo il passo 3, i dati iniziali sono fragili: un refresh, crash della scheda o timeout login possono cancellarli. Crea la bozza appena hai un'identità stabile (sessione account o email) e salva a ogni transizione di passo.

Definisci anche l'ownership chiaramente. Decidi chi può riprendere e modificare una bozza: solo l'utente originale, chiunque nella stessa organizzazione o un teammate invitato. Rendi quella regola visibile nella UI.

Altri punti da pianificare:

• Invii duplicati: rendi l'invio finale idempotente (la stessa richiesta due volte non deve creare due record)
• Cambi di ordine dei passi: memorizza una wizard_version e mappa le bozze vecchie ai nuovi passi quando possibile
• Ripresa con dati obsoleti: ricontrolla campi critici (come prezzo del piano) al submit finale
• Pulizia dimenticata: scadi le bozze e i token vecchi e elimina i dati non necessari secondo una pianificazione
• Mancanza di audit trail: logga i cambi di stato così il supporto può aiutare gli utenti bloccati

Checklist rapida prima della pubblicazione

Prima del rilascio, controlla le basi che incidono su abbandono e ticket di supporto.

Controlli funzionali

• La ripresa funziona tra dispositivi e browser.
• Ogni passo può essere salvato anche se il wizard non è completo.
• Le bozze sopravvivono a refresh, timeout e chiusura della scheda.
• C'è un chiaro passo di revisione finale.
• Puoi vedere dove le persone abbandonano (tasso di completamento per passo, tempo per passo, errori di validazione comuni).

Controlli di sicurezza

I link riprendibili sono chiavi temporanee. Tienili privati, a tempo e sicuri da condividere solo intenzionalmente.

Una regola pratica: se qualcuno inoltra l'email alla persona sbagliata, quella persona non dovrebbe poter vedere dati sensibili della bozza. Usa scadenze brevi e richiedi ri-autenticazione per i passi ad alto rischio.

Esempio realistico: onboarding cliente in 6 passi

Immagina un wizard B2B con sei passi: dati azienda, contatti, fatturazione, documenti di compliance, setup prodotto e revisione finale. L'obiettivo è ottenere un account funzionante senza costringere le persone a finire tutto in una sola sessione.

La parte difficile è il passo 4 (documenti di compliance). Alcuni clienti non hanno i file pronti. Altri hanno bisogno dell'approvazione di un responsabile. Quindi il wizard salva una bozza dopo ogni passo e mantiene stati chiari come Draft, Waiting for documents, Waiting for approval o Submitted.

Un momento comune di abbandono: l'utente finisce il passo 3 (fatturazione) e se ne va. Quando ritorna non trova un form vuoto: arriva su una schermata “Riprendi onboarding” che mostra progresso (3 di 6 completati), cosa manca (documenti) e un pulsante per continuare dal passo 4. Questo è il cuore di salva-e-riprendi: trattare l'abbandono come normale, non come fallimento.

Se l'utente è partito da un invito via email o deve cambiare dispositivo, un link riprendibile può riportarlo esattamente alla bozza e al passo, dopo i controlli che richiedi (login, codice monouso o entrambi).

Dal lato team, support e sales possono vedere il progresso delle bozze in una vista admin: quale passo ha raggiunto ogni cliente, da quanto la bozza è inattiva e cosa blocca la submission.

Prossimi passi: rilascia iterativamente e mantieni il tutto manutenibile

Inizia in piccolo. Scegli un wizard che già soffre di abbandono (checkout, onboarding, application) e aggiungi prima le bozze. Un semplice “Salva” più l'autosalvataggio al cambio passo spesso riduce l'abbandono più rapidamente di una riprogettazione completa.

Misura prima di cambiare, poi misura dopo il rilascio. Monitora completamento passo-per-passo, tempo per completare e quante persone riprendono dopo aver lasciato. Guarda anche i ticket di supporto e gli eventi “bloccati” (utenti che rimbalzano tra due passi o falliscono ripetutamente la validazione).

Assumi che il wizard cambierà. Si aggiungono nuovi passi, le domande vengono rinominate e le regole si fanno più severe. Il modo più semplice per evitare di rompere le vecchie bozze è versionare ciò che salvi. Memorizza una wizard_version su ogni bozza e mantieni piccole regole di migrazione così le bozze vecchie possono ancora aprirsi.

Se vuoi costruire un salva-e-riprendi senza programmare l'intero stack a mano, AppMaster (appmaster.io) è un'opzione. Puoi modellare un'entità Draft nel database, costruire la logica passo-passo come Business Process e distribuire lo stesso flusso su web e mobile nativo.