[LG design dei servizi web] 5. Requisiti

All’interno della documentazione dei contratti pubblici concernenti l’affidamento di design, restyling, sviluppo e/o gestione di siti e servizi digitali, le Amministrazioni DEVONO inserire la seguente dicitura:
«Il fornitore incaricato di sviluppare il servizio web deve rispettare le indicazioni riportate nelle Linee guida di design per i servizi web della PA».

Continua a leggere su Docs Italia.

Ma ci saranno riferimenti ad una progettazione allargata tipo progettazione del servizio e basta (ovvero service design)? Le linee guida sono utili e riguardano i servizi digitali, ma ormai il digitale è collegato anche al fisico. Se riprogetto un servizio digitale senza avere un’ottica integrata di design del servizio (aldilà dei canali e delle tecnologia) rischio di creare punti di contato non armonici che invece di favorire l’utilizzo confondono gli utenti o addirittura diventano barriera per altri.

1 Mi Piace

proposta:
«Il fornitore incaricato di sviluppare il servizio web deve rispettare le indicazioni riportate nelle Linee guida di design per i servizi web della PA».
Proposta:
«Il fornitore incaricato di sviluppare il servizio web deve rispettare le indicazioni riportate nelle Linee guida di design per i servizi web della PA e deve rilasciare dichiarazione di accessibilità e di trasparenza** ».

** per quanto riguarda la normativa sulla trasparenza ove il potale oggetto di contratto web riguardi la sezione “Amministrazione Trasparente” di una P.A.

altra domanda:

il link alla dichiarazione di accessibilità, nel footer del sito web;Esiste un modello?

è a carico del fornitore o dell’ente?

le informazioni, opportunamente aggregate, derivanti dal monitoraggio statistico attivato sul singolo sito;

Cosa si intende ? un export WAI ?

Sarebbe opportuno prevedere un Capitolo “Interfaccia applicativa”, oltre a “Interfaccia Utente”, con il seguente contenuto:

Finalità: mettere a disposizione interfacce applicative programmabili (API) per permettere l’interoperabilità con software esterni

Azioni richieste:
SI DEVONO realizzare API coerenti e consistenti;
SI DEVONO realizzare API per ogni funzione di acquisizione dati;
SI DEVONO realizzare API per ogni funzione di interrogazione dati;

3 Mi Piace

Il capitolo 5.3 si focalizza su ‘costruire interfacce usabili…’ come, Tutta via per garantire la semplicità d’uso, spesso non basta agire sull’interfaccia. Aggiungerei esplicitamente anche il tema di ‘progettare processi’.

2 Mi Piace

Nel capitolo ‘5.3 Semplicità di consultazione ed uso’ si mette l’accento sulla costruzione delle interfacce utente per ridurre tempi e costi e soddisfare esigenze. La creazione di interfacce da sola non è sufficiente, sarebbe opportuno menzionare il fatto che anche i processi che costituiscono il servizio vanno ri-progettati.

3 Mi Piace

Nel punto 5.6 piuttosto che nel 5.3 evidenzierei il focus sull’usabilità

3 Mi Piace

Accessibilità: in ambito Europeo si seguono i requisiti imposti dal WCAG 2.1 (ormai quasi 2.2), sia per l’HTML che per altri linguaggi di programmazione esistono software per fare un check delle caratteristiche dell’accessibilità della piattaforma con questi parametri.
In ogni caso sarebbe bellissimo utilizzare un approccio modulare su “.io”, come Instagram o FB, in cui vengono aggiunte funzioni sulla piattaforma di base. Stop alle app per qualsiasi cosa (afferma da un giovine studente).

Si suggerisce di spostare i primi due paragrafi nella sezione 2.2 (soggetti destinatari) visto che si tratta di una indicazione che riguarda i soggetti destinatari e non i requisiti di siti web e servizi online.

Si suggerisce di inserire una parte testuale che introduca il significato delle informazioni di sintesi proposte nei paragrafi successivi.

paragrafo 5.5: si suggerisce di eliminare il richiamo all’obbligo di pubblicare il link alla dichiarazione di accessibilità, gia’ ricompreso nella apposite linee guida, a loro volta richiamate in toto dal paragrafo 5.1.

Suggerirei di modificare il titolo del 5.3 in “Usabilità ed esperienza d’uso”, per coerenza rispetto alla normativa tecnica internazionale (i.e. filone ISO 9241-xxx e 250xx) e alle terminologie ormai consolidate tanto in ambito accademico quanto professionale.

1 Mi Piace

Suggerirei, anche sulla base di diversi altri commenti precedenti al mio, di ampliare le finalità del 5.3 come segue “comprendere i bisogni dell’utente a cui il servizio intende dare risposta; costruire sistemi e servizi digitali usabili, utili e capaci di fornire una più ampia esperienza d’uso attraverso i diversi punti di contatto, riducendo tempi e costi di sviluppo, e osservare come gli utenti interagiscono con il servizio, per un suo miglioramento costante.”.

Suggerirei di rivedere/integrare le azione del 5.3 come segue:

  • SI DEVE adottare un approccio progettuale orientato alle persone capace di coinvolgere, ascoltare ed osservare gli utenti nelle varie fasi di analisi, ideazione, progettazione e sviluppo;
  • SI DEVONO svolgere attività di ricerca con utenti per definire in modo esplicito le caratteristiche ed esigenze delle persone rispetto allo specifico contesto d’uso per il quale si sta progettando il sistema/servizio;
  • SI DEVONO descrivere gli scenari d’uso attuali e come immagino che questi evolveranno con il nuovo sistema o servizio;
  • SI DEVONO creare dei prototipi, a diversi livelli di maturità, per verificare e migliorare iterativamente le soluzioni progettuali in termini di usabilità ed esperienza d’uso;
  • SI DOVREBBE definire il livello di usabilità, in termini di efficacia, efficienza e soddisfazione, con cui mi aspetto che i miei utenti dovranno raggiungere i loro obiettivi attraverso il sistema/servizio che sto progettando;
  • SI DEVE basare l’architettura dell’informazione sui risultati delle ricerche sugli utenti;
  • SI DEVONO condurre delle valutazioni di usabilità con utenti, su servizi digitali esistenti o in fase di progettazione, per individuarne i problemi e/o misurarne la qualità in uso in termini di usabilità ed esperienza d’uso;
  • SI DEVE utilizzare un linguaggio e un’organizzazione dei contenuti web adeguati all’utente destinatario;
  • SI DEVE rendere facilmente trovabile, dai motori di ricerca esterni e interni al sito, il contenuto pubblicato;
  • SI DOVREBBE inserire nei contratti di gara per lo sviluppo dei siti web l’obbligo di adottare una modalità di progettazione orientata alle persone (Human-Centred) che garantisca la valutazione e l’implementazione degli aspetti connessi all’usabilità ed all’esperienza d’uso.
1 Mi Piace

Buongiorno,
manca una sezione fondamentale legata a un problema annoso: quello delle licenze.

Queste linee guida annullano e sostituiscono le precedenti «Linee guida per i siti web delle PA» e per questo do per scontato di poter fare riferimento a elementi di contenuto.

Ecco una proposta di integrazione.

5.8 Licenza dei contenuti

Finalità: applicare ai contenuti esposti una licenza aperta, in coerenza con le norme correnti.

Azioni richieste:

  • associare come licenza generale per i contenuti, una di quelle aperte previste dalle norme e darne adeguata evidenza;
  • nel caso di applicazione di licenze che limitino il riutilizzo dei contenuti, motivare opportunamente la scelta e darne evidenza;
  • verificare che nello spazio web realizzato e nei suoi template non siano presenti riferimenti “fantasma/orfani” a licenze non aperte. Nel caso rimuoverli;
  • verificare che la versione di licenza aperta applicata sia una di quelle correnti (evitare ad esempio una CC BY 2.5, ed usare la CC BY 4.0);
  • inserire sempre il link alla licenza.

Riferimenti normativi: Codice Amministrazione Digitale, Linee guida nazionali per la valorizzazione del patrimonio informativo pubblico, Piano Triennale per l’informatica nella Pubblica Amministrazione e direttiva EU 2019/1024.

11 Mi Piace

Sarebbe utile pero’ fare una sintesi di cosa si intenda per “contenuti”.
Esempio: come comportarsi in caso di pubblicazione (libera o in area a registrazione) di digitalizzazioni di beni culturali?
Es.: fondi librari, manoscritti, documenti d’archivio - per questi “contenuti” trovano applicazione norme (codice dei beni culturali) che pongono limiti alla libera riproduzione.

Da un testo normativo chiamato “linee guida” ci si attende appunto che guidi anche nell’orientarsi nel dedalo di fonti di rango superiore.

il 5.3 ha troppi punti, sovrapponibili in parte e vaghi:

  • i primi 4 punti danno una specie di metodo per la prima realizzazione, ma non si può sintetizzare una metodologia in 4 punti; se il documento deve restare sintetico meglio citare direttamente l’HCD e rimandare ad approfondimenti; sena contare che il processo deve essere iterativo, e con quei 4 punti si spinge per fare un solo “giro” anche se fatto bene
  • “facilmente trovabile dai motori”, non è misurabile, non da indicazioni, ha poco senso, o si danno consigli pratici o citare la cosa non ha effetto
  • il linguaggio della PA è sempre un punto critico, e l’indicazione è poco incisiva; viene smarcata la questione un po’ troppo semplicemente. Le PA scrivono in legalese, l’utente non capisce, esiste letteratura vecchia di decenni a cui rimandare per approfondimenti o per conformarsi;
1 Mi Piace