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

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

Dizajneri i frontend developeri do krajnjeg rezultata svog rada dolaze na skroz drugačije načine i često sami dizajn drugačije interno percipiraju. No, ako svoj posao dobro odrade, krajnji rezultat rada frontend developera savršeno će zrcaliti rad dizajnera...

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.

“The prickly people are tough-minded, rigorous, and precise, and like to stress differences and divisions between things…. The gooey people are tender-minded romanticist who love wide generalizations and grand syntheses” ~ Alan W. Watts

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.

You wouldn’t know what a prickle was unless you knew what a goo was. Because life isn’t either prickles or goo, it’s either gooey prickles or prickly goo.

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.

https://www.netokracija.com/newsletter

Pravila ponašanja

Na Netokraciji za vas stvaramo kvalitetan, autorski potpisan sadržaj i zaista se veselimo vašim kvalitetnim, kontruktivnim komentarima. Poštujmo stoga jedni druge prilikom komentiranja držeći se sljedećih pravila ponašanja:

  • Ne budite 💩: Nema vrijeđanja, diskriminiranja, ni psovanja (osim ako nije osobni izričaj, ali onda neka psovka bude općenita, a ne usmjerena prema nekome)
  • Samo kvalitetna rasprava, manje trolanja: Ne morate se ni sa kim slagati, ali budite konstruktivni i doprinesite raspravi! Svako trolanje, flameanje, koliko god "plesalo" na granici, leti van.
  • Imenom i prezimenom, nismo Anonymous 👤: Autor sadržaja stoji iza svog sadržaja, stoga stojite i vi iza svog komentara. Koristimo ime i prezime (Hrvoje Lončar) ili barem ime i inicijala (Hrvoje L.) te pravu email adresu. Kako koristimo podatke koje tamo ostavljate? Bacite oko na našu izjavu o privatnosti.

Sve ostale komentare ćemo s guštom spaliti, jer ne zaslužuju svoje mjesto na internetu.

Komentari

  1. Borna

    Borna

    20. 07. 2021. u 1:32 pm Odgovori

    Radim front i dizajn već više od 10 godina, ali ja ne razumijem što je pjesnik htio reći. Više mi ovo vuče na teoriju, a manje na stvarna iskustva s dizajnerima i projektima. Nikad mi nije palo na pamet davit dizajnere s typescriptom, pretočim dizajn u dynamic styleguide component library, ali i to samo za veće projekte. Također imenovanje komponenti je moja odgovornost, ne dizajnera, a i to nije znanost jer postoji bootstrap gdje se može može kopirati najbolja praksa imenovanja komponenti za veliku većinu njih ako već idemo u smjeru generičkih naziva tipa “Card”, “Button”, “Footer” itd.

Odgovori

Tvoja e-mail adresa neće biti objavljena.

Popularno

Tehnologija

Brate, trebam li stvarno uzeti Šaomi?

Xiaomi je u relativno kratkom vremenu postao brend koji se daleko najviše preporučuje u Hrvatskoj i regiji. Zašto?

Kolumna

Što će nam uopće kriptovalute?

Iako o kriptovalutama slušamo već godinama, rijetko kad nam je netko dao suvisao odgovor na pitanje, a što će nama kriptovalute zapravo? U vremenima kada se centralizirani sustavi poput banaka igraju s našim povjerenjem, nikada nije bilo jasnije. Evo odgovora...

Izrada web stranica

Kad vam u 2021. padne server, što očekivati od svog hosting poslužitelja?

Po muci se poznaju junaci pa tako i hosting poslužitelji. Kako izgleda posao s druge strane vašeg weba, otkrili smo.

Što ste propustili

Startupi i poslovanje

Head of Growth: Ima li takvih superjunaka u Hrvatskoj?

Domaćim tehnološkim tvrtkama ojačanima investicijama na putu prema rastu trebaju iskusni multidiscplinarni stručnjaci koji će taj rast ubrzati. Analiziramo kako Head of Growth razmišlja, što treba znati te gdje ga i kako naći, a svoja razmišljanja dali su i Filip, vlasnik growth agencije te Tana, suosnivačica Bazzara, koji upravo zapošljava jednog.

Sponzorirano

eCommerce nakon pandemije? Najveće okupljanje industrije otkriva nam korijenske promjene

Svjedoci smo povijesnih preokreta u digitalnoj trgovini i promjena koje će imati dalekosežne posljedice. Kako se pripremiti za postpandemijski svijet eCommercea, Neuralab ekipa donosi saznanja sa središnjeg eCommerce događaja - RetailXa u Chicagu.

Startupi i poslovanje

Superology i Sportening: Želimo odgajati vrhunske product managere u Hrvatskoj

Jedan je prošao put od programera preko 'Katice za sve' do voditelja razvoja proizvoda, a drugi je nakon doktorata i akademske karijere u Kaliforniji radio u Googleu u Zürichu pa se vratio u Zagreb biti suosnivač startupa. Otkrili su nam što čini dobrog product managera, što dobri produktni tim i koji je najkraći put do inovacije.

Kultura 2.0

Velimir Grgić: “Ljudski mozak (i sve njegove mane) postao je transparentniji nego ikada, a sve zahvaljujući internetu.”

Velimir je kao novinar, pisac, scenarist i producent prošao zbilja sito i rešeto toga, ali teorije zavjera ostale su mu trajna inspiracija još od ranih dana. Zašto itko promišlja o zemlji koja je ravna ploča, hoće li teoretiziranje o zavjerama ikada prestati te koja teorija je njemu osobno najintrigantnija - saznali smo od autora netom rasprodane knjige "Teorije zavjera 21. stoljeća".

Društvene mreže

Book Tok ili kako je Tik Tok knjige učinio ponovno modernima

Kako se dogodilo da je upravo Tik Tok, društvena mreža kratkih i dinamičnih videa, za koju smo mislili da će potpuno uništiti fokus i pažnju djeci i mladima, učinila upravo suprotno, potaknula ih da - čitaju!

Startupi i poslovanje

Od design-driven do data-driven tvrtke, kako je Score Alarm postao Superology

Superology će uskoro napuniti 10 godina, no njihov rebrending odvio se ne samo ususret toj velikoj obljetnici već kao posljedica rasta tvrtke koja je doktorirala razvoj digitalnog proizvoda u svom području.