Frontend developeri i dizajneri, detaljno postavljanje dizajnerskog sustava olakšat će vam svima život!

Svaki dizajn analizom možemo rastaviti na proste faktore, uvijek možemo razaznati specifične elemente korisničkog sučelja, obrasce dizajna korisničkog iskustva i dizajn tokene koji se kroz cijeli taj dizajn provlače i ponavljaju. Možemo definirati okvire i ograničenja dizajnerskog sustava (design system) u tome kako se u dizajnu korištene boje, tipografija i sl.

Na neki način svaki dizajn u sebi ima implicitno ugrađen određeni sustav, taj sustav možda nije namjerno, direktno definiran i komuniciran kroz dizajn fazu projekta, ali svejedno, sam po sebi on komunicira svoje specifične obrasce i okvire koji mu daju njegov identitet.

Te obrasce i okvire programeri interpretiraju i oni postaju obrasci i okviri arhitekture koda.

Za većinu manjih projekata eksplicitno definiranje i dokumentiranje dizajnerskog sustava možda nije nužno. Ako su promjene na projektu s vremenom rijetke i nisu zahtjevne, relativno je jednostavno postići da sve ostane u harmoniji sa svim ostalim što se tu već nalazi i sa strane dizajna i sa strane koda.

S druge strane, za velike projekte, koji će se dugo razvijati i evoluirati kako vrijeme bude prolazilo, kako dodajemo nove mogućnosti i dok se dizajneri, programeri i ostali uključeni izmjenjuju u međuvremenu, lako se izgubi konzistencija u dizajnu, izgubi se organiziranosti i održivost koda, a možemo i narušiti dojam identiteta brenda i upotrebljivost aplikacije krajnjim korisnicima.

Pronalaženje zajedničkog jezika

Frontend programeri i dizajneri pronalaze se u zanimljivoj jukstapoziciji, ako svoj posao dobro odrade, na površinskoj razini rezultat rada frontend developera savršeno će zrcaliti rad dizajnera, ali dizajneri i developeri do krajnjeg rezultata svog rada dolaze na skroz drugačije načine i često sami dizajn drugačije interno percipiraju.

Kako bi dizajnerski sustav stvarno bio koristan u praksi na našim projektima, dizajneri i frontend developeri trebaju surađivati i ulagati vrijeme u eksplicitno definiranje i dokumentiranje dizajn odluka, obrazaca i drugih elemenata dizajnerskog sustava.

U ovom članku želim ponuditi ideju inspiriranu “oblicima” u TypeScriptu, ideju za koju mislim da nam može pomoći da bolje komuniciramo i surađujemo na projektima postavljanjem zajedničkog jezika i mentalnog modela za koncepte koji postoje u korisničkom sučelju s obje strane zrcala, sa strane dizajna i sa strane koda.

Ideja je da definiramo “oblik dizajnerskog sustava” kao središnju reprezentaciju ukupnog dizajnerskog sustava koju je jednostavno održavati, unaprjeđivati i mijenjati.

Znači, želim dizajnere učiti typescript?

Ne baš, ali za potrebe ovoga članka ne bi škodilo da kratko objasnim što je to typescript i kako ga mi kao developeri koristimo.

Typescript je superset JavaScripta koji nama kao developerima omogućava da budemo strogi oko tipova podataka s kojima radimo.

S typescriptom možemo definirati recimo da se neka komponenta ne može prikazati bez da joj se dodjeli naslov, mora imati datum objave u specifičnom formatu i može, ali ne mora imati i svoju pripadajuću sliku.

Ako onda negdje pokušamo koristiti našu komponentu bez da joj damo naslov ili ako prekršimo neko drugo pravilo koje smo postavili za njene podatke, typescript će nas upozoriti i naša aplikacija neće raditi dok to ne ispravimo.

Ilustrativan način razmišljanja o ovom konceptu je putem analogije s dječjim igračkama koje uče djecu o oblicima. Djeca pokušavaju shvatiti kako upariti pripadajuće oblike i zaraditi jedno veliko ‘bravo’ kad oblici napokon sjednu na svoje mjesto.

Koncept oblika je jednako jednostavan i s typescriptom u našim komponentama: ako koristimo krivi oblik podataka u našoj komponenti, podatci jednostavno “neće proći” i typescript će nam dati informacije o tome što trebamo ispraviti.

Slične prednosti koje kao developeri dobijemo s typescriptom nam mogu biti korisne ako ih primijenimo ne samo na komponente nego i na cijeli dizajnerski sustav.

Kada definiramo oblike, garantiramo konzistentnost u tome kako se naše komponente mogu koristiti, omogućujemo da više developera može brzo razumjeti kako se komponenta koju je netko drugi razvio može i treba koristiti tako da pogledaju njen oblik (sučelje/interface).

Kada širimo funkcionalnost neke komponente, obično prvo krenemo širenjem njenog oblika, u slučajevima kada vidimo da oblik postaje prenapuhan i ima previše opcija, to nam može biti rani signal da bi trebali razmisliti o restrukturiranju koda.

Izborna traka? Siva traka? Administracijska traka!

Prije nego krenemo s razvojem želimo napraviti inventuru sučelja (interface inventory) – želimo pregledati cijeli dizajn i napraviti plan o tome kako želimo podijeliti stranice, layoute i elemente, kako ćemo ih nazivati i tako dalje.

Frontend developeri su ključni u ovom koraku, jer će producirana struktura biti nacrt za arhitekturu njihovog projekta, ali korisno je da se inventura sučelja radi s raznolikom grupom članova tima.

Najvredniji trenutci budu oni kad se različite perspektive sudare.

Parafrazirat ću primjer koji sam za čuo od Bred Frosta koji daje primjer projekta na kojem je dizajner mislio da je dizajnirao “izbornu traku”. Projekt menadžer je “izbornu traku” uvijek zvao siva traka, a u kodu ju je developer nazvao “administracijska traka”.

Kada inventuru sučelja radimo zajedno kao tim, to nam pomaže da uklonimo ili bar minimiziramo moguća nerazumijevanja koja se mogu pojaviti kasnije u razvoju.

Krajnji “opipljivi” rezultat inventure sučelja bi trebao biti jedan dokument koji je uvijek krajnji izvor istine definicija, naziva, hijerarhije i kategorizacije dijelova i cijele strukture našeg dizajn sistema.

Sljedeći primjer predočava generalnu ideju, ali može biti dodatno razrađen i modificiran za specifične načine koje bi odgovarale drugim timovima.

Prvo da objasnim što se tu gore događa za one koji možda nisu najbolji s typescriptom.

U našoj JSON definiciji jedan UIElement, opisujemo tako da mu damo ime, možemo ga dodati u kategoriju, može imati svoje manje dijelove od kojih se sastoji, možemo ga linkati na originalni dizajn te definirati o kojim drugim unutrašnjim i vanjskim skriptama te komponentama ovisi. UICategory tip nam samo pomaže da možemo rekurzivno definirati strukturu s koliko god levela dubine želimo.

Kao potencijalne dodatne informacije možemo ostaviti opciju dodavanja linkova na cijeli repozitoriji/dizajn/storybook, to kasnije može biti korisno, ali za potrebe ovog članka nije nam toliko bitno.

Prednosti JSON definicije… su mnogobrojne.

Uobičajen zadatak na radionicama izrade inventure sučelja bude da grupa dobije zadatak izrezati škarama elemente raznih stranica web sajta ili aplikacije i organizirati ih u kategorije. Sličan rezultat u digitalnom obliku najlakše možemo postići koristeći artboard bilo kojeg dizajn programa (veliki plus su alati koji omogućavaju kolaboraciju uživo – Figma, Miro…).

Umjesto rezanja škarama, dijelove dizajna možemo screenshotati pa grupirati, nazivati i lijepiti na artboard kako se zajedno dogovaramo tijekom procesa. Ako nakon toga rezultat našeg procesa prevedemo u JSON strukturu to nam otvara nekoliko zanimljivih mogućnosti. Primjerice, možemo kreirati skriptu koja bi nam na osnovi tog JSON-a pomogla pri kreiranju strukture projekta.

U primjeru JSON-a kojeg sam naveo imamo dovoljno informacija da naša skripta može kreirati datoteke svih komponenti, layoutova i stranica u mapama gdje se oni trebaju nalaziti. Ovisno o vašem CSS stacku, iz dizajn tokena možete generirati Sass varijable, tailwind konfiguraciju, custom varijable ili što god vam drugo može zatrebati za apstraktiranje tematskog sloja.

Istim principom taj JSON fajl može nam pomoći napraviti programatski test koji bi provjeravao da su struktura i naming pa čak i korišteni dizajn tokeni unutar projekta u skladu s definicijom u JSON-u i s time u skladu s dizajnerskim sustavom.

Održavanjem definicije dizajnerskog sustava ažurnom, prisiljavamo se da svaku novu izmjenu koju uvedemo, s ostatkom tima vidimo u kontekstu cijelog sustava. To nam pomaže da cijeli projekt ostane organiziran, konzistentan i održiv.

Ako JSON definiciju našeg dizajnerskog sustava držimo u repozitoriju zajedno s kodom, točno ćemo putem povijesti promjena moći vidjeti kako se dizajnerski sustav razvijao kroz vrijeme.

Inventura sučelja minimalan je, a ključan proces

Izradu inventure sučelja preporučio bi za svaki projekt koji se aktivno razvija, bez obzira započinje li tek sada ili postoji već neko vrijeme.

Ako se radi o postojećem projektu, bilo bi najbolje kad bi pokušali zaboraviti kako su različiti dijelovi već nazvani u kodu ili dizajnu i truditi se dokumentirati idealno stanje prema kojemu se želimo kretati, a ne samo dokumentirati ono što je već tu.

Kada se u budućnosti dogodi da se u dizajn primjeni neka nadogradnja ili u razvoju shvatimo da bi mijenjanjem strukture donijela neke prednosti, nove promjene bi trebali uvijek dokumentirati u JSON-u.

Ovisno o raznim faktorima, vrijeme koje ćemo na projektu posvetiti održavanju dizajnerskog sustava naveliko će varirati. Izrade inventure sučelja i održavanje samog JSON dokumenta ažurnim ne iziskuje puno vremena, a samo za sebe nam pomaže naći zajednički jezik među timom i držati projekt sistematiziranim i konzistentnim.

Vrijeme za skaliranje?

Kada bi naš dizajn sistem u svojoj implementaciju bio u potpunosti u skladu s JSON definicijom to bi uključivalo da korišteni design tokeni, komponente i sve njihove varijacije postoje jednako izdvojene, kategorizirane i imenovane i u kodu i u dizajn alatu, te dokumentirane kroz alat kao storybook i tako dalje ovisno koliko duboko u detalje na danom projektu u danom trenutku želimo ići.

Možda nikad ćemo dostići 100% usklađenosti dizajnerskog sustava, dizajna u našim dizajn alatima, u organizaciji koda i na samom živom proizvodu, ali dok god imamo definirano idealno stanje na jednome mjestu, imat ćemo bolju perspektivu iz koje možemo vagati koji dio vremena ulagati u dodatni razvoj i rast samog proizvoda, a koliki u usklađivanje i usavršavanje dizajnerskog sustava kako bi buduća unaprjeđenja bila što jednostavnija.