Smashing Podcast Episodio 7 con Amy Hupe: che cos'è un sistema di progettazione del governo?

Ti sei mai chiesto come vengono utilizzati i sistemi di progettazione all'interno di un governo? Inoltre, se volessi documentare un sistema di progettazione nel miglior modo possibile, come lo faresti? Ho parlato con l'avvocato di Design Systems, Amy Hupe, che condivide i suoi consigli e le lezioni apprese.

Mostra note

• Il sistema di progettazione GOV.UK
• Segui Amy su Twitter
• Il sito di Amy

Aggiornamento settimanale

• "Capire la griglia CSS: creare un contenitore di griglia", di Rachel Andrew
• "Elenco di controllo delle prestazioni front-end 2020", di Vitaly Friedman
• "Perché dovresti scegliere HTML5 <articolo> su <sezione>", di Bruce Lawson
• "La personalità divisa dello sviluppo web brutalista", di Frederick O'Brien
• "Come creare e distribuire un'applicazione materiale angolare", di Shubham

Trascrizione

Drew McLellan: è una specialista dei contenuti e una sostenitrice dei sistemi di progettazione che ha trascorso gli ultimi tre anni lavorando come designer di contenuti senior presso il Government Digital Service. In quel periodo, ha guidato la strategia dei contenuti per il sistema di progettazione GOV.UK, incluso un approccio diretto e inclusivo alla documentazione. In precedenza ha lavorato per un'azienda di difesa dei consumatori, quale? dove ha scritto di tutto, dal compostaggio al trasporto. E un nuovo ruolo per il 2020 la vede assumere come Project Manager per Babylon Health Design System, DNA.

Drew: È una cuoca esperta, una instagrammer e sa come usare il linguaggio per rendere i servizi accessibili e inclusivi. Ma lo sapevi che una volta ha cantato come cori per Billy Ray Cyrus? Miei formidabili amici, vi prego di dare il benvenuto ad Amy Hupe. Ciao Amy. Come stai?

Amy Hupe: Sto distruggendo. Grazie.

Drew: Quindi oggi volevo parlarti del ruolo dei sistemi di progettazione all'interno delle organizzazioni governative in generale, ma in particolare del sistema di progettazione GOV.UK, con cui so che hai lavorato molto. Immagino prima di tutto, cosa comprende il sistema di progettazione GOV.UK? E qual è stato il tuo coinvolgimento mentre eri alla GDS?

Amy: Quindi comprende tutti i tipi di cose. Quindi penso che la rappresentazione più ovvia sia il tipo di lato del sito Web, che è GOV.UK/design-system. E lì troverai tutto il tipo di documentazione. Quindi tutte le linee guida di progettazione, i componenti e i modelli, e vedrai parte del codice, molti esempi e molti consigli su come usarlo. Ma pensando in modo più ampio, comprende anche cose come il kit di prototipi, che è uno strumento di prototipazione utilizzato dal governo per creare prototipi HTML e CSS. Quindi prototipi ad alta fedeltà e ha anche un proprio tipo di framework front-end, chiamato GOV.UK Front End. Quindi questo è tutto il codice che usano per creare i servizi.

Amy: Ma poi mi piace pensare ai sistemi di progettazione in modo più olistico. Quindi, oltre a tutte quelle cose, ci sono anche tutti i processi che le circondano. Quindi cose come il modo in cui le persone contribuiscono ad esso e come le persone vengono a sapere che esiste. Cose come l'adozione, la consapevolezza e tutto quel genere di cose. Quindi tutte le cose che consentono alle persone di progettare e costruire servizi nel governo è come lo definirei.

Drew: Allora, qual è stato il tuo coinvolgimento mentre eri alla GDS con quello? Dove ti sei inserito in quel sistema?

Amy: È successo tutto per caso, credo. Quindi mi sono unito come designer di contenuti a gennaio 2017 e la mia intenzione quando sono arrivato in GDS era in realtà di entrare a far parte dei team di contenuti di Gov UK. Quindi ho pensato di iniziare a scrivere una guida per il sistema, e quello era il mio sogno. Era quello che volevo fare. Poi sono arrivato il primo giorno e sono stato inserito in questo piccolo team di protezione, chiamato team di modelli e strumenti del manuale di servizio.

Amy: A quel punto il sistema di progettazione non esisteva, ma avevamo i nostri modelli di progettazione e alcuni frammenti che giravano in luoghi diversi. C'era l'ambizione di provare a mettere insieme queste cose. Quindi sono stato inserito in quel team come designer di contenuti. Non sapevo cosa fosse un design pattern, non sapevo nulla di codice, non sapevo assolutamente nulla di web design. Tutto quello che sapevo veramente era contento.

Amy: Quindi è stata una curva di apprendimento piuttosto ripida e ho trascorso i successivi sei mesi o un anno, credo, aiutando il team a creare prototipi e capire come sarebbe stato organizzato e strutturato e come avremmo scritto la nostra guida, e tutto quel genere di cose. Poi, in mezzo a tutto questo, oltre a lavorare sul contenuto, ho anche iniziato a esaminare il lato dei contributi. Quindi come le persone contribuirebbero ad esso e come le persone verrebbero a scoprirlo e, a mettersi in contatto con noi, e cosa faremmo quando si mettessero in contatto con noi per cercare di renderlo migliore.

Drew: Allora, cosa implica la progettazione di contenuti in quel tipo di contesto? Che tipo di attività quotidiane stavi affrontando?

Amy: Quindi davvero ogni genere di cose. Voglio dire, ci sono state settimane alla volta in cui non ho scritto una sola parola ed è stato più solo uscire per fare ricerche e incontrare i nostri utenti e cercare di capire cosa volevano da un sistema di progettazione. Quindi sì, senza entrare troppo nel dettaglio, ci sono stati tentativi di creare qualcosa come il sistema di progettazione GOV.UK prima, ed è così che siamo finiti con questo tipo di insieme di risorse leggermente disparate.

Amy: Per una ragione o per l'altra, queste cose sono finite piuttosto sparpagliate, e non è mai stato visto come il posto centrale dove andare per questa roba. Quindi molto, stava solo cercando di capire cosa era successo prima e perché quelle cose non erano necessariamente decollate nel modo in cui speravamo. Cercando di capire quali frammenti del nostro panorama esistente funzionassero per le persone e quali no.

Amy: Quindi molto è stato uscire con la nostra ricerca [non udibile 00:05:07], partecipare a interviste di ricerca degli utenti, prendere appunti e parlare con le persone, e semplicemente capire di cosa avevano bisogno. Poi ci sono stati giorni in cui mi sono seduto alla tastiera e ho scritto alcune indicazioni su alcune cose, il che è stato anche bello. Ma sì, per me è stato molto diverso. Come hai menzionato nell'introduzione, il mio background era lavorare in Quale? Quindi era molto più un ruolo editoriale tradizionale ed ero abituato a lavorare su contenuti di lunga durata ea scrivere solo articoli e pezzi davvero lunghi. Quindi sì, è stato un grande cambiamento. È stato un grande salto da quello.

Drew: Quindi i tuoi utenti in questo contesto sono persone che lavorano in diverse organizzazioni governative? È giusto? Diversi dipartimenti all'interno del governo?

Amy: Sì. Si, è esatto. Quindi le persone che lavorano, penso che ci siano 25 diversi dipartimenti ministeriali nel governo, e poi ci sono anche molte agenzie e dipartimenti del governo locale. Quindi stavamo cercando di allargarci e parlare con una vasta gamma di persone provenienti da tutto il servizio civile. Quindi sì, molti viaggi in quei primi giorni.

Drew: Pensi che progettare o lavorare su un sistema di progettazione per un governo, in sostanza, sia diverso da un sistema di progettazione per una piccola azienda o un grande tipo di impresa?

Amy: Penso di sì. Voglio dire, penso da quello che posso raccogliere dalle conversazioni che ho avuto, dalle conferenze a cui sono stato e cose del genere, ogni sistema di progettazione è leggermente diverso e il contesto è sempre leggermente diverso, e il governo non è diverso sotto questo aspetto . Ma sì, suppongo che alcune delle sfide uniche nel lavorare su qualcosa per il governo, siano prima di tutto la sua portata. Quindi il pubblico è probabilmente il più grande che potresti avere perché il governo è così grande e tutti i diversi tipi di dipartimenti e la diffusione geografica di quelle organizzazioni. Quindi la sua scala è sicuramente qualcosa di leggermente diverso.

Amy: Penso anche al fatto che non sia commercialmente competitivo. Quindi non stavamo cercando di tenere tutto nascosto. Tutto è stato fatto all'aperto, per quanto possibile. Sì, è tutto gestito come un grande progetto open source, il che era un concetto un po' insolito per me. Mi ci è voluto un po' per abituarmi.

Amy: Certamente quando l'abbiamo rilasciato per la prima volta, avremmo visto alcune delle nostre linee guida e del codice spuntare nei sistemi di progettazione di altre persone. Mi ci è voluto un po' per sentirmi bene. Penso che all'inizio pensassi: "Cosa sta succedendo? Perché queste persone prendono le nostre cose?" Ma in realtà ora, mi piace molto. Lo vedo come un grande complimento e penso che sia davvero bello riutilizzare ciò che puoi. Ma sì, è uno strano tipo di mondo in cui entrare quando sei abituato a lavorare in un ambiente più commerciale, immagino.

Drew: Suppongo che il fatto che sia un sistema essenzialmente finanziato con fondi pubblici, significhi che è particolarmente adatto al pubblico che lo prende e lo utilizza, ma anche in tutto il mondo hai visto molto uso al di fuori del Regno Unito?

Amy: Sì, sì, ci sono stati alcuni progetti davvero eccitanti in tutto il mondo che l'hanno raccolto. Quindi so che il governo della Nuova Zelanda ne ha usato parecchio. Non sono sicuro di quale sia lo stadio in cui si trovano al momento, ma sicuramente ho visto il loro primo sistema di progettazione dei dati e hanno davvero utilizzato gran parte della nostra guida e del nostro codice, dei nostri layout e altro. Penso che anche il governo olandese stia utilizzando il sistema di progettazione GOV.UK principalmente come prima prova di concetto. Il governo australiano ha iniziato con tutte le nostre linee guida sui contributi e le ha adattate in base alla loro ricerca. Quindi siamo stati in grado di riprendere alcune di quelle cose. Sì, quindi è diventato piuttosto globale. È eccitante.

Drew: Prenderesti in considerazione il fatto che le persone lo userebbero quando prendono decisioni sul tipo di fase successiva delle cose? Incorporerebbe nelle tue decisioni il fatto che in realtà il tuo pubblico improvvisamente non è solo il governo del Regno Unito, ma potrebbe potenzialmente essere un pubblico mondiale?

Amy: È sicuramente una considerazione e penso che a volte ci abbia reso come una squadra piuttosto nervosi per alcune cose che stavamo facendo perché il nostro pubblico e la portata di tutto ciò sono diventati improvvisamente molto più grandi quando stavamo pensando a tutte le diverse persone che lo stavano usando. Ma personalmente penso che non puoi essere troppo preso dal fatto che principalmente siamo lì per servire il governo del Regno Unito. Quindi non è pratico considerare tutto il pubblico potenziale per questo. In un certo senso penso che spetti ai team adattarlo come è necessario per i propri utenti. Ma sì, sicuramente ti fa pensare abbastanza attentamente a buttare le cose là fuori prima che siano pronte e testate e cose del genere.

Drew: Quindi ci sono state altre sorprese nel lavorare su questo sistema di progettazione oltre al fatto che è stato poi preso e utilizzato in modo più ampio di quanto ti aspettassi inizialmente? È saltato fuori qualcos'altro che ti ha sorpreso?

Amy: Una cosa che sicuramente mi ha colpito è stata la gamma di persone nel nostro pubblico. Quindi non solo la dimensione del pubblico, ma come la variazione del livello di conoscenza delle persone, le loro capacità, la loro fiducia, i diversi tipi di lavoro che hanno svolto e il tipo di contesto in cui stavano lavorando. Penso che ci siano sicuramente molte variazioni. Penso che la mia percezione fosse quella di avere in testa questa visione di questo come uno sviluppatore front-end di design, qualcuno che ha molte conoscenze tecniche e in realtà è solo un tipo di utente. Ci sono molte altre persone come i designer di contenuti e le cose non erano necessariamente un pubblico previsto per questo, ma si sono rivelate utenti chiave.

Amy: Quindi penso, sì, quella è stata sicuramente una sorpresa per me. Quindi pensare a come potremmo soddisfare tutte quelle persone con una serie così ampia di esigenze con il sistema di progettazione è stata sicuramente una grande sfida. Sì, penso che sia stata probabilmente la mia più grande sorpresa. Quindi immagino che oltre a quanto le persone abbiano visto adottarlo come proprio. Quindi penso che dopo aver lanciato abbastanza rapidamente, sono rimasto davvero piacevolmente sorpreso da quante persone avrei visto uscire a sostenerlo all'interno dei propri dipartimenti e team e persone che cercavano di contribuire e persone che si mettevano in contatto con noi per chiederci come potrebbero adattarlo ai propri utenti. Mi è sembrato davvero di proprietà della comunità sin dal primo giorno e non era necessariamente qualcosa che mi aspettavo, ma qualcosa che era pronto davvero bello da vedere.

Drew: Immagino che gran parte del ruolo di un sistema di progettazione sia come una sorta di documentazione delle decisioni di progettazione che sono state prese in modo che tali decisioni possano essere poi implementate, comprese e utilizzate dalle persone. Quindi immagino che un sistema di progettazione sia più che altro, un artefatto di documentazione, non è vero? Sta prendendo quelle decisioni che sono state prese e spiegandole in un modo che le persone possano riutilizzarle. Come ti sei avvicinato come team che progettano il sistema come una sorta di artefatto di documentazione? Come hai documentato quello che stavi facendo?

Amy: Quindi penso che si trattasse di ottenere quanto più possibile in un quadro molto chiaro di ciò di cui le persone avevano bisogno da quella documentazione. Quindi questo torna al punto in cui ho fatto in modo che fosse un pubblico piuttosto ampio perché c'è un'intera gamma di esigenze diverse di cui le persone parlano di documentare un componente o uno schema come se fosse una specie di compito singolo. Ma in realtà ci sono molti modi diversi in cui puoi farlo e ci sono un sacco di esigenze diverse che devi prendere in considerazione. Quindi abbiamo persone che, ad esempio, direbbero semplicemente: "Oh, voglio vedere la ricerca dietro questo". Per alcune persone significa un numero. Vogliono sapere che viene utilizzato in 20 diversi servizi in modo da poter dire al loro product manager che vale la pena investire tempo e denaro per implementarlo all'interno del loro servizio.

Amy: E per loro si tratta solo di ottenere quel supporto basato sull'evidenza per la decisione che stanno cercando di portare avanti. Ma poi ci sono altre persone che si preoccupano davvero di comprendere la ricerca e se è appropriata per il loro contesto e quali ricerche aggiuntive potrebbero aver bisogno di colmare per colmare eventuali lacune che sono state perse o che forse stanno affrontando nella loro situazione unica. Quindi penso che l'approccio fosse cercare di capire tutte queste diverse esigenze e cercare di ottenere un senso di priorità tra queste e capire come potevamo soddisfare tutte le diverse esigenze che le persone avevano dalla documentazione. Non è solo un tipo di cosa che si adatta a tutti.

Amy: Quindi capire come affrontare tutte queste esigenze e segnalare il contenuto molto bene in un modo che significasse che le persone potevano saltare anche i bit che non erano rilevanti per loro. Perché quando cerchi di servire un pubblico così ampio, ovviamente finisci per fornire molte informazioni. Quindi assicurarmi che sia davvero ben segnalato e organizzato, penso sia stato fondamentale per quello che stavamo facendo.

Drew: Quindi ho ragione nel capire che i diversi dipartimenti all'interno del governo non sono effettivamente obbligati ad adottare il sistema di progettazione? Devi davvero venderglielo in modo efficace e convincerli a usarlo?

Amy: Sì, quindi è un po' complicato. Quindi nel governo c'è qualcosa chiamato standard dei servizi governativi ed è uno standard che tutti i servizi governativi con più di un certo numero di utenti devono soddisfare per ottenere finanziamenti e poi passare ad Alpha e poi Beta e poi live. Uno dei punti dello standard di servizio, me ne sono andato tre settimane fa ed è già uscito dalla mia testa a quale numero è, ma uno dei punti dello standard di servizio, parla del riutilizzo di schemi e componenti e del tentativo di riutilizzare ciò che è già lì. Quindi più o meno sotto quel punto sono obbligati a usarlo, ma è sciolto e dipende da chi è l'assessore. Non è una specie di pesante mandato. Tutti noi sosteniamo sempre di fare ciò che è meglio nel contesto specifico piuttosto che semplicemente riutilizzare schemi fuori dagli schemi per il gusto di spuntare un punto su una valutazione del servizio. Quindi è difficile forzarlo. Quindi l'approccio è sempre stato molto più collaborativo e si è sempre concentrato sulla creazione di supporto e sulla promozione del sistema di progettazione senza spingerlo in gola alle persone.

Drew: Credo che a tal fine, uno dei modi in cui sei riuscito a farlo è incoraggiare il contributo. È giusto?

Amy: Sì, decisamente. Quindi sono un grande fan del contributo alla progettazione di sistemi. Penso che sia qualcosa di davvero interessante e sì, sicuramente nel team abbiamo lavorato molto per rendere possibile il contributo al sistema di progettazione GOV.UK. Uno dei veri vantaggi che abbiamo visto è stato l'aumento dei sostenitori della rete per il sistema di progettazione. Quindi, quando chiedi a qualcuno di contribuire e poi si sente un po' più coinvolto in esso e in ciò che abbiamo ricevuto, quelle persone si rivolgerebbero ai loro team e diventerebbero i nostri migliori venditori quasi perché si sentirebbero come se l'avessero fatto un piccolo pezzo di esso e avevano qualcosa da mostrare alla gente e avrebbero quindi incoraggiato più persone a contribuire. Quindi quell'effetto finisce per essere abbastanza esponenziale. Sì. Quindi ci siamo impegnati molto per renderlo possibile.

Drew: Che tipo di cose hai fatto per incoraggiare il contributo?

Amy: Abbiamo iniziato molto presto. Quindi, molto prima di avere un sistema di progettazione pubblico, abbiamo iniziato a interagire con persone che pensavamo potessero essere contributori interessati. Dovrei menzionare qui, abbiamo avuto un brillante progettista di servizi nel team. Si è unita a noi, al momento non ho intenzione di ottenere le date corrette in alcun modo, ma penso che abbia lavorato con noi per tutto il 2018 e si chiami Ignatia e ha fatto un lavoro fantastico andando in giro e coinvolgere le persone. Quindi una delle cose che ha fatto è stata identificare tutti i diversi modelli di governo e tutte le diverse variazioni di quei modelli. Quindi uscire e dire, ok, ci sono 10 modi diversi per chiedere un indirizzo al governo. Diamo un'occhiata a tutti insieme e decidiamo quale riteniamo sia l'approccio più appropriato.

Amy: Come possiamo consolidarli in uno? Ha condotto un grande seminario per cercare di convincere le persone a guardarli e fare quel tipo di consolidamento come squadra. Penso che sicuramente il suo approccio alla costruzione della collaborazione in un modo molto prima che rilasciassimo qualcosa al pubblico abbia davvero aiutato in questo perché significava che le persone ne avevano già quel tipo di consapevolezza e molte persone avevano già contribuito in un modo o nell'altro prima di noi in realtà lo ha reso pubblico. Quindi mettici qualche passo avanti. Quindi penso che fosse davvero importante. E solo persistenza, come molta persistenza da parte dell'intero team nell'aiutare le persone a contribuire. Penso che ci sia un'idea per cui se fai in modo che le persone contribuiscano a un sistema di progettazione è un concerto piuttosto carino perché puoi semplicemente convincere le persone a fare tutto il lavoro per te.

Amy: E ti siedi lì e apporti le correzioni al codice di livello e tutti ti stanno davvero dando tutte le cose buone. Ma in realtà, come saprà chiunque abbia lavorato su un sistema di progettazione, è incredibilmente complesso. È molto difficile creare una soluzione centralizzata che funzioni per più team diversi e, a meno che tu non abbia lavorato su un sistema di progettazione, non è ragionevole aspettarsi che qualcuno capisca davvero cosa ci vuole. Quindi c'è molto da tenere per mano. C'è molto lavoro coinvolto nel supportare i contributori a contribuire, penso di averlo detto prima, ma probabilmente ci vuole più tempo, penso, per aiutare qualcuno a contribuire a un sistema di progettazione, quindi sarebbe solo fare la cosa da soli nel team centralizzato . Ma penso che riconoscere il valore che porta ed essere persistenti nei tuoi sforzi per rendere le persone consapevoli del contributo e aiutarle a farlo, li aiuti a sentirsi in qualche modo motivati ​​a farlo. Penso, sì, che quella persistenza sia stata davvero una sorta di chiave del nostro successo in quell'area.

Drew: E parlando in pratica con la gestione di quei contributi dalla comunità, c'erano strumenti o processi o qualcosa che aiutava in questo?

Amy: Sì, quindi abbiamo avuto un processo piuttosto rigoroso, direi. Rigoroso nella misura in cui forse, severo è la parola sbagliata, completo è probabilmente una parola migliore. Quindi sì, abbiamo una serie di criteri di contribuzione che sono nel sistema di progettazione. Quindi tutto è il più aperto possibile in modo che le persone sappiano cosa aspettarsi. Quindi c'è una serie di criteri che abbiamo sviluppato con le varie persone della comunità governativa al di fuori del nostro team, quindi ancora una volta, come cercare di coinvolgere le persone nella creazione di questi processi, penso sia davvero importante. Quindi c'è una serie di criteri che tutti i contributi al sistema di progettazione devono soddisfare e per assicurarci che fossimo abbastanza imparziali, suppongo, ed equi in termini di decisioni sul fatto che le cose soddisfassero o meno quei criteri, abbiamo arruolato il sostegno di un gruppo di lavoro, che era un gruppo di rappresentanti di tutto il governo. Tutti provenienti da dipartimenti diversi e discipline diverse e persone con diversi livelli di anzianità.

Amy: Quindi tutti avrebbero una prospettiva leggermente diversa sui contributi e ci riunivamo con loro una volta al mese e chiedevamo loro di rivedere eventuali nuovi contributi e decidere se avevano soddisfatto o meno i criteri. Quindi sì, è stato una sorta di processo progettato per cercare di democratizzare il design del sistema di progettazione, suppongo, e per renderlo rappresentativo e garantire che non fosse solo il nostro team seduto nel mezzo a prendere tutte le decisioni senza capire davvero come influenzerebbe le squadre che usano quelle cose.

Amy: Sì, quello era il nostro tipo di processo. Un altro post che dovrei menzionare è che c'è un arretrato della comunità su GitHub, che chiunque può usarlo. Non devi lavorare nel governo per andare a vederlo. È accessibile dal sistema di progettazione ed è fondamentalmente un luogo in cui cerchiamo di ospitare tutta la ricerca e tutto il materiale sperimentale e gli esempi che entrano nei loro componenti e modelli nel sistema di progettazione. Quindi, ancora una volta, si tratta di spingere per quella trasparenza e lavorare all'aperto il più possibile in modo che le persone possano avere voce e influenzare le cose prima che siano effettivamente pubblicate.

Drew: E pensi che il processo abbia funzionato bene? Se dovessi intraprendere di nuovo la stessa cosa, pensi che adotteresti un processo simile o c'è qualcosa che non ha funzionato?

Amy: Penso che adotterei un processo simile, ma forse entrerei con aspettative leggermente diverse. Quello che direi sono forse aspettative leggermente più realistiche e dopo aver detto quello che ho detto su come pensiamo che contribuire renderà le cose più facili e veloci. Ero decisamente in quel campo. Penso di aver pensato che all'inizio ci sarebbe stato un picco di lavoro per far familiarizzare le persone con i contributi e poi nel tempo saremmo stati in grado di essere più vicini e le persone avrebbero semplicemente preso il controllo e sarebbe andato tutto bene. Ma in realtà ciò non si è mai realmente materializzato. C'è sempre stato molto lavoro per aiutare le persone a contribuire e, come ho detto, penso che sia prevedibile. Non credo che tu possa davvero farne a meno, ma penso comunque che sia prezioso.

Amy: Penso ancora che valga la pena investire quel tempo, ma forse non con l'idea che accelererai le cose o che sarai in grado di scalare più velocemente o di più dall'avere un contributo. Quindi sì, penso che il processo abbia funzionato bene. Penso che debba essere adattato a diverse organizzazioni, quindi lunedì inizierò un nuovo ruolo abbastanza divertente, sto lavorando su un altro sistema di progettazione e non mi aspetto di essere in grado di riprendere quel processo e spostarmi è laggiù. Penso che tutto debba essere adattato all'organizzazione e al contesto con cui hai a che fare, ma ci sono sicuramente degli elementi che vorrei provare a portare. Ma sì, con aspettative leggermente mitigate, credo.

Drew: Ho parlato un paio di episodi fa con Hayden Pickering della progettazione di componenti, in particolare all'interno di un sistema di progettazione che deve essere accessibile. È qualcosa con cui hai anche molta esperienza, credo. Ovviamente l'accessibilità è davvero, davvero cruciale quando si lavora all'interno di un sistema di progettazione governativo, ma molti di noi sosterrebbero che è davvero, davvero cruciale ovunque si lavori. Pensi che i sistemi di progettazione svolgano un ruolo nell'accessibilità di un progetto o nell'attuazione di un progetto?

Amy: Quindi c'è un brillante discorso di Tatiana Mack sulla costruzione di sistemi di design inclusivi che tocca questo e che è stato molto influente per me e parla del tipo di effetto moltiplicativo dei sistemi di design. Quindi, con i sistemi di progettazione, stiamo dicendo alle persone che aspetto ha il bello e stiamo offrendo alle persone modi rapidi per implementare ciò che stiamo dicendo alle persone sono le migliori pratiche. Quindi può funzionare in entrambi i modi. Può funzionare molto bene se dai alle persone un buon design e un buon design accessibile, allora hai il potenziale per moltiplicare quel design accessibile e per rendere le cose più accessibili e più inclusive per impostazione predefinita.

Amy: Se prendi decisioni che escludono le persone in un sistema di design, in quello spazio centralizzato, che diventa il punto di partenza per le persone che progettano servizi, allora hai davvero il potenziale per proliferare quel design esclusivo. Quindi penso decisamente che i sistemi di progettazione svolgano un ruolo nella promozione e nella moltiplicazione dell'accessibilità. Ma penso che tutto inizi con l'intenzione dei team di lavorare e utilizzare il sistema di progettazione per realizzarlo. Un sistema di progettazione è davvero solo il tipo di veicolo suppongo e l'intenzione deve essere presente per rendere le cose accessibili.

Drew: Una delle cose che mi affascina sempre, in particolare con i sistemi di progettazione che hanno un pubblico così ampio e variegato come il sistema di progettazione di GFI UK, è il processo di proliferazione dei cambiamenti nel sistema. Quindi, se, ad esempio, trovi un miglioramento dell'accessibilità che potresti apportare in un determinato modello e lo fai nel sistema di progettazione, come puoi assicurarti che venga implementato in un pubblico così ampio? È qualcosa con cui hai qualche esperienza?

Amy: Sì. Quindi, ancora una volta, penso che nel team del sistema di progettazione GOV.UL abbiamo tenuto in grande considerazione il modo in cui funzionerebbe. Devo essere onesto, molto ha a che fare con il modo in cui è tecnicamente implementato e sicuramente non sono la persona giusta per parlare così tanto dell'aspetto tecnico della squadra. Trovo che ci siano una specie di due campi con i sistemi di progettazione e c'è un campo che è come portare le cose là fuori il più rapidamente possibile. Apriamolo appena possibile e questo fermerà la duplicazione e la moltiplicazione degli sforzi e quindi potremo ripeterlo mentre andiamo avanti. Poi penso che ci sia una sorta di accampamento un po' più lento, in cui penso di trovarmi, che favorisce il trattenimento nel rilasciare materiale finché non hai un certo livello di fiducia in esso.

Amy: E penso che sia abbastanza importante perché penso che in generale, se stai progettando prodotti e servizi, iniziare con la cosa minima e poi ripetere mentre procedi penso che funzioni alla grande, ma penso che quando stai costruendo qualcosa centrale che è progettato per un sacco di persone da riutilizzare e dare a un sacco di pubblico diverso, usi molto rapidamente il controllo dell'oggetto e il modo in cui viene utilizzato. Quindi penso che avere una certa fiducia in qualcosa prima di rilasciarlo e avere una sorta di processo di assicurazione in atto, significa che hai una certa sicurezza che è accessibile prima che esca, è abbastanza chiave e quindi si spera che il la cosa è leggermente più stabile e penso che sia davvero importante per la fiducia. Penso che la fiducia sia abbastanza importante quando si parla di apportare modifiche ai sistemi di progettazione perché se rilasciamo continuamente modifiche, ciò rende il sistema abbastanza instabile da usare e penso che ciò rompa la fiducia e quindi le persone non lo siano. È così probabile che installi aggiornamenti e cose.

Amy: Mentre penso che se riesci a dimostrare che sei attento a ciò che stai rilasciando e stai rilasciando le modifiche solo quando necessario, allora hai quella buona volontà e quindi le persone sono più disposte a fare aggiornamenti e cose che penso. Ma sì, voglio dire, so che molto lavoro è stato fatto per assicurarsi che il processo di aggiornamento fosse abbastanza fluido e facile da implementare nel sistema di progettazione GPV.UK. Non sono la persona giusta per parlarne, credo.

Drew: Quindi abbiamo parlato brevemente della documentazione. Se stavo cercando di documentare un sistema di progettazione e se volevo fare un ottimo lavoro, c'è qualcosa che mi consiglieresti di fare per assicurarmi di documentare bene le cose?

Amy: Non penso mai che sia possibile fare una dichiarazione generale qui perché ha davvero bisogno di soddisfare il pubblico specifico con cui hai a che fare. La mia cosa è puntare sempre ad essere solo un po' più inclusivo di quello che forse senti di dover essere. Quindi, se stai pensando, specialmente in un'organizzazione più piccola, che forse si sta ridimensionando, penso che devi essere altrettanto premuroso del tuo pubblico futuro e del tuo pubblico potenziale come il tuo pubblico attuale. Quindi, se hai una piccola organizzazione e hai 10 sviluppatori front-end e tutti conoscono lo stesso tipo di cose e sono in grado di parlare tra loro e comunicare abbastanza liberamente, allora la tua documentazione potrebbe non essere completa come all'interno dell'organizzazione più ampia.

Amy: Ma penso che per aiutare un sistema di progettazione a scalare e assicurarsi che sia attrezzato per farlo, devi pensare a chi potrebbe entrare a far parte dell'organizzazione in futuro e di chi hai bisogno per lasciare la porta aperta per? A chi hai bisogno per chiarire le cose? Quindi penso che miri sempre a essere un po' più chiaro di quanto pensi di dover essere in questo momento. Penso che testare molto la documentazione sia davvero utile, quindi ci sono molti modi diversi per testare contenuto e documentazione e penso che sia davvero importante uscire e assicurarsi che abbia senso per le altre persone. Penso che Caroline Darret dica sempre che se lo capisci abbastanza bene da sapere che è corretto, allora sai troppo per dire che è chiaro.

Amy: L'ho detto correttamente? Se lo conosci abbastanza bene da sapere che è corretto, allora lo sai troppo bene per dire che è chiaro, penso sia meglio. E sono davvero d'accordo con questo. Penso che per scrivere una buona documentazione devi avere una buona conoscenza dell'argomento o devi o finisci per sviluppare quella conoscenza dell'argomento nel tempo e attraverso il processo di scrittura. Quando avrai acquisito quella conoscenza dell'argomento, è davvero difficile giudicare se l'hai trasmessa o meno in un modo che sia chiaro a qualcuno che non lo fa. Quindi uscire e testarlo con persone che non conoscono l'argomento come te e convincerli a provarlo effettivamente a usarlo in un'attività pratica penso sia davvero importante. Sì, questo è il mio genere di cosa numero uno. Imparerai molto di più mettendolo di fronte alle persone, quindi imparerai leggendo in giro e guardando cosa hanno fatto le altre persone, penso.

Drew: E così facendo otterrai ovviamente un feedback su quella documentazione. Hai qualche suggerimento su come ti avvicineresti a sistemare le cose in base a quel feedback? Is there anything specific that you'd be looking for in the feedback to understand how well your documentation had worked?

Amy: Yeah, I mean there's a few things I think to watch out for. I think it's is really important to separate preferences and people perhaps not liking the documentation from people actually not being able to use it. So I think any task-based testing with documentation is better because it might be that actually somebody complains their way through an entire guide but they still complete the task that you've set them. That's not to say that that doesn't matter. If they wanted to do the thing but they actually hated the process, then you of course need to take that into consideration. But I think that some people and I'm probably one of them just can't help themselves and will start, especially if it's a content designer, I think we can't kind of ever quite put that content design mentality aside.

Amy: So I definitely have a tendency to start live editing stuff if I'm supposed to be participating as research candidate on it. So I think yeah, separating preference from actual kind of usability and blockers is quite important. I think that making sure that your really interrogating the need to make changes and to update things. I think sometimes if somebody is particularly engaged with a design system, depending on the sort of person they are, they can be quite vocal about how they think it could be better or how they think that how they would've done it perhaps or how it could be clearer. I think it can be quite, especially if you're sort of trying to build Goodwill and you're in that early stage with the design system, it can be quite tempting to just immediately respond to that feedback and do what they say or try and make it clearer.

Amy: But then you can end up building it too far in the direction of the loud minority and I think actually really saying like how many people have got this problem? What evidence do we have that this isn't working for people? And does that warrant a kind of update? I think yeah, trying to resist the temptation to respond to every comment and bit of criticism that you receive is quite important too, yeah.

Drew: I suppose I'm a common theme here with design systems that enable consistent design and give you a reusable resource in your design and about accepting contributions that make those designs stronger and implementing accessible design choices and documenting your design to make it easy to access and use. It really all comes back to sort of inclusion, would you say that was fair that including people as much as possible?

Amy: Definitely. Sì. I mean I think that a good design system is a representative design system and I don't think it's possible to achieve representation by acting on people's behalf. I think you really need to try and involve people in the process as much as possible. I think often for people working on design systems and certainly it was the case for us at the GOV.UK design system, you tend to be one step removed from your organizations end users. So if you think for the GOV.UK design system, the people that the design system is ultimately there to serve are members of the public and citizens and people using government services. But we in our team, we're really working directly with those people. Most of the time our direct users are people working in the civil service. So making sure that you've got really strong feedback loops between your direct users and then their users to ensure that it's representative I think is really important and I think that's where inclusion comes in and yeah, I completely agree. I think it's a really central thing, like I can't imagine how you could build a successful design system without a focus on that.

Drew: Is there anything else that you'd like to share with us about your work on the GOV.UK design system?

Amy: I think my sort of main takeaway from working on it is that, I hate using the word physical when I'm talking about anything on the web, but the the visual representation of a design system I think can end up being the thing that we all get really fixated on. We look at how it's coded and we look at how it's organized and what it looks like and how it's documented and what the design is. I think that obviously that stuff is really important. I think that it's the thing that you can look at and show people and share. So it's easy to see why we get fixated on that. But I really think that the most important factor of it is the people. I think that having inclusive processes and making sure that you're kind of fostering safe discussion spaces and that you're giving people an opportunity to get involved in the work and to participate and feel motivated to help you with it and to feel this sense of ownership over it.

Amy: I think all of that stuff is really important and all of that stuff really happens outside of the code and outside of the documentation. So yeah, I think my key takeaway from working on the GOV.UK design system is how much of it is really just people work and not really anything to do with guidance and code.

Drew: Here's at Smashing we're all about learning. So what have you been learning lately?

Amy: Lately I've been learning a lot about productivity and focus. I think definitely towards the end of last year I became aware that I was really plate spinning and luckily I don't think I smashed any of those plates but I found myself kind of working quite chaotically and moving around lots of different projects and saying yes to everything. So this year is the year that I want to really improve my focus. So I'm trying to learn a little bit about mindfulness and organization and how to say no to things strategically so that I don't get overwhelmed and too distracted. I've started bullet journaling so I've really become the full 2020 cliche at this point. So that's what I'm learning at the moment.

Drew: If you dear listener, would like to hear more from Amy, you can follow her on Twitter where she's @Amy_Hupe or find her on the web at amyhupe.co.uk. Thanks for joining us today. Amy, do you have any parting words for us?

Amy: Stay cool. Che cosa? Why did I say that? Just came out, it just came out.