Apri un’applicazione per svolgere un’attività semplice e ti ritrovi davanti menu, pulsanti, impostazioni e possibilità che non sai distinguere. Volevi completare un lavoro, ma prima devi capire da dove cominciare. Se poi sei tu a progettare quello strumento, potresti guardare la stessa schermata e vedere tante opportunità offerte al cliente.
È qui che vale la pena mettersi in discussione. Quello che per noi rappresenta una possibilità in più, per chi utilizza il prodotto potrebbe essere una scelta in più da decifrare.
Quando valuto se mantenere una funzione, partirei quindi da una domanda: quale problema risolve e per chi? Prima di ragionare su quanto sia interessante o su quanto lavoro abbia richiesto svilupparla, cercherei di capire che cosa permette alle persone di ottenere.
Guardare l’utilità oltre il numero di utilizzi
Una funzione può essere utilizzata ogni giorno oppure servire soltanto in determinate circostanze. Questa differenza conta, ma da sola non basta a stabilirne il valore.
Immagina un programma gestionale con uno strumento necessario per preparare un documento richiesto poche volte l’anno. Potresti vedere pochi utilizzi, ma per chi deve produrre quel documento la funzione potrebbe essere importante. Prima di eliminarla, vorrei sapere come verrebbe svolto quel lavoro e quali difficoltà comporterebbe l’alternativa.
Allo stesso tempo, ogni funzione richiede attenzione: bisogna mantenerla funzionante, aggiornarla, spiegarla e rispondere alle richieste di assistenza. Anche questo entra nella valutazione, insieme alla fatica che introduce per chi comincia a usare il prodotto.
Se una persona deve comprendere dieci opzioni prima di svolgere la sua prima attività, dobbiamo interrogarci su come abbiamo organizzato il percorso. Quanto deve imparare prima di ottenere qualcosa di utile? E ciò che le chiediamo di capire è necessario proprio in quel momento?
Per me conta anche la coerenza con ciò che il prodotto vuole offrire. Se proponi uno strumento semplice per organizzare il lavoro, ogni aggiunta dovrebbe contribuire a quella promessa. Una possibilità può essere valida e, allo stesso tempo, poco adatta alla direzione che hai scelto.
Anche senza dati perfetti possiamo cominciare da questi ragionamenti. Possiamo chiarire che cosa sappiamo, quali ipotesi stiamo facendo e quali informazioni servono per decidere.
I numeri aiutano, ma vanno interpretati
Guardare come viene utilizzato un prodotto permette di osservare dove le persone si fermano, quali attività completano e quando chiedono aiuto. Sono elementi utili, purché lasciamo spazio a più di una spiegazione.
Una funzione poco utilizzata potrebbe essere superflua, ma potrebbe anche essere difficile da trovare. Molti passaggi sulla stessa schermata potrebbero indicare interesse oppure difficoltà a completare il lavoro. Il dato ci offre un punto da approfondire; il significato richiede una verifica.
Quando vogliamo confrontare due soluzioni circoscritte, possiamo ricorrere a un test A/B: mostrare due versioni a gruppi diversi di utenti e osservare come vengono utilizzate. Lo considererei soprattutto quando ci sono abbastanza utilizzi da rendere il confronto significativo e abbiamo chiaro che cosa vogliamo verificare.
Se invece il prodotto è giovane, gli utenti sono pochi o il problema riguarda l’organizzazione complessiva, darei più peso alla chiarezza del percorso: evitare duplicazioni, distinguere le attività principali da quelle secondarie e mostrare le opzioni quando diventano necessarie.
Anche questo approccio richiede attenzione. Noi possiamo essere soddisfatti di una schermata essenziale, mentre chi lavora con lo strumento deve aprire quattro menu per raggiungere ciò che prima trovava subito.
La semplicità va verificata nel lavoro che una persona riesce a svolgere.
Prima di cancellare, considera le alternative
Immagina un servizio online in abbonamento con una funzione avanzata usata dal 5% degli utenti. Mantenerla costa e la sua presenza confonde chi entra per la prima volta.
Quel numero mi porterebbe ad approfondire. Chi compone quel 5%? Quale attività svolge? Quanto dipende da quella funzione? E la confusione nasce dalla funzione stessa o dal posto che occupa?
Il primo errore sarebbe attribuirle poco valore soltanto perché serve a poche persone. Il secondo sarebbe ridurre la scelta a conservarla oppure cancellarla. Potremmo semplificarla, collocarla nelle impostazioni avanzate o sostituirla con un’alternativa più sostenibile.
Il terzo errore sarebbe introdurre il cambiamento senza accompagnare chi la utilizza. Una funzione può essere entrata nelle procedure di un cliente, coinvolgere dati o sostenere impegni già presi. Anche una decisione ragionevole richiede di considerare queste conseguenze.
Come gestire il cambiamento
Procederei attraverso sei passaggi, mantenendo chiaro il problema che vogliamo risolvere.
1. Analizzare la situazione. Individua chi utilizza la funzione, per quale attività e con quali difficoltà. Considera costi, alternative e conseguenze della rimozione, confrontandoti con le persone coinvolte.
2. Comunicare la proposta. Spiega che cosa vorresti cambiare, perché e con quali tempi. Se la decisione è ancora aperta, dichiaralo e raccogli le esigenze prima di chiuderla.
3. Introdurre la modifica gradualmente. Quando possibile, comincia con un intervento limitato. Per esempio, rendi la funzione meno presente nel percorso iniziale, preservando dati e accesso per chi ne ha bisogno.
4. Preparare il ripristino. Il termine tecnico è rollback: significa poter tornare alla situazione precedente se emergono problemi. Prima del rilascio, chiarisci come farlo, chi può deciderlo e in quali circostanze. Considera anche i dati, oltre alle schermate.
5. Verificare gli effetti. Stabilisci prima che cosa osserverai: attività completate, difficoltà dei nuovi utenti, richieste di assistenza e conseguenze per chi usava la funzione. Confronta questi elementi con la situazione precedente.
6. Offrire supporto. Prepara indicazioni comprensibili e un contatto per chi incontra ostacoli. Dopo il cambiamento, verifica che l’alternativa permetta alle persone di continuare a lavorare.
Semplificare richiede disponibilità ad ascoltare e a correggere le proprie scelte. Possiamo esserci affezionati a una funzione perché l’abbiamo immaginata, sviluppata e migliorata. Possiamo anche volerla togliere perché ormai ci sembra ingombrante. In entrambi i casi, tornare al problema dell’utente ci aiuta a decidere con più elementi.
La domanda che terrei presente è questa: dopo il cambiamento, le persone riusciranno a svolgere il loro lavoro con maggiore chiarezza? Da lì partirei per scegliere che cosa mantenere, che cosa spostare e che cosa lasciare andare.