Come implementare nuove funzionalità senza danneggiare gli utenti fedeli

“Sii agile; rilascio anticipato; rilascia spesso. Conosciamo il trapano. Ma è strategicamente saggio continuare a implementare spesso le funzionalità? Soprattutto una volta che un prodotto che stai creando raggiunge una certa dimensione, probabilmente non vuoi rischiare l'integrità della tua applicazione con ogni nuova versione minore.

La cosa peggiore che può succedere al tuo prodotto è che gli utenti fedeli, i clienti che hanno utilizzato quella piccola funzionalità in modo coerente nel corso degli anni, improvvisamente non sono in grado di utilizzarla nello stesso modo conveniente. Il cambiamento potrebbe potenziare maggiormente gli utenti, ma l'esperienza diventa meno semplice. La frustrazione e l'ansia entrano nei social media in modo rapido e improvviso e la pressione sull'assistenza clienti per rispondere in modo significativo e in tempo aumenta di minuto in minuto. Ovviamente, non vogliamo lanciare nuove funzionalità solo per renderci conto che in realtà danneggiano gli utenti fedeli.

Ulteriori letture su SmashingMag: Link

• Come abbiamo iniziato a rilasciare le funzionalità due volte più velocemente
• L'elenco di controllo per il lancio del sito Web: 15 controlli essenziali prima della pubblicazione
• Un approccio incentrato sull'utente al web design per dispositivi mobili
• Come lanciare qualsiasi cosa

Possiamo evitarlo essendo più strategici durante il lancio di nuove versioni dei nostri prodotti. In questo articolo, esamineremo una strategia per i progettisti di prodotti e gli ingegneri front-end per testare e distribuire a fondo una funzionalità prima di rilasciarla all'intera base di utenti e come evitare che i problemi di UX si insinuino lungo la strada.

Prima di immergerci in una vera e propria strategia di test, facciamo un passo indietro ed esaminiamo le idee sbagliate comuni su come una nuova funzionalità viene progettata, costruita e infine implementata.

Idee sbagliate sulle nuove funzionalità

Ogni volta che viene progettata una nuova funzionalità per un prodotto esistente, l'obiettivo principale è solitamente come esattamente dovrebbe essere integrata nell'interfaccia esistente. Per ottenere la coerenza, noi designer esamineremo spesso i modelli esistenti e applicheremo il linguaggio di progettazione stabilito per far sì che la nuova funzionalità si adatti bene all'interfaccia utente. Tuttavia, i problemi spesso si verificano non perché i componenti non funzionino insieme visivamente, ma piuttosto perché risultano confusi o ambigui se combinati in modi inaspettati .

Forse la copia dell'interfaccia è ambigua in aree correlate ma distanti del sito Web, o il risultato dell'utilizzo attivo di due funzionalità contemporaneamente ha senso dal punto di vista tecnico ma non corrisponde alle aspettative dell'utente o ha importanti implicazioni sulle prestazioni e danneggia l'UX .

In effetti, nel design, sono queste numerose combinazioni che sono così difficili da prevedere e rivedere a fondo. Un modo per affrontare il problema già nel processo di progettazione consiste nel considerare i valori anomali: casi d'uso in cui è più probabile che le cose vadano storte. Come sarebbe un profilo utente se il nome dell'utente è molto lungo? Una panoramica delle e-mail senza risposta è ancora ovvia quando vengono utilizzate una dozzina di etichette di posta in arrivo? Un nuovo filtro avrebbe senso per gli utenti che si sono appena registrati e hanno solo poche email nella loro casella di posta?

Progettazione di valori anomali: lo stack dell'interfaccia utente

Come possiamo progettare esattamente i valori anomali una volta che li abbiamo identificati? Una buona strategia è studiare i diversi stati dell'interfaccia utente. Lo "stack dell'interfaccia utente", un'idea introdotta da Scott Hurff, è versatile e complicato e quando progettiamo le nostre interfacce, di solito non è sufficiente creare un mockup perfetto per i pixel in Photoshop, Sketch o HTML e CSS: dobbiamo considerare vari casi limite e stati: lo stato vuoto, lo stato di caricamento, lo stato parziale, lo stato di errore e lo stato ideale. Questi non sono così semplici come potremmo pensare.

Lo stato vuoto non deve essere vuoto: potremmo utilizzare gli operatori dei servizi per fornire una migliore esperienza offline ai visitatori regolari. Lo stato parziale non deve essere interrotto: potremmo migliorare l'esperienza con immagini e JavaScript non funzionanti attraverso un miglioramento progressivo.

Lo stato ideale potrebbe differire in modo significativo dai nostri modelli di "risultato perfetto", a causa delle preferenze personalizzate dell'utente e della scelta del browser dell'utente; alcuni contenuti e font Web potrebbero non essere visualizzati a causa della configurazione di un browser, ad esempio.

Quindi, il panorama è, come sempre, complesso, contorto e imprevedibile, e non possiamo trascurare il rischio che le cose vadano storte, ma questo non significa che non possiamo minimizzare il rischio in modo efficace. Esplorando i valori anomali e l' intero stack dell'interfaccia utente all'inizio, possiamo prevenire problemi di UX comuni nelle prime fasi di progettazione. Non diventa più facile dal punto di vista tecnico, però.

L'effetto farfalla nella distribuzione

Anche modifiche minori tendono a portare a reazioni a catena, introducendo bug in aree e situazioni che sembrano assolutamente non correlate. La ragione principale di ciò è l'enorme quantità di variabili che influenzano l'esperienza dell'utente ma che sono fuori dal nostro controllo. Conosciamo i nostri metodi con i browser, ma ciò non significa che sappiamo di più sul contesto in cui un utente sceglie di vedere il sito Web che abbiamo creato in modo così instancabile e completo.

Ora, mentre modifiche minori come il riempimento su un pulsante o un'area di testo progressivamente migliorata potrebbero non sembrare un grosso problema, tendiamo a sottovalutare l'impatto di queste piccole modifiche o funzionalità brillanti su larga scala. Ogni volta che prendiamo una decisione di progettazione o sviluppo, quel cambiamento ha qualche effetto sul sistema complesso che stiamo costruendo, soprattutto perché i componenti che stiamo costruendo non esistono mai isolati.

La realtà è che non costruiamo mai un pulsante, né scriviamo mai una nuova funzione JavaScript: pulsanti e funzioni appartengono a una famiglia di componenti o librerie e operano tutti all'interno di una determinata impostazione e sono inevitabilmente collegati ad altri parti del sistema dalle loro proprietà o dal loro ambito o dal loro nome o dalle convenzioni non scritte del team.

Queste connessioni "silenziose" appena percettibili sono il motivo per cui è difficile implementare le funzionalità e perché prevedere le conseguenze di vasta portata di un cambiamento spesso si rivela un esercizio di vista acuta. Ecco perché è una buona idea evitare il più possibile le dipendenze non necessarie, che si tratti di CSS o JavaScript: non ti aiuteranno con la manutenzione o il debug, soprattutto se ti affidi a una libreria che non comprendi appieno .

Fortunatamente, per comprendere meglio l'impatto di una modifica, possiamo utilizzare risorse come gli strumenti di sviluppo di un browser. Possiamo misurare la portata di un selettore o di una funzione JavaScript e, a volte, potrebbe essere una buona idea tornare su di essa durante lo sviluppo per mantenere l'ambito della modifica il più locale e minimo possibile.

Questo è utile, ma è anche solo una parte della storia. Facciamo ipotesi, consciamente e inconsciamente, sulla base della nostra esperienza con l'interfaccia e delle nostre abitudini, spesso dimenticando che le ipotesi potrebbero (e, quindi, cambieranno ) in modo significativo da utente a utente. La maggior parte delle applicazioni ha una sola interfaccia, ma questa o le sue configurazioni possono avere dozzine di stati, con viste che cambiano a seconda delle impostazioni e delle preferenze dell'utente.

Pensa a dashboard con schede personalizzabili (software di analisi), client di posta con visualizzazioni "compatte", "comode" e "dettagliate" (Gmail), un'interfaccia di prenotazione che cambia per i clienti loggati e per gli ospiti, un'esperienza di lettura per le persone che utilizzano un ad blocker o un filtro antivirus aggressivo. L'effetto farfalla ha un impatto non solo sulla base di codice; anche tutti questi fattori esterni hanno un peso e il test contro di essi, a differenza degli unit test o del QA in generale, è molto difficile perché spesso non sappiamo nemmeno su cosa testare.

Convalida delle funzionalità e massimo locale

Possiamo utilizzare la diagnostica e le metriche per determinare quali modifiche devono essere apportate, ma seguendo i soli dati, potresti finire per stagnare a quello che tendiamo a chiamare un "massimo locale", uno stato dell'interfaccia con un design sufficientemente buono ma che manca completamente di innovazione perché segue sempre iterazioni logiche e prevedibili. Quando si lavora su un progetto ed esploriamo i dati, tendiamo a raggruppare le funzionalità nei seguenti quattro bucket:

• Funzionalità interrotte. . Funzionalità che sembrano danneggiate o inefficienti: ovviamente, dobbiamo risolverle;
• Funzionalità inutilizzate. . Funzionalità che funzionano come previsto ma vengono utilizzate raramente, spesso un segno che dovrebbero essere rimosse o hanno un disperato bisogno di innovazione;
• Funzionalità d'uso impreviste. . Caratteristiche che vengono utilizzate in un modo estremamente diverso da quello che i loro creatori avevano originariamente immaginato: un buon candidato per un perfezionamento lento e continuo;
• Funzionalità del cavallo di battaglia. . Funzionalità che sono ampiamente utilizzate e sembrano funzionare come previsto, nel qual caso ci chiediamo se esiste un modo per migliorare ulteriormente la loro UX esplorando in parallelo sia il lento processo iterativo che concetti innovativi completamente diversi.

I primi due bucket sono fondamentali per mantenere un'interfaccia funzionale e utilizzabile, mentre gli ultimi due sono fondamentali per mantenere gli utenti coinvolti e felici. Idealmente, vogliamo raggiungere entrambi gli obiettivi contemporaneamente, ma i limiti di tempo, budget e squadra hanno il sopravvento.

Tuttavia, una volta scelta una nuova iterazione o una nuova idea, si può essere tentati di saltare subito alla progettazione o alla costruzione della nuova funzionalità. Ma prima ancora di pensare a come una funzionalità si adatterebbe a un'interfaccia esistente, è una buona strategia convalidare prima l'idea, con un rapido prototipo e una ricerca dell'utente. Un modo comune per raggiungere questo obiettivo è utilizzare un processo iterativo rapido, come lo sprint di progettazione di Google Ventures. Eseguendo un'iterazione entro un paio di giorni, puoi identificare come implementare la nuova funzionalità e/o se è utile nel modo in cui l'avevi immaginata inizialmente.

Con gli sprint di design, esponiamo l'idea alla ricerca sull'usabilità nella fase iniziale. Nella metodologia di Google Ventures, testeresti un progetto con cinque utenti al giorno; quindi, iteraresti e faresti un altro giro di test del nuovo design. Il motivo per cui sono coinvolti tutti gli stessi utenti è perché se si testa un design diverso con ogni utente quel giorno, non si avrebbero dati validi per sapere quali elementi dovrebbero cambiare. Sono necessari alcuni utenti per convalidare un'iterazione di progettazione.

Applichiamo un modello leggermente diverso nei nostri sprint. Quando iniziamo a lavorare su una nuova funzionalità, una volta creato il primo prototipo iniziale, riuniamo designer, sviluppatori e il team UX nella stessa stanza, invitiamo utenti reali a testare e quindi ripetere in base a un programma serrato. Il primo giorno, i primi tester (da due a tre persone) potrebbero essere programmati per un colloquio di 30 minuti alle 9:00, il secondo gruppo alle 11:00, il successivo alle 14:00 e l'ultimo uno intorno alle 16:00. Tra le interviste con gli utenti, abbiamo "finestre temporali aperte", quando effettivamente ripetiamo il design e il prototipo fino a quando ad un certo punto non abbiamo qualcosa di fattibile.

La ragione di ciò è che, all'inizio, vogliamo esplorare rapidamente direzioni completamente diverse, a volte anche opposte; una volta raccolto feedback su diverse interfacce, possiamo convergere verso quella che sembra l' interfaccia del "massimo assoluto" . In questo modo possiamo ottenere feedback molto diversificati su iterazioni di progettazione molto diversificate in questo modo. Il feedback si basa principalmente su tre fattori: mappe di calore che registrano i clic degli utenti, il tempo necessario agli utenti per completare un'attività e quanto sia piacevole l'esperienza per loro. Nel corso della settimana, continuiamo a lavorare in modo coerente con un numero maggiore di utenti, proprio come fa Google, convalidando permanentemente il nuovo design man mano che procediamo.

Fin qui tutto bene, ma a volte una nuova funzionalità apparentemente innovativa si scontra con una funzionalità esistente e averle entrambe nella stessa interfaccia ingombra il design. In questo caso, esploriamo se una delle opzioni possa essere considerata un'estensione dell'altra. Se potesse essere, allora iniziamo ribadendo la sua funzionalità e il design. È allora che dobbiamo scegliere una riprogettazione radicale o un cambiamento incrementale. Il secondo è meno rischioso e manterrà un modello di interazione familiare per gli utenti, mentre il primo è necessario se è impossibile ottenere modifiche critiche in altro modo o se i guadagni derivanti da modifiche incrementali sarebbero troppo superficiali.

In entrambi i casi, è fondamentale mantenere l'attenzione sull'intera esperienza utente del prodotto, piuttosto che sul valore di una singola funzionalità all'interno di quel prodotto. E una volta che hai scelto la funzione e hai progettato e realizzato il primo prototipo, è il momento di testare.

Gli otto livelli di test

Bene, allora, come possiamo prevenire efficacemente che errori e guasti si insinuino in un ambiente reale reale? Quanti controlli, revisioni e test eseguiamo prima che una funzionalità venga distribuita? E in quale sequenza eseguiamo questi test? In altre parole, quale sarebbe la strategia definitiva per implementare le funzionalità?

Una delle migliori strategie per implementare le funzionalità è stata proposta da Andrew Sumin, responsabile dello sviluppo di Mail.ru, uno dei principali provider di posta elettronica in Russia. La strategia non sarebbe applicabile a tutti i progetti, ma è un approccio ragionevole e completo per le aziende che servono prodotti di medie e grandi dimensioni a migliaia di clienti.

Diamo un'occhiata alla strategia in dettaglio e copriamo gli otto passaggi di un'implementazione di funzionalità, coprendo il processo di sviluppo del prodotto di Mail.ru:

1. prova con gli sviluppatori,
2. testare con utenti reali in un ambiente controllato,
3. testare con utenti a livello aziendale,
4. prova con beta tester,
5. testare con utenti che aderiscono manualmente,
6. split-test e verifica conservazione,
7. rilasciare lentamente e gradualmente,
8. misurare le conseguenze.

Nel caso di Mail.ru, la caratteristica più importante da mantenere intatta a prescindere da cosa stia componendo un messaggio (ovviamente). Questo è il pezzo più utilizzato dell'interfaccia e consentire che non sia disponibile o funzioni in modo errato anche per secondi sarebbe assolutamente fuori questione. Quindi, cosa accadrebbe se volessimo estendere la funzionalità di un'area di testo, magari aggiungendo alcune funzioni intelligenti di completamento automatico, o un contatore o un'anteprima laterale?

1. Prova con gli sviluppatori

Più tempo passa nello sviluppo, più costoso diventa risolvere un problema. Ancora una volta, pensa a quanto sono connesse tutte le decisioni nello sviluppo del prodotto; più raffinato è il prodotto, più decisioni devono essere annullate, costando tempo e risorse. Quindi, identificare e risolvere i problemi nelle prime fasi sia dal punto di vista del business che dal punto di vista del design e dello sviluppo.

Tuttavia, non è possibile eseguire il debug di un'idea, quindi i test iniziali dovrebbero aver luogo durante la produzione, sui primissimi prototipi. I primi tester di Mail.ru, quindi, sono gli sviluppatori che scrivono effettivamente il codice. L'azienda incoraggia i propri dipendenti a utilizzare il prodotto per la comunicazione interna (e anche privata); quindi, gli sviluppatori potrebbero essere considerati utenti irriducibili del prodotto.

Il primo passaggio è abbastanza ovvio: progettare e creare la funzionalità, quindi testarla, rivederla e distribuirla localmente sul server di staging. È qui che entrano in gioco i test QA, con strumenti completi e task runner che tentano di mandare in crash la funzionalità e l'interfaccia, potenzialmente automatizzati con strumenti di test delle scimmie come Gremlins.js.

I risultati vengono monitorati e quindi reinseriti nel ciclo di feedback per la successiva iterazione della funzione. Ad un certo punto, gli sviluppatori si sentiranno abbastanza sicuri della build: la modifica sembra funzionare come previsto e i requisiti sono stati soddisfatti. È allora che entrano in gioco i test degli utenti reali.

2. Testare con utenti reali in un ambiente controllato

Quando il primo prototipo funzionante è terminato, la funzionalità viene testata con utenti reali in interviste. I clienti sono invitati a completare le attività e, mentre lo fanno, il team UX monitora i vicoli ciechi e i problemi che emergono e li affronta sul posto.

Tuttavia, non solo la nuova funzionalità è in fase di test; l'obiettivo del test di usabilità è garantire che la nuova funzionalità non influisca sui componenti critici dell'interfaccia, motivo per cui gli utenti completano le attività di routine, come la composizione di un messaggio e l'apertura, la risposta e l'esplorazione delle e-mail nella posta in arrivo. Se sia la nuova funzionalità che le vecchie funzionalità sono ben comprese, il processo può andare avanti.

3. Testare con utenti a livello aziendale

Ovviamente, il feedback del test di usabilità spinge gli sviluppatori a introdurre modifiche, che poi tornano ai tester di usabilità, andando avanti e indietro fino a quando il risultato sembra avere valore per un pubblico più ampio. Il passaggio successivo, quindi, è che la funzionalità venga messa in evidenza all'interno dell'azienda: viene inviata un'e-mail a tutta l'azienda che incoraggia tutti i colleghi a controllare la funzionalità e inviare segnalazioni, bug e suggerimenti in un tracker.

Con i test, non c'è una differenza particolarmente grande tra gli utenti nei reparti "remoti" all'interno dell'azienda e gli utenti in natura. Anche gli utenti interni non sanno quali cambiamenti aspettarsi o sanno esattamente cosa fa una funzione o come dovrebbe funzionare o apparire. L'unica differenza principale è che ai colleghi può essere richiesto di inviare rapidamente un feedback o lasciare un commento. Questo è quando vengono introdotti i moduli di voto. I tester possono non solo giocare con la funzione, ma anche aggiungere un commento e votarlo verso l'alto o verso il basso. Il voto deve essere valutato rispetto alla strategia del prodotto e ai requisiti aziendali, ma se gli utenti trovano chiaramente una funzionalità inutile o utile, è un modo semplice ed efficace per raccogliere feedback e verificare se il prodotto funziona come previsto.

4. Prova con i beta tester

Se una funzionalità ha superato un controllo tecnico, un controllo di usabilità e una revisione all'interno dell'azienda, il passaggio logico successivo è presentarla ad alcuni segmenti dell'audience. Tuttavia, invece di distribuirlo a un segmento casuale di utenti, il team invia una funzionalità per la revisione tra i beta tester, utenti che hanno scelto di partecipare ai test e inviare feedback per le funzionalità sperimentali. Possono eseguire il downvote o l'upgrade di una funzionalità, nonché segnalare bug e eseguire il commit di parti di codice.

Ma come si scelgono i beta-tester appropriati? Bene, se vuoi incoraggiare i tester a rompere l'interfaccia, potresti concentrarti su utenti fedeli avanzati con competenze tecniche: utenti che sarebbero in grado di fornire dettagli tecnici su un bug, se necessario, e utenti che conoscono l'interfaccia esistente abbastanza bene da esserlo in grado di anticipare i problemi che altri utenti potrebbero avere.

Tuttavia, sono necessari criteri per determinare se un utente è sufficientemente avanzato per essere un beta tester. Nel caso di un client di posta elettronica, potrebbe essere qualcuno che utilizza Chrome o Firefox (cioè sa come cambiare il browser predefinito), che ha creato più di tre cartelle nella propria casella di posta e che ha anche installato l'app mobile.

5. Testare con utenti che aderiscono manualmente

Finora i test hanno coinvolto un numero gestibile di utenti, configurazioni e rapporti di prova. Tuttavia, la diversità di utenti, sistemi e configurazioni in natura, inclusi sistema operativo, browser, plug-in, impostazioni di rete, software antivirus e altre applicazioni installate localmente, può essere di dimensioni leggermente più scoraggianti.

Nel caso di Mail.ru, il passo successivo è implementare la funzionalità in un'interfaccia live, dietro una bandiera, e inviare un'e-mail a questo segmento più ampio di utenti attivi, presentando la nuova funzionalità e invitandoli ad attivarla sul proprio proprio nell'interfaccia, di solito con un pulsante lucido "Aggiorna". Per misurare il valore della funzionalità per gli utenti effettivi, il team utilizza di nuovo un sistema di voto, con alcune richieste qua e là, che sostanzialmente chiedono agli utenti se trovano la funzionalità utile o utile. Si noti che la differenza tra questo livello e il livello precedente è che l'attivazione manuale coinvolge un pubblico molto più ampio, molti dei quali non sono affatto tecnici, a differenza dei beta tester.

Quindi, tempismo e coordinamento sono importanti . Probabilmente non sceglieresti un giorno a caso per inviare l'e-mail agli utenti attivi, perché vorrai che il team di assistenza clienti e gli sviluppatori siano disponibili quando il flusso di segnalazioni di bug inizia ad arrivare. Ecco perché l'e-mail viene inviata all'indirizzo l'inizio della settimana, quando tutti (o la maggior parte) degli sviluppatori sono disponibili e il team di supporto è pronto per entrare in azione, dopo essere stato informato e connesso attivamente con gli sviluppatori tramite Skype o Slack. In un'azienda più piccola, potresti persino far sedere gli sviluppatori per alcune ore ai banchi di supporto per arrivare più rapidamente al nocciolo di un problema parlando direttamente con i clienti.

6. Prova divisa e controlla la conservazione

Nei passaggi fino ad ora, ad eccezione dei test di usabilità, tutti i tester hanno utilizzato la nuova funzionalità volontariamente. Tuttavia, se abiliti la funzione per impostazione predefinita, all'improvviso gli utenti dovranno utilizzarla e questo è un tipo di gruppo molto diverso, che non abbiamo affatto testato.

Per assicurarti di non rompere le abitudini degli utenti passivi, puoi eseguire lo split test con tre piccoli segmenti di utenti e misurare la fidelizzazione . Dopotutto, vuoi assicurarti che una nuova versione funzioni almeno come la precedente. Identifica l'attività più importante nell'interfaccia e misura non solo quanto tempo gli utenti trascorrono su di essa prima e dopo il roll-out, ma anche quanto tempo passa prima del loro ritorno. Nel caso di Mail.ru, la conservazione comporta che gli utenti controllino la propria posta elettronica e scrivano un messaggio. Più spesso un utente torna, maggiore è la fidelizzazione, che è un indicatore di una migliore UX.

Ogni segmento ottiene una vista leggermente diversa , che ci consente di testare come visualizzare la nuova funzionalità a tutti gli utenti in un secondo momento. Per il primo segmento, aggiungiamo la nuova funzionalità e forniamo un tutorial su come utilizzarla. Per il secondo segmento, aggiungiamo semplicemente la nuova funzionalità. Per il terzo segmento, potremmo lasciare la funzione così com'è. Per tutti questi segmenti, potremmo implementare la modifica contemporaneamente, selezionare un periodo di tempo ragionevole per eseguire il test, misurare la fidelizzazione e quindi confrontare i risultati. Maggiore è la fidelizzazione di un segmento, più è probabile che il design venga promosso a tutti gli utenti in seguito.

7. Rilasciare lentamente e gradualmente

Se una funzione è arrivata fino a questo punto, probabilmente funziona già bene per un ampio segmento di pubblico. Questo è il momento in cui puoi distribuirlo gradualmente a tutti gli utenti, con una richiesta di voto per raccogliere feedback. Se il feedback è per lo più positivo, puoi continuare a implementare la funzione e alla fine diventerà parte integrante dell'interfaccia. In caso contrario, valuteresti il ​​feedback e tornerai al laboratorio per l'iterazione successiva.

Tuttavia, l'implementazione della funzionalità non è sufficiente: deve essere comunicata agli utenti. Un modo comune per farlo è tramite e-mail e social media. Tuttavia, potrebbe essere utile anche un breve tutorial dettagliato che spieghi il valore della funzionalità in scenari di vita reale. Inoltre, non dimenticare di integrare una casella dei suggerimenti per raccogliere immediatamente un feedback.

8. Misura le conseguenze

Una volta che la funzionalità è stata implementata, possiamo monitorarne le prestazioni e provare diversi metodi per attirare l'attenzione su di essa, in modo che gli utenti possano svolgere le proprie attività in modo più efficiente. È possibile tenere traccia delle attività più comuni o delle pagine più visitate e quindi visualizzare una piccola nota in linea che consiglia un modo leggermente più intelligente e veloce per consentire all'utente di raggiungere il proprio obiettivo, quindi misurare se l'utente preferisce questa nuova funzionalità o il metodo abituale.

Non dimenticare di riportare il feedback all'intero team, non solo agli sviluppatori o ai designer, in modo che siano motivati ​​e coinvolti e vedano come le persone utilizzano una funzionalità che inizialmente non era altro che un'idea approssimativa. Niente è più motivante che vedere persone felici e contente che usano un'applicazione esattamente nel modo in cui ti aspettavi, o in modi completamente diversi. Inoltre alimenterà la crescita delle caratteristiche successive della squadra.

Il processo di revisione sembra complesso e completo, ma a volte solo il tempo e un'ampia rete per i test degli utenti possono svelare un problema. Ad esempio, se una modifica influisce sull'aspetto della panoramica dei messaggi in arrivo, nessun test unitario potrebbe scoprire le difficoltà che potrebbero incontrare gli utenti del software assistivo. In un'interfaccia di posta, cosa vuoi che il dispositivo di accessibilità legga per primo: la data, il mittente, la riga dell'oggetto o il messaggio stesso? Il modo in cui riorganizzi le colonne nella panoramica potrebbe cambiare il modo in cui gli utenti scelgono di accedere alle informazioni; quindi, anche consentire loro di disattivare la nuova funzionalità sarebbe fondamentale.

Conclusione

Allora, che aspetto ha una strategia di roll-out? Potresti iniziare esplorando il grafico delle dipendenze per capire quanto potrebbe essere di vasta portata la tua modifica. Quindi, potresti testare la funzionalità con sviluppatori e con utenti reali in un ambiente controllato. Quindi, potresti chiedere ai colleghi di rivedere la funzionalità, prima di inviarla a un gruppo selezionato di beta tester. Infine, potresti rendere la funzione disponibile come opzione per gli utenti. E, prima di abilitare la funzionalità per tutti, è possibile eseguire uno split test per capire il modo migliore per introdurre la funzionalità e quindi misurare i tassi di conservazione per le attività critiche.

Ovviamente, la distribuzione non è un processo lineare . Durante tutto il processo, potresti dover fare due passi indietro per fare un passo avanti, fino a quando non avrai finalmente un candidato per il rilascio. Il flusso di lavoro sopra descritto potrebbe sembrare piuttosto lento e non particolarmente agile, ma riduci drasticamente il rischio che gli utenti si trovino improvvisamente di fronte a un problema imprevisto e di conseguenza abbiano un'esperienza inferiore. In alcune situazioni, potrebbe valerne la pena.