7 errori in tema di accessibilità

Questa è la traduzione dell’articolo Seven accessibility mistakes (part 1) pubblicato originariamente su Digital Web Magazine il 31 gennaio 2006. La traduzione viene qui presentata con il consenso dell’editore e dell’autore.

Ci sono diversi motivi per cui vengono pubblicati sul web siti non accessibili. Di uno abbiamo discusso in un mio precedente articolo: a molti clienti dell’accessibilità non importa praticamente nulla. Le loro motivazioni hanno un senso se ci si mette nei loro panni. Un’altra ragione è rappresentata dagli errori di noi sviluppatori. Fare errori è naturale, pagarne le conseguenze e imparare da quegli errori è ciò che può renderci migliori, come sviluppatori e come persone.

In questo articolo parlerò di alcuni fra i principali errori che ho dovuto affrontare nel corso della mia attività di sviluppatore web professionista. Se li terremo in considerazione nel futuro, è molto probabale che riusciremo a creare siti belli e accessibili senza tanti problemi, accontendando clienti e visitatori.

Alla fine di ogni sezione, presenterò anche una serie di suggerimenti utili ad evitare simili errori. È possibile che non tutti siano in grado di seguirli, per ragioni di budget, o perché alcuni richiedono un rapporto molto stretto con il cliente, ma tenerli presenti non può certo far male. Nessun passo compiuto nella direzione di un design fatto a vantaggio dell’utente e che tenga conto delle idee del cliente può rappresentare una perdita di tempo.

I sette errori in tema di accessibilità: 1-3

Errore #1: Fidarsi dei prodotti senza testarli

Molti strumenti di editing, framework o sistemi CMS dichiarano di poter creare siti standard compliant e conformi al livello WAI tripla-A. Molti di essi si limitano però a chiudere i tag HTML, a mettere in minuscolo i nomi degli elementi generati da un editor WYSIWYG e a rispettare le regole relative all’uso dell’attributo alt sulle immagini. Non c’è niente di male in tutto ciò, ma non basta.

Un codice HTML valido non è necessariamente corretto a livello semantico o logico, solo un essere umano è in grado di stabilire se lo è davvero. Non vorrei essere frainteso: ci sono strumenti di editing sicuramente validi, ma sono solo strumenti, macchine che non sono in grado di comprendere le questioni riguardanti l’interazione degli esseri umani con un computer. Le macchine non possono determinare in alcun modo se il risultato finale abbia o meno un senso, per quanto siano sofisticate. Nel bel mezzo di un progetto, poi, uno può scoprire che un certo CMS ha qualche difetto tenuto ben nascosto nei siti dimostrativi che in genere ne accompagnano la distribuzione (mi viene in mente la conformità rispetto alla codifica UTF-8 per i siti internazionali).

Cosa significa tutto ciò per lo sviluppatore?

• Dedicare molto tempo ad attività di training su uno specifico prodotto (nel caso di un IDE si tratta di un investimento che paga una volte per tutte).
• Documentare errori e bug insieme ai modi per risolverli. Fare di questo documento una parte obbligatoria del progetto da consegnare poi al team di gestione del sito o a eventuali nuovi membri del team di sviluppo.
• Svolgere test con esseri umani nel corso della fase di sviluppo. È un compito che può essere svolto da un editor appositamente addestrato se non c’è il tempo per un ciclo di test completi.

Errore #2: Assumersi troppe responsabilità

Diciamolo. Un sito web non rimarrà mai come era stato concepito nel progetto originale. I siti web hanno la tendenza a crescere in maniera organica, ed è proprio questo che li rende interessanti. Se non si vuole essere l’unica persona responsabile della gestione dei cambiamenti, si dovrà fare in modo che il cliente sia informato su tutti i dettagli del progetto.

Presentarsi al cliente come il supereroe dell’accessibilità che combatte il crimine di notte con il suo bel costumino è il miglior modo per fallire su tutta la linea. La questione non è che il cliente potrebbe non fidarsi di noi – sarà magari felicissimo di liberarsi di questa responsabilità. Il problema è che così facendo, si verrà coinvolti giocoforza nelle dispute interne all’azienda e ci si dovrà assumere per intero la responsabilità.

Ecco uno scenario tipico. Quelli del Marketing arrivano con del testo che è totalmente inaccessibile perché dipende in tutto e per tutto dalle immagini che lo accompagnano (forse prese da una campagna pubblicitaria portata avanti sulla stampa o in TV). Il project manager ti passa quel testo. Tu spieghi che possono esserci dei problemi e lui ti risponde che quelli del Marketing vogliono assolutamente quella cosa, e ti chiede in che modo potrebbe affrontare la questione. Tu glielo spieghi e lui dimentica questo o qualche altro piccolo dettaglio quando riferisce sul probema agli uomini del Marketing. Allora inizia un giochetto snervante, e finisce che tu perdi un sacco di tempo a ripetere cose ovvie senza concludere nulla.

I fatti:

• Il cliente vuole un sito web
• Il cliente vuole acquirenti, lettori, ascoltatori o visitatori felici e soddisfatti
• Il cliente cambierà probabilmente tutto per diverse ragioni

La soluzione logica è di istruire il cliente il prima possibile sui problemi di accessibilità e di accordarsi sul fatto di rimanere entro certi limiti (davvero non strettissimi) quando si tratta di apportare modifiche al sito.

Questo può anche aiutarci a coprirci le spalle nel caso in cui il cliente debba affrontare qualche causa legale. Si dovrebbe sempre dire: “Ti aiutiamo a raggiungere l’accessibilità”, non “Ti facciamo un sito accessibile”.

Cosa significa questo per lo sviluppatore?

• Considerare l’opportunità di organizzare sessioni di addestramento sull’accessibilità con il cliente prima di iniziare lo sviluppo del sito.
• Trovare nell’azienda del cliente qualcuno che si occupi di far rispettare gli standard di accessibilità. C’è sempre qualcuno che vuole mettersi in mostra, e questa è un’ottima opportunità – l’accessibilità è anche una questione legale.
• Produrre materiale sulle azioni da intraprendere in tema di accessibilità e su come implementarle in caso di modifiche al progetto.
• Avere nel contratto una parte chiara e coincisa che stabilisca che l’accessibilità del contenuto, dal momento della consegna, è responsabilità del cliente. Ogni intervento aggiuntivo e successivo dovrebbe avere un costo extra. Proprio la minaccia di costi aggiuntivi dovrebbe convincere il cliente a far prestare più attenzione ai nostri discorsi da parte del suo staff.
• Assicurarsi di mettere in pratica ciò che si predica. Il contenuto e il codice che si consegna deve essere perfetto. Gli errori saranno replicati ed è poi difficile spiegare al cliente che una tua raccomandazione era in realtà sbagliata.

Errore #3: Pianificare solo per lo scenario peggiore

Può accadere che noi sviluppatori, pieni di altruismo verso le persone disabili, ci dimentichiamo del contesto generale. Ma l’accessibilità è per tutti, a prescindere dalle abilità personali o dal contesto geografico. Molti di noi non avevano probabilmente mai pensato prima a cose come l’accesso da tastiera, il riconoscimento vocale o gli utenti che usano uno screen-reader. A questo punto ci sentiamo in colpa e vorremmo compensare la nostra indifferenza di prima contrastando fieramente tutto ciò che potrebbe impedire l’accesso ad un sito con uno screen-reader.

Ecco un piccolo segreto. Uno screen-reader è uno strumento che ha le sue regole di funzionamento. Molti sviluppatori web sembrano credere in tutta una serie di miti su di essi. Basta invece testarne uno, o chiedere a persone che dipendono da tecnologie assistive come li usano, cosa vorrebbero, di cosa hanno bisogno.

Non esiste, letteralmente, un modo per conoscere in anticipo il livello di abilità, la dotazione hardware e l’esperienza di chi sta dall’altra parte dello schermo. Tentando di identificare una sorte di minimo comun denominatore, non riusciremo a rendere il sito accessibile, usabile e godibile per la maggior parte dei visitatori. Non faremo altro che perpetuare la leggenda secondo cui i siti accessibili devono essere spogli e brutti.

I requisiti minimi per un sito accessibile sono:

1. Un markup HTML semanticamente corretto, logico e valido
2. Un contenuto che ha senso quando viene letto o ascoltato
3. Testo alternativo per ogni tipo di contenuto visuale
4. Titoli e link che abbiano un senso fuori dal loro contesto

Questi elementi di base devono essere i fondamenti del nostro sito. Se tutto gli elementi extra che inseriamo al di sopra di essi non ne inficiano la funzionalità, siamo sulla strada buona.

Elementi extra da evitare sono:

• Colori poco contrastati nella grafica e nei CSS
• Combinazioni di colori difficilmente distinguibili per chi ha problemi di vista
• Testo troppo piccolo o che non può essere ridimensionato
• Sovrapposizione di elementi che si nascondono a vicenda quando si ingrandisce il testo

Aggiungere un po’ di Javascript per consentire il drag-and-drop o per aggiungere un menu drop-down va bene. Bisogna solo assicurarsi che il Javascript sia applicato soltanto quando lo user agent è in grado di gestirlo. Meglio: presentiamolo come un’opzione oppure offriamo un modo per disabilitarlo a favore di un’interfaccia più semplice.

Cosa significa questo per lo sviluppatore?

• Assicurarsi che gli elementi di base vengano realizzati per primi e far vedere al cliente che il sito funziona in tutti i tipi di scenario.
• Provare a introdurre l’idea di progressive enhancement. Non partire dagli elementi visuali, ma da schemi privi di appeal visivo e senza stili di presentazione.
• Usare strumenti che consentano all’editor del sito di produrre testo al di fuori di qualsiasi framework visuale. Potrebbero essere dei template di Word molto semplici o strumenti come WordPress.
• Far vedere come la cura per gli elementi di base dell’accessibilità possa aiutare tutti – si potrebbe far navigare il sito con un cellulare o un palmare, per esempio.
• Non dimenticare di dire che un contenuto accessibile è amico dei motori di ricerca.
• Progettare tenendo in mente l’usabilità. Una buona grafica non è solo importante per l’impatto emotivo, ma facilita al visitatore il compito di trovare subito ciò che è importante, senza dover pensare troppo.
• Progettare tenendo in mente la flessibilità. I siti web dovrebbero essere in grado di crescere sia dal punto di vista dell’architettura dell’informazione, sia dal punto di vista dello spazio occupato sullo schermo. Evitiamo di riempire ogni spazio. Un giorno si dovranno aggiungere nuovi link di navigazione o cambiare quelli esistenti; oppure si tradurranno i testi in una lingua con parole più lunghe.

Nel seguito dell’articolo parlerò di altri quattro errori di accessibilità che ho dovuto affrontare:

• Condividere i problemi con i visitatori
• Provare a risolvere problemi che sono al di fuori della nostra esperienza diretta
• Nascondere i miglioramenti di accessibilità e usabilità
• Provare a soddisfare i tuoi clienti – e non i loro clienti

Abbiamo già discusso dei primi tre errori dei sette con che ho dovuto affrontare nel corso della mia carriera. Per l’esattezza:

• Errore #1: Fidarsi di certi prodotti senza testarli. Non è divertente dover scoprire nel bel mezzo della fase di sviluppo che il CMS non aiuta a creare un markup pulito, o che il framework utilizzato produce controlli che è possibile usare solo con il mouse.
• Errore #2: Assumersi troppe responsabilità. Talvolta diamo al cliente l’impressione che per creare un sito accessibile basta fidarsi di noi. Dovremmo invece aiutarlo a capire che quando arriva il momento di modificare il sito, l’accessibilità è una responsabilità sua e nostra.
• Errore #3: Pianificare solo per lo scenario peggiore. Troppo spesso pensiamo che progettare per l’accessibilità significhi tenere conto di una sorta di minimo comun denominatore, perpetuando il mito secondo cui i siti accessibili debbano essere brutti e spogli.

Questa settimana affronteremo altri quattro scenari da evitare e vedremo come evitarli. Se il budget o i rapporti con il cliente sono un limite, queste idee potrebbero almeno suggerirvi dei metodi per guidare il cliente nella direzione di uno sviluppo che tenga al centro di tutto l’utente.

I sette errori in tema di accessibilità: 4-7

Errore #4: Condividere i problemi con i visitatori

Vogliamo proteggere il nostro sito dallo spam di commenti, dallo spoofing di indirizzi e-mail e dal furto dei contenuti. Ma perché scaricare tutto il peso sui visitatori, costretti magari a dover inserire in un modulo cose che vedono – o non posono vedere – su un’immagine quando tutto ciò non fa davvero niente per proteggerli? Qualunque cosa sia generata da un computer può essere oggetto di hack di vari tipo da parte di un altro computer, basta un po’ di tempo e di impegno. Il discorso vale anche per sistemi che si presumono a prova di hack come i cd. CAPTCHA.

E perché i visitatori del nostro sito dovrebbero affrontare la compilazione di un lungo modulo solo per farci una domanda? Se riceviamo tanto spam, il problema è nostro, non loro. Certo, tutto ciò può far desistere qualche birbante capitato lì per caso e può darci modo di mettere in mostra qualche strumento di supporto del sito come la sezione di FAQ, ma comporta anche, per quanti vogliano davvero contattarci, il dover affrontare un procedimento molto più lungo e complicato del necessario. Quante volte abbiamo attaccato bruscamente il telefono dopo aver ascoltato tutte le opzioni di un sistema di risposta automatico?

È fondamentale offrire ai visitari un modo per riuscire a comunicare con noi: è il segno che prestiamo attenzione alle loro richieste e ai loro problemi. E ci copre le spalle nel caso in cui qualcuno si lamenti per il fatto di non riuscire a contattarci. In alcuni paesi ci sono addirittura leggi che obbligano a inserire su ogni pagina del sito un modo per comunicare con chi lo gestisce. In Germania, ad esempio, ogni sito deve avere un ‘Impressum’, ovvero una lista dei vari modi con cui è possibile contattare un’azienda.

Un’altra preoccupazione di cui ho sentito parlare spesso riguarda la protezione della grafica e dei testi. Appena compaiono sul web, ci sarà di sicuro qualche abile ladro che riuscirà a impossessarsene. Gli script che prevengono il click destro del mouse, le immagini coperte con una GIF trasparente e i filmati Flash messi in loop, non sono davvero misure di sicurezza. Tutto ciò che si ottiene è rendere complicata la vita dei visitatori che potrebbero aver bisogno del click destro o che non hanno il Flash player installato.

Cosa significa tutto ciò per lo sviluppatore?

• Non promettere misure di sicurezza basate su Javascript o sui CSS: semplicemente non esistono. Sono fastidiose per i visitatori normali e rappresentano un piccolo ostacolo per chi voglia davvero combinare guai.
• Istruire i clienti sull’importanza dei canali di comunicazione. Un sito web è prima di tutto un mezzo per la distribuzione di contenuti, ma è anche uno strumento di comunicazione. Il numero di richieste che si trasformano in pareri positivi è una misura del successo ottenuto nel proprio business.
• Trovare soluzioni efficaci a livello di backend per lo spam invece di rendere più complicata la vita dei visitatori che vogliono contattare il cliente.

Errore #5: Cercare di risolvere problemi che sono al di fuori della nostra esperienza diretta

È sempre una tentazione usare tecniche di scripting client-side come JavaScript per aggirare i difetti dei browser. Uno strumento di cui si è sempre molto discusso sono i widget che consentono di ridimensionare il testo. Fanno sempre una straordinaria impressione nelle presentazioni ai clienti, i quali non mancheranno di contattarci per farci notare che i loro concorrenti lo usano sui loro siti.

I widget usati per ridimensionare la grandezza dei font sono in genere rappresentati da pulsanti con etichette tipo A, A-, A+ e A++, oppure testo piccolo, testo normale, testo grande. I tipi più bizzarri usano immagini di 10×10 pixel con testo grigio su uno sfondo leggermente più chiaro. Come può trovarli una persona che ha necessità di avere un testo piuttosto grande sulla pagina?

Tutte le soluzioni di questo tipo non fanno altro che emulare funzioni che strumenti esterni al sito dovrebbero svolgere e in effetti svolgono meglio. Avere un testo più grande non è propriamente un requisito del sito. Si tratta di qualcosa che riguarda il sistema operativo del computer ed è pertanto un problema che riguarda i produttori di sistemi operativi e di browser.

Più cerchiamo di trovare hack atti a risolvere i problemi degli user agent, meno gli utenti saranno inclini a sostituirli con strumenti migliori. Un sito web con un testo ragionevolmente grande e non espresso con unità di misura fisse, può essere ridimensionato dal visitatore usando le opzioni del browser. Se tali opzioni sono ben nascoste dietro una porta inaccessibile su cui magari c’è scritto ‘Attento al Leopardo’, allora un visitatore che ha realmente bisogno di un testo più grande non starà usando quel browser oppure ha trovato il modo per risolvere il problema. Se vogliamo davvero aiutare le persone, spieghiamo, nelle pagine dedicate alla nota sull’accessibilità, come possono ridimensionare il testo nei vari browser. Abbiamo già tante cose di cui preoccuparci riguardo al nostro sito; non proviamo a migliorare con esso i prodotti di altri.

Cosa significa tutto ciò per lo sviluppatore?

• Non entusiasmarsi troppo per widget di vario tipo e per gli strumenti che consentono di modificare il comportamento dei browser attraverso tecnologie client-side. Bisogna ricordarsi che esistono tanti tipi di persone e di user agent.
• Non replicare le funzionalità degli user agent. In molti browser posso salvare un bookmark, stampare e cambiare le dimensioni del testo con elementi dell’interfaccia (tipo pulsanti) e scorciatoie da tastiera. Se vogliamo aiutare gli utenti insesperti, aggiungiamo una sezione di Help che spieghi come ridimensionare il testo. Comunque, è inutile aspettarsi che la leggano in molti: quelli che hanno davvero necessità di un testo più grande sono arrivati per qualche motivo sul sito e sanno come farlo.
• Se si aggiungono widget, devono essere davvero validi. Dovrebbero funzionare anche con gli script disabilitati ed essere ridimensionabili attraverso le impostazioni del browser.
• Se si vuole dare ai visitatori la possibilità di personalizzare il sito, facciamolo nel modo dovuto. Offriamo ad esempio modi per cambiare il layout, aggiungere ed eliminare sezioni, spostare la navigazione, forniamo funzionalità che offrono già i portali e i siti delle intranet.
• Essere consapevoli che i piccoli trucchetti usati per risolvere oggi difetti e problemi dei browser, sono destinati a rimanere anche domani e dopodomani. Sembra che gli sviluppatori siano molto solerti ad aggiungerli, ma piuttosto riluttanti a toglierli. Quante volte incontriamo link tipo ‘Clicca per aggiungere questa pagina ai preferiti’ che funzionano solo su Internet Explorer?

Errore #6: Nascondere i miglioramenti di accessibilità e usabilità

Non sono molti i sistemi per migliorare l’accessibilità che modificano drasticamente l’aspetto visuale di un sito, e talvolta di essi non c’è proprio bisogno. Un elemento di miglioramento che potrebbe risultare necessario e che scatena discussioni furiose su forum e mailing list sono i cosiddetti ‘skip links’.

Questi link aiutano il visitatore a saltare le sezioni che si ripetono uguali su ogni pagina – come i trenta link messi sopra la prima riga di contenuto vero e proprio. Sono davvero molto utili per i non vedenti, ma aiutano anche quelli che sono legati alla tastiera per la navigazione o che navigano utilizzando dispositivi con schero piccolo come telefoni cellulari e palmari.

Ma allora che danno fa un link ‘Vai direttamente ai contenuti’ scritto con un font molto piccolo e allineato a destra invece che essere nascosto con i CSS? Molto più che un loghetto di conformità WAI-AAA è il segno che i nostri clienti hanno a cuore i bisogni dei loro visitatori.

Lo stesso si può dire per i fieldset, le label e il bordo di evidenziazione che alcuni browser aggiungono intorno al link corrente. È vero: non sempre sono esteticamente gradevoli, ma hanno una loro ragion d’essere. I fieldset, ad esempio, consentono a tutti gli utenti di capire che i campi che contiene rappresentano un’unità logica.

I link presentano stati differenti, e ha molto senso definire diversi stili di visualizzazione per ciascuno di questi stati. Personalmente mi sono sempre chiesto a cosa servisse lo stato ‘active’, e ho sempre ritenuto che esso fosse visibile per un istante, fino al caricamento della pagina linkata o fino all’esecuzione dell’azione richiamata in uno script. Non sapevo che gli user agent impostano lo stato ‘active’ sull’ultimo link visitato quando si preme il pulsante ‘Indietro’ del browser o si usa l’equivalente scorciatoia da tastiera. Ha o non ha senso?

Cosa significa tutto ciò per lo sviluppatore?

• Assicurarsi che tutti i miglioramenti di accessibilità che si aggiungono possano essere usati da chi ne ha bisogno. Gli ‘skip links’ non sono utili solo a chi usa uno screen reader.
• Sebbene non risulti immediatamente chiaro, ci sono ragioni ben precise per cui i browser rendono in un modo specifico i form e i link. Se si interviene a modificare queste modalità di default e si fa piazza pulita di ‘quegli orribili bordi in stato di hover’, bisogna avere ragioni veramente valide e fare dei test di usabilità con esseri umani. I produttori di browser lo hanno fatto.
• Ogni volta che si modifica l’aspetto dei form, si perde il beneficio del loro riconoscimento immediato. Per fare interventi del genere deve valerne la pena.

Errore #7: Provare a soddisfare i tuoi clienti – e non i loro clienti

I tempi dei clienti che non sanno nulla del web e che credono ad ogni cosa diciamo loro, sono, purtroppo, finiti. Anni e anni di produttori di software, riviste, sviluppatori dilettanti o parenti che che dicono ai nostri clienti che fare un sito è facile come cliccare con il mouse, hanno reso molto più complicato il nostro lavoro.

I clienti amano le cose visuali e si faranno conquistare molto più probabilmente da un fantastico menu drop-down che da una mappa del sito ben organizzata con estratti di contenuto che aiutino i visitatori a trovare facilmente e nel più breve tempo possibile ciò che cercano.

Di questi tempi, poi, è probabile che i clienti non siano disposti a spendere molto denaro, e vogliono risultati tangibili da subito. Workshop, formazione, sessioni di architettura dell’informazione, esercizi di card-sorting per l’usabilità e analisi della concorrenza sono tutte cose che fanno diminuire il tempo dedicato allo sviluppo, dal momento che non si mette niente in forma di codice che non sia stato valutato e meditato con estrema attenzione. Purtroppo, queste attività non producono nulla di concreto e sono pertanto difficili da vendere, è dura vedere destinato ad esse un po’ del tempo già ristretto fissato per il progetto. Sembra che la velocità del web dia l’impressione che sviluppare un sito debba essere veloce e rapido quanto usarlo. Alcuni clienti pensano che mettere su una presentazione che è simile ad un’applicazione web, rappresenti la metà del lavoro da fare.

È forte allora la tentazione di lasciar perdere e smussare ogni angolo pur di fare contento il cliente. Se lui usa solo Internet Explorer, perché perdere tempo testando il sito con gli altri browser? Se il budget in termini di tempo e denaro è già tanto ristretto, perché non sbarazzarsi del supporto per gli utenti senza Javascript nella nostra applicazione web? Dopo tutto, lo fanno anche gli altri!

La cosa triste è che tutto ciò funziona. Il cliente è felice, non c’è praticamente feedback negativo da parte degli utenti e si può andare avanti nei limiti imposti dal budget. Un successo finanziario straordinario. Ma chi usa quel prodotto merita di più. Sembra che tutti siano disposti a perdonare tutto, ma quelli che non soddisfatti, non si lamentano: semplicemente vanno via.

Questo è l’errore più insidioso da evitare, e non posso fornire una soluzione semplice. I clienti sono molto più vicini a noi rispetto agli utenti finali. Ciò che ci serve sono esempi di casi in cui una progettazione centrata sui bisogni dell’utente abbia portato molto più denaro e ha fatto crescere un’azienda senza che essa esplodesse alla fine del periodo della bolla speculativa. Se avete storie di successo al riguardo, condividetele!

Cosa significa tutto ciò per lo sviluppatore?

• Non cedere di fronte a tutte le idee che il cliente vorrebbe vedere implementate sul sito. Non siamo maggiordomi, ma esperti assunti per svolgere un lavoro in modo adeguato.
• Assicurarsi di avere esempi che facciano entusiasmare il cliente e avere a disposizione materiale che mostri perché potrebbe non essere una buona idea implementare certe idee sul suo sito.
• Non agire per impuslo. Spiegare che per ogni cambiamento c’è bisogno di test e del parere di altre persone dell’azienda – analisti, tecnici, progettisti, svilupaptori web, etc. Prevedere budget e spazi di tempo ben precisi per il lavoro di implementazione prima di procedere.
• Ridurre al minimo il numero di persone che parla direttamente con il cliente. Idealmente dovrebbe essereci un unico punto di contatto che smista i compiti da svolgere al team di sviluppo. Con troppi canali di comunicazione aperti, qualcuno prometterà di implementare una modifica senza consultare il team, o sottovaluterà il lavoro necassario. I bambini conoscono bene questo trucchetto: se papà dice ‘no’, prova con la mamma!
• Iniziare a tenere un catalogo di storie di successo di design centrato sull’utente per tutti i progetti. Si potrebbe essere in grado di implementare un pezzettino di ciascuno e mettere insieme un buon portfolio da mostrare nel futuro.