Spesso i requisiti falliscono perché vengono definiti troppo tardi nel processo di pensiero. Un feature brief può descrivere schermate, regole e casi limite, ma tralasciare la sequenza reale che un utente deve seguire. I product manager possono colmare questa lacuna mappando i flussi utente prima ancora di redigere qualsiasi ticket di progettazione o attività di sviluppo. Questo rende il lavoro meno reattivo e offre al team una visione più chiara di ciò che il prodotto deve aiutare l'utente a realizzare.
Mappatura dei percorsi utente, dall'intento al successo.
Una mappa del flusso utente dovrebbe mostrare il percorso dall'intento al risultato. Dovrebbe includere dove l'utente entra, quali punti decisionali appaiono, quali informazioni sono necessarie e dove il prodotto potrebbe perdere l'utente. Un riferimento pratico, il Libreria di flussi utente PageFlows, Questo strumento può aiutare i product manager a studiare i flussi reali di acquisizione, attivazione, monetizzazione, fidelizzazione e supporto prima di trasformare le ipotesi in requisiti. Il valore non sta nel copiare un modello, ma nel vedere come i prodotti reali strutturano le fasi, gli attriti, il recupero e il completamento.
Parti dall'obiettivo aziendale, poi traducilo in movimento degli utenti.
Un flusso non dovrebbe iniziare con un nome utente, bensì con un obiettivo di prodotto misurabile. L'acquisizione potrebbe significare convincere un visitatore a registrarsi, mentre l'attivazione potrebbe significare aiutare un nuovo account a raggiungere il primo risultato utile. La monetizzazione potrebbe comportare un upgrade, un acquisto o la decisione di sottoscrivere un abbonamento. La fidelizzazione potrebbe includere promemoria, salvataggio dei progressi, avvisi di rinnovo o attività di re-engagement. L'assistenza potrebbe consistere nel risolvere un problema senza costringere l'utente a un lungo ciclo di contatto con un operatore. Una volta che l'obiettivo è chiaro, il Product Manager può descrivere quali azioni deve compiere l'utente.
Separare il flusso principale dai percorsi di recupero
Il flusso principale rappresenta il percorso più pulito. Mostra cosa succede quando l'utente comprende l'offerta, ha le informazioni corrette e completa ogni passaggio senza problemi. Questo percorso è importante perché fornisce al team un punto di riferimento. Aiuta anche a eliminare il lavoro superfluo dalla prima versione dei requisiti. Se il percorso principale risulta confuso sulla carta, è probabile che il prodotto risulti peggiore nell'utilizzo.
I percorsi di recupero sono il punto in cui emergono molte lacune nei requisiti di sicurezza. Un utente dimentica la password, seleziona il piano sbagliato, abbandona il processo di acquisto, inserisce dati di pagamento non validi o ha bisogno di cambiare l'indirizzo email.
Questi casi non sono secondari dal punto di vista dell'utente. Spesso sono i momenti in cui la fiducia viene ricostruita o persa. Un product manager dovrebbe mapparli prima di definire i criteri di accettazione, perché sviluppatori e designer devono sapere come si comporta il prodotto quando il percorso si interrompe.
Acquisizione, attivazione, monetizzazione, conservazione e supporto delle mappe come sistemi separati
I flussi di acquisizione riguardano il passaggio dall'interesse iniziale all'ingresso nel prodotto. Il product manager dovrebbe definire la fonte dell'intento, la promessa fatta e la prima azione prevista da parte dell'utente. Un visitatore proveniente da una ricerca, da un referral, da media a pagamento o da una campagna email potrebbe aver bisogno di un contesto diverso prima di intraprendere un'azione. Il requisito non dovrebbe presupporre che ogni utente parta con lo stesso livello di consapevolezza. Una buona mappatura dell'acquisizione mostra cosa è necessario comprendere prima che inizi la registrazione.
I flussi di attivazione meritano una mappa a parte, perché la registrazione non equivale all'attivazione. La creazione di un account può essere necessaria, ma raramente è l'esito che dimostra il valore del prodotto. Il product manager dovrebbe definire il primo momento di successo significativo e tracciare il percorso più breve e ragionevole per raggiungerlo. Tale percorso può includere l'onboarding, le autorizzazioni, le preferenze, i dati di esempio, le fasi di configurazione o il completamento della prima attività. Ogni passaggio dovrebbe guadagnarsi la sua importanza aiutando l'utente a raggiungere più rapidamente l'utilità del prodotto.
I flussi di monetizzazione richiedono un'attenta definizione dei requisiti prima della stesura degli stessi. Il Product Manager dovrebbe definire quando viene visualizzata un'offerta a pagamento, quali informazioni l'utente già possiede, quale confronto è necessario e cosa accade dopo il pagamento. Pagine dei prezzi, inviti all'aggiornamento, schermate di checkout, fatture, fine del periodo di prova e avvisi di rinnovo appartengono allo stesso sistema. I requisiti dovrebbero includere anche le procedure di cancellazione, rimborso e cambio di piano, poiché questi momenti influenzano le conversioni future. Un flusso di pagamento che nasconde le vie di uscita può aumentare il tasso di conversione a breve termine, ma può generare richieste di assistenza evitabili in seguito.
Trasforma ogni flusso in decisioni, input, stati e risultati.
Una volta disegnato il flusso, questo dovrebbe essere tradotto in semplici blocchi di requisiti. Ogni passaggio richiede una decisione, un input, uno stato del sistema o un risultato. Una decisione chiede all'utente di scegliere. Un input chiede all'utente di fornire informazioni. Uno stato indica al team cosa sa il prodotto in quel momento. Un risultato conferma cosa è cambiato dopo il passaggio. Questa struttura impedisce che il requisito si trasformi in una vaga descrizione di una schermata.
Utilizza la mappa di flusso per scrivere biglietti migliori
Un ticket efficace dovrebbe indicare un punto preciso all'interno del flusso. Dovrebbe spiegare l'intento dell'utente, la condizione di ingresso, l'azione prevista, lo stato di successo e i principali stati di errore. Questo rende il ticket più facile da stimare e da testare. Inoltre, fornisce ai team di progettazione e ingegneria una motivazione condivisa per il lavoro svolto. Senza questo contesto di flusso, i team spesso discutono di dettagli superficiali prima di concordare sul problema che il passaggio risolve.
Un'utile abitudine nella gestione dei progetti è quella di considerare i requisiti come il risultato di un processo di pensiero orientato al flusso, non come il punto di partenza. Una mappatura del flusso può rivelare che una funzionalità pianificata è in realtà composta da cinque flussi interconnessi, o che una schermata richiesta non è affatto necessaria. Può mostrare che la pressione sul supporto deriva da un'attivazione poco chiara, o che la monetizzazione fallisce perché il confronto tra i piani avviene troppo presto. Queste scoperte non sono una strategia astratta. Cambiano il lavoro che viene scritto, progettato, realizzato e misurato.
Mappa il flusso prima di scrivere i requisiti e il lavoro diventerà più preciso in ogni fase. Pensare in termini di flusso permette di individuare schermate ridondanti, lacune nascoste nei meccanismi di ripristino e richieste mal programmate prima che si trasformino in un ticket, in modo che ciò che viene realizzato risolva il problema giusto fin da subito.
Leave A Comment