Bastone o carota?

Ormai lo sapete I’M FALLING IN LOVE! Si, mi sono innamorato dei Design principles britannici sui SERVIZI PUBBLICI DIGITALI e mi accingo a commentarne qualcuno, frustrandomi, tafaziandomi e anche incazzandomi non poco.

Tutto inizia con una premessa: These principles are intended to be ‘carrot not stick’. They’re not a list of bad things to be avoided, they’re a set of principles to inspire you, accompanied by examples which explain things further and code and resources which will make the principles easier to follow.
We’d love to know what you think — will these principles and examples be useful for you? Please let us know via govuk-feedback@digital.cabinet-office.gov.uk.

Sinteticamente: ‘NON SIAMO QUI PER BASTONARE NESSUNO, NON ENUNCIAMO QUESTI PRINCIPI PER AFFERMARE CHE TUTTO FA SCHIFO, MA SIAMO QUI PER PORTARE QUALCHE ESEMPIO ISPIRATORE E RENDERE LE COSE PIU’ FACILI. CI PIACEREBBE SAPERE CHE NE PENSATE, DUNQUE FATECELO SAPERE

Crowdsoucing, co-costruzione, ascolto, analisi dei fabbisogni???? Non lo so, ma mi sembra così chiaro e semplice che rispetto ai nostri pistolotti è già anni luce avanti. E continua la frustazione. Carry on!

Ed eccoci ai 10 comandamenti (in origine erano 7)

The 7 GDS digital principles

1) Start with needs (PARTIRE DAI BISOGNI) *quelli degli utenti, non quelli della Pubblica Amministrazione

The design process must start with identifying and thinking about real user needs. We should design around those — not around the way the ‘official process’ is at the moment. We must understand those needs thoroughly — interrogating data, not just making assumptions — and we should remember that what users ask for is not always what they need.

LA PROGETTAZIONE DEVE BASARSI SULLE ESIGENZE REALI DEGLI UTENTI. TUTTA LA PROGETTAZIONE VA FATTA ATTORNO ALL’UTENTE  (user centric design ……che bel termine ignorato beatamente nell’italico paese ). BISOGNA CAPIRE I BISOGNI ANALIZZANDOLI IN PROFONDITA’ E NON CADERE NEL SOLITO ERRORE DI FARE DELLE SUPPOSIZIONI (io direi non arrogandoci la boria di sapere cosa i cittadini vogliono). SENZA DIMENTICARE CHE CIO’ CHE CHIEDONO NON RAPPRESENTA SEMPRE UN BISOGNO.

Esempi in Italia? Citofanate nei commenti, perchè io non ne vedo.

2) Do less (FARE MENO) e qui parte la ola, perchè questo articolo letteralmente mi arrappa.

Government should only do what only government can do. If someone else is doing it — link to it. If we can provide resources (like APIs) that will help other people build things — do that. We should concentrate on the irreducible core.

LA PUBBLICA AMMINISTRAZIONE DOVREBBE FARE SOLO QUELLO CHE LA PUBBLICA AMMINISTRAZIONE PUO’ FARE (sostituirei ‘dovrebbe’ con ‘deve’). SE QUALCUNO SA FARLO MEGLIO FATECELO SAPERE E GLI OFFRIAMO TUTTI GLI STRUMENTI PER POTER SVILUPPARE AL MEGLIO LE SOLUZIONI. NEL CONTEMPO NOI CI CONCENTREREMO (meglio) SULLA NOSTRA MISSIONE E SUGLI ASSET IRRINUNCIABILI.

E dopo l’applauso? Citofonate esempi.

3) Design with data (PROGETTARE CON I DATI)

Normally, we’re not starting from scratch — users are already using our services. This means we can learn from real world behaviour. We should do this, but we should make sure we continue this into the build and development process — prototyping and testing with real users on the live web. We should understand the desire paths of how we are designing with data and use them in our designs.

SOLITAMENTE NON PARTIAMO DA ZERO QUANDO SIAMO CHIAMATI A PROGETTARE SERVIZI. ALLORA IMPARIAMO DA CIO’ CHE SUCCEDE NEL MONDO E DA QUELLO CHE STA SUCCEDENDO SUL WEB PER DISEGNARNE DI MIGLIORI. DOVREMMO CONCENTRARCI DI PIU’ SUI PERCORSI CHE SONO CREATI DAI COMPORTAMENTI DELLE PERSONE E DA COME LORO UTILIZZANO I DATI. (Gli inglesi son fantastici, usano il ‘desire path’, che figurativamente rappresenta il solco della bicicletta che devia dal percorso che gli è stato preconfigurato, per esaltare l’alternativa, la scorciatoia, la creatività e il fai da te……ecco perchè il Civic Hacking è nato da loro…..sospirone)

Short cut :)

Comunque, tema difficile perchè in Italia siamo alla fase uno, ovvero alla liberazione del dato, non ancora al suo utilizzo. Appsforitaly? http://www.appsforitaly.org/

4) Do the hard work to make it simple  (IMPEGNARSI PER SEMPLIFICARE LE COSE)

Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.

FARE QUALCOSA CHE SEMBRI SEMPLICE, È ABBASTANZA FACILE, FARE QUALCOSA DI SEMPLICE DA USARE È MOLTO PIÙ DIFFICILE – SOPRATTUTTO QUANDO I SISTEMI SOTTOSTANTI SONO COMPLESSI – MA QUESTO È QUELLO CHE DOVREMMO FARE.

A chi lo dite. Qui nemmeno le cose che appaiono semplici lo sono. Mi vengono in mente, anche se esco dal seminato, i siti dei provider di telefonia mobile ….. depressione.

5) Iterate. Then iterate again.  (RIPETERE, CON INSISTENZA)

The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.

Difficile da tradurre, perché è un modo di dire e di intendere il concetto di routine ripetitiva (loop), tipicamente anglosassone. PARTIRE DALLE PICCOLE COSE E RIPETERLE CON ENERGIA. PASSARE DALL’ALFA ALLA BETA E AGGIUNGERE CONTINUAMENTE FUNZIONALITA’ E MIGLIORAMENTI IN BASE AI FEEDBACK RACCOLTI

Si tratta della teoria (più volte enunciata su questo blog e nei miei scritti) della BETA PERPETUA. Inutile costruire cose complesse e ingestibili, meglio concentrarsi sulle piccole cose, tanto mutano in fretta e non son mai stabili. Mutare al mutare delle abitudini e degli stili. ….molto informatico :-)

6) Build for inclusion.  (COSTRUIRE SERVIZI ACCESSIBILI)

Accessible design is good design. We should build a product that’s as inclusive, legible and readable as possible. If we have to sacrifice elegance — so be it. We shouldn’t be afraid of the obvious, shouldn’t try to reinvent web design conventions and should set expectations clearly.

I servizi devono essere inclusivi, comprensibili e leggibili, pazienza se si deve sacrificare l’eleganza. Non dobbiamo avere paura dell’ ovvio, nemmeno di reinventare le convenzioni del web design e definire le aspettative in modo più chiaro.

7) Understand context. (CAPIRE IL CONTESTO)

We’re not designing for a screen, we’re designing for people. We need to think hard about the context in which they’re using our services. Are they in a library? Are they on a phone? Are they only really familiar with Facebook? Have they never used the web before?

Non stiamo realizzando servizi per il monitor del computer ma per le persone.Dobbiamo essere sicuri di aver capito da chi verrà utilizzato il servizio ed in quali circostanze. I nostri utenti stanno in una biblioteca? Usano un telefono? Son fidelizzati con  Facebook? Hanno mai usato il web prima?

8) Build digital services, not websites. (COSTRUIRE SERVIZI DIGITALI NON SITI WEB)

Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.

Attualmente il web è il miglior modo per distribuire i servizi,ma tutto può cambiare rapidamente. Inoltre i servizi debbono poter essere utilizzati anche fuori dal nostro spazio web.

9) Be consistent, not uniform. (ESSERE COERENTI, NON UNIFORMI)

Wherever possible we should use the same language and the same design patterns — this helps people get familiar with our services. But, when this isn’t possible, we should make sure our underlying approach is consistent. So our users will have a reasonable chance of guessing what they’re supposed to do.

Quando possibile bisognerebbe utilizzare lo stesso linguaggio e lo stesso format per i diversi servizi. L’importante è che la logica di fondo sia coerente.

10) Make things open: it makes things better. (FARE LE COSE OPEN: VENGONO MEGLIO)

We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers get spotted, better alternatives get pointed out, the bar gets raised.

Bisogna condividere il più possibile le cose che stiamo facendo. Più occhi ci sono su un servizio, meglio potrà essere sviluppato.

E’ inutile, non avremo mai la capacità di sintesi degli anglosassoni che, per certi versi è devastante e  irragiungibile. Mi si perdoni per certe sbavature nella traduzione ma, spero, di aver rappresentato un po’ del loro modo di pensare.

Veniamo ora al tema che pone Salvatore nel suo ultimo post e al ‘problema’ dei linguaggi.
FARE LE COSE OPEN: VENGONO MEGLIOBisogna condividereil più possibile lecose che stiamofacendo. Più occhi cisono su un servizio,meglio potrà esseresviluppato.
Questa mia escursione nella perfida Albione vorrebbe far riflettere sul fatto che i vari linguaggi non sono un ostacolo se la cultura digitale è condivisa fra la PA e i cittadini. Enunciando i loro principi di design dei servizi pubblici, i britannici si rivolgono a operatori acculturati che possono velocemente correggere gli errori del passato. Da noi, invece, il problema è ancora quello del burocratese e dell’autoreferenza.
A mio modo di vedere l’Action Plan italiano è poco sexy, non tanto perchè non si allinea al linguaggio geek della rete (o meglio: non solo), ma perché è  difficile da digerire. E’ un lungo elenco dei TANTI problemi e delle POCHE cose fatte, che mal si adattano a un contesto di DIGITAL GOVERNMENT.
Esempio? Proviamo a leggere questa frase dell’Action Plan: ‘approvazione di un quadro normativo più efficace per la prevenzione e la lotta alla corruzione nella PA al fine di assicurare un miglioramento delle condizioni di mercato per la concorrenza e di favorire il contenimento della spesa pubblica. I provvedimenti all’esame prevedono l’obbligatorietà dell’adozione di piani anticorruzione a carico di tutte le PA, con il coordinamento del Dipartimento della funzione pubblica, l’individuazione di un responsabile della prevenzione della corruzione, la valorizzazione di una rete capillare sul territorio, quella dei Prefetti, nella forma di supporto tecnico e informativo agli enti locali e quali tramiti tra essi e l’Autorità nazionale anticorruzione.
Ma su che pianeta viviamo? Che lingua parliamo?
Capito ora perché mi son innamorato della perfida Albione?

6 Comments

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...