Dizajneri su iz Saturna, programeri iz Jupitera: ili, zašto je komunikacija bitna

O "Ali to izgleda drugačije u efektu Specifikacije", korisničkim sučeljima alata i drugim stvarima.

Dva različita planeta, ali barem su u istom Sunčevom sustavu! I to je kraj analogije sa planetima.

Savjeti za alergije

Ovo je članak o dizajnerskim sustavima, posebno na temu UI alata i dinamike komunikacije između dizajnera i programera.

Dizajneri, nešto mi govori da znate za Design Systems i da ih možete iskopati :) U slučaju da želite pročitati više, Nathan Curtis je puno napisao o tome. Volim i poštujem njegov rad na dizajnerskim sustavima.

Razvojni programeri, pokazat ću na kraju neki kôd. Igralište je aplikacija React + CSS-u-JS (poput emocija ili styled-komponenata).

Neka vrsta tipičnog scenarija

Naš dizajner stvorio je niz lijepih dizajna, uključujući izgled naše stranice Dokumenti:

https://www.sketchappsources.com/free-source/2576-ooto-productivity-dashboards-sketch-freebie-resource.html

Čisto je, uravnoteženo, nekako je ugodno za oko. Za dizajnere ovo je vrhunac dugog procesa, čitavog niza zadataka koji uključuju istraživanje, intervjuiranje, razmišljanje, pregled, ponovno razmišljanje, rad na ploči, izradu prototipa i žičarenje. Zastrašujući dug i mučan proces kojem programeri često nisu izloženi.

Kako su dizajneri uopće stvorili tu sliku? Vjerojatno su koristili priručnik za dizajn. Vrlo popularan je Sketch.

Jao, način rada ovog softvera dijametralno je suprotan načinu na koji rade programeri. I kažem da je to suština naše stvari.

Dizajneri trebaju alate koji im omogućuju brzo ponavljanje, pregled i ažuriranje, povratne informacije nakon povratnih informacija, sastanak jednog od dionika za drugim. Dizajneri trebaju alate poput Sketch.

Programeri, s druge strane, rade drugačije.

Oni rade na stalno promjenjivim bazama podataka koje u bilo kojem trenutku moraju stvoriti radno izdanje aplikacije. Potrebni su napori za implementaciju izgleda poput onog iz našeg primjera, projektiranje, apstrahiranje, implementacija, refaktoring, testiranje, pregled, refaktoring, ispravljanje pogrešaka, refactoring. Razvojni programeri moraju biti sigurni da ne prekidaju ništa drugo niti onečišćuju bazu koda lošim, dupliranim kodom.

Meni je biti dizajner više poput skakanja naprijed i naprijed, dok programeri rade u neprekidnom petlji razvoja.

Datoteka Visual Spec

Sada je vrijeme da dizajneri komuniciraju s programerima, predaju palicu.

Postoje nacrti, razmaci i boje (i tako dalje) koji se moraju dokumentirati. Skica ili bilo koji drugi alat ne zna mnogo o vašoj trenutnoj bazi podataka, vašoj datotečnoj strukturi ili apstrakciji, pa što može učiniti Sketch? Izmjerite stvari. A to će se proizvesti:

Nekoliko dana prođe ...

Stvari su spremne i dizajneri to prvi pogledaju:

Frustrirani dizajneri, frustrirani programeri.

To je trenutak kad je zadivljenost zaista slomljena. Datoteka Spec. Mali problemi s bojom, razmakom, tipografijom, izgledom, pogrešno komuniciranim detaljima, nedostajućim ponašanjima.

Razvojni programeri morat će protumačiti i prilagoditi specifikacije vlastitom sustavu u kodnoj bazi kad bi se samo trebali brinuti oko implementacije poslovne logike nove značajke. Dizajneri ipak nisu krivi - možda jednostavno ne znaju za takav sustav.

Moj djed je govorio:

Kad dizajneri i programeri ne komuniciraju dobro, nabavite dizajnerski sustav s dobro podijeljenim i komuniciranim nizom alata, apstrakcija i ograničenja.

Trebate dobar UI Toolkit

Dizajneri i programeri mogu učinkovito komunicirati bez stresa kroz zajednički sustav. Cilj UI Toolkit je ojačati principe dokumentirane u sustavu dizajna. Njime upravlja visoko podijeljeni i dokumentirani skup konvencija, UI obrazaca, ponašanja i svi su ga osmislili, testirali i dogovorili. Tu se susreću napori dizajnera i programera.

Zašto vam stvarno treba dobar alat za korisničko sučelje

  • Postaje li vaša aplikacija sve složenija?
  • Govore li dizajneri prilično puno o nedosljednostima u aplikaciji?
  • CI / CD-a? Brzo idete brzo?
  • Daljinski timovi?
  • Malo se zabrljate s tim CSS datotekama?
  • Počinjete brinuti o veličini aplikacije?
  • Je li korisničko iskustvo srž vašeg poslovnog modela?

Ne morate sve to označavati - čak i jedno može biti dovoljno :)

Zašto trebate svoj vlastiti korisnički priručnik za korisničko sučelje

Sustav dizajna govori o jeziku. Vizualni jezik, jezik dizajniranja UI, itd. Potrebno je mnogo napora da definirate svoj vlastiti: proizvod, dizajn, inženjering, svi će ti odjeli biti jako uključeni.

Puno puta to nije održiva opcija. Postoje nevjerojatni okviri, semantički-ui, ant-dizajn, Bootstrap, Material-UI. Svi oni dolaze s svojevrsnim unaprijed napravljenim Language i bitkom testiranim UI Toolkitom, spremnim za upotrebu.

Ulov? Po mom iskrenom mišljenju, uskoro vam više neće odgovarati. Htjet ćete ih izbjeći. Usto, skupovi korisničkih sučelja vjerojatno su toliko dizajnirani da ih je teško kontrolirati. Imajte na umu da su ti okviri napravljeni da prođu bezbroj slučajeva, možda i više nego što vam treba. Uz to se ova dodatna složenost plaća i u kb.

Ukrasti kao umjetnik

Ne prihvaćajte UI Toolkit. Kopirajte od drugih, a time mislim na one koji vam najviše odgovaraju i implementirajte ih ispočetka. Sada je uobičajeno da tvrtke s visokim brojem korisnika imaju vlastiti sustav dizajna, a mnoge od njih su otvorene!

Pogledajte ovaj popis dizajnerskih sustava: https://adele.uxpin.com:

  • BBC: Gel
  • Trello: Nachos
  • Salesforce: Munja

i još desetaka. I na kraju, sve je stvar zajedno dizajnirati i dostaviti. Radi se o tome da izgradite nešto specifično za vašu domenu, također jedinstvenu i reprezentativnu za vašu marku. To je nagrađujuće, a možete dobiti i lijepo ime :)

Napravimo jedan

Pokazat ću vam kako je lako pokrenuti vlastiti sustav dizajna.

Nazvat ću ga Larry.

Uzmimo mali dio našeg izgleda i pokušajmo ga izgraditi ispočetka:

Najprije krajnji rezultat

Sljedeći CodeSandbox jedina je aplikacija na svijetu koja implementira Larryja:

Larryja možete pronaći na GitHubu: https://github.com/albinotonnina/larry

Dokumentacija

Ovaj je bit najvažniji. Tko je zadužen za to, možda dizajneri? Pa obično da, ali vjerujte mi u ovome: oboje biste trebali biti jednako uključeni u dokumentiranje svog jezika. Oboje biste se trebali dogovoriti o doslovno svemu.

Počnimo s definiranjem nekih stvarno osnovnih konvencija:

boje

Kreirajmo paletu za naš izgled.

Predlažem vam da definirate niz semantičkih imena iz ovih boja, poput:

headerText = JapanIndigo
stavkaText = JapanIndigo
elementBackgroundDefault = Snijeg
elementBackgroundHover = Briljantan Azur
elementButton = LightGray - alfa 60%

Ovo su imena koja ćete oboje upotrijebiti za vrijeme traženja (što je riječ).

razmak

Obratite dodatnu pozornost na razmak. Bez jasne strategije za razmak, stvari mogu poći po zlu.

Definirajte i dogovorite sustav za razmak, na primjer:

Datoteka spec izgledala bi ovako:

Tipografija

Osigurajte da se veličine fonta, težine fonta, visine linija, margine, boje u vašim naslovima, odlomci i tako dalje podudaraju. Nazovite ih imenima koja vam se sviđaju, npr. HeaderHuge, HeaderLarge, HeaderTiny ili pravilno koristiti semantičke oznake (h1, h2, h3). Samo se pobrinite za to.

obrasci

Što se rima s UI Toolkit? Biblioteka uzoraka! Morate početi puštati svoju biblioteku uzoraka. Ono što želite je da se komponente koje trebate ponašaju onako kako ste dogovorili kako biste ih mogli sastaviti onako kako želite, u bilo kojem trenutku.

Počnite od čestica i primitiva, kao što je takva komponenta Boxa, kada morate postaviti razmake i obrube oko nečeg drugog.

Dodajte više specijaliziranih novih čestica, kao što je Text Text ili Flex komponenta, koje biste mogli zamisliti kao Box komponentu + neke fleksibilne alate.

Pogledajte ih kao čestice koje žive u izolaciji, nesvjesne konteksta u kojem će se koristiti i prostora koji bi trebao postojati oko njih.

Nastavite s složenijim UI komponentama, kompozicijama drugih najmanjih komponenti i tako dalje.

Ono što je ovdje važno nije tehnologija ili vrsta apstrakcija koje se nalaze u vašoj dokumentaciji. Ono što je važno jeste da to radite zajedno.

Primjer složenije komponente UI

Shvaćaš li suštinu?

Definirali ste konstante i imate neke čestice koje treba izgraditi.

Ponovno ćete ponoviti te čestice i prilično brzo proširiti knjižnicu, pa zagrlite i pripremite se za elastičnost. Programeri, ne želite da dizajneri završe dokumentiranje cijelog sustava prije nego što počnu implementirati kôd. To morate učiniti zajedno ili se neće jednostavno poleteti.

Dakle, dizajneri i programeri, odmah nakon članka, napravite svoj Larry ako ga nemate!

Kodirati

Imate kopiju Larryja, možete se klonirati i igrati se s njom. Vaš Larry se može razlikovati ili možda koristite različite okvire, tako da ću proći kroz ključne točke ovog pristupa.

Tema, definirajte konstante

To je objekt s našim konstantima tema, pa razmake definiraju, boje, fontove, tipografiju, točke prekida, bilo šta. Evo teme Larryja, a evo i primjera njegove verzije:

Nema ograničenja u složenosti / cjelovitosti koju ovdje možete postići, nakon što je stvar generiranja JavaScript objekta, zamislite što biste mogli učiniti!

Ovo je osnovna datoteka. Svaka boja, rub ili podloga, veličina fonta ili težina fonta ili prijelomna točka moraju potjecati odavde i samo odavde.

CSS-in_JS knjižnice su nevjerojatni alati, a stilski ih sustav čini još boljim. To je skup alata za Dizajnerske sustave, a sastoji se od funkcija koje uzimaju rekvizite kao argument i vraćaju objekte u stilu, pojednostavljujuće korištenje vrijednosti iz teme i primjenu stilova odgovorno na prijelomne točke.

Ovaj pristup iskoristi ove uslužne programe, pa ga slobodno procijenite.

Uključite temu u svoju aplikaciju

Navedite te konstante svojoj aplikaciji: svaka komponenta aplikacije imat će pristup našim tematskim konstantama.

Stvorite osnovne komponente korisničkog sučelja

primitivna komponenta korisničkog sučelja okvira

Više specijaliziranih komponenti korisničkog sučelja

Evo Flex komponente.

Implementirajte komponente UI u datotekama značajki

Vrijeme je za nešto napraviti

Ovdje implementirate svoju korisničku sučelje i poslovnu logiku.

Struktura datoteka

Ovo je Larryjeva datoteka datoteke. Nemam čvrsta mišljenja o datotečnim strukturama, zapravo vjerujem u nešto drugačije: premještajte datoteke dok se s njima ne osjećate ugodno.

Larry je sve u mapi „dizajn-sustav“. Ovdje možete pronaći njegove konstante i generičke UI komponente koje se mogu ponovo koristiti.

Primijetite i mapu korisničkog sučelja u mapi Izgled dokumenta - tu definiram i izvozim komponente korisničkog sučelja specifične za našu značajku.

Zaključak

S velikim i složenim aplikacijama nikada nije jednostavno održavati sučelje dosljednim i kohezivnim. Sustavi dizajna pomažu. Sustavi prilagođenog dizajna i prilagođeni UI alati za pomoć zaista pomažu.

Dizajneri i programeri mogu imati vrlo različite pristupe istom problemu, ali to ne znači da ne mogu učinkovito komunicirati.

https://dribbble.com/shots/2712522-Designer-vs-Developer

Hvala na čitanju

Imate li pozitivna iskustva za dijeljenje? Molimo da to učinite u komentarima.

Pozdrav, ja se zovem Albino Tonnina, ja sam softverski inženjer koji radi u Londonu, možete me naći na Twitteru ili Githubu, Instagramu ili gradu.

Moji najnoviji članci

Kako izgubiti IT posao u 10 minuta
Kada govorimo o web izgledima ... uvodeći tehniku ​​Magic Hat

Slijedite me na Twitteru!