Definire decisioni, non solo una galleria di stili
Un design system è più di screenshot. Registra decisioni ricorrenti: la spaziatura tra sezioni, il trattamento dell'azione primaria, come funziona un errore di modulo e il linguaggio usato dopo un successo o un fallimento. USWDS descrive i design token come palette discrete per valori quali tipografia, spaziatura, colore, interlinea e opacità. Documenta la regola, lo scopo, le varianti approvate e il proprietario. Inizia con le fondamenta e i cinque-otto componenti usati più spesso nei percorsi importanti; standardizzare ogni pagina in una volta di solito crea rumore anziché chiarezza.
Registra i ruoli colore approvati, i font, le spaziature, i bordi, i raggi, i breakpoint e le scelte di motion che il tuo sito usa effettivamente.
Usa un pattern per un arrangiamento di compiti ripetibile, come la creazione account o i risultati di ricerca, invece che per un singolo effetto visivo.
Usare i token per controllare i valori ripetuti
Un design token è un nome leggibile associato a un valore. Il Design Tokens Community Group descrive i token come un modo indipendente dalla piattaforma per esprimere decisioni di design; come minimo, un token è un nome e un valore. Usa nomi di scopo come color-action-primary o space-section invece di disperdere valori grezzi nei template. Mantieni una mappatura documentata dai token di scopo ai valori base. I token rendono più facili le modifiche coordinate, ma non garantiscono contrasto, branding o una buona gerarchia. Valida ogni combinazione renderizzata e stato della pagina.
Crea token per scelte ripetute, non per ogni eccezione; altrimenti la lista di token conserva semplicemente l'incoerenza.
Per un token usato diffusamente, elenca le pagine interessate, testa schermate rappresentative e fornisci indicazioni di migrazione o rollback quando necessario.
Costruire componenti con comportamento e confini
Un componente è una parte dell'interfaccia riutilizzabile con comportamento, non solo una forma visiva. Documenta la struttura semantica, gli input obbligatori e opzionali, le varianti, il comportamento responsive e tutti gli stati rilevanti: loading, disabled, error, empty e success. Includi il comportamento da tastiera e le linee guida sul contenuto. Non forzare ogni layout in un componente. GOV.UK valuta i componenti condivisi per utilità, unicità, usabilità, coerenza e versatilità; è una disciplina utile per decidere cosa merita manutenzione condivisa. Un componente ampiamente riutilizzato può diffondere un difetto su larga scala, quindi testalo nelle pagine dove le persone lo usano.
Elenca ogni stato visibile all'utente e mostra etichette reali, testi lunghi ed errori in modo che i limiti di implementazione siano evidenti.
Segna chiaramente le varianti vecchie, indica la sostituzione e rimuovile solo dopo che i percorsi interessati sono stati revisionati.
Rendere l'accessibilità una condizione di rilascio
L'accessibilità deve essere integrata nel sistema perché le scelte ripetute possono ripetere barriere. WCAG 2.2 richiede, al livello A, l'operabilità tramite tastiera per le funzionalità salvo dove il percorso di movimento è intrinseco, e richiede un ordine di focus significativo quando la sequenza conta. Rendi parte delle linee guida dei componenti controlli semantici, focus visibile, etichette, movimento logico del focus, identificazione degli errori e completamento di attività senza puntatore. Usa controlli automatici precocemente, poi test manuali con tastiera, zoom, responsive e test di pagina. USWDS avverte che componenti accessibili non garantiscono un servizio accessibile; codice personalizzato, copia, integrazioni e contesto richiedono comunque revisione.
Conferma che le persone possono raggiungere, usare, comprendere e lasciare i controlli senza mouse o senza rimanere intrappolate nel focus.
I doveri legali variano per giurisdizione e contratto. Cerca una revisione qualificata in ambito accessibilità e legale quando la conformità è rilevante.
Trattare gli standard di contenuto come standard d'interfaccia
Le parole sono input dei componenti, non decorazioni aggiunte dopo il design. Stabilisci regole per etichette d'azione, etichette di modulo, messaggi di errore, titoli, link, terminologia, date, numeri e abbreviazioni. La guida GOV.UK favorisce la voce attiva e l'uso del tu quando possibile; applica il principio di linguaggio chiaro e coerente, adattando la voce al tuo pubblico. Abbina le regole a un modello di contenuto: indica quali campi sono obbligatori, suggerimenti sensati sulle lunghezze e cosa succede quando l'informazione manca. Metti le linee guida nei documenti dei componenti e nei flussi CMS, dove gli editor possono usarle.
Indica cosa è fallito, dove è successo e la prossima azione quando è sicuro e utile farlo.
Un limite è un segnale per riprogettare o riscrivere, non il permesso di rimuovere significato essenziale.
Governa il sistema prima che cresca più in fretta della fiducia
La governance è il processo leggero per proprietà, richieste, revisioni, rilasci e ritiro. Nomina un proprietario responsabile e un gruppo di revisione che porti competenze di design, engineering, contenuto e accessibilità. Abbina le prove al raggio d'azione. Un pattern locale può richiedere una dichiarazione del problema e un test di pagina. Un cambiamento condiviso di un pulsante o di un token dovrebbe includere i percorsi interessati, i controlli di accessibilità, il confronto visivo, le note di migrazione e le istruzioni di rollback. GOV.UK chiede ai contributori di dimostrare che un componente è utile per molti team, non duplicato, e testato con utenti rappresentativi; usa questo come modello pratico piuttosto che regola universale.
Salva il problema, le opzioni, la decisione, il proprietario, la versione interessata e la data di revisione dove i team possano cercarlo.
Etichetta i cambi come patch, aggiuntivi o breaking in modo che i consumatori sappiano quando sono necessarie migrazione e un periodo di compatibilità.
Prevenire regressioni prima del rilascio
Collega il sistema alla delivery. Richiedi che una modifica identifichi i token e i componenti toccati, poi testa gli stati interessati e le pagine rappresentative. Confronto visivo, test di interazione, revisione dei contenuti e controlli di accessibilità trovano difetti diversi. Dai priorità ai percorsi ad alta conseguenza oltre che a quelli ad alto traffico; accesso account e moduli di contatto possono essere importanti anche con traffico modesto. Questo supporta il lavoro proattivo di ottimizzazione dell'uptime e di rimedio di Status Is UP restringendo l'ambito del difetto e rendendo una correzione approvata più facile da verificare. Non è monitoraggio di downtime né sostituisce un piano di incidenti.
Conserva la versione del componente, i risultati dei test, i riscontri, le approvazioni e ogni rischio accettato con il record di rilascio.
Preserva la versione stabile precedente e testa le operazioni di ripristino e i passaggi di verifica durante la manutenzione a basso rischio.