Use(r)
Quando penso all’archetipo dell’utente nella mia testa compare Homer J. Simpson con la sua plancia di controllo alla centrale nucleare. Mi chiedo chi abbia realizzato quei comandi, perché siano stati disposti in quel determinato modo e soprattutto se qualcuno abbia pensato a chi avrebbe poi dovuto usarli.
Nel momento in cui ci avviciniamo pericolosamente alla detonazione atomica e a un disastro nucleare, pronti a vivere in pieno fallout post-apocalittico, ridiamo tutti di Homer mentre interagisce con il proprio strumento di lavoro? (O urliamo “stupido picchio!”?)
UI
Cos’è una interazione?
Un’interazione è, secondo la Treccani, “una azione, reazione, influenza reciproca di cause, fenomeni, forze, elementi, sostanze, agenti naturali, fisici, chimici, e, per estens., psicologici e sociali.”
Secondo Wikipedia invece, relativamente in ambito informatico, “tende a facilitare l’interazione uomo-macchina tramite un’interfaccia ergonomica.”
Quindi, da bravi designer, realizziamo questa interfaccia ergonomica che mostra informazioni, scatena delle azioni e il nostro utente potrà lavorare senza doversi preoccupare di nulla.
Potremmo quindi dire che basterebbe mostrare questo
per permettere al nostro utente di svolgere l’azione per la quale questo elemento esiste.
Dopotutto si tratta chiaramente di un bottone, giusto?
Un bottone (o pulsante), sempre secondo la Treccani è un
elemento grafico visualizzato sullo schermo del monitor che, azionato con il mouse o con altri dispositivi d’individuazione (per es. una penna ottica), svolge le funzioni di uno o più tasti della tastiera.
Ah non lo so, potrebbe anche essere un input forse?
Un input invece, dice Wikipedia è
un termine inglese con significato di “immettere” che in campo informatico definisce una sequenza di dati o informazioni, immessi per mezzo di una “periferica detta appunto di input” e successivamente elaborati.
Ok. Quindi si tratta di un bottone – clicco e succede qualcosa – o di un input – clicco, inserisco qualcosa? Sono un po’ confuso. Non dovevamo facilitare le cose per il nostro utente?
Fermi tutti, non è ne l’uno ne l’altro, la so: è un touchpoint.
Proviamo a astrarre e pensare più al marketing e forse si tratta proprio di
un punto di contatto che ci permette di comunicare con i brand e soddisfare i nostri bisogni di consumatori
Lo dice Maria Cristina Lavazza, Wikipedia aggiungerebbe che, in questo caso specifico si potrebbe trattare di un “Company-created touchpoint”.
Scusate ma a questo punto non potrebbe semplicemente essere un rettangolo con del testo? Secondo il dizionario del Corriere un rettangolo è
geom. Quadrilatero con quattro angoli retti.
A questo punto direi che basta mettersi d’accordo – noi che sviluppiamo, il cliente che ci ha commissionato il lavoro, gli utenti che useranno il prodotto – su quello che stiamo osservando e il gioco è fatto.
Perfetto. Fine dell’articolo. Grazie.
Quanto sarebbe bello, eh? E invece ho scritto questo articolo, quindi… 😀
Perché questo articolo?
Elucubrazioni mentali a parte e voglia di sfogare logorrea cronica, si tratta di fare il punto su esperienze lavorative passate e presenti, parlare di comunicazione e di rapporti tra persone e esporre cosa mi ha aiutato a mettere in fila problemi e portare a compimento/chiusura/conclusione nel miglior modo possibile un lavoro (o parte di esso).
Ci sono quattro punti che, in modo più o meno marcato, ritornano ciclicamente:
Quando una buona idea diventa un’idea non sfruttata
Feature date per scontate e sviluppate senza analisi che usano parte dell’effort di un progetto senza portare valore, come ad esempio il caricamento e la modifica dell’avatar dell’utente all’interno di una app aziendale senza che nessun dipendente l’abbia mai usata.
Quando il progetto parte ma nel tempo cambia la percezione del progetto (o le specifiche)
Senza la giusta quantità di check durante lo sviluppo di un progetto, il cliente potrebbe aspettarsi qualcosa di diverso da quello che è stato sviluppato e avere delle perdite di tempo, analisi e sviluppo per rientrare nelle nuove direttive.
Quando il progetto cala dall’alto
Quando le figure di riferimento si pongono su un livello diverso rispetto al fornitore e è difficile portare le proprie skill come referenze e motivazioni di scelte tecniche o progettuali.
Quando l’interlocutore si riferisce ad un volere divino da compiere
Il caso in cui tutte le persone che lavorano sul progetto non hanno potere decisionale e si attende una decisione dall’alto che non ha avuto modo o non desidera essere coinvolta.
Le casistiche esposte o, nel peggiore dei casi, la combinazione di esse possono portare a prodotti disfunzionali.
A prodotti disfunzionali corrispondono organizzazioni disfunzionali
– J. Kolko
Quando creiamo qualcosa che non funziona nel modo desiderato, ne risentono tutti.
Noi che sviluppiamo, il cliente che ci ha commissionato il lavoro, gli utenti che useranno il prodotto. Estendendo la citazione direi che le organizzazioni disfunzionali sono almeno due: l’azienda che ha realizzato l’opera e l’azienda che l’ha commissionata.
Nessuno è contento, il prodotto non parte, l’utente non sa cosa sta utilizzando o come dovrebbe utilizzarlo, si perdono tempo e soldi.
Per evitare di arrivare a un prodotto disfunzionale possiamo quindi seguire alcuni suggerimenti:
Il cliente non è l’utente
Prima di tutto mettere in chiaro con se stessi e con il cliente (o lo/gli stakeholder, usate pure il termine che preferite in base al contesto) che l’utente finale non è necessariamente rappresentato da chi vi commissiona il lavoro. Il “ma io lo vorrei così” è comunque lecito e propositivo e può portare a spunti interessanti e mostrare punti di vista non presi in considerazione.
Collaborazione radicale
Le persone sono un valore e l’approccio dovrebbe essere basato sul consenso, la conflittualità e il malcontento impediscono di abbattere gli ostacoli e di vedere vantaggio nella diversità delle opinioni, delle esperienze o delle skill degli altri attori in gioco.
Coinvolgere il cliente
Chi coinvolgere e quando coinvolgere il cliente sono domande subordinate a quali sono gli effettivi obiettivi della collaborazione e è fondamentale capire quanto l’azienda con la quale ci stiamo interfacciando sia disposta alla contaminazione con la nostra realtà. Coinvolgere il cliente nei processi di design e sviluppo porta a una consapevolezza maggiore e a uno scambio reciproco di responsabilità.
Un nuovo tipo di designer
Focus, imparzialità, ottimismo ma soprattutto fiducia (reciproca): siamo dei professionisti e amiamo il nostro lavoro, a volte è difficile avere una visione puramente oggettiva mentre mettiamo tutte le nostre forze e energie nello sviluppo di qualcosa. Ottimo quindi concentrarsi su ciò che stiamo realizzando ma è importante essere imparziali se il nostro lavoro viene messo in discussione, diamo fiducia all’interlocutore per iniziare una conversazione e averne in cambio.
Definire informazioni
Strategie top-down e bottom-up: da un lato prendiamo tutti i contenuti esistenti e li organizziamo, dall’altra coinvolgiamo il cliente nella stesura. Dalla sovrapposizione dei due documenti avremo dei cluster sui quali cominciare a fare analisi.
UX: gli strumenti
A questo punto oltre ai suggerimenti servono anche degli strumenti: a seconda della necessità ho scelto uno o più combinazioni degli strumenti a seguire, non è un elenco esaustivo e si riferisce nel dettaglio solo a una parte della mia esperienza personale in rapporto ai clienti con i quali lavoro. Se volete immergervi nella vastità degli strumenti da utilizzare sdt sarà il vostro migliore amico. <3
Empathy map
Comportamenti e attitudini: permette di produrre una panoramica di chi è l’utente, di identificare eventuali incongruenze su come l’utente sia percepito da parte dei vari membri del team.
Chi: Utente e cliente
Perché: L’utente diventa definito e condiviso.
User stories
Descrivere i requisiti di un servizio dalla prospettiva dell’utente: descrivono in dettaglio tutti gli elementi e le interazioni che consentono l’esperienza utente prevista, collegano il lavoro dei vari team, consentendo un flusso di lavoro più integrato e parallelo.
Chi: Utente
Perché: Connette design e sviluppo verso un workflow integrato.
Journey map
Descrive come l’utente interagisce con il servizio attraverso i touchpoint: è una rappresentazione sintetica che descrive passo passo come un utente interagisce con un servizio. Il processo è mappato dal punto di vista dell’utente, descrivendo cosa accade in ogni fase dell’interazione, quali punti di contatto sono coinvolti, quali ostacoli e barriere possono incontrare. A volte si aggiungono rappresentazioni del livello di emozioni positive / negative vissute durante l’interazione.
Chi: Utente
Perché: Descrive l’intera esperienza dell’utente, rappresentando il processo, nonché i pain point e i flussi emotivi.
Service blueprint
Mappa l’intero processo di sviluppo, sopra e sotto la linea di visibilità a tutti i livelli: è un diagramma che mostra l’intero processo di erogazione del servizio, elencando tutte le attività che avvengono in ciascuna fase, eseguite dai diversi ruoli coinvolti.
Vengono elencati prima tutti gli attori coinvolti nel processo di servizio su un asse verticale e tutti i passaggi necessari per fornire il servizio sull’asse orizzontale. La matrice risultante permette di rappresentare il flusso di azioni che ogni ruolo deve compiere lungo il processo, evidenziando le azioni che l’utente può vedere (sopra la linea di visibilità) e quelle che avvengono dietro le quinte (sotto la linea di visibilità).
Chi: Cliente
Perché: Unisce le relazioni interfunzionali e allinea i processi front-stage e back-stage.
Service roadmap
Pianifica l’esecuzione del servizio nel tempo, da MVP a esperienza completa: si tratta di un output dei processi di pianificazione e descrive visivamente una sequenza temporale di alto livello per il processo di sviluppo, consegna ed evoluzione di un prodotto.
L’obiettivo è identificare il set minimo di funzionalità necessarie per essere pronti per la prima versione e quindi aggiungere i miglioramenti successivi che potrebbero essere apportati. La roadmap prende in considerazione lo sforzo necessario per sviluppare e costruire componenti di servizi specifici, così come il tempo richiesto per eventuali fasi (come quelle di test). Una volta che il primo MVP è pronto si può cominciare il roll-out.
In generale, la service roadmap deve rispondere a tre domande essenziali: a che punto siamo ora? Dove vogliamo andare? Come possiamo arrivarci?
Chi: Cliente
Perché: Identifica il set minimo di funzionalità necessarie, l’effort per sviluppare il nostro servizio, i test, definire tutti gli obiettivi, le scadenze, le feature future.
Service specifications
Documentazione completa: linee guida scritte che chiariscono tutti i requisiti e gli obiettivi di ogni fase specifica dell’esperienza utente descritta in dettaglio, inclusi design, sketch o qualsiasi altro materiale pertinente che possa aiutare a comprendere le indicazioni specifiche. In questo modo possono essere utilizzate per coinvolgere altre figure in fasi successive e per coordinare nuovi sviluppi (fornendo indicazioni su come vengono utilizzati, ad esempio, diversi componenti).
Chi: Cliente
Perché: Descrive dettagliatamente ogni punto di contatto, ogni funzionalità e interazione per supportare la progettazione e l’implementazione.
Prototipazione grezza
Mock-up veloci realizzati con strumenti semplici e pochi dettagli, sketching: serve a simulare comportamenti specifici con l’obiettivo di spiegare meglio un comportamento o una funzionalità e iniziare a discutere i requisiti specifici di ogni touchpoint. I prototipi grezzi possono essere semplicemente costruiti con la carta, per avere una maggiore presa su tutte le persone coinvolte. Sono uno strumento potente durante le sessioni di co-design, per consentire a tutti di tradurre visivamente concetti specifici in forme e interfacce tangibili e chiare.
Chi: Cliente
Perché: Co-design / feedback immediato e tangibile / Concept walkthrough
In conclusione
Cercando di applicare gli strumenti ai diversi contesti, i concetti che porto sempre come esempio sono i seguenti:
Dare forma, tutto è semplice ma tutto è complicato – se cominciamo a mostrarlo possiamo interpretarlo e portarlo nella direzione desiderata.
Iterazione come risultato, fallisci prima per riuscire presto – con un processo iterativo e continuo si ha un maggior controllo e una maggior flessibilità sul progetto e una miglior gestione dello stress.
Il conflitto come forza, se il processo è condiviso c’è le possibilità che si creino confronti, talvolta anche accesi, tra gli attori in gioco: affrontarli per capire se possono dare valore al prodotto è meglio che ignorarli o barricarsi.
Documentazione come strumento, se tutto è documentato abbiamo una certificazione comune di ciò che stiamo realizzando.
Comunicazione come condivisione, due chiacchiere e un “ciao come va?” non hanno mai fatto male a nessuno. Stiamo lavorando, è vero ma…
Us & them and after all we’re just ordinary men” come diceva mio zio Roger (o forse era David?)
Riferimenti
- Radical Collaboration – Maria Cristina Lavazza
I libri della UXU UXUniversity - Intranet Information Architecture Giacomo Mason
I libri della UXU UXUniversity - Service Design Tools
www.servicedesigntools.org - Design Thinking Comes of Age – Jon Kolko
https://hbr.org/2015/09/design-thinking-comes-of-age
