Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

7 errori in tema di accessibilità

Cose da evitare nella gestione di un progetto rivolto alla realizzazione di un sito accessibile
Cose da evitare nella gestione di un progetto rivolto alla realizzazione di un sito accessibile
Link copiato negli appunti

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
      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
        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
        è 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
        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
        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
            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

              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.

Ti consigliamo anche