O rețetă pentru un sistem de design bun

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la Backlight, o platformă de colaborare care dă putere echipelor front-end să construiască și să livreze sisteme de design grozave. Mulțumesc!

În teorie, toată lumea are un concept relativ similar pentru ceea ce înseamnă un „sistem de proiectare”, deși nuanțele încep să apară pe măsură ce ne apropiem de lumea reală. Ținta poate fi în continuare aceeași, dar diferite organizații vor avea nevoie de strategii diverse pentru a le îndeplini. Ca și în cazul multor sarcini complicate din inginerie și arhitectură, nu există nicio soluție pentru ceea ce face un sistem de proiectare bun.

Deși eforturile de succes împărtășesc câteva modele comune care au permis apariția instrumentelor și a celor mai bune practici. În acest articol, vom arunca o privire la ce soluții se potrivesc în interiorul umbrelei unui sistem de proiectare și la câțiva pași importanți și puncte de control pe care trebuie să le urmăriți pe parcursul proiectelor dvs. Experiența noastră poate diverge, dar sperăm că vor exista învățăminte pentru tine în care eu personal am eșuat și am reușit.

Scop și semnificație

Dacă considerăm un „sistem” ca o combinație de părți care lucrează împreună, iar „designul” ca plan de aspect și funcție a ceva. Apoi putem înțelege Sistemul de proiectare ca un colectiv de definiții care vor dicta modele în care părțile interconectate ale unui sistem vor arăta, simți și funcționează. Acest lucru este încă destul de abstract, dar suficient pentru a înțelege mai mult decât aspectul .

Nu este o bibliotecă de componente pe care o asamblați ca un puzzle și ajungeți la un aspect consistent. Un sistem de design are într-adevăr un aspect de prezentare, dar este și despre funcție și integrare. Este vorba despre experiență .

• Experiența utilizatorului
  Cu o interfață de utilizator fiabilă și consecventă din punct de vedere funcțional.
• Experiență de dezvoltator
  Cu componente ușor de integrat și modele definite.
• Experiența părților interesate
  Cu o privire de ansamblu asupra modului în care produsul evoluează și crește.

Cu atât de multe piese în mișcare, este de înțeles că nu există un singur răspuns pentru toate sistemele de proiectare.

Intenționat vs organic

Când o echipă decide să creeze un sistem de proiectare, există două abordări în care trebuie să decidă din timp:

• Organic
  Luați o aplicație existentă ca referință, extrageți bucăți din ea și extrageți-le suficient pentru a fi utilizate de o altă aplicație. Această abordare implică mai puține decizii de la început, dar necesită un efort mai reactiv din partea echipei pentru a se adapta cerințelor nou găsite de adoptatori. Deciziile arhitecturale tind să fie luate pe măsură ce apare nevoia, nu în mod proactiv.
• Intenționat
  Jetoanele, modelele și componentele sunt gândite din timp. Sunt definite limitele unui produs minim viabil (MVP) și începe munca. Pentru această abordare, a avea obiective și cerințe este un pas important pentru a alinia așteptările cu părțile interesate.

Organic

Când permiteți sistemului de proiectare să se dezvolte organic, succesul demersului se rezumă la acceptarea părților interesate și a adoptatorilor. Și cât de eficient va fi capabilă să reacționeze echipa în timp ce evacuează toate necunoscutele pe care le găsesc pe parcurs, fără a fi excesiv de perturbatoare, cu sprijin continuu. Este un drum dificil și comunicarea este cheia. Nu există o cale clară de acțiune, deoarece este strâns legată de contextul echipei.

În plus, este greu de modificat ca sistem în timp ce acesta funcționează (adresați-vă electricianului local) și, deoarece sarcinile necesită timp, cerințele se pot schimba: piața nu va aștepta biblioteca dvs. de componente. Un moment obișnuit de tip „make it or break it” pentru un sistem de design organic este aflarea poveștii de dezvoltare a unui MVP (produs minim viabil) al componentelor.

Pe de o parte, avem dezvoltatori și designeri care doresc să creeze cea mai bună experiență posibilă și calitatea codului prin excelență; pe de altă parte, există KPI-uri, ROI-uri și banda sa de acronime pentru a măsura succesul. Găsirea echilibrului și a rămâne scalabil este dificil. Cum să abstrageți ceva neterminat este și mai dificil, iar evitarea ca aceste sarcini ulterioare să fie uitate la întârziere este problema de un milion de dolari a managementului produsului.

Capacitatea de a repeta rapid și progresiv pe sistemul dvs. de proiectare devine o cerință de bază atunci când aveți de-a face cu abordarea organică. Și necesită, de asemenea, un nivel suplimentar de claritate din partea dezvoltatorilor tăi consumatori (în cazul în care există echipe separate: una creează sistemul de proiectare, cealaltă creează caracteristicile produsului). Ambele trebuie să alinieze în mod clar așteptările cu privire la cerințele de produs și la cerințele experienței dezvoltatorului pentru a avea o simbioză adecvată. Pentru că un sistem de design nu este nimic dacă este enervant de utilizat sau dacă înrăutățește în vreun fel experiența utilizatorului.

Intenționat

Există mult mai multă planificare necesară, necunoscute care trebuie eliminate și infrastructură de pregătit atunci când faceți alegerea conștientă de a construi sistemul de proiectare înainte de a avea un produs pe care să îl utilizați. Reversul aduce mai multă claritate cu constrângeri. obiective și așteptări. Dacă pânzele sunt verificate de două ori înainte de a părăsi portul, furtuna este mai puțin înspăimântătoare.

Previzibilitatea sistemului crește, de asemenea, atunci când se planifica în viitor, și asta pentru că sistemul de proiectare devine propriul său produs și nu instrumentul pentru a-i face pe alții mai buni. Cu această abstractizare, modelele și soluțiile folosite în altele sunt mai ușor de transportat.

Deși alegerea intenționată în locul organic poate părea contraproductivă la început pentru echipele cu mai puțină experiență, deoarece nu au o dovadă de concept pe care să o testați, este deosebit de util să evitați capcanele comune atunci când începeți. „Stand pe umerii giganților” este un jargon comun și este adevărat în acest caz. Așadar, cea mai bună rețetă ar trebui să fie aproximativ:

1. Identificarea cerințelor de bază;
2. Cercetați din timp și amănunțit pentru cazuri similare;
3. Scoateți rezultatele din 2 pentru soluții și strategii implicite;
4. Fă-ți totul personal prin asamblarea unei combinații de soluții comune și adăugând propriul sos;
5. Repeta.

Acești cinci pași pot suna simpli și evidenti, dar nu sunt. Este ușor să sări peste una dintre adunările de cerințe sau să scurtezi cercetarea. Sfat, totuși: veți plăti dobândă la pasul 4 dacă ați uitat oricare dintre acestea.

Construiți pentru eficiență

Niciun pachet nu se bucură de consumator când o actualizare a dependenței îi distruge aplicația în vreun fel. Nu este diferit atunci când pachetul în cauză face parte dintr-un sistem de proiectare. De fapt, s-ar putea sublinia că este mai rău. Reacția unei dependențe interne care distruge o aplicație tinde să fie mai mare decât atunci când este un pachet open-source, în plus, modificările UI tind să se „rupă în tăcere” mai întâi în fața utilizatorilor finali: ceea ce este deosebit de frustrant.

Având în vedere acest lucru, putem deja alinia câteva probleme:

• Documentația API
  Faceți-l ușor de descoperit și utilizat.
• Versiune
  Indică modul în care se preconizează că lansările vor avea impact asupra consumatorilor.
• Jurnalul modificărilor
  Indică ce modificări aduce fiecare lansare.
• Eliberarea
  O modalitate sănătoasă de a păstra codul stabil ușor de livrat pentru toți consumatorii.
• Mediu de dezvoltare
  Nu există încă nicio aplicație care o folosește, trebuie să-și dea seama cum să prezinte și să dezvolte artefacte.

Important de subliniat, cât de prioritară este fiecare dintre aceste articole poate varia în funcție de kilometrajul dvs. Dar necesitatea acestora va crește pe măsură ce sistemul de proiectare crește, crește adoptarea și caracteristicile cresc. S-ar putea să nu fie suficiente pentru a împiedica o echipă să avanseze, dar cu siguranță vor împiedica productivitatea dacă capacitatea este distorsionată pentru a găsi acele soluții.

Sursa-Adevărului

Un alt eventual punct de durere cu care se confruntă multe echipe este identificarea sursei adevărului într-un sistem de proiectare. Este cod, interfață de utilizare sau documentație? Pentru multe tipuri de produse, ne uităm doar la partea consumatorului și putem identifica cu ușurință care este rezultatul principal. Motivul pentru care devine dificil în acest caz este că fiecare tip de consumator îl va folosi diferit și, prin urmare, răspunsul va varia în funcție de demografia cerută.

Un sistem de proiectare este adesea o combinație între o bibliotecă de componente, documentație și un ghid de stil. Și nu numai consumatorul este diferit pentru fiecare dintre aceste artefacte, ci și meșterul este diferit. Un dezvoltator, un designer, un scriitor tehnic; vor fi necesare persoane diferite pentru a crea fiecare ieșire.

Cartof fierbinte

Pentru a menține livrarea consecventă, comunicarea și colaborarea sunt esențiale. Și procesul de tip cascadă deja stabilit nu este încurajator pentru nici unul.

Nu există un spațiu proiectat (cu joc de cuvinte) pentru colaborare sau iterare pe baza fiecărei specialități. Adesea, designerul nu este conștient de anumite limitări ale codului, iar dezvoltatorul nu are nicio idee despre UX-ul destinat rezultatului. Această abordare nu este extrem de prejudiciabilă, este posibil să se creeze un produs bun cu ea. Dar unul grozav este greu, fiecare parte a procesului este aproape deconectată, dacă echipa nu face un efort activ pentru a o corecta.

Mereu uimitor Dan Mall și Brad Frost au inventat numele la fel de grozav pentru un nou proces: Hot Potato. Acest proces nu numai că încurajează comunicarea, ci și impune direct colaborarea echipei prin unificarea sursei adevărului muncii. Prin urmare, nu numai că fiecare artefact livrat are o origine comună, ci și un produs al experienței echipei combinate.

Cu toate acestea, a face acest tip de colaborare fără fricțiuni este mai ușor de spus decât de făcut. Chiar și stând unul lângă altul pentru a evita „sunteți dezactivat”, „conexiunea mea s-a întrerupt” și „mă auzi?” supărări, atunci când este amplasat, schimbul de informații tinde să devină informal cu ușurință, iar apoi procesul poate ajunge greu de documentat sau prea sincron. Vrem mai puține blocaje, nu mai multe.

Colaborarea live a ajuns la mare măsură între colegi. La fel ca VSCode Share sau FigJams de la Figma, IDE-uri cloud, există multe opțiuni. Dar când vine vorba de iterare între diferite specialități, nu este foarte simplu. Adăugați acest lucru la grămada de instrumente, arhitectură sau procese menționate în secțiunile anterioare și aveți o grămadă de muncă de făcut chiar înainte de a începe să lucrați.

Arhitectarea unui sistem

După cum sa menționat mai sus, menținerea unui sistem de proiectare este multă muncă. Cel mai bun sfat este probabil să încercați și să nu faceți lucrurile de la zero ori de câte ori este posibil. Folosiți resursele comunității acolo unde este convenabil. Procedând astfel, veți compensa mai puțin timp pentru a menține anumite puncte ale sistemului și va ajuta inginerii și proiectanții la bord dacă sunt deja familiarizați cu anumite părți ale sistemului.

Intră lumina de fundal. Este o platformă ca serviciu care reunește o serie de instrumente într-un mod obișnuit, dar flexibil, pentru a accelera întreaga configurație a arhitecturii. Puteți fie să începeți de la zero, fie să alegeți un șablon de pornire care se potrivește cel mai bine proiectului dvs. Nicio roată nu este reinventată dacă nu este complet necesară, folosesc resursele comunității în toate starterele lor (cel pe care l-am încercat, Yogi, se bazează pe ChakraUI), mai puțină întreținere pentru ele, iar consumatorul nu-și face griji să fie blocat. În plus, codul va fi trimis către platforma dvs. de versiuni, deci sunt doar câteva comenzi shell distanță de a fi mutate dacă este necesar.

Odată ajuns acolo, va aranja integrarea cu o platformă de versiuni (sunt acceptate Gitlab și GitHub), un sandbox bazat pe Storybook, un IDE bazat pe VSCode, teste unitare și chiar publicarea în registrul NPM (acest ultim va depinde de planul dvs. cu ei, acesta poate fi în contul dvs. sau al lor).

Ieșiri multiple

Am mapat anterior, există cel puțin 3 ieșiri diferite pe care majoritatea sistemelor de proiectare necesită: documentație, cod, interfață cu utilizatorul. Odată ce arhitectura este gata să producă fiecare dintre ele, echipa descoperă de obicei o altă provocare: menținerea lor sincronizată. Dezvoltatorii sunt întotdeauna dornici să facă schimbări atomice, atingeți un loc și se răspândesc în fiecare loc consumând acele informații. În cadrul unui sistem de proiectare, acest lucru nu este întotdeauna clar cum să se realizeze.

Dacă nu urmați procesul Hot Potato, este ușor să pierdeți evidența actualizărilor UI care au fost deja abordate de dezvoltatori. Și chiar dacă o faci, atunci există documentație. Iluminarea de fundal abordează această problemă prin alinierea tuturor.

Și odată ce modificările sunt făcute, fără a părăsi tabloul de bord al platformei. Este posibil să verificați documentația live actualizată.

Și toate acestea nu fac decât să zgârie suprafața cu ceea ce vă pot îmbunătăți arhitectura. De asemenea, primești:

• Testarea capturii de ecran pentru Pull Requests cu funcția lor „Vizual Review”.
• Suport pentru dezvoltare bazată pe teste cu teste unitare încorporate
• Sandbox cu previzualizare live

Este un mediu de dezvoltare complet pentru sistemul dumneavoastră de proiectare. Și încă primești toate acele integrări, chiar dacă decizi să nu folosești starter-ul lor. Infrastructura este acolo pentru a construi biblioteca de componente care vă va alimenta sistemul de proiectare de la zero.

Colaborare la distanță în timp real

După cum am menționat anterior, Procesul Hot Potato poate deveni deranjant pentru echipe pentru a configura un mod de lucru la distanță și asincron. Iluminarea de fundal abordează acest lucru cu o combinație de două caracteristici:

• Integrarea designului;
• Distribuie un link live.

Integrarea designului aduce artefactul de design din instrumentul dvs. de proiectare în cadrul aceleiași platforme. Astfel, restul echipei poate căuta, adăuga comentarii și poate consulta lucrări direct din același tablou de bord:

Cu această caracteristică, procesul de cartofi fierbinți începe chiar de la planșa de desen, indiferent unde se află echipa ta. Și fără a comuta filele, ușurează și înainte și înapoi procesul de codare cu funcția de partajare a linkurilor, mai bine explicată cu gif-ul lor promoțional decât orice aș putea face eu. Dezvoltatorii pot partaja o legătură de la distanță în timp real a muncii lor, fără a publica lucruri oriunde, fără procese intermediare, acesta este un mare impuls pentru echipele care trebuie să repete rapid lucrările detaliate.

Concluzii

În cazul în care nu a fost încă, sperăm, acum este mai clar ce presupune crearea și întreținerea unui Sistem de proiectare. Mult mai mult decât o mână de clase CSS, definiții de token și fonturi; este instrumente, sprijin activ și advocacy. Utilitatea unui proiect este dictată de calitatea rezultatelor sale și de cât de repede se poate adapta la cerințele în continuă schimbare.

Deci, dacă nu altceva, pregătiți-vă pentru a fi productiv și eficient atunci când vă creați proiectul. Dacă încă vă găsiți terenul, instrumente precum Iluminarea de fundal vă vor ajuta cu setări implicite sensibile și cu o experiență excelentă pentru utilizator. Dacă sunteți deja condimentat cu o arhitectură specifică, alegeți-vă bătăliile cu înțelepciune și folosiți comunitatea pentru a se ocupa de restul.