In particolare, il capitolo sull’usabilità sembra uscito dal mio blog, nel senso che (specialmente da cittadino) sono perfettamente concorde e felice di ciò.
Lo copioincollo tutto, a futura memoria:
4.4.2. Indirizzi sul design e usabilità
Rivolgendosi a una platea eterogenea ed estremamente differenziata (giovani, anziani, cittadini con diverso grado di scolarizzazione, disabili, utenti con scarsa dimestichezza nell’utilizzo degli strumenti informatici, ecc.), i siti web della pubblica amministrazione devono contenere informazioni e servizi facilmente utilizzabili da tutti.
Un sito pubblico deve quindi essere progettato considerando le esigenze di tutti gli utenti, qualsiasi sia la loro competenza informatica o abilità
fisica.
Un aspetto estremamente importante per tutti i siti della Pubblica Amministrazione risulta quindi l’usabilità dei propri servizi on line. L’usabilità non è una caratteristica intrinseca del sito, ma riguarda invece l’ambito dell’interazione tra l’uomo e il sito con il quale si trova a interagire.
L’usabilità deve essere dunque definita e creata nel corso della progettazione, verificata insieme agli utenti in un processo iterativo di controllo e correzione e, quindi, valutata alla fine del processo.
Sul tema dell’usabilità non esiste una normativa specifica a supporto, anche se il CAD stabilisce i principi generali per la progettazione dei siti web, ricordando che è obbligo delle pubbliche amministrazioni realizzare siti istituzionali che rispettino i principi di elevata usabilità e reperibilità, chiarezza di linguaggio e semplicità di consultazione.
L’obiettivo deve essere il miglioramento della qualità del sito e l’aumento della soddisfazione dei cittadini, a cui può fare seguito una riduzione dei costi di assistenza agli utenti e un perfezionamento dell’immagine complessiva dell’ente e della pubblica amministrazione in generale.
Per migliorare l’usabilità dei propri siti web, le pubbliche amministrazioni devono:
rispettare i principi di usabilità definiti dalla letteratura internazionale
effettuare test periodici con i propri utenti
attivare forme di ascolto dei cittadini per raccogliere eventuali segnalazioni sulle difficoltà incontrate nell’utilizzo dei servizi erogati on line
dare pubblicità circa test effettuati con gli utenti, in modo permettere la diffusione delle migliori pratiche.
Tra i benefit, in grassetto ho sottolineato e ribadisco:
riduzione dei costi di assistenza agli utenti (beneficio diretto)
perfezionamento dell’immagine complessiva dell’ente e della PA in generale (i cosiddetti benefici sul brand).
Aggiungerei il miglioramento dei processi e delle persone che lavorano nella PA, ma accontentiamoci.
Dal punto di vista di processo sono anche lieto che si sia differenziato chiaramente non solo il lavoro di analisi (vecchio eufemismo per dire che si fanno un sacco di riunioni senza decidere niente), ma anche la parte di progettazione distinta dalla parte di sviluppo.
Altri punti degni di nota:
utilizzo di formati aperti
utilizzo di licenze aperte per i contenuti (creative commons o simili)
partecipazione e web 2.0.
Adesso speriamo che alle parole seguano i fatti e che l’execution funzioni, dai siti importanti, fino a quelli delle PA locali.
Rilancio volentieri l’iniziativa di Gianandrea Giacoma e Davide “Folletto” Casali (entrambi amici e frequentatori del mio blog), di realizzare una checklist per valutare l’usabilità sociale di un social network.
L’usabilità sociale, in base alla definizione di Gianandrea, “è un attributo qualitativo che definisce quanto facile è realizzare interazioni social all’interno di una specifica interfaccia uomo-macchina-uomo“.
Puoi scaricare la checklist (pdf) e utilizzarla a piacimento per verificare l’usabilità sociale della tua piattaforma social.
La prima idea è che non sono sicuro esista qualcosa che possiamo definire usabilità sociale come “attributo intrinseco” di un’applicazione web (in realtà Gianandrea la definisce “attributo qualitativo”, per cui non so se abbia un’idea simile alla mia, non ci siamo mai confrontati veramente).
La seconda idea nasce da una duplice osservazione: non è detto che un’applicazione sociale debba avere tutti gli attributi definiti nella checklist, ma soprattutto all’inizio bisogna scegliere bene quali avere e quali non avere.
Il design di un’applicazione prevede che si facciano delle scelte sulle funzionalità che potranno avere gli utenti. La strategia di design -lo dico da tempo- per me è prima di tutto scegliere cosa non fare.
Quindi, ad esempio, un social network ha tutto il diritto di non avere messaggi diretti tra gli utenti, ma solo i messaggi pubblici, se la sua natura non prevede quel tipo di interazione.
L’ultima idea è che ho sempre avuto difficoltà a lavorare con le checklist. Ci ho provato molte volte, anche perché di checklist sull’usabilità ce ne sono un sacco, ma preferisco di gran lunga una valutazione basata sul cognitive walkthrough.
Detto questo, stampo e incollo al muro la checklist, perché a ben guardare credo sia utile per il nostro lavoro. Se non altro a offrire spunti e idee, oltre a dare chiarezza nel progettare un’applicazione social.
Livia si concentra nell’ordine in cui investigare gli utenti e le statistiche:
It’s inneficient to start digging deeper to answer the WHY questions if you don’t have a baseline of WHATs identified.
È l’approccio che si usa comunemente, aggiungerei solo che andrebbe fatto ciclicamente: analizzare un po’ le stastistiche e poi investigare gli utenti, poi tornare a guardare le statistiche e fare altre ricerche con gli utenti. E così via.
Certo, tra i commenti al post, appare trafelato “un certo” Jared Spool che inchioda tutti con un’affermazione:
I’m not sure that you can separate the WHATs and the WHYs. I think good methodology is both.
Il punto di Jared è che il COSA (per esempio cosa misurare) spesso dipende molto dal PERCHÈ, quindi vanno semplicemente analizzati assieme.
Da questo si deduce che:
durante la fase di ricerca sugli utenti bisogna fare anche analisi delle statistiche (e fin qui c’eravamo)
dentro i team di design c’è sempre più bisogno di esperti di web analytics (!).
È un tema a me caro e ne ho parlato diverse volte qui sul blog:
Excrement. That’s what I think of Mr. J. Evans Pritchard.
We’re not laying pipe, we’re talking about poetry. -John Keating, Dead poet society
Da tempo chi si occupa di user experience ha iniziato a confrontarsi con la necessità di avere informazioni quantitative (dati, numeri e percentuali, per intenderci) per poter operare (o giustificare ai committenti) scelte di design.
Per questo di recente si parla molto di misurare la user experience attraverso tool di analytics, sistemi di testing remoto, ecc. Ne ho parlato diverse volte qui nel blog.
Però, anche se il confronto con i dati sulle scelte di design credo sia un passaggio fondamentale nel nostro lavoro, oggi ho avuto un “a-ha moment” come dicono gli anglofoni.
È solo un esempio, ma vediamo se riesco a farvi capire quello che penso.
Da qualche tempo a Doralabimpostiamo i wireframe basandoci su alcuni framework css, per poter facilitare il lavoro di produzione dell’html.
Oggi, ho chiesto agli amici-partner di Ideato quanto tempo abbiamo risparmiato lavorando in questo modo in un progetto che è andato particolarmente bene da questo punto di vista.
La risposta è che non abbiamo mai misurato questo dato confrontandolo con le soluzioni classiche, ma si stima che ci sia un risparmio di almeno il 20-30% nei tempi di produzione dell’html.
Anche se è una stima, è un dato importante.
Ma la vera chicca è una frase di Francesco Trucchia, uno dei fondatori di Ideato:
“la cosa che più conta è la fedeltà che si rispetta passando dal wireframe/psd all’html”.
Ecco, per me questo conta più di quel 20-30% di tempo risparmiato, perché la qualità è più importante della quantità.
Purtroppo, per i clienti, non ha un gran valore rispetto ai benefit quantitativi (e se invece prendessimo la qualità del lavoro come un KPI?), ma per gli utenti?
Non sono forse gli utenti a dovergli unici a poter stabilire il valore della ux? Per loro, probabilmente, la qualità dell’interfaccia finale è più importante di qualsiasi dato quantitativo.
E arrivo ad una generalizzazione, che cercherò di argomentare meglio nel futuro: ci piaccia o meno, la user experience non è misurabile, qualunque cosa facciamo.
La cosa era passata un po’ in sordina, ma il vostro ha continuato a tenere monitorata la discussione, perché non è mica un tema da poco e in parte converge con la mia idea di rendere autonomi i clienti attraverso il lavoro di consulenza che facciamo.
Is giving in to the clients’ desire to receive a list of solid recommendations the best for the clients?
[...]
When we finish our engagement with our clients, they’ve learned how to do the work themselves. They can continue researching and enhancing their designs, using the techniques and tricks we’ve taught them. We’ve done our job and they’re happy continuing on their own.
When Nick and the Catalyst team have delivered their recommendations, their client goes off and makes changes. The question I have, however, is this: are they left in a situation where the only way they can make any further changes and enhancements is to call Nick’s team back?
Unfortunately, many projects aren’t like Chris’s HBO site. They need to evolve as the business, the technology, and the customers mature. They need new features, new enhancements, and new ways of thinking about the problems they’re solving.
Are we leaving our clients with the best possible experience? Are we considering that when we first pitch the project and its deliverables?
Per me il discorso è chiaro e l’ho scritto anche nel mio post. Pensare di “formare” il cliente e renderlo autonomo aumenta la qualità del lavoro e rinforza l’esperienza che rilasciamo al cliente.
C’è anche un altro aspetto: lavorare in questo modo cambia il “deliverable” del lavoro, che non è più solo il “deliverable fisico” (report, wirefreme, prototipo, mockup, etc), ma soprattutto il metodo con cui si raggiunge il risultato.
Inoltre, Jared aggiunge, nel primo articolo:
What our preliminary research has found is a typical recommendation looks something like this: “Users had trouble seeing the field labels. I recommend you put the label on the top of each field, instead of on the left.”
However, some teams are using a different approach: “We’re seeing that our users have trouble with the field labels. We’d like to try an experiment and see if moving the labels to the top of each field makes an improvement.”
It’s a subtle difference. And it was the approach we saw most in use amongst those UX professionals who had a solid track record of consistently improving their designs. These professionals told us they refuse to make recommendations, but love to experiment.
Insomma, lavorare sul design significa soprattutto lavorare sul processo (incrementale, misurabile, etc) e aiutare i clienti ad avere un approccio giusto verso i cambiamenti.
E alla fine la consulenza di design rilascia knowhow prima che deliverable. La differenza tra quelli bravi e la classica “web design agency” è tutta qua.
(certo, chissà cosa ne pensano “dall’altra parte della barricata”…)
Insomma, sono ricominciate le discussioni sull’italia del rugby e come ogni anno mi ritrovo in mezzo a quelli che:
prima della partita: “potremo anche vincere, sempre che…” (aggiungere motivazione tecnica a scelta, o a caso).
dopo la partita: “non abbiamo giocato male, certo abbiamo perso, però se solo…” (aggiungere motivazione tecnica a scelta o a caso)
Ora, anch’io prendo spesso queste posizioni, ma mi sarei anche rotto.
La verità è che l’italia potrebbe vincere domenica al flaminio, se lo volesse veramente.
Sia chiaro, domenica gli albioni ci fanno a pezzi. Però se uno lo volesse davvero…
Ci sono cose impossibili che molti hanno fatto, ma non è successo per caso: si sono impegnati oltre l’immaginabile (vedi contributo audiovisivo qui sotto).
Ecco, in generale, in Italia c’è invece l’idea che le cose succedono per caso, per fortuna o per amicizia (o una combinazione delle 3).
La verità è che se vuoi ottenere qualcosa, ti devi impegnare infinitamente tanto, per anni forse, e non smettere mai di crederci.
Poi, se uno ci pensa, tra trattenere il fiato per 17 minuti e battere l’inghilterra: qual’è la cosa più difficile da fare?
A me battere gli inglesi non sembra così impossibile.
D’altronde un mio professore all’università diceva: “L’impossibile non esiste, necessita solo un po’ più di tempo”.
Quindi per tornare in tema: se io fossi l’allenatore dell’italia farei le solite scelte a caso, ma poi farei vedere questo video a tutti, un’ora prima della partita. E poi gli chiederei: adesso cosa siete disposti a fare per vincere?
Nella newsletter di Adaptive Path (non trovo l’url online) c’è una stupenda intervista con il direttore UX di YouTube, che spiega tra l’altro come hanno usato una tecnica di codesign chiamata FIDO per riprogettare l’interfaccia di YouTube. Interesting.
UPDATE: aggiungo alcuni stralci dell’intervista, per appuntarmeli e perché sono “highly inspirational”.
Sulla semplicità e priorità dei task:
Ours goals were to make the experience simpler, smarter, and cleaner. We removed many things from the default view that weren’t critical to watching videos and finding more videos to watch.
[...]
For viewers, the site is first and foremost about watching videos and finding great videos to watch. So our focus is to make those experiences the best they can be. In order to do that, we knew we needed to “unlaunch” some things to focus attention back onto what matters. We analyzed the usage of each UI element and feature, and were pretty rigorous about removing infrequently used elements from the default view.
Sulla tecnica di codesign utilizzata che guida le scelte di design, assieme ai dati (analitics, clickstreams, heatmaps, etc):
We used a participatory design technique called FIDO (Freehand Interactive Design Online); it’s kind of like refrigerator poetry for design. You provide a magnetic board to the study participant, and you ask him or her to design their ideal video watching interface by choosing just the right elements and functionality from a collection of magnets.
[...]
The most important finding was the distinct difference between what someone who watches videos wants versus the needs of someone who uploads and curates videos. (vedi foto) These findings allowed us to discuss what was critical to the page and what was of secondary importance. We combined the data with other studies like heat maps of clicks on the page as well as session analysis to drive some tough discussions about de-emphasizing and un-launching things. This is hard, because every element is the result of some team’s hard work. But we now had data to make the right decisions.
Sulle metriche e gli effetti del redesign:
There are a few things we are watching closely. Obviously the time spent on site and how often they visit are very important metrics. We are looking to extend sessions by exposing people to a more diverse set of videos to watch. And from our UI clean up work, over time, we’ll see an increase of usage of our sharing and community features, as people take a fresh look at the options and discover things of interest to them.
Lo sottolineo, perché è importante: la semplificazione ha aumentato la scoperta delle nuove opzioni e l’utilizzo da parte degli utenti. Semplificare aiuta a favorire e intensificare le azioni degli utenti.
Sul processo interno e integrazione con i team di sviluppo:
One of the changes we’ve made over the past year is the role of user experience research. It was hard for the team to run traditional lab studies and share the findings quickly enough to impact the work before it shipped. So we shifted our time towards upfront, strategic research to understand our users and better inform the business, and instead of extended lab studies, we focus on lighter, quicker validation techniques. As a result, research is in a much more influential role. UX designers are working more strategically as well, driving aspects of the product vision, while concurrently keeping pace with the short release cycles. It’s challenging to balance the flows, but the team is doing a great job.
[...]
sometimes the product gets developed in silos, rather than holistically. So in UX, we’re moving to organize the projects around similar experiences instead of around our organizational structure. For example, historically the advertising department would focus on ads across the entire site. But we knew that the ways the ads look and behave in relation to the context in which they are placed is very important. So the same designers working on the video watch page and player design are driving the UX for the ads design. The result will be a cleaner, more intuitive, and more effective user experience.
[...]
Working directly and effectively with engineers is critical to the success of any designer at YouTube or Google. We form small interdisciplinary teams that often sit together and are focused on solving specific problems. Our focus on deep collaboration on product strategy up front bonds the teams; when you have shared goals and a shared vision, you tend to be better partners and better listeners. In UX, we are always gathering feedback and changing the ways that we work with other departments.
Sulla leadership e il management:
It’s very difficult to do great work without support from leadership. At YouTube, we have an executive team that cares deeply about the user experience and wants to do the right thing and to always be improving. I and members of my team meet regularly with our executives and share our work on an ongoing basis; their level of engagement is really remarkable. That focus gives me a lot of confidence to speak authoritatively. It gives me the ability to have high expectations of what the team must deliver. And it also gives us the inspiration to craft a longer term vision for where we are headed. This vision must be formed and shared as a team, since each team member will need to go out and share and apply that vision across every part of our organization and the site experience.
Posterous is an engineered product, while Tumblr is a designed product.
La cosa è interessante, anche perché di recente ho citato Posterous nella mia presentazione al Digital User Experience Festival. Secondo me Posterous ha reso efficacemente l’idea che “non serve iscriversi, basta una mail”.
Però significa puntare tutto su una funzionalità, anzichè sulla user experience:
In fact, that sign-up-via-email feature: engineering feature. [...] Very long signups can discourage users, but by God, pulling up their email client, finding a picture or a video to post, attaching it, and emailing it to post@posterous.com (or is it new@posterous.com? posterous@posterous.com?), that’s easier! It’s exactly the kind of thing where an engineer thinks “Oh, nobody does that, I’ll do that, that’ll be cool!” but in real life it’s useless. I mean, posting by email is a nice feature. But it’s not a killer feature.
E ancora:
Meanwhile Posterous is typical of the Silicon Valley engineering mindset where everything is measured, ranked, weighted. It’s like Google. And having terrible design like Google is great if you have a technology edge. But if you’re in a market where what matters is design edge, that’s not enough. There needs to be great design, by which I don’t mean looks (though they’re important), but how it works for the end user. [...] for consumer web apps today, design matters more than technology.
Tra Posterous e Tumblr io ho scelto da tempo immemore Tumblr e l’ho anche definita una delle interfacce più semplici che abbia mai utilizzato. Tempo fa ho provato anche Posterous, ma poi non ho capito bene come funzionava e ho lasciato stare.
Ecco, oggi ho la conferma del perché: design matters more than technology.
ps: con questo post mi inserisco sulla diatriba nata dall’articolo di Norman, che ha dichiarato che nell’innovazione è più importante la tecnologia rispetto ai bisogni dell’utente. Secondo me, Don sto giro ha preso un granchio.
Il conto ve lo faccio io: 11 ricerche in 50 secondi, una ogni 4,5 secondi.
Questa pubblicità mette assieme un’idea di brand experience (ti fa trovare le cose che cerchi e a cui tieni) con la velocità di Google (vantaggio competitivo verso gli altri: siamo i più veloci -anche perché tra un po’ Bing sarà superiore in termini di pertinenza dei risultati).
Scopro da LukeW la lista delle linee guida per la progettazione della user experience per iPad.
Premetto che la cosa è interessante in se: alla Apple sanno bene che l’esperienza di una app viene spesso associata al prodotto e quindi avere pessime app significa anche avere un minimo di ricaduta sul brand.
Per cui da tempo hanno rilasciato una serie di linee guida per il design delle esperienze sulle app di iPhone e ora anche di iPad.
Tra i vari punti elencati, alcuni mi hanno colpito dal punto di vista dell’interaction design e architettura dell’informazione:
Enhance Interactivity (Don’t Just Add Features): significa che per i nuovi device mobili, bisogna pensare ad arricchire l’interazione, anzichè aumentare il numero di features (less is more, again, ever)
Flatten Your Information Hierarchy: gli spazi informativi si appiattiscono, l’accesso alle funzionalità è più diretto, meno “profondo” (in senso fisico: pensate all’alberatura dei “vecchi siti”)
C’è da immaginarsi che tra i parametri con cui Apple valuta l’approvazione delle app (e magari anche la loro “importanza di promozione” all’interno dello store) ci siano anche questi preziosi suggerimenti.
Mi chiamo Alberto Mucignat, vivo a Roma e faccio lo User Experience Designer, ovvero mi occupo di progettare siti e servizi web efficaci e facili da usare.
Per questo ho fondato Doralab, azienda che si occupa di progettazione della user experience, user-centered design e usabilità.
Nel tempo libero mi dedico alla natura: arrampico, vado in mtb e mi piace esplorare posti sconosciuti.
