GOV.UK

Approccio pragmatico e orientato al servizio quello del nascente sito GOV.UK: grafica leggera e leggibile, home page eterea, informazioni al posto di propaganda della PA.

Una delle parti interessati per tutti i professionisti del web è l’elenco (sempre suscettibile di modifica) delle linee guida che merita di essere tradotto perché valido per ogni sito della PA (e non) anche dall’altro lato della Manica.

Da notare come l’accento sia posto veramente sull’utilizzatore, come sia valorizzato il concetto di open (open data, open source…) e come sia scoraggiata l’autoreferenzialità.

Finito di leggere questo decalogo andate a fare un giro su un sito della PA italiana, uno qualsiasi.

1. Inizia con le esigenze (dei cittadini, non della PA) – Bisogna analizzare le esigenze dei cittadini e costruire un sito che si basa su quelle esigenze, tenendo presente che quello che chiedono gli utenti può non essere quello di cui hanno bisogno. La chiarezza è fondamentale.
2. Fare di meno – Senza fare facili battute, il sito della PA deve fare solamente quello che può fare, se qualcun altro lo fa, si mette un link. Favorire, se possibile, la pubblicazione di API per richiamare le informazioni, in modo tale che altri pubblichino i dati elaborati. Ci si deve concentrare sul core, non sui fronzoli.
3. Progettare con i dati – Imparare dal comportamento del mondo reale, iniziare un processo continuo di miglioramento che passa dai test fatti con utenti veri.
4. Lavorare duro per rendere le cose semplici – Creare qualcosa che sembri semplice è facile, ben più difficile è creare qualcosa che sia effettivamente semplice, specialmente quando il sistema sottostante è complesso. Tenere sempre presente che gli utenti devono utilizzare i servizi della PA e che spesso non hanno altra scelta.
5. Iterare. Poi iterare di nuovo – Il sistema migliore per costure servizi efficaci è partire con qualcosa di semplice e continuare a lavorarci su. Rilasciare appena possibile un prodotto con funzionalità essenziali, raccogliere i commenti e le reazioni e aggiungere funzioni ascoltando gli utenti. Questo approccio riduce i rischi e gli sprechi derivanti da scelte che poi si rivelano inefficaci.
6. Costruire per inclusione – Bisogna costruire un prodotto il più possibile accessibile, leggibile e comprensibile, anche a costo di sacrificare l’eleganza. Non bisogna aver paura dell’ovvio e non si devono reinventare il web e i suoi paradigmi.
7. Comprendere il contesto – Non si sta disegnano un sito per uno schermo, ma per delle persone, quindi bisogna pensare al contesto in cui queste persone fruiranno del sito. Potrebbero essere dei vecchi lupi della rete come degli assoluti neofiti.
8. Costruire servizi digitali, non siti web – Il servizio non si deve limitare al sito: potrebbe partire da un motore di ricerca e terminare in un ufficio postale; bisogna tener ben presente questo fatto, anche se non si può controllare ogni parte del processo.
9. Essere coerenti, ma non uniformi – Ogni volta che è possibile si devono usare gli stessi linguaggi e gli stessi schemi per aiutare gli utenti; quando non si può farlo si deve fare in modo che l’approccio al problema sia coerente.
10. Rendere le cose aperte le rende migliori – Bisogna condividere quanto più possibile, con i colleghi, con gli utenti, con il mondo intero. Bisogna condividere il codice, le strutture, le idee, le intenzioni e gli errori.