Sistemele de proiectare sunt despre relații

Sistemele de proiectare pot fi incredibil de utile. Ele oferă elemente reutilizabile și linii directoare pentru crearea unui „aspect și senzație” consistent între produse. Drept urmare, utilizatorii pot lua ceea ce au învățat de la un produs și îl pot aplica altuia. În mod similar, echipele pot lansa modele bine testate pentru navigare sau recenzii, făcând produsele mai demne de încredere. Sistemele de proiectare eficiente rezolvă probleme plictisitoare într-un mod repetabil, astfel încât dezvoltatorii și designerii să se poată concentra pe rezolvarea unor probleme noi.

Cu toate acestea, când cineva folosește termenul „sistem de proiectare” într-o întâlnire, nu sunt niciodată sigur la ce reacție să mă aștept. Am văzut curiozitate și entuziasm în ceea ce privește încercarea unui nou mod de lucru, dar am văzut și frustrare și îngrijorare la ideea unui sistem care limitează creativitatea designerilor. Unii designeri susțin că sistemele de design slăbesc creativitatea sau că sunt soluții în căutarea unei probleme. Sistemele de proiectare se pot fragmenta în timp, determinând echipele să nu le mai folosească.

Sistemele de proiectare nu dispar, totuși. Doar 15% dintre organizații nu aveau un sistem de design în 2018, potrivit unui sondaj. Este în scădere față de 28% anul precedent. Unele echipe folosesc sisteme de proiectare mari, de uz general, cum ar fi Material Design de la Google, în timp ce altele folosesc sisteme mai mici, mai personalizate, cum ar fi Cedar de la REI și Protocolul Mozilla.

Sistemele de proiectare ar trebui să împuternicească echipele, nu să le limiteze. Pentru ca asta să se întâmple, trebuie să începem să gândim mai holistic. Un sistem de proiectare nu este doar cod, sau desene sau documentație. Sunt toate aceste lucruri, plus relațiile dintre oamenii care creează sistemul și cei care îl folosesc. Include nu doar fișiere CSS și documente Sketch, ci și încredere, comunicare și proprietate comună. După cum se dovedește, există un întreg domeniu de studiu dedicat explorării sistemelor ca acestea.

Imaginea de ansamblu

O lucrare din 1960 intitulată „Sisteme socio-tehnice” a explorat interacțiunile dintre tehnologie, oameni și mediul mai larg în care acestea există. Enid Mumford a explicat că cercetătorii au început prin a investiga cum să construiască relații mai bune între manageri și angajați, dar până în anii 1980, ei s-au concentrat să facă munca mai eficientă și mai rentabilă. În 2011, Gordon Baxter și Ian Sommerville au scris că această cercetare a ajutat la inspirarea designului centrat pe utilizator și că mai rămâne mult de lucru.

Baxter și Sommerville au susținut că astăzi există încă o tensiune între cercetarea „umanistă”, care se concentrează pe calitatea vieții angajaților, și cercetarea „managerială”, care se concentrează pe productivitatea acestora. Ei au explicat, de asemenea, că este important să se ia în considerare atât tehnologia, cât și interacțiunile umane: „performanța sistemului se bazează pe optimizarea comună a subsistemelor tehnice și sociale”.

Aș susține că sistemele de proiectare sunt sisteme socio-tehnice. Ele implică interacțiuni între oamenii care creează sistemul, oamenii care creează produse folosind sistemul și utilizatorii finali care interacționează cu aceste produse. Ele evocă, de asemenea, aceeași tensiune între eficiență și umanism pe care au văzut-o Baxter și Sommerville.

Sistemele de proiectare nu sunt compuse doar din imagini și cod; implică conversații între designeri, dezvoltatori, manageri de produs, directori executivi și persoane aleatorii de pe GitHub. Aceste interacțiuni apar în diferite contexte - o companie, o comunitate open-source, o casă - și se întâmplă peste culturi și granițele organizaționale. Construirea unei echipe poate însemna reunirea oamenilor din discipline precum animația, designul sunetului, vizualizarea datelor, haptica și copywriting. Crearea unui sistem de proiectare de succes necesită părți egale de expertiză tehnică și abilități soft.

Și totuși, citiți cu atenție agregatorii de știri de proiectare sau inginerie și probabil că veți vedea un accent distinct pe acel „subsistem tehnic” - cod și instrumente, mai degrabă decât oameni și conversații. Care instrument creativ este cel mai bun pentru a ține evidența jetoanelor de design? Ce tehnologii JavaScript ar trebui folosite pentru a construi componente reutilizabile — React, componente web sau altceva? Care instrument de construcție este cel mai bun?

Răspunsul la aceste întrebări este, desigur, „depinde!” Cine va proiecta, construi și utiliza sistemul? Care sunt nevoile lor? Sub ce constrângeri operează ei? Cu ce ​​instrumente și tehnologii se simt confortabil? Ce vor să învețe?

Pentru a răspunde la acest fel de întrebări, Baxter și Sommerville recomandă două tipuri de activități:

• Activități de sensibilizare și conștientizare
  Aflați despre diversele persoane care vor crea și vor participa la sistem și împărtășiți acele informații în toată lumea.
• Angajament constructiv
  Comunicând între roluri, construind prototipuri și luând în considerare atât părțile tehnice, cât și cele sociale ale sistemului.

Săpat în

La începutul lui 2019, am făcut parte dintr-o echipă – să le numim „echipă albastră” – care construia un sistem de proiectare pentru o organizație mare. Am facilitat discuții informale cu această echipă și „team green”, care folosea sistemul de design pentru a construi o aplicație web. La fiecare două săptămâni, am reunit toți dezvoltatorii și designerii în jurul unei mese și am vorbit despre ceea ce construim și ce probleme încercam să rezolvăm. Aceste chat-uri au fost „activitățile noastre de sensibilizare și conștientizare”.

Nu aveam permisiunea de a face public sistemul nostru de design, așa că am făcut următorul lucru cel mai bun: l-am tratat ca pe un mic proiect open-source în cadrul organizației. Am pus codul într-un depozit pe care ambele echipe l-au putut accesa și am cerut contribuții. Team blue era responsabilă pentru revizuirea și aprobarea acestor contribuții, dar oricine din oricare echipă putea contribui. Team blue construia, de asemenea, o aplicație proprie, așa că, într-un fel, erau atât utilizatori, cât și custozi ai sistemului de design.

Aceste interacțiuni au ajutat echipele să construiască produse mai bune, dar, la fel de important, au stabilit încredere între echipe. Team blue a aflat că oamenii foloseau sistemul cu grijă și construiau idei noi inteligente pe deasupra. Team Green a învățat că sistemul a fost într-adevăr adaptat nevoilor lor, astfel încât să poată lucra cu el și nu împotriva lui. Baxter și Sommerville ar putea numi această lucrare „angajament constructiv”.

Am descoperit că ambele echipe au fost sub presiune să învețe noi tehnologii și să livreze rapid un produs complet. Cu alte cuvinte, aceștia operau deja sub o încărcătură cognitivă destul de considerabilă. Drept urmare, cele două echipe au convenit să se concentreze pe a face sistemul ușor de utilizat. Asta însemna să ocolim întreaga dezbatere a componentelor web, concentrându-ne mai ales pe CSS și să ne asigurăm că documentația noastră este clară și prietenoasă.

Punând totul laolaltă

Organizațiile de toate dimensiunile creează elemente de design reutilizabile pentru a ajuta echipele să construiască aplicații mai consistente și mai elegante. Nevoile și dinamica diferitelor organizații sunt exprimate în sistemele lor de proiectare. Iată doar câteva exemple:

• Material Design de la Google are mai multe implementări în cadre și limbi diferite. Este folosit de o varietate de persoane din interiorul și din afara Google, așa că are o documentație cuprinzătoare și o varietate de seturi de instrumente pentru aplicații de proiectare.
• Fluent Design System de la Microsoft vizează patru platforme foarte diferite. La fel ca Material, include seturi de instrumente pentru designerii UX și documentație cuprinzătoare.
• Protocolul Mozilla este implementat în JavaScript Sass și vanilla. Are un accent puternic pe internaționalizare. Alex Gibson spune că acest sistem îl ajută pe Mozilla să „creeze pagini web de marcă într-un ritm mai rapid, cu o muncă manuală mai puțin repetitivă”.
• Cedar de la REI este construit cu componente Vue.js și nu poate fi folosit cu alte cadre JavaScript. Cedarul este folosit în principal de dezvoltatorii interni ai REI și este strâns legat de marca companiei. Codul sistemului de design este open source, dar fonturile nu sunt.
• Sistemul de proiectare Lightning de la Salesforce este un cadru CSS agnostic de JavaScript. Opțional, poate fi utilizat alături de Lightning Component Framework, care include două implementări JavaScript: una folosind componente web și alta folosind cadrul proprietar Aura Salesforce.
• PatternFly de la Red Hat a fost creat pentru a oferi o experiență consecventă utilizatorului în produsele platformei cloud ale companiei, astfel încât are o densitate de informații relativ mare și include o varietate de componente de vizualizare a datelor. Echipa PatternFly a trecut recent de la Angular la React după câteva experimente cu componente web. PatternFly include, de asemenea, o implementare independentă de JavaScript, folosind HTML și CSS. (Dezvăluire completă: sunt un fost Red Hatter.)
• Carbon Design System de la IBM oferă implementări în JavaScript React, Vue, Angular și vanilla, precum și un set de instrumente de proiectare pentru Sketch. Echipa Carbon experimentează cu componente web. (Sfat de pălărie lui Jonathan Speek pentru că a găsit acel depozit.)

Sistemele ca acestea sunt consistente și fiabile, deoarece oameni din diferite echipe și roluri au lucrat împreună pentru a le construi. Aceste sisteme rezolvă probleme reale. Nu sunt rezultatul dezvoltatorilor care încearcă să-și impună voința asupra designerilor sau invers.

Josh Mateo și Brendon Manwaring explică că designerii Spotify „își văd rolul de colaboratori și co-autori de bază ai unui sistem partajat – unul asupra căruia ei dețin”. Mina Markham se descrie ca fiind „translatorul între inginerie și design” în sistemul de design Pantsuit. Jina Anne analizează dinamica echipei și cercetarea utilizatorilor din spatele sistemelor de proiectare: „Alertă spoiler! Veți avea nevoie de mai mult decât de designeri.”

Să construim niște lucruri!

Acum că am trecut prin cercetări și câteva exemple, să vorbim despre cum să construim un nou sistem de proiectare. Începe prin a vorbi cu oamenii. Aflați cine va folosi și va contribui la sistemul dvs. de proiectare. Acești oameni vor cuprinde probabil o varietate de discipline - design, dezvoltare, management de produs, afaceri și altele asemenea. Aflați despre nevoile și obiectivele oamenilor și cereți-le să împărtășească la ce lucrează. Luați în considerare planificarea unei întâlniri informale cu gustări, cafea sau ceai pentru a crea o atmosferă primitoare. Stabiliți o comunicare regulată cu acești oameni. Aceasta ar putea însemna să vă alăturați unei camere de chat partajate sau să programați întâlniri regulate. Păstrați tonul casual și prietenos și concentrați-vă pe ascultare.

Pe măsură ce vorbiți despre ceea ce lucrați, căutați probleme și obiective comune. Este posibil să descoperiți că echipele trebuie să afișeze cantități mari de date, așa că investighează instrumente pentru afișarea tabelelor și generarea de rapoarte. Prioritizează soluțiile pentru aceste probleme.

Căutați, de asemenea, modele și variații repetate pe teme similare. S-ar putea să descoperiți că butoanele și formularele de conectare arată puțin diferit în funcție de echipă. Care este semnificația acestor variații? Ce variații sunt intenționate - de exemplu, un buton principal versus un buton secundar - și ce variații s-au întâmplat accidental? Sistemul dumneavoastră de proiectare poate denumi și cataloga modelele și variațiile intenționate și poate elimina variațiile „accidentale”.

Scopul aici este de a stabili o buclă rapidă de feedback cu oamenii care folosesc sistemul de proiectare. Feedback-ul mai rapid și iterațiile mai mici pot ajuta la evitarea mersului prea departe în direcția greșită și a nevoii de a schimba radical cursul. PJ Onori numește aceste schimbări bruște și mari „thrash”. El spune că unele thrash sunt bune - este un semn că înveți și răspunzi la schimbare - dar că prea mult poate fi perturbator. „Nu ar trebui să te temi de thrash”, spune el, „dar trebuie să știi când este util și cum să ajuți la atenuarea dezavantajelor sale. Una dintre cele mai bune [modalități] de a atenua dezavantajele thrash-ului este să începi cu mici — cu totul .”

Luați în considerare să începeți cu puțin, stabilind câteva elemente de bază:

• Un sistem de control al versiunilor pentru a vă stoca codul. GitHub, GitLab și Bitbucket sunt toate opțiuni excelente aici. Asigurați-vă că toți cei care utilizează sistemul pot accesa codul și pot propune modificări. Dacă este posibil, luați în considerare crearea codului open source pentru a ajunge la cel mai larg public posibil.
• Cod CSS pentru implementarea sistemului. Utilizați variabile Sass sau proprietăți personalizate CSS pentru a stoca „semnificative de design” - valori comune, cum ar fi lățimi și culori.
• Un fișier package.json care definește modul în care aplicațiile pot construi și instala sistemul de proiectare.
• Documentație HTML care demonstrează cum se utilizează sistemul de proiectare, în mod ideal folosind propriul CSS al sistemului.

Documentația node-sass pentru cadrul CSS Bulma descrie acești pași mai detaliat. Puteți sări peste instalarea și importarea Bulma dacă doriți să începeți de la zero, sau îl puteți include dacă doriți să începeți cu unele dintre elementele de bază.

Poate ați observat că nu am menționat nimic despre JavaScript aici. Poate doriți să adăugați acest element în cele din urmă, dar nu aveți nevoie de el pentru a începe. Este ușor să mergi într-o groapă de iepure căutând cele mai bune și mai noi instrumente JavaScript, iar pierderea în această cercetare poate îngreuna începerea. De exemplu, „5 motive pentru care componentele web sunt perfecte pentru sistemele de proiectare” și „de ce nu folosesc componente web” sunt ambele puncte valide, dar numai tu poți decide ce instrumente sunt potrivite pentru sistemul tău. Începând doar cu CSS și HTML, vă permite să adunați feedback din lumea reală care vă va ajuta să luați această decizie atunci când va veni momentul.

Pe măsură ce lansați versiuni noi ale sistemului, actualizați numărul versiunii sistemului pentru a indica ce s-a schimbat. Utilizați versiunea semantică pentru a indica ce s-a schimbat cu un număr precum „1.4.0”. Creșteți ultimul număr pentru remedieri de erori, numărul din mijloc pentru funcții noi și primul număr pentru schimbări mari, perturbatoare. Continuați să comunicați cu cei care folosesc sistemul de design, invitați feedback și contribuții și aduceți mici îmbunătățiri pe măsură ce mergeți. Acest mod de lucru colaborativ și iterativ poate ajuta la minimizarea „lozurilor” și la stabilirea unui sentiment de proprietate comună.

În cele din urmă, luați în considerare publicarea sistemului dvs. de proiectare ca pachet pe npm, astfel încât dezvoltatorii să-l poată utiliza prin rularea comenzii npm install your-design-system . În mod implicit, pachetele npm sunt publice, dar puteți, de asemenea, să publicați un pachet privat, să publicați pachetul într-un registru privat sau să cereți dezvoltatorilor să instaleze pachetul direct dintr-un sistem de control al versiunilor. Utilizarea unui depozit de pachete va facilita descoperirea și instalarea actualizărilor, dar instalarea direct din controlul versiunilor poate fi o soluție ușoară pe termen scurt pentru a ajuta echipele să înceapă.

Dacă sunteți interesat să aflați mai multe despre partea de inginerie a lucrurilor, Building Your Design System de la Katie Sylor-Miller oferă o scufundare fantastică în profunzime. (Dezvăluire completă: am lucrat cu Katie.)

Încheierea

Sistemele de proiectare sunt alcătuite din cod, design și documentație, precum și relații, comunicare și încredere reciprocă. Cu alte cuvinte, sunt sisteme socio-tehnice. Pentru a construi un sistem de proiectare, nu începe prin a scrie cod și a alege instrumente; începeți prin a vorbi cu oamenii care vor folosi sistemul. Aflați despre nevoile și constrângerile lor și ajutați-i să rezolve problemele. Când luați decizii tehnice, de proiectare sau de strategie, luați în considerare nevoile acestor oameni în detrimentul modului teoretic „cel mai bun” de a face lucrurile. Începeți mic, repetați și comunicați pe măsură ce mergeți. Păstrați-vă sistemul cât mai simplu posibil pentru a minimiza atacurile și invitați feedback și contribuții pentru a stabili un sentiment de proprietate comună.

Acordând o pondere egală considerentelor de inginerie și interpersonale, putem obține beneficiile sistemelor de proiectare evitând în același timp capcanele. Putem lucra într-un mod eficient și uman; nu trebuie să alegem unul în detrimentul celuilalt. Putem împuternici echipele în loc să le limităm. Echipele împuternicite ne ajută, în cele din urmă, să ne deservim mai bine utilizatorii – care, la urma urmei, este motivul pentru care suntem aici în primul rând.

Citiți suplimentare despre SmashingMag:

• Sfaturi pentru gestionarea sistemelor de proiectare
• Inclusiv animație în sistemul dvs. de proiectare
• Dincolo de instrumente: cum construirea unui sistem de proiectare poate îmbunătăți modul în care lucrați
• Construirea unui sistem de proiectare la scară largă pentru guvernul SUA (studiu de caz)