A2A PULIamo

A2A PULIamo iOS Android

Con questa storia raccontiamo il primo approccio di CommonSense a quello che è generalmente conosciuto come Service Design, la sintesi di ciò che ci piace di più: mettere in luce lo scopo, la funzione di un’applicazione con l’ausilio non invasivo della tecnologia.

A2A è la più grande azienda multi-utility in Italia, capofila nei settori energia e ambiente. La sua Divisione per i Servizi Ambientali aveva già messo a disposizione dei propri utenti una applicazione mobile già operativa e funzionante ma i suoi responsabili hanno pensato alla necessità di un cambiamento, riguardante in special modo le prestazioni.

Verso la fine di Aprile del 2015 si sono rivolti a noi con una serie di punti di attenzione riguardanti ad esempio la velocità di risposta alle richieste degli utenti o i tempi di ricezione e aggiornamento dei dati inseriti da back end. Come spesso accade a seguito dei nostri dialoghi con i clienti, abbiamo scoperto che le necessità che A2A credeva di avere erano espressione di qualcosa di più profondo: era arrivato il momento per quello che definiamo Problem Setting.

Problem Setting vs. Problem Solving

Per un’azienda come la nostra, centrata su quella che comunemente viene definita User Experience (UX), la soluzione di un problema non esaurisce il compito di un designer ma costituisce la fase finale di un attento processo di analisi e identificazione dei bisogni. La UX non (solo) risolve problemi ma li mette in evidenza: questo è particolarmente vero nel caso dello sviluppo mobile coniugato con il service design,  contesto in cui non si dà solo evidenza di un servizio ma se ne tracciano le funzioni operative.

Il contesto di business in cui si inquadra l’app PULIamo è molto complesso: la Divisione per i Servizi Ambientali è in realtà un gruppo di aziende che operano in diverse realtà locali secondo regole differenti da città a città. La struttura dati fornita dai servizi web era la stessa utilizzata dal sito web e non era fedele alla natura dei servizi offerti. L’applicazione esistente rispecchiava questo stato di cose: non veniva esplicitata alcuna gerarchia informativa e i servizi offerti erano strettamente legati alla città inserita dall’utente al primo accesso.

old_home

 

La versione precedente di PULIamo mostrava tutte le funzionalità principali in una griglia piatta senza fornire nessun tipo di architettura delle informazioni. Questo sicuramente semplificava, specie nella fase di sviluppo, l’approccio all’intricato contesto descritto sopra e garantiva un maggior controllo rispetto ai diversi servizi offerti dalle varie aziende a livello locale. Dall’altra parte però, relegava l’utente al ruolo di mero operatore invece di riconoscerlo come il beneficiario e allo stesso tempo il promotore di un servizio, in uno specifico momento e in uno specifico luogo.

Se consideriamo quanto definito da Gianluca Diegoli nel suo “Intimate Computing – Modello ed esempi di una strategia vincente per il mobile marketing” relativamente agli obiettivi che un’applicazione dovrebbe porsi per essere considerata di valore per l’utente, l’applicazione PULIamo nella sua versione precedente non colpiva quella che definiamo come zona di relazione: i bisogni che andava a soddisfare erano in larga parte tecnologici e istituzionali mentre lasciava un po’ in disparte l’utente finale.

Il nostro obiettivo dunque era, sempre per citare Diegoli, “quell’utilizzo continuativo o ripetuto e intensamente partecipato” che “provoca una relazione forte, volontaria e percepita come arricchente”, sempre nel rispetto dell’identità, tecnologica e istituzionale, coltivata negli anni dal nostro cliente.
L’analisi dell’esistente non ha però solo riguardato il contesto di utilizzo dell’applicazione e il risultato finale messo a disposizione degli utenti. Abbiamo infatti anche considerato tutto l’ambiente in cui era nata PULIamo e in cui si sarebbe evoluta con la nostra proposta. Per fare questo abbiamo dovuto dare il via a quella che per noi è la fase essenziale di ogni lavoro: la Ricerca.

Ricerca

La Ricerca per Commonsense è prima di tutto una fase di contrattazione: in questo momento definiamo con il cliente i ruoli che ogni partecipante al progetto dovrà rivestire. Chiedendo massima libertà nella gestione di questa fase chiediamo un investimento da parte del cliente in quello che non è un passaggio strettamente operativo o comunque a ritorno immediato: ci guadagniamo la sua fiducia producendo tutti i documenti necessari a fargliene comprendere la crucialità, ingaggiando in questo modo un dialogo.

circles

 

Le vere e proprie operazioni di ricerca sono partite dalla considerazione di quali sarebbero stati i destinatari principali della nuova versione dell’app. La realizzazione di una serie di interviste a utilizzatori dell’app – reali e potenziali – ci ha permesso di creare diverse personas di riferimento con i relativi scenari di utilizzo. Abbiamo inoltre considerato gli utenti interni, coloro che giornalmente hanno a che fare con il back-end per la produzione dei dati: grazie a questo approccio siamo stati in grado di creare un contesto di ascolto continuo che ci ha permesso in diversi casi di anticipare problematiche associate alla qualità dei dati. Imparare a parlare la stessa lingua del cliente ci ha permesso di farlo diventare collettore di feedback e trasformare l’applicazione in un dialogo con chi la usa.

Un confronto assolutamente necessario è stato quello con una terza parte, quella che si occupava dello sviluppo dei servizi web, gli stessi utilizzati dal sito istituzionale. Questo incontro è stato fondamentale per capire quanto in là il nostro sforzo di distanziarci dalle logiche per il web avrebbe potuto spingersi: in questo modo abbiamo potuto ottenere – non in tutti i casi ma in molti – delle modifiche alle strutture dati restituite che dessero all’applicazione un carattere più operativo che informativo.

Dall’analisi degli scenari di utilizzo abbiamo estratto i bisogni a cui la nostra applicazione doveva rispondere e per ogni categoria di bisogno abbiamo ricavato un’area funzionale. Abbiamo in questo modo individuato le funzionalità realmente necessarie, aggregando attività simili, eliminando quelle superflue e creandone di nuove. L’articolazione di queste attività si è servita dell’utilizzo della componente temporale oltre che di quella geografica, già considerata dalla versione precedente. Solo in questo modo infatti viene sfruttata la caratteristica fondamentale dei dispositivi mobile: la loro presenza quasi costante (ubiquità, pervasività, intimità) nelle nostre attività quotidiane. Ci siamo allontanati in questo modo da uno stile progettuale troppo prossimo alla progettazione per il web, dando alle informazioni una connotazione dinamica.

Funzionalità

 

Accesso e gestione degli indirizzi

Funzione: determinare il “qui” della persona

Come nella versione precedente dell’applicazione, il primo accesso consiste nella definizione di un indirizzo attorno al quale si possa costruire l’esperienza dell’utente. A differenza di quanto accadeva prima però non c’è un rapporto 1:1 tra l’indirizzo indicato e l’istanza di utilizzo. Più indirizzi possono essere indicati e selezionati senza dover uscire dal contesto dell’app.

trio

 

Oggi

Funzione: dati il qui/ora, definire le attività possibili per la persona

Da un punto di vista informativo questa sezione dà una sintesi dei servizi disponibili per un dato giorno e per un certo indirizzo. In particolare è possibile:

  • conoscere i tipi di raccolta porta a porta e i relativi orari;
  • conoscere gli orari dell’eventuale lavaggio strade con e senza divieto di sosta;
  • conoscere quali sono i punti di conferimento mobili vicini e i relativi orari.

Ma per promuovere quell’utilizzo continuativo e partecipato di cui abbiamo parlato in precedenza, abbiamo ritenuto fondamentale fornire due strumenti fondamentali di interazione:

  • la possibilità di definire un raggio di interesse per il servizio di lavaggio strade; 
  • impostare un promemoria relativo a tutti i servizi elencati in precedenza.

Oggi non è altro che la cima del calendario completo, accessibile direttamente da questa sezione. Il calendario, rappresentato in precedenza come una griglia perlopiù vuota con un apporto informativo minimo, riporta oggi unicamente i giorni rilevanti. La selezione di un giorno in calendario porta a una visualizzazione del tutto analoga a quella vista per la schermata Oggi.

Vincoli tecnologici

Questo ambito dell’applicazione, totalmente nuovo rispetto a quanto presente nella versione precedente, rappresenta per noi il maggiore punto di distacco dalle logiche web. Nella sua concezione iniziale il fattore tempo giocava un ruolo molto importante: gli orari determinavano l’evidenza immediata della disponibilità di un servizio (centri di conferimento aperti in un certo momento, raccolta porta a porta in corso o prossima) e davano la possibilità di gestire i promemoria in maniera automatica.

Il modo in cui gli orari sono rappresentati nella struttura dati che riceviamo in risposta dai servizi web – una stringa senza una formattazione univoca – non ci fornisce un dato abbastanza affidabile da ottenere il risultato immaginato. Una modifica dei servizi in questo senso avrebbe allungato sensibilmente i tempi di lavorazione. Abbiamo quindi trovato una soluzione alternativa con il proposito di raggiungere quanto progettato in una prossima release dell’applicazione.

Dove lo butto

Funzione: guidare la persona nello stabilire in che modo differenziare i rifiuti

Questa sezione aiuta l’utente a essere parte attiva di quello che è lo scopo fondamentale del servizio offerto da A2A: incrementare la percentuale di rifiuti differenziati correttamente. Con questo obiettivo abbiamo riunito in un’unica sezione quelle che nella versione precedente erano due attività separate: il vademecum e la mappa con i punti di conferimento più prossimi all’indirizzo correntemente selezionato.

Segnalazioni e Biciclami

Funzione: fornire un punto di comunicazione tra la persona e la società fornitrice dei servizi

Anche la sezione Segnalazioni è nata inizialmente dall’aggregazione tra attività che nella versione precedente dell’app erano riportate separatamente:

  • Segnalazioni
  • Biciclami
  • Segnalazione di un oggetto non presente nel vademecum

In particolare la nostra intenzione era quella di raggruppare le funzionalità Biciclami (attiva solo per la città di Milano) e le segnalazioni generiche, vista la struttura simile della schermata di invio. Ma il legame tra Biciclami e la città di Milano non è per nulla superficiale: è infatti un’iniziativa non interamente di A2A ma promossa e portata avanti dal Comune di Milano per la rimozione di biciclette abbandonate nel territorio comunale. Si tratta a tutti gli effetti di un servizio con uno sviluppo operativo che va oltre gli scopi dell’applicazione Puliamo, da cui affiora solo un capo. È stato necessario per questo motivo dargli una rilevanza maggiore rispetto alle semplici segnalazioni.

Un altro discorso è quello relativo alla segnalazione di un oggetto non presente nella lista del vademecum in Dove lo butto. Questa possibilità era inclusa nel form di ricerca del Vademecum, posizione più che naturale per una funzionalità del genere. Ma una posizione a così alta rilevanza e senza nessun filtro a monte ha avuto un effetto indesiderato: un numero estremamente alto di segnalazioni di questo tipo, impossibile da razionalizzare in tempi utili per un utilizzo futuro effettivo.  La scelta di ridurre questa funzionalità a un’opzione fra le varie segnalazioni ha ridotto l’immediatezza dell’interazione, suggerendo all’utente che si tratta di un’operazione da eseguire quando effettivamente necessaria, e l’ha vincolata all’indicazione da parte dell’utente della sua posizione e delle sue generalità. In questo modo abbiamo ridotto il numero di segnalazioni da gestire lato back-end ma un punto che resta aperto riguarda la qualità del dato: una futura revisione dell’applicazione affronterà la questione delle segnalazioni ridondanti e l’introduzione delle voci valide nel vademecum.

Ritiro ingombranti

Funzione: richiedere il ritiro a domicilio di rifiuti ingombranti

Questa sezione è un punto di accesso verso un servizio fornito in realtà dal sito web. Questo servizio, come Biciclami, non è disponibile per tutti i comuni. Per questo motivo scompare dalla navigazione quando il comune selezionato non è fra quelli serviti.

Notifiche

Funzione: elencare i messaggi importanti inviati tramite push notification

Questa sezione è un ulteriore esempio della distanza che abbiamo voluto guadagnare rispetto a una progettazione orientata al web. La sezione Notifiche è un sostituto infatti del banner News presente nella versione precedente, che riportava tutte le notizie relative ai servizi A2A indipendentemente dal contesto di utilizzo. Tramite una piattaforma dedicata sarà possibile per A2A inviare le sole informazioni relative ai Servizi Ambientali eventualmente filtrate per le città indicate dall’utente fra quelle rilevanti.

Impostazioni

Funzione: fornire un punto di accesso e modifica alle personalizzazioni applicate all’app

La sezione Impostazioni è una sezione di servizio che consente all’utente di gestire le personalizzazioni apportate durante l’utilizzo. In particolare da qui è possibile gestire gli indirizzi, le vie limitrofe e i promemoria impostati. Questa sezione garantisce all’utente un totale controllo sui dati inseriti e sulle funzioni abilitate.

Contenuti multilingua

La sezione Contenuti multilingua compare nel menu di navigazione solo per alcuni comuni. La sua posizione separata dalle altre sezioni riflette la sua trasversalità: i contenuti interni a questa web view riguardano tutti gli aspetti trattati dall’app. Anche in questo caso abbiamo ridotto le difficoltà di accesso a questa sezione che invece erano presenti nella versione precedente di PULIamo: per accedere ai contenuti in lingue diverse da quella selezionata al primo accesso era necessario uscire dal contesto dell’applicazione e rientrare in un’app dall’aspetto completamente diverso.

Conclusioni

Il nostro intervento sull’applicazione PuliAmo ha avuto l’obiettivo di guadagnare quello spazio dei bisogni definito come Zona di Relazione.
Per fare questo abbiamo messo in pratica i principi fondamentali dello UX Design unendovi quello slancio creativo che ci ha consentito di andare oltre al livello informativo per conquistare quella fase operativa considerata arricchente da chi utilizza l’app.

C’è ancora molto da fare per rendere l’applicazione una compagna fedele per chi vuole contribuire correttamente alle operazioni di raccolta differenziata. La chiave dei nostri prossimi interventi sarà costituita da una maggiore adesione dei servizi web al servizio offerto da A2A: questo renderebbe l’app più utile in un dato presente dell’utente, consentendo di sfruttare meglio la pervasività del dispositivo mobile.

Che cosa abbiamo imparato lavorando a questo progetto

Raffaela Canu

UX Designer

Dal punto di vista della progettazione questo lavoro ha rappresentato una sfida: sarò capace di restare in ascolto? Perché questo è ciò che viene richiesto da un settore come quello in cui si muove l’app di A2A, un contesto caratterizzato da un forte scambio tra chi fornisce un servizio e chi ne usufruisce. Perché il rapporto funzioni è necessario agevolare il più possibile le buone pratiche che il destinatario dovrà acquisire per rendere lo scambio proficuo. Per fare questo è stato necessario – e ancora lo è anche a progetto concluso – capire come il sistema informativo sottostante possa essere rimodellato in modo da rappresentare fedelmente l’esperienza finale della persona.