Cum pot dezvoltatorii de front-end să contribuie la realizarea decalajului dintre designeri și dezvoltatori

Publicat: 2022-03-10
Rezumat rapid ↬ Se știe că dezvoltatorii sunt, de obicei, ultimii care își lasă amprentele înainte ca un site web sau orice fel de produs web să fie livrat. Evident, este implicată multă responsabilitate, iar calitatea muncii lor poate fie să facă ca un proiect să exceleze, fie să iasă la gunoi. Acest articol oferă sugestii despre ce pot face dezvoltatorii de front-end pentru a reduce mai bine decalajul dintre designeri și dezvoltatori.

În ultimii nouă ani, aproape toți designerii cu care am lucrat și-au exprimat frustrarea cu privire la faptul că trebuie să petreacă frecvent zile întregi oferind feedback dezvoltatorilor pentru a corecta spațierile, dimensiunile fonturilor, aspectele vizuale și de aspect care pur și simplu nu fuseseră implementate corect. . Acest lucru a dus adesea la slăbirea încrederii dintre designeri și dezvoltatori și a cauzat designerilor nemotivați împreună cu o atmosferă proastă între cele două discipline.

De multe ori, dezvoltatorii par să aibă în continuare reputația proastă de a fi prea tehnici și ignoranți atunci când vine vorba de a fi atenți la detaliile pe care echipa de proiectare a venit. Potrivit unui articol al lui Andy Budd, „[…] mulți dezvoltatori sunt în aceeași poziție în ceea ce privește designul – pur și simplu nu își dau seama.” În realitate însă (după cum subliniază Paul Boag), „dezvoltatorii [trebuie] să ia decizii de proiectare tot timpul”.

În acest articol, voi oferi sfaturi practice pentru dezvoltatorii de front-end pentru a evita frustrarea și pentru a crește productivitatea atunci când lucrează cu omologul lor creativ.

Privind prin ochii unui designer

Să ne imaginăm pentru un moment că ai fost designer și ai petrecut ultimele săptămâni – dacă nu luni – pentru a elabora un design pentru un site web. Dumneavoastră și colegii dvs. de echipă ați trecut prin mai multe revizuiri interne, precum și prin prezentări ale clienților și a depus un efort serios pentru a ajusta detaliile vizuale, cum ar fi spațiul alb, stilurile de font și dimensiunile. (Într-o era receptivă - pentru mai multe dimensiuni de ecran, desigur.) Design-urile au fost aprobate de client și au fost predate dezvoltatorilor. Te simți ușurat și fericit.

Câteva săptămâni mai târziu, primiți un e-mail de la dezvoltator care spune:

„Site-ul de organizare este înființat. Iată linkul. Poți, te rog, QA?”

Într-un fior de anticipare, deschizi acel link de punere în scenă și după ce ai derulat unele dintre pagini, observi că site-ul arată puțin dezactivat. Spațierile nu sunt nici măcar aproape de ceea ce a sugerat designul dvs. și observați unele îndoieli în aspect: fețe și culori greșite, precum și interacțiuni incorecte și stări de trecere cu mouse-ul. Emoția ta începe să se estompeze încet și să se transforme într-un sentiment de frustrare. Nu poți să nu te întrebi: „Cum s-a putut întâmpla asta?”

Mai multe după săritură! Continuați să citiți mai jos ↓

Căutarea Motivelor

Poate că au existat doar o mulțime de neînțelegeri nefericite în comunicarea dintre designeri și dezvoltatori. Cu toate acestea, continui sa te intrebi:

  • Cum a arătat predarea modelelor? Au fost doar câteva PDF-uri, fișiere Photoshop sau Sketch partajate prin e-mail cu unele comentarii, sau a existat o ședință efectivă de predare în care s-au discutat diverse aspecte precum un posibil sistem de design, tipografie, comportament responsive, interacțiuni și animații?
  • Au existat prototipuri interactive sau în mișcare care ajută la vizualizarea anumitor interacțiuni?
  • A fost creată o listă de aspecte importante cu niveluri definite de prioritate?
  • Câte conversații au avut loc — cu designeri și dezvoltatori în aceeași cameră împreună?

Deoarece comunicarea și predarea sunt două puncte cheie foarte importante, să aruncăm o privire mai atentă asupra fiecăruia.

Comunicarea este cheia

Designeri și dezvoltatori, vă rugăm să discutați între ei. Vorbește mult . Cu cât este mai devreme în proiect și cu cât mai des, cu atât mai bine. Dacă este posibil, revizuiți împreună lucrările de proiectare în desfășurare la începutul proiectului (și în mod regulat) pentru a evalua în mod constant fezabilitatea și a obține contribuții interdisciplinare. În mod natural, designerii și dezvoltatorii se concentrează pe diferite aspecte ale aceleiași părți și, prin urmare, văd lucrurile din unghiuri și perspective diferite .

Verificarea din timp permite dezvoltatorilor să se familiarizeze cu proiectul, astfel încât să poată începe să cerceteze și să planifice din timp în termeni tehnici și să-și aducă ideile despre cum să optimizeze funcțiile. Înregistrările frecvente aduce echipa împreună la nivel personal și social și înveți cum să te abordezi pentru a comunica eficient.

Predarea de la proiectare la dezvoltare

Cu excepția cazului în care o organizație urmează un flux de lucru cu adevărat agil, o predare inițială a componentelor de proiectare și a activelor (de la echipa de proiectare la dezvoltatori) se va întâmpla probabil la un moment dat într-un proiect. Această predare – dacă este făcută minuțios – poate fi o bază solidă de cunoștințe și acorduri între ambele părți. Prin urmare, este esențial să nu vă grăbiți și să planificați ceva timp suplimentar.

Puneți o mulțime de întrebări și discutați despre fiecare cerință, pagină, componentă, caracteristică, interacțiune, animație, orice - și luați note. Dacă lucrurile nu sunt clare, cereți lămuriri . De exemplu, atunci când lucrează cu echipe externe sau bazate pe contract, atât designerii, cât și dezvoltatorii pot semna notele luate ca document de acord reciproc pentru referințe viitoare.

Compozițiile de proiectare plate și statice sunt bune pentru a afișa aspectele grafice și de aspect ale unui site web, dar, evident, le lipsește reprezentarea adecvată a interacțiunilor și animațiilor. Cererea de prototipuri sau demonstrații de lucru ale animațiilor complexe va crea o viziune mai clară asupra a ceea ce trebuie construit pentru toți cei implicați.

În zilele noastre, există o gamă largă de instrumente de prototipare disponibile pe care designerii le pot utiliza pentru a modela fluxurile și interacțiunile în diferite niveluri de fidelitate. Javier Cuello explică cum să alegeți instrumentul de prototipare potrivit pentru proiectul dvs. într-unul dintre articolele sale cuprinzătoare.

Fiecare proiect este unic, la fel și cerințele sale. Datorită acestor cerințe, nu toate caracteristicile conceptualizate pot fi întotdeauna construite. Adesea, timpul și resursele disponibile pentru a construi ceva pot fi un factor limitativ. În plus, constrângerile pot proveni din cerințe tehnice, cum ar fi fezabilitate, accesibilitate, performanță, utilizare și asistență între browsere, cerințe economice precum bugetul și taxele de licență sau constrângeri personale precum nivelul de calificare și disponibilitatea dezvoltatorilor.

Deci, ce se întâmplă dacă aceste constrângeri provoacă conflicte între designeri și dezvoltatori?

Găsirea de compromisuri și construirea de cunoștințe comune

Pentru a livra cu succes un proiect la timp și pentru a îndeplini toate cerințele definite, găsirea unor compromisuri între cele două discipline este în mare parte inevitabil. Dezvoltatorii trebuie să învețe să vorbească cu designerii în termeni non-tehnici atunci când le explică motivele pentru care lucrurile au nevoie de schimbări sau nu pot fi construite într-o anumită situație.

În loc să spună doar „Ne pare rău, nu putem construi acest lucru”, dezvoltatorii ar trebui să încerce să ofere o explicație care să fie de înțeles pentru designeri și, în cel mai bun caz, să pregătească sugestii pentru o soluție alternativă care funcționează în limitele constrângerilor cunoscute. Susținerea punctului dvs. cu statistici, cercetări sau articole vă poate ajuta să vă subliniați argumentul. De asemenea, dacă sincronizarea este o problemă, poate implementarea unor părți care necesită timp poate fi mutată într-o fază ulterioară a proiectului?

Chiar dacă nu este întotdeauna posibil, faptul că designerii și dezvoltatorii stau unul lângă altul poate scurta buclele de feedback și poate facilita elaborarea unei soluții compromise. Adaptarea și prototiparea se pot face direct prin codificare și optimizare cu DevTools deschis.

Arată-le colegilor tăi designeri cum să folosească DevTools într-un browser, astfel încât să poată modifica informațiile de bază și să previzualizeze mici modificări în browser (de ex. umplutură, margini, dimensiuni de font, nume de clase) din mers.

Dacă proiectul și structura echipei permit acest lucru, construirea și prototiparea în browser cât mai curând posibil poate oferi tuturor celor implicați o mai bună înțelegere a comportamentului receptiv și poate ajuta la eliminarea erorilor și erorilor în stadiul incipient al proiectului.

Cu cât designerii și dezvoltatorii lucrează împreună mai mult timp, cu atât designerii vor înțelege mai bine ce este mai ușor și ce este mai greu de construit pentru dezvoltatori. De-a lungul timpului, ei se pot referi în cele din urmă la soluții care au funcționat pentru ambele părți în trecut:

„Am folosit acea soluție pentru a găsi un compromis în Proiectul A. O putem folosi și pentru acest proiect?”

Acest lucru îi ajută, de asemenea, dezvoltatorilor să aibă o mai bună înțelegere a detaliilor despre care designerii sunt foarte specifici și ce aspecte vizuale sunt importante pentru ei.

Designerii se așteaptă ca front-end să arate (și să funcționeze) ca designul lor

Fișierul de proiectare vs. Comparație browser

O tehnică utilă pentru a preveni frustrarea designerilor este să faci o comparație simplă stânga-dreapta între fișierul de design pe care l-ai predat și cum arată starea ta actuală de dezvoltare. Acest lucru poate suna banal, dar, ca dezvoltator, trebuie să ai grijă de atât de multe lucruri care trebuie să funcționeze sub capotă, încât s-ar putea să fi ratat câteva detalii vizuale. Dacă observați unele discrepanțe vizibile, pur și simplu corectați-le.

Gândiți-vă la asta astfel: fiecare detaliu din implementarea dvs. care arată exact așa cum a fost conceput vă economisește atât dvs., cât și designerului timp și bătăi de cap prețios și încurajează încrederea. Nu toată lumea poate avea același nivel de atenție la detalii, dar pentru a vă antrena ochiul să observe diferențele vizuale, o rundă rapidă de Can't Unsee ar putea fi de mare ajutor.

„Can’t Unsee” este un joc în care trebuie să alegi cel mai corect design dintre două opțiuni.
(Credite imagine: Can't Unsee) (Previzualizare mare)

Acest lucru îmi amintește cu nostalgie de un joc pe care îl jucam cu mult timp în urmă, numit „Find it”. A trebuit să găsești discrepanțe comparând două imagini aparent similare pentru a obține puncte.

În „Find it”, jucătorii trebuie să găsească erori în compararea a două imagini
(Credite imagine: Mordillo le găsește) (Previzualizare mare)

Totuși, s-ar putea să vă gândiți:

„Ce se întâmplă dacă pur și simplu nu există un sistem vizibil de dimensiuni și spații ale fonturilor în design?”

Ei bine, bun punct! Experiența mi-a arătat că poate ajuta să începi o conversație cu designerul(i) cerând clarificări , mai degrabă decât să începi să schimbi lucrurile pe cont propriu și să creezi surprize nedorite pentru designer(i) mai târziu.

Învață regulile de bază tipografice și de design

După cum afirmă Oliver Reichenstein într-unul dintre articolele sale, 95% din informațiile de pe web sunt limbaj scris. Prin urmare, tipografia joacă un rol vital nu numai în design web, ci și în dezvoltare. Înțelegerea termenilor și conceptelor de bază ale tipografiei vă poate ajuta să comunicați mai eficient cu designerii și, de asemenea, vă va face mai versatil ca dezvoltator. Recomand să citești articolul lui Oliver, deoarece el elaborează importanța tipografiei pe web și explică termeni precum micro- și macro-tipografie .

În „Ghidul de referință pentru tipografie în designul web mobil”, Suzanne Scacca acoperă în detaliu terminologia tipografiei, cum ar fi tipografia, fontul, dimensiunea, greutatea, crentarea, conducerea și urmărirea, precum și rolul tipografiei în designul web modern.

Dacă doriți să vă extindeți în continuare orizontul tipografic, cartea lui Matthew Butterick „Tipografia practică a lui Butterick” ar putea merita citită. De asemenea, oferă un rezumat al regulilor cheie ale tipografiei.

Un lucru pe care l-am găsit deosebit de util în designul web responsive este că ar trebui să se urmărească o lungime medie a liniei (caractere pe linie) de 45 până la 90 de caractere, deoarece liniile mai scurte sunt mai confortabil de citit decât liniile mai lungi.

Compararea a două paragrafe de text cu lungimi de linii diferite
Compararea diferitelor lungimi de linii (Previzualizare mare)

Ar trebui dezvoltatorii să proiecteze?

Au existat multe discuții dacă designerii ar trebui să învețe să codeze și este posibil să vă puneți aceeași întrebare și invers. Eu cred că cu greu se poate excela la ambele discipline, și asta e perfect.

Rachel Andrew subliniază frumos în articolul ei „Working Together: How Designers And Developers Can Communicate To Create Better Projects” că, pentru a colabora mai eficient , cu toții trebuie să învățăm ceva din limbajul, abilitățile și prioritățile colegilor noștri, astfel încât să putem poate crea un limbaj comun și zone de expertiză suprapuse.

O modalitate de a deveni mai informați în domeniul designului este un curs online cunoscut sub numele de „Design for Developers”, oferit de Sarah Drasner, în care ea vorbește despre principiile de bază ale aspectului și teoria culorilor - două domenii fundamentale în design web.

„Cu cât înveți mai mult în afara propriei discipline, este de fapt mai bine pentru tine [...] ca dezvoltator.”

— Sarah Drasner

Centrul vizual

Colaborând cu designeri, am învățat diferența dintre centrul matematic și cel vizual. Când vrem să atragem atenția cititorului asupra unui anumit element, punctul focal natural al ochiului nostru se află puțin deasupra centrului matematic al paginii.

Putem aplica acest concept, de exemplu, la modalii de poziție sau orice fel de suprapuneri. Această tehnică ne ajută să atragem în mod natural atenția utilizatorului și face ca designul să pară mai echilibrat:

Compararea a două layout-uri de pagină în care unul arată un text aliniat la cel matematic și celălalt un text aliniat la centrul vizual
(Previzualizare mare)

Suntem în asta împreună

În mediile de agenție cu ritm rapid și nu atât de agile, cu termene limită strânse, dezvoltatorilor li se cere adesea să implementeze front-end-uri responsive complet funcționale, bazate pe o machetă mobilă și desktop. Acest lucru forțează inevitabil dezvoltatorul să ia decizii de proiectare pe tot parcursul procesului. Întrebări precum „La ce lățime vom reduce dimensiunea fontului titlurilor?” sau „Când ar trebui să comutăm aspectul nostru pe trei coloane pe o singură coloană?” poate apărea.

De asemenea, în căldura momentului, se poate întâmpla ca detalii precum stări de eroare, notificări, stări de încărcare, modali sau stiluri de 404 pagini să cadă pur și simplu prin fisuri. În astfel de situații, este ușor să începi să arăți cu degetul și să dai vina pe cei care ar fi trebuit să se gândească la asta mai devreme. În mod ideal, dezvoltatorii nu ar trebui să fie niciodată puși într-o astfel de situație, dar dacă este cazul?

Când l-am ascultat pe fondatorul și CEO-ul Ueno, Haraldur Thorleifsson, vorbind la o conferință din San Francisco în 2018, el a prezentat două dintre valorile lor de bază:

„Nimic aici nu este problema altcuiva.”
„Ridicăm gunoiul pe care nu l-am lăsat jos.”

Ce se întâmplă dacă mai mulți dezvoltatori încep în mod proactiv să modeleze părțile lipsă menționate mai sus cât de bine pot, în primul rând, și apoi să rafinească împreună cu designerul care stă lângă ei? Site-urile web trăiesc în browser, așa că de ce să nu îl folosiți pentru a construi și a perfecționa?

Deși s-ar putea să nu fie întotdeauna ideal să aruncăm aripile lipsă sau uitate, am învățat în experiențele mele din trecut că ne-a ajutat întotdeauna să avansăm mai repede și să eliminăm erorile din mers - ca o echipă .

Desigur, acest lucru nu înseamnă că designerii ar trebui să fie anulați în acest proces. Înseamnă că dezvoltatorii ar trebui să încerce să întâlnească cu respect designerii la jumătatea drumului, dând dovadă de inițiativă în rezolvarea problemelor. Pe lângă asta, eu, ca dezvoltator, am fost mult mai apreciat de echipă pentru pur și simplu grijă și asumarea responsabilității.

Construirea încrederii între designeri și dezvoltatori

A avea o relație de încredere și pozitivă între echipa creativă și cea tehnologică poate crește puternic productivitatea și rezultatul muncii. Deci, ce putem face noi, ca dezvoltatori, pentru a crește încrederea între cele două discipline? Iată câteva sugestii:

  1. Arătați un ochi pentru detalii .
    Construirea lucrurilor exact așa cum au fost proiectate le va arăta designerilor că vă pasă și le va pune un zâmbet larg pe chip.
  2. Comunicați cu respect .
    Cu toții suntem ființe umane într-un mediu profesional care luptă pentru cel mai bun rezultat posibil. Arătarea respectului pentru disciplina celuilalt ar trebui să fie baza oricărei comunicări.
  3. Verificați-vă devreme și regulat .
    Implicarea dezvoltatorilor de la început poate ajuta la eliminarea erorilor de la început. Printr-o comunicare frecventă, membrii echipei pot dezvolta un limbaj comun și o mai bună înțelegere a pozițiilor celuilalt.
  4. Fă-te disponibil .
    Având cel puțin o fereastră opțională de 30 de minute pe zi, când designerii pot discuta idei cu dezvoltatorii, le poate oferi designerilor un sentiment de sprijin. Acest lucru oferă, de asemenea, dezvoltatorilor posibilitatea de a explica lucruri tehnice complexe în cuvinte pe care oamenii nu foarte tehnici le pot înțelege mai bine.

Rezultatul: o situație de câștig-câștig

A trebui să petreacă mai puțin timp în QA printr-o comunicare eficientă și o predare adecvată a design-urilor oferă atât echipei creative, cât și echipei de dezvoltare mai mult timp pentru a se concentra pe construirea de lucruri reale și mai puține dureri de cap. În cele din urmă, creează o atmosferă mai bună și creează încredere între designeri și dezvoltatori. Vocea dezvoltatorilor de front-end care arată interes și cunoștințe în unele domenii legate de design va fi auzită mai mult în întâlnirile de design.

Contribuția proactivă la găsirea unui compromis între designeri și dezvoltatori și rezolvarea problemelor în calitate de dezvoltator vă poate oferi un sentiment mai larg de proprietate și implicare în întregul proiect. Chiar și în industria creativă în plină expansiune de astăzi, nu este ușor să găsești dezvoltatori cărora, pe lângă setul de abilități tehnice, le pasă și au un ochi pentru detaliile vizuale. Aceasta poate fi oportunitatea ta de a ajuta la reducerea decalajului din echipa ta.

Resurse conexe

  • „Cum să alegi instrumentul potrivit de prototipare”, Javier Cuello
  • „Un ghid de referință pentru tipografie în designul web mobil”, Suzanne Scacca
  • „Tipografia practică a lui Butterick”, Matthew Butterick
  • „Lucrând împreună: modul în care designerii și dezvoltatorii pot comunica pentru a crea proiecte mai bune”, Rachel Andrew
  • „Design for Developers”, Sarah Drasner, Frontend Masters
  • „Designul web este 95% tipografie”, Oliver Reichenstein
  • „Can’t Unsee”, un test de browser pentru a vă antrena simțul recunoașterii detaliilor vizuale.