Specifiche web: descrivono gli usi anziché le schermate

Gestione progetto digitale · 6 lettura min

Un'utile specifica web descrive chi dovrebbe fare cosa, in quale situazione e con quale risultato atteso. Gli schermi vengono dopo, per tradurre questi usi. Per una piccola azienda, questo approccio consente soprattutto di confrontare proposte su un ambito comune e di verificare che il sito consegnato soddisfi le esigenze definite.

Da ricordare

• Inizia con attività effettive, non con un elenco di funzionalità desiderate.
• Associare ciascun utilizzo prioritario a criteri di convalida osservabili.
• Specificare le eccezioni, i dati richiesti e chi decide.
• Conservare i modelli come supporto alla discussione, senza farli sostituire ai requisiti.

Partire dalle attività che il sito deve consentire

"Aggiungi un'area cliente" descrive una soluzione. "Consentire a un acquirente di trovare un documento relativo al proprio ordine" descrive un'esigenza. La distinzione è importante: la seconda affermazione permette di discutere le possibili soluzioni e i loro vincoli, mentre la prima impone già una forma.

Il Manuale di servizio GOV.UK consiglia di descrivere il problema dell'utente e di trattare i suggerimenti dei non utenti come ipotesi da verificare. Questo metodo, pensato per i servizi pubblici britannici, può anche orientare le specifiche aziendali.

Raccogli situazioni, non solo opinioni

Esaminare le richieste ricevute dal supporto, le domande aziendali e le difficoltà segnalate dal team. Chiedi di spiegare un compito recente: qual è stato il punto di partenza, quali informazioni mancavano, come ha ottenuto la risposta la persona? Distinguere tra osservazioni documentate e ipotesi. Un desiderio del manager può restare rilevante, ma deve apparire come una scelta da discutere.

Non dimenticare gli utenti interni. Preparare un ordine, correggere una scheda prodotto o inviare una richiesta alla persona giusta rientra negli utilizzi da descrivere, anche se tali azioni non sono visibili sul sito.

Scrivere un foglio di utilizzo verificabile

Per ogni attività prioritaria, indicare il profilo interessato, l'innesco, l'azione desiderata e il suo obiettivo. Aggiungi le informazioni necessarie, il risultato atteso e le condizioni speciali. Il Documentazione GOV.UK sulle storie degli utenti propone questo quadro e definisce i criteri di accettazione come risultati per verificare che il bisogno sia soddisfatto.

Definisci cosa ti consentirà di accettare la consegna

Evitare "il modulo deve funzionare". Specifica cosa succede quando viene inviata, cosa vede il visitatore, dove arriva la richiesta e come viene segnalato un errore. I criteri descrivono il comportamento atteso, senza imporre inutilmente estensioni o tecnologie.

Assegnare una priorità ad ogni utilizzo: essenziale per l'apertura, utile ma differibile o fuori ambito. Se tutto è essenziale, chiedi quale compito può effettivamente attendere. Notare anche le dipendenze: dati di prodotto, accesso al software o convalida aziendale possono condizionare l'implementazione.

Esempio illustrativo: richiedere un preventivo utilizzabile

Questo esempio è fittizio. Un'azienda di forniture professionali desidera ricevere richieste di preventivo per apparecchiature configurabili. Il suo primo documento menziona solo “una pagina di preventivo con modulo”.

Una formulazione focalizzata sull'utilizzo sarebbe: “Come responsabile acquisti, voglio trasmettere le caratteristiche dell'attrezzatura ricercata in modo che l'azienda possa studiare la mia richiesta senza farmi reinserire tutto. »

I criteri di convalida potrebbero essere i seguenti:

• Il richiedente identifica le informazioni essenziali prima dell'invio.
• Le informazioni mancanti vengono segnalate senza eliminare i campi già compilati.
• Dopo un invio riuscito, una conferma spiega l'ulteriore elaborazione.
• La richiesta arriva alla persona designata con le sue informazioni strutturate.
• Il team è in grado di distinguere una nuova richiesta da una richiesta già supportata.

Un mockup può quindi mostrare i campi e la conferma. Non dimostra, di per sé, che la richiesta stia arrivando o che la squadra sappia come gestirla.

Inserisci i vincoli e apri le decisioni

Aggiungere i vincoli che modificano la possibile risposta: consultazione mobile, documenti da allegare, software destinatario, diritti dei dipendenti, contenuti disponibili. Per i dati personali, l' La CNIL ricorda il principio di minimizzazione : la raccolta deve essere adeguata, pertinente e necessaria al suo scopo. Quindi giustifica ogni campo invece di ripetere un modulo per abitudine.

Separare i requisiti confermati dai punti da arbitrare. Ogni domanda aperta dovrà avere un responsabile e una scadenza di decisione compatibile con il progetto. Se l'ambito cambia, registrare la modifica, la sua ragione e le sue conseguenze sull'implementazione prima di accettarla.

Lista di controllo prima di trasmettere le specifiche

• Vengono identificati i profili interessati e le loro principali mansioni.
• I bisogni osservati vengono distinti dalle ipotesi.
• Gli usi essenziali hanno criteri di accettazione.
• Vengono descritti errori e situazioni speciali.
• Dati, contenuti e dipendenze hanno una persona responsabile.
• L'ambito escluso viene scritto, non lasciato implicito.
• Viene designata la persona che convalida ogni utilizzo.

Limitazioni ed errori comuni

Un documento dettagliato non esenta dal discutere gli usi con le persone interessate. Può persino congelare un’ipotesi sbagliata se nessuno la controlla. Altri errori: copiare il sito di un concorrente senza capirne il funzionamento, confondere preferenza grafica ed esigenza di business, oppure aggiungere funzionalità senza modificare i criteri di ricezione. Includere i vincoli visivi già noti, come la carta grafica o la leggibilità prevista, per poi affinare le scelte in fase di progettazione. Descrivere gli usi non significa escludere dalle specifiche i requisiti di accessibilità, sicurezza, prestazione o manutenzione. Rendi esplicite anche le modifiche all'ambito.

Domande frequenti

Dobbiamo eliminare l'elenco delle pagine?

No. Serve per comprendere l'organizzazione dei contenuti. Collega semplicemente ciascuna pagina ai compiti che facilita, anziché trattarla come un requisito sufficiente.

Dovremmo già scegliere una tecnologia?

Solo se un vincolo reale lo impone. Altrimenti, descrivi gli usi e le interfacce necessarie, quindi chiedi al fornitore di servizi di giustificare la sua scelta tecnica.

Chi deve convalidare i criteri?

La persona che conosce il compito aziendale, con il team che effettuerà i test. Il manager arbitra le priorità, ma non deve indovinare da solo il funzionamento quotidiano.

Passaggio successivo: descrivere un'attività essenziale

Scegli un utilizzo senza il quale il sito non fornirebbe il servizio previsto. Scrivi il modulo, le sue eccezioni e i suoi criteri, poi fallo rileggere da chi oggi svolge questo compito. Per situare quest'opera a supporto, consultare il servizi web di 4SYSTEM.

Fonti e risorse

• GOV.UK: comprendere gli utenti e le loro esigenze.
• GOV.UK: scrittura delle storie degli utenti e criteri di accettazione.
• CNIL: minimizzare i dati raccolti.