Problema
I dati ci hanno mostrato che un numero significativo di update non andavano a buon fine perché gli utenti effettuavano la stessa richiesta più volte in un breve arco temporale. Inoltre, molti utenti ripetevano la richiesta anche dopo che quella precedente non era andata a buon fine, causando ulteriori errori.
Obiettivi e limitazioni
Diminuire la percentuale di update non andati a buon fine senza effettuare modifiche strutturali.
Aumentare la chiarezza delle informazioni senza sovraccaricare l'utente.
Ipotesi
Per l'utente non è chiaro se l'update richiesto è in fase di lavorazione e quanto tempo serve per completarlo. Dare priorità a queste informazioni e avvisare l'utente dei problemi generati da richieste multiple dello stesso update diminuirà la percentuale di update non andati a buon fine.
Ho accorciato e reso più chiare le informazioni e ho reso più visibile il tempo necessario per completare gli update. Ho riscritto la CTA in modo che sia più specifica e renda chiaro che cosa deve essere confermato dall'utente.
Un messaggio avvisa l'utente quando uno o più update sono in fase di lavorazione.
Se l'utente vuole comunque richiedere lo stesso update, una modale lo informa dei problemi che questo può generare.
Un messaggio avvisa l'utente quando un update non è andato a buon fine e lo invita a controllare lo storico e contattare l'assistenza per risolvere il problema.
Risultati
La percentuale di update non andati a buon fine è scesa progressivamente fino a raggiungere stabilmente il 50% in meno rispetto al periodo antecedente il nostro intervento.
Osservazioni per ulteriori miglioramenti
Le CTA dei due servizi sono incoerenti.
Il titolo "Manage service numbers" non spiega efficacemente a cosa serve quella sezione.
L'informazione sulla quantità di telefoni selezionati può creare confusione in quanto quella stessa frase deve anche spiegare all'utente l'azione da compiere.
L'esperienza utente andrebbe rivista e semplificata sia per "Manage service numbers" che per "Update services".
Problema
Una ricerca qualitativa ha confermato le osservazioni finali emerse durante il progetto precedente. Inoltre, le feature che è possibile gestire autonomamente dall'utente sono limitate e disorganizzate.
Obiettivi e limitazioni
Migliorare l'esperienza utente nella gestione dei servizi.
Aggiungere più feature da poter gestire nonostante lo spazio limitato.
Creare un design che in futuro possa ospitare più servizi da gestire.
Ho riscritto i nomi dei servizi per indicare chiaramente il tipo di modifiche che consentono.
La struttura a card permetterà di aggiungere altri servizi in futuro. In questo modo, l'area di scelta e gestione del servizio rimarrà alla stessa altezza di quella di selezione dei telefoni indifferentemente da quanti servizi verranno aggiunti.
Ho rinominato le network feature per renderle più chiare e le ho raggruppate a seconda dell'area di pertinenza. Questo non solo ha permesso di mantenere la lista compatta nonostante l'aggiunta di 18 nuove feature, ma ha anche risolto un altro problema del vecchio design. Infatti, le feature denominate "bar" avevano un funzionamento opposto rispetto alle altre feature e una volta portate su "on", bloccavano la feature indicata. Unire tutte le feature "bar" in un unico gruppo nominato "restrictions" anziché lasciarle insieme alle altre ne ha reso più chiaro e immediato il funzionamento di queste feature.
Tuttavia, alcune feature "bar" si riferivano strettamente ad altre categorie. Per esempio, tra le nuove feature da includere, c'era il "Full roaming bar". Inserire questa feature all'interno della categoria "restrictions", quando ce n'è una dedicata proprio al roaming, non sarebbe stato corretto. Quindi, dopo aver individuato tutte le feature che presentavano un caso simile, ho proposto di rinominarle e invertirne la logica di funzionamento per allinearlo a quello delle altre feature del gruppo di appartenenza. Per esempio, "Full romaing bar" è diventato "Roaming capability" che diventa attivo su "on" e inattivo su "off".
Ho anche riscritto i nomi e le descrizioni della maggior parte delle feature per renderle più chiare. Infine, dove possibile, ho proposto di accorpare alcune feature con altre che potevano essere gestite insieme. Il documento che ho creato con nome, descrizione e funzionamento di ogni feature è stato discusso con il P.O. e numerosi stakeholder, e ha permesso di arrivare alla lista finale delle feature da inserire sul portale.
Un indicazione numerica segnala quanti update di ogni gruppo sono stati selezionati. In questo modo, anche richiudendo la tendina, l'utente ha sempre una panoramica delle sue scelte. Inoltre, tramite l'icona dedicata, l'utente può visualizzare la descrizione di ogni feature.
Ho scritto una nuova richiesta di conferma che specifica più dettagliatamente il tempo necessario per processare l'update.
Oltre alla richiesta dei codici PAC, STAC e INFO è stata aggiunta la possibilità di richiedere la terminazione del contratto, che precedentemente doveva essere effettuata in un'altra pagina.
La nuova iterazione del messaggio di conferma per la richiesta dei codici PAC, STAC e INFO migliora la leggibilità e la chiarezza delle informazioni.
Inoltre ho creato un nuovo messaggio di conferma per le disconnessioni.