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:
- Un markup HTML semanticamente corretto, logico e valido
- Un contenuto che ha senso quando viene letto o ascoltato
- Testo alternativo per ogni tipo di contenuto visuale
- 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 10x10 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.
