Smashing Podcast Episodul 7 cu Amy Hupe: Ce este un sistem de proiectare guvernamentală?

Publicat: 2022-03-10
Rezumat rapid ↬ În acest episod al Smashing Podcast, aruncăm o privire asupra sistemului de proiectare al guvernului Regatului Unit. Cum sunt utilizate sistemele de proiectare în cadrul guvernului? Este diferit de modul în care am putea lucra în sectorul comercial? Drew McLellan discută cu avocatul sistemelor de proiectare Amy Hupe.

V-ați întrebat vreodată cum sunt utilizate sistemele de proiectare în cadrul unui guvern? De asemenea, dacă ați dori să documentați un sistem de proiectare în cel mai bun mod posibil, cum ați proceda? Am vorbit cu avocatul Design Systems, Amy Hupe, care ne împărtășește sfaturile și lecțiile învățate.

Afișați note

  • Sistemul de proiectare GOV.UK
  • Urmărește-o pe Amy pe Twitter
  • Site-ul lui Amy

Actualizare săptămânală

  • „Înțelegerea rețelei CSS: crearea unui container grilă”, de Rachel Andrew
  • „Front-End Performance Checklist 2020”, de Vitaly Friedman
  • „De ce ar trebui să alegeți HTML5 <articol> peste <secțiune>”, de Bruce Lawson
  • „Personalitatea divizată a dezvoltării web brutaliste”, de Frederick O'Brien
  • „Cum să creați și să implementați aplicația de material unghiular”, de Shubham

Transcriere

Fotografie cu Amy Hupe Drew McLellan: Este specialist în conținut și avocat în sisteme de proiectare, care și-a petrecut ultimii trei ani lucrând ca designer senior de conținut la Serviciul digital guvernamental. În acel timp, ea a condus strategia de conținut pentru sistemul de design GOV.UK, inclusiv o abordare simplă și incluzivă a documentării. Ea a lucrat anterior pentru o companie de promovare a consumatorilor, Which? unde a scris despre orice, de la compostare la transport. Și un nou rol pentru 2020 o vede ca manager de proiect pentru Babylon Health Design System, DNA.

Drew: Este un bucătar priceput, un Instagrammer și știe să folosească limbajul pentru a face serviciile accesibile și incluzive. Dar știai că ea a cântat odată cori pentru Billy Ray Cyrus? Prietenii mei zdrobitori, vă rog bun venit lui Amy Hupe. Bună Amy. Ce mai faci?

Amy Hupe: Sunt zdrobitoare. Mulțumesc.

Drew: Așa că am vrut să vă vorbesc astăzi despre rolul sistemelor de proiectare în cadrul organizațiilor guvernamentale în general, dar în special despre sistemul de proiectare GOV.UK, cu care știu că ați lucrat mult. Bănuiesc, în primul rând, ce cuprinde sistemul de proiectare GOV.UK? Și care a fost implicarea ta în asta în timp ce ai fost la GDS?

Amy: Deci cuprinde tot felul de lucruri. Deci, cred că cea mai evidentă reprezentare a acesteia este tipul de site web, care este GOV.UK/design-system. Și acolo vei găsi tot felul de documentație. Deci, toate liniile directoare de proiectare, componentele și modelele, și veți vedea o parte din cod, o mulțime de exemple și o mulțime de sfaturi despre cum să îl utilizați. Dar gândind mai larg decât atât, include și lucruri precum kit-ul de prototip, care este un instrument de prototipare care este folosit în guvern pentru a realiza prototipuri HTML și CSS. Deci, prototipuri destul de de înaltă fidelitate și are, de asemenea, propriul său tip de cadru frontal, care se numește GOV.UK Front End. Deci, acesta este tot codul pe care îl folosesc pentru a construi serviciile.

Amy: Dar apoi îmi place să mă gândesc la sistemele de proiectare mai holistic. Deci, pe lângă toate aceste lucruri, există și toate procesele care stau în jurul lui. Deci, lucruri precum modul în care oamenii contribuie la el și cum oamenii ajung să știe că există. Lucruri precum adopția și conștientizarea și tot felul de lucruri. Deci, toate lucrurile care le permit oamenilor să proiecteze și să construiască servicii în guvern sunt așa cum le-aș defini.

Drew: Deci, care a fost implicarea ta în timp ce erai la GDS cu asta? Unde ai intrat în acel sistem?

Amy: Totul s-a întâmplat din întâmplare, cred. Așa că m-am alăturat ca designer de conținut în ianuarie 2017, iar intenția mea când am venit la GDS a fost de fapt să mă alătur echipelor de conținut Gov UK. Așa că am crezut că voi începe să scriu ghiduri pentru sistem și acesta a fost visul meu. Asta am vrut să fac. Apoi am ajuns în prima zi și am fost introdus în această mică echipă de protecție, numită echipa de modele și instrumente ale manualelor de service.

Amy: În acel moment, sistemul de design nu exista, dar aveam modelele noastre de design și câteva bucăți și bucăți care se răsfrângeau în diferite locuri. A existat o ambiție de a încerca să reunească aceste lucruri. Așa că am fost pus în acea echipă ca designer de conținut. Nu știam ce este un model de design, nu știam nimic despre cod, nu știam absolut nimic despre web design. Tot ce știam cu adevărat era mulțumit.

Amy: Așadar, a fost o curbă de învățare destul de abruptă și mi-am petrecut următoarele șase luni până la un an, cred, ajutând echipa să-l prototipeze și să-și dea seama cum va fi organizat și aranjat și cum vom scrie îndrumările noastre și tot felul de chestii. Apoi, în mijlocul tuturor, pe lângă lucrul la conținut, am început să mă uit și la partea contribuțiilor. Așadar, cum ar contribui oamenii la ea și cum ar ajunge oamenii să o descopere și să intre în contact cu noi și ce am face atunci când ar intra în contact cu noi pentru a încerca să o îmbunătățească.

Drew: Deci, ce presupune proiectarea conținutului într-un asemenea context? Care erau genul de sarcini zilnice pe care le abordai?

Amy: Deci tot felul de lucruri într-adevăr. Vreau să spun că au fost săptămâni la un moment dat, cred că nu am scris un singur cuvânt și a fost mai degrabă să cercetez și să ne întâlnim cu utilizatorii noștri și să încerc să înțeleg ce anume își doreau de la un sistem de design. Așa că da, fără a intra prea mult în asta, au existat încercări de a face ceva ca sistemul de proiectare GOV.UK înainte, așa că am ajuns să avem acest tip de set ușor disparat de resurse.

Amy: Dintr-un motiv sau altul, aceste lucruri au ajuns să fie destul de răspândite și nu a fost niciodată unul dintre ele care a fost văzut ca locul central pentru aceste lucruri. Așadar, în mare parte, încercam doar să înțeleg ce s-a întâmplat înainte și de ce acele lucruri nu au decolat neapărat în modul în care am sperat că se va întâmpla. Încercarea de a înțelege ce părți din peisajul nostru existent funcționau pentru oameni și care părți nu.

Amy: Așadar, o mulțime de lucruri au fost făcute cu cercetările noastre [inaudible 00:05:07] și am stat la interviuri de cercetare cu utilizatorii, și luam notițe și vorbesc cu oamenii și doar înțelegeam de ce aveau nevoie. Apoi au fost zile în care chiar am putut să stau la o tastatură și să scriu niște îndrumări despre unele lucruri, ceea ce a fost și drăguț. Dar da, a fost foarte diferit pentru mine. După cum ați menționat în introducere, experiența mea a lucrat la Which? Așa că a fost mult mai mult un rol editorial tradițional și eram obișnuit să lucrez la conținut de formă lungă și să scriu doar articole și piese foarte lungi. Deci da, a fost o schimbare destul de mare. A fost un salt mare de la asta.

Drew: Deci utilizatorii tăi în acest context sunt oameni care lucrează în diferite organizații guvernamentale? Este corect? Diferite departamente din guvern?

Amy: Da. Da, este adevărat. Deci, oamenii care lucrează în, cred că există 25 de departamente ministeriale diferite în guvern și apoi sunt o mulțime de agenții și departamente guvernamentale locale. Deci am încercat să ne răspândim și să vorbim cu o gamă foarte largă de oameni din întreaga funcție publică. Deci da, multe călătorii în acele zile de început.

Drew: Crezi că proiectarea sau lucrul la un sistem de proiectare pentru un guvern, în esență, este diferit de un sistem de proiectare pentru o companie mică sau un tip de companie mare?

Amy: Cred că da. Adică cred că din ceea ce pot aduna din conversațiile pe care le-am avut și din conferințe la care am fost și alte chestii, fiecare sistem de design este ușor diferit și contextul este întotdeauna ușor diferit, iar guvernul nu este diferit în acest sens . Dar da, presupun că unele dintre provocările unice de a lucra la ceva pentru guvern sunt în primul rând amploarea acesteia. Deci audiența este probabil cea mai mare pe care o puteți avea, deoarece guvernul este atât de mare și toate tipurile diferite de departamente și răspândirea geografică a acestor organizații. Deci amploarea acesteia este cu siguranță ceva care este ușor diferit.

Amy: Cred și faptul că nu este competitiv din punct de vedere comercial. Deci nu încercam să ținem totul sub secret. Totul s-a făcut în aer liber pe cât posibil. Da, totul se desfășoară ca un mare proiect open source, ceea ce a fost un concept puțin neobișnuit pentru mine. Mi-a luat puțin timp să mă obișnuiesc cu asta.

Amy: Cu siguranță, când l-am lansat pentru prima dată, am vedea fragmente din îndrumarea și codul nostru să apară în sistemele de proiectare ale altor oameni. Mi-a luat puțin timp să mă simt bine în privința asta. Cred că la început am spus: „Ce se întâmplă? De ce ne iau oamenii ăștia lucrurile?” Dar de fapt acum, îmi place foarte mult asta. Văd asta ca pe un mare compliment și cred că este foarte bine să refolosești tot ce poți. Dar da, cred că este un fel ciudat de lume în care să intri când te-ai obișnuit să lucrezi într-un cadru mai comercial.

Drew: Presupun că faptul că este un sistem, în esență, finanțat din fonduri publice, înseamnă că este potrivit în mod unic pentru publicul care îl ia și îl folosește, dar și la nivel mondial, ați văzut o mulțime de utilizare în afara Regatului Unit?

Amy: Da, da, au existat proiecte cu adevărat interesante în întreaga lume care au preluat-o. Așa că știu că guvernul Noua Zeelandă a folosit destul de mult. Nu sunt sigur în ce stadiu se află în acest moment, dar cu siguranță am văzut sistemul lor timpuriu de proiectare a datelor și au folosit foarte mult îndrumările noastre și codul nostru, machetele și lucrurile noastre. Cred că guvernul olandez folosește, de asemenea, sistemul de design GOV.UK în primul rând ca primă dovadă a conceptului. Guvernul australian a început cu toate orientările noastre privind contribuțiile și le-a adaptat într-un fel pe baza cercetărilor lor. Așa că am reușit să luăm unele dintre acele lucruri înapoi. Da, așa că a devenit destul de global. Este incitant.

Drew: Ați lua în considerare faptul că oamenii l-ar folosi atunci când iau decizii cu privire la tipul de următoarea fază a lucrurilor? Ar lua în considerare în deciziile tale faptul că, de fapt, publicul tău, dintr-o dată, nu este doar guvernul Regatului Unit, de fapt ar putea fi un public la nivel mondial?

Amy: Este cu siguranță o considerație și cred că uneori asta ne-a făcut ca o echipă destul de nervoși cu privire la anumite lucruri pe care le făceam, deoarece publicul nostru și domeniul de aplicare au devenit dintr-o dată mult mai mari atunci când ne gândim la toți diferiții oameni care îl foloseau. Dar, personal, cred că nu poți fi prea implicat în faptul că în primul rând suntem acolo pentru a servi guvernul Regatului Unit. Deci, nu este practic să luăm în considerare toate publicurile potențiale pentru aceasta. Cred că depinde de echipe să-l adapteze așa cum trebuie pentru propriii lor utilizatori. Dar da, cu siguranță te face să te gândești destul de atent la doar aruncarea lucrurilor acolo înainte ca acestea să fie gata testate și alte chestii.

Drew: Așadar, au existat și alte surprize în lucrul la acest sistem de design, în afară de faptul că a fost apoi luat și utilizat mai larg decât te-ai fi așteptat inițial? A mai ieșit ceva și te-a surprins în legătură cu asta?

Amy: Un lucru care m-a remarcat cu siguranță a fost gama de oameni din publicul nostru. Deci nu doar dimensiunea audienței, ci și variația nivelului de cunoștințe al oamenilor, abilitățile lor, încrederea lor, diferitele tipuri de joburi pe care le-au făcut și tipul de contexte în care lucrau. Cred că există cu siguranță o mulțime de variații acolo. Cred că percepția mea a fost că aveam în cap această viziune despre acest designer front end developer, cineva care are multe cunoștințe tehnice și de fapt acesta este doar un tip de utilizator. Există o mulțime de alți oameni precum designerii de conținut și lucrurile nu au fost neapărat un public așteptat pentru el, dar s-au dovedit a fi utilizatori cheie.

Amy: Deci cred că, da, asta a fost cu siguranță o surpriză pentru mine. Apoi, să ne gândim la modul în care am putea satisface toți acei oameni cu un set atât de larg de nevoi cu sistemul de design a fost cu siguranță o provocare destul de mare. Da, cred că asta a fost probabil cea mai mare surpriză a mea. Apoi bănuiesc, alături de asta, cât de mult au văzut oamenii să-l adopte drept al lor. Așa că cred că după ce ne-am lansat destul de repede, am fost foarte plăcut surprins de câți oameni aș vedea că pledează pentru asta în propriile departamente și echipe și oameni care încearcă să contribuie la el și oameni care iau legătura cu noi pentru a ne întreba cum ar putea să-l adapteze pentru propriii utilizatori. M-am simțit cu adevărat deținut de comunitate încă din prima zi și nu a fost neapărat ceva la care mă așteptam, ci ceva care era gata foarte bine de văzut.

Drew: Presupun că o mare parte din rolul unui sistem de proiectare este un fel de a documenta deciziile de proiectare care au fost luate, astfel încât acele decizii să poată fi apoi implementate, înțelese și utilizate de oameni. Deci, cred că un sistem de proiectare este la fel de mult ca orice, un artefact de documentare, nu-i așa? Este să ia acele decizii care au fost luate și să le explici într-un mod în care oamenii le pot reutiliza. Cum v-ați abordat ca echipă, ei proiectează sistemul ca un fel de artefact de documentare? Cum ai documentat ceea ce făceai?

Amy: Așa că cred că era vorba de obținerea cât de mult am putut obține într-o imagine foarte clară a ceea ce oamenii aveau nevoie din acea documentație. Așadar, acest lucru revine la punctul pe care l-am spus că este un public destul de larg, deoarece există o gamă întreagă de nevoi diferite despre care oamenii vorbesc despre documentarea unei componente sau a unui model ca și cum ar fi un fel de sarcină unică. Dar, de fapt, există o mulțime de moduri diferite în care poți face asta și există o mulțime de nevoi diferite pe care trebuie să le iei în considerare. Deci avem oameni care, de exemplu, ar spune: „Oh, vreau să văd cercetarea din spatele acestui lucru”. Pentru unii oameni asta înseamnă un număr. Vor să știe că este folosit în 20 de servicii diferite, astfel încât să-și poată spune managerului de produs că merită să investească timpul și banii în implementarea acestuia în cadrul serviciului lor.

Amy: Și asta pentru ei este doar despre obținerea acelui sprijin bazat pe dovezi pentru decizia pe care încearcă să o facă. Dar mai sunt și alți oameni cărora le pasă cu adevărat să înțeleagă cercetarea și dacă este adecvată pentru contextul lor și ce cercetări suplimentare ar putea avea nevoie să completeze pentru a umple eventualele lacune care au fost ratate sau poate cu care se confruntă în situația lor unică. Așadar, cred că abordarea a fost să încercăm să înțelegem toate aceste nevoi diferite și să încercăm să obținem un sentiment de prioritate printre acestea și să înțelegem cum am putea răspunde tuturor cerințelor diferite pe care oamenii le aveau din documentație. Nu este un singur fel de lucru care se potrivește tuturor.

Amy: Așadar, să-mi dau seama cum să răspund tuturor acestor nevoi și să semnalizezi conținutul foarte bine într-un mod care să însemne că oamenii ar putea sări peste părțile care nu erau relevante și pentru ei. Pentru că atunci când încerci să deservi un public atât de larg, evident că ajungi să oferi destul de multe informații. Așa că să ne asigurăm că este bine indicat și organizat, cred că a fost esențial pentru ceea ce făceam.

Drew: Deci am dreptate când înțeleg că diferitele departamente din cadrul guvernului nu sunt de fapt obligate să adopte sistemul de proiectare? De fapt, trebuie să le vinzi efectiv și să-i convingi să-l folosească?

Amy: Da, deci este puțin complicat. Deci, în guvern, există ceva numit standard de servicii guvernamentale și este un standard pe care toate serviciile guvernamentale cu peste un anumit număr de utilizatori trebuie să-l îndeplinească pentru a obține finanțare și apoi să intre în Alpha și apoi Beta și apoi să trăiască. Unul dintre punctele standardului de service, am plecat acum trei săptămâni și deja mi-a scăpat din cap la ce număr este, dar unul dintre punctele standardului de service, vorbește despre reutilizarea modelelor și componentelor și încercarea de a reutiliza ceea ce este deja acolo. Deci, cam sub acest punct, sunt obligați să-l folosească, dar este liber și depinde de cine este evaluatorul. Nu este un fel de mandatat puternic. Cu toții am susține întotdeauna să facem ceea ce este mai bun în contextul specific, mai degrabă decât să reutilizam modele din cutie de dragul ei, pentru a bifa un punct în evaluarea serviciului. Deci este greu să o forțezi. Așa că abordarea a fost întotdeauna mult mai colaborativă și a fost întotdeauna despre construirea de sprijin și susținerea sistemului de proiectare, nu să-l împingă în gâtul oamenilor.

Drew: Cred că, în acest scop, una dintre modalitățile prin care ați reușit să faceți asta este prin încurajarea contribuției. Este corect?

Amy: Da, cu siguranță. Deci sunt un mare fan al contribuției la sistemele de proiectare. Cred că este ceva cu adevărat interesant și, cu siguranță, în echipă am muncit mult pentru a face posibilă contribuția la sistemul de design GOV.UK. Unul dintre beneficiile reale pe care le-am văzut de aici a fost susținătorii net pentru creșterea sistemului de proiectare. Așa că, atunci când ai pe cineva să contribuie la asta și se simte mai mult investit în asta și în ceea ce am primit, acei oameni mergeau apoi în echipele lor și deveneau cei mai buni oameni de vânzări ai noștri aproape pentru că s-ar simți ca și cum ar fi făcut-o. o mică parte din ea și aveau ceva de arătat oamenilor și apoi încurajau mai mulți oameni să contribuie. Deci acel efect ajunge să fie destul de exponențial. Da. Așa că am depus mult efort pentru a face acest lucru posibil.

Drew: Ce fel de lucruri ai făcut pentru a încuraja contribuția?

Amy: Am început foarte devreme. Așadar, cu mult înainte de a avea un sistem public de design, am început să ne angajăm cu oameni despre care credeam că ar fi contribuitori interesați. Ar trebui să menționez aici, am avut un designer de servicii genial în echipă. Ea s-a alăturat nouă, nu o să corectez datele în niciun fel momentan, dar cred că a lucrat cu noi în tot anul 2018 și se numește Ignatia și a făcut o treabă fantastică de a merge prin jur. și implicarea oamenilor. Așa că unul dintre lucrurile pe care le-a făcut a fost să identifice toate modelele diferite din guvern și toate variațiile diferite ale acestor modele. Deci, să ieși și să spui, bine, există, există 10 moduri diferite de a cere o adresă în guvern. Să le analizăm pe toate împreună și să decidem care credem că este cea mai potrivită abordare.

Amy: Cum le putem consolida într-unul singur? Ea a condus un atelier mare pentru a încerca să îi convingă pe oameni să se uite la acestea și să facă acest tip de consolidare ca o echipă. Cred că abordarea ei de a construi colaborarea cu mult înainte de a lansa ceva publicului a ajutat cu adevărat la asta, deoarece însemna că oamenii au deja acest tip de conștientizare și mulți oameni deja au contribuit într-un fel sau altul înainte de noi. chiar a făcut-o public. Asa ca pune-ne cativa pasi inainte. Deci cred că asta a fost foarte important. Și doar perseverență, ca multă perseverență din partea întregii echipe în felul de a ajuta oamenii să contribuie. Cred că există ideea că, dacă îi convingi pe oameni să contribuie la un sistem de design care este un concert destul de dulce, poți să-i convingi pe oameni să facă toată munca pentru tine.

Amy: Și stai acolo și faci remedieri ale codului de nivel și toată lumea îți oferă de fapt toate lucrurile bune. Dar, de fapt, așa cum știe oricine care a lucrat la un sistem de proiectare, este incredibil de complex. Este foarte dificil să faci o soluție centralizată care să funcționeze pentru mai multe echipe diferite și, într-adevăr, dacă nu ai lucrat la un sistem de proiectare, nu este rezonabil să te aștepți ca cineva să înțeleagă cu adevărat de ce este nevoie. Deci există multă ținere de mână. Este multă muncă implicată în sprijinirea contribuitorilor să contribuie, cred că am spus asta înainte, dar probabil că durează mai mult, cred, pentru a ajuta pe cineva să contribuie la un sistem de proiectare, decât să faci singur lucrul în echipa centralizată. . Dar cred că recunoscând valoarea pe care o aduce și să fii perseverent în eforturile tale de a face oamenii conștienți de contribuție și de a-i ajuta să o facă, îi ajută-i să se simtă oarecum motivați să o facă. Cred, da, că persistența a fost într-adevăr cheia succesului nostru în acea zonă.

Drew: Și, practic, vorbind despre gestionarea acelor contribuții din partea comunității, au existat instrumente sau procese sau ceva care a ajutat la asta?

Amy: Da, așa că am avut un proces destul de strict, aș spune. Strict în măsura în care poate, strict este cuvântul greșit, cuprinzător este probabil un cuvânt mai bun. Deci, da, avem un set de criterii de contribuție care sunt în sistemul de proiectare. Deci totul este cât se poate de deschis, astfel încât oamenii să știe la ce să se aștepte. Deci, există un set de criterii pe care le-am dezvoltat împreună cu diverși oameni din comunitatea guvernamentală din afara echipei noastre, așa că din nou, cum ar fi încercarea de a implica oamenii în crearea acestor procese, cred că este foarte important. Deci, există un set de criterii pe care trebuie să le îndeplinească toate contribuțiile la sistemul de proiectare și pentru a ne asigura că suntem destul de imparțiali, presupun, și echitabili în ceea ce privește luarea deciziilor despre dacă lucrurile îndeplinesc acele criterii sau nu, am înrolat sprijinul unui grup de lucru, care era un grup de reprezentanți din întreaga guvernare. Toți din diferite departamente și discipline diferite și oameni cu diferite niveluri de vechime.

Amy: Deci toată lumea ar avea o perspectivă ușor diferită asupra contribuțiilor și ne-am întâlni cu ei o dată pe lună și le-am rugat să analizeze orice contribuții noi și să decidă dacă au îndeplinit sau nu criteriile. Deci da, a fost un fel de proces conceput pentru a încerca să democratizeze designul sistemului de proiectare, presupun, și pentru a-l reprezenta și pentru a se asigura că nu doar echipa noastră stă la mijloc care ia toate deciziile fără a înțelege cu adevărat cum ar afecta echipele care folosesc acele lucruri.

Amy: Da, acesta a fost genul nostru de proces. Încă o postare pe care ar trebui să o menționez este că există un acumulator al comunității pe GitHub, pe care oricine îl poate folosi. Nu trebuie să lucrezi în guvern pentru a merge să vezi. Este accesibil din sistemul de proiectare și este practic un loc în care încercăm să găzduim toate cercetările și toate lucrurile experimentale și exemplele care intră în componentele și modelele lor în sistemul de proiectare. Deci, din nou, este vorba de a face forță pentru acea transparență și de a lucra în mod deschis cât mai mult posibil, astfel încât oamenii să aibă o voce și să poată influența lucrurile înainte de a fi publicate efectiv.

Drew: Și crezi că acest proces a funcționat bine? Dacă te-ai îmbarca din nou în același lucru, crezi că ai adopta un proces similar sau există ceva care nu a funcționat?

Amy: Cred că aș adopta un proces similar, dar probabil că aș intra cu așteptări ușor diferite. Ceea ce aș spune sunt poate așteptări puțin mai realiste și, după ce am spus ceea ce am spus, despre modul în care credem că contribuția va face lucrurile mai ușoare și mai rapide. Am fost cu siguranță în tabăra aceea. Cred că m-am gândit că la început va exista un vârf de muncă pentru a familiariza oamenii cu contribuția și apoi, în timp, vom putea să fim mai departe de mâini și oamenii ar fi înțeles și ar fi bine. Dar de fapt asta nu s-a concretizat niciodată. A fost întotdeauna multă muncă implicată în a ajuta oamenii să contribuie și, așa cum spun, cred că este de așteptat. Nu cred că poți scăpa cu adevărat de asta, dar tot cred că este valoros.

Amy: Încă cred că merită să investești acel timp, dar poate nu cu ideea că vei accelera lucrurile sau că vei putea crește mai repede sau mai mult din a avea contribuție. Deci da, cred că procesul a funcționat bine. Cred că trebuie adaptat pentru diferite organizații, așa că încep un nou rol luni destul de amuzant, lucrez la un alt sistem de proiectare și nu mă aștept să pot relua acel proces și doar să mă mișc. e acolo. Cred că totul trebuie să fie adaptat organizației și contextului cu care aveți de-a face, dar cu siguranță există elemente pe care aș dori să le aduc. Dar da, cu așteptări ușor temperate, cred.

Drew: Am vorbit acum câteva episoade cu Hayden Pickering despre proiectarea componentelor, în special în cadrul unui sistem de proiectare care să fie accesibil. Cred că asta e ceva cu care ai multă experiență. În mod evident, accesibilitatea este cu adevărat, cu adevărat crucială atunci când lucrați într-un sistem de proiectare guvernamental, dar mulți dintre noi ar susține că este cu adevărat, cu adevărat crucial oriunde lucrați. Credeți că sistemele de proiectare joacă un rol în accesibilitatea unui design sau în implementarea unui design?

Amy: Așa că există o discuție strălucitoare a Tatiana Mack despre construirea sistemelor de design incluzive care atinge acest lucru și asta a fost într-adevăr influent pentru mine și ea vorbește despre tipul de efect de multiplicare al sistemelor de proiectare. Deci, cu sistemele de proiectare, le spunem oamenilor cum arată bine și le oferim oamenilor modalități rapide de a implementa ceea ce le spunem oamenilor că sunt cele mai bune practici. Deci asta poate funcționa în orice mod. Poate funcționa foarte bine dacă oferiți oamenilor un design bun și un design bun accesibil, atunci aveți potențialul de a multiplica acel design accesibil și de a face lucrurile mai accesibile și mai incluzive în mod implicit.

Amy: Dacă iei decizii care exclud oamenii într-un sistem de design, în acel spațiu centralizat, care devine punctul de plecare pentru oamenii care proiectează servicii, atunci chiar ai potențialul de a prolifera acel design exclusiv. Deci cu siguranță cred că sistemele de proiectare joacă un rol în promovarea și multiplicarea accesibilității. Dar cred că totul începe cu intenția echipelor care lucrează și folosesc sistemul de proiectare pentru a face acest lucru. Un sistem de design este într-adevăr, este doar genul de vehicul presupun și intenția trebuie să fie acolo pentru a face lucrurile accesibile.

Drew: Unul dintre lucrurile care mă fascinează întotdeauna, în special cu sistemele de proiectare care au un public atât de mare și variat, cum ar fi sistemul de proiectare GFI UK, este procesul de proliferare a schimbărilor în sistem. Deci, dacă, de exemplu, găsiți o îmbunătățire a accesibilității pe care ați putea-o face într-un anumit model și o faceți în sistemul de design, cum vă asigurați că aceasta este implementată într-un public atât de larg? Este ceva cu care ai experiență?

Amy: Da. Deci, din nou, cred că noi, într-un fel, în echipa sistemului de proiectare GOV.UL, luăm foarte mult în considerare modul în care ar funcționa. Trebuie să fiu sincer, o mare parte are de-a face cu modul în care este implementat tehnic și cu siguranță nu sunt persoana potrivită pentru a vorbi atât de mult despre aspectul tehnic al echipei. Găsesc că există un fel de două tabere cu sisteme de proiectare și există o tabără care este ca și cum să scoatem lucrurile acolo cât mai repede posibil. Să o deschidem cât mai curând posibil și asta va opri dublarea efortului și multiplicarea efortului și apoi o putem repeta pe măsură ce mergem mai departe. Apoi, cred că există un fel de tabără să ne mișcăm puțin mai încet, în care cred că mă aflu, care favorizează să nu mai lansăm lucruri până când ai un anumit nivel de încredere în el.

Amy: Și cred că este destul de important pentru că cred că, în general, dacă proiectați produse și servicii, atunci începeți cu lucrul minim și apoi repeți pe măsură ce mergi cred că funcționează grozav, dar cred că atunci când construiești ceva central, care este conceput pentru ca o mulțime de oameni să reutilizeze și să le ofere la o mulțime de publicuri diferite, folosiți foarte repede controlul asupra obiectului și asupra modului în care este utilizat. Deci, cred că a avea o anumită încredere în ceva înainte de a-l lansa și a avea un fel de proces de asigurare în vigoare, asta înseamnă că ai o anumită încredere că este accesibil înainte de a ieși acolo este destul de esențial și apoi sperăm că Lucrul este puțin mai stabil și cred că este foarte important pentru încredere. Cred că încrederea este destul de importantă atunci când vorbim despre schimbarea sistemelor de proiectare, pentru că, dacă lansăm modificări tot timpul, atunci asta face sistemul destul de instabil la utilizare și cred că asta distruge încrederea și apoi oamenii sunt" nu este atât de probabil să instalez actualizări și lucruri.

Amy: În timp ce cred că dacă poți să arăți că ești atent cu ceea ce lansezi și că faci modificări numai atunci când este necesar, atunci ai această bunăvoință și atunci oamenii sunt mai dispuși să facă actualizări și chestii cred. Dar da, vreau să spun că știu că sa lucrat mult pentru a ne asigura că procesul de actualizare a fost destul de simplu și ușor de implementat în sistemul de proiectare GPV.UK. Doar că nu sunt persoana potrivită să vorbesc despre asta, cred.

Drew: Deci am vorbit pe scurt despre documentare. Dacă aș fi căutat să documentez un sistem de proiectare și dacă aș vrea să fac o treabă foarte bună cu acesta, există ceva ce m-ați sfătui să fac pentru a mă asigura că documentez bine lucrurile?

Amy: Nu cred că este posibil să faci o declarație generală aici, pentru că într-adevăr trebuie să satisfacă publicul specific cu care ai de-a face. Lucrul meu este să urmăresc întotdeauna să fii puțin mai incluziv decât poate simți că trebuie să fii. Deci, dacă te gândești la, mai ales într-o organizație mai mică care poate crește, cred că trebuie să fii la fel de atent ca publicul tău viitor și publicul tău potențial ca publicul tău actual. Deci, dacă aveți o organizație mică și aveți 10 dezvoltatori front-end și toți știu același fel de lucruri și sunt capabili să vorbească între ei și să comunice destul de liber, atunci documentația dvs. poate să nu fie la fel de cuprinzătoare ca aceasta în cadrul organizației mai mari.

Amy: Dar cred că pentru a ajuta un sistem de proiectare la scară și pentru a te asigura că este echipat pentru a face asta, trebuie să te gândești cine s-ar putea alătura organizației în viitor și cine trebuie să lași ușa deschisă. pentru? Cui trebuie să-i explici lucrurile? Așa că cred că ținește întotdeauna să fii puțin mai clar decât simți că trebuie să fii în acest moment. Cred că este util să testați foarte mult documentația, așa că există o mulțime de moduri diferite de a testa conținutul și documentația și cred că este foarte important să ieșiți și să vă asigurați că are sens pentru alți oameni. Cred că Caroline Darret spune întotdeauna că dacă înțelegi suficient de bine pentru a ști că este corect, atunci știi prea multe ca să spui că este clar.

Amy: Am spus asta corect? Dacă o știi suficient de bine ca să știi că este corect, atunci știi prea bine ca să spui că este clar, așa cred că e mai bine. Și chiar sunt de acord cu asta. Cred că, pentru a scrie o documentație bună, trebuie să aveți cunoștințe destul de bune în materie sau aveți nevoie sau ajungeți să dezvoltați aceste cunoștințe în timp și prin procesul de scriere. Până când ai cunoștințele despre subiect, este foarte greu să judeci dacă le-ai transmis sau nu într-un mod clar pentru cineva care nu o are. Așa că ieșiți și testați-l cu oameni care nu cunosc subiectul ca tine și convingeți-i să încerce și să îl folosească într-o sarcină practică cred că este foarte important. Da, acesta este genul meu de lucru numărul unu. Veți învăța mult mai mult punându-l în fața oamenilor, apoi veți învăța citind în jur și uitându-vă la ceea ce cred alți oameni au făcut.

Drew: Și, făcând asta, evident vei primi feedback cu privire la acea documentație. Do you have any suggestions for how you would approach fixing things based on that 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. Da. 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. Ce? Why did I say that? Just came out, it just came out.