Design la scară: un an cu Figma
Publicat: 2022-03-10Acest articol va vorbi despre modul în care echipele mari pot beneficia de utilizarea unor instrumente mai deschise, colaborative și despre cum să facă adoptarea și migrarea fezabile și plăcute. De asemenea, în cazul în care nu ați ghicit încă din titlul articolului, o mare parte va fi despre Figma și despre cum am reușit să adoptăm acest instrument de design în echipa noastră.
Publicul vizat este reprezentat de designeri experimentați care lucrează în echipe mai mari cu sisteme de design, dezvoltatori sau manageri de produs care doresc să îmbunătățească modul în care echipele interfuncționale lucrează în organizația lor.
Folosesc instrumente de design într-un cadru profesional de peste zece ani și încerc mereu să fac echipele pe care le deservesc să lucreze mai eficient și mai eficient. De la scripturi și acțiuni în Photoshop, la biblioteci de widget-uri în Axure, la pluginuri Sketch, iar acum cu Figma — am ajutat echipele de proiectare să rămână la vârf fără a lăsa în urmă dezvoltatorii sau managerii de produs.
Cunoștințele de bază ale sistemelor și instrumentelor de proiectare vor fi utile, dar nu necesare, deoarece sper să împărtășesc exemple specifice și, de asemenea, concepte și metode de „nivel înalt” pe care le puteți adapta pentru echipa sau contextul dvs.
Fluxul nostru de lucru de proiectare Circa 2015
Instrumentul nostru principal în 2015 a fost Schița și aproape aici s-au oprit aspectele comune. Cu toții aveam metode diferite de prototipare, export și partajare a design-urilor cu părțile interesate (InVision, Axure, Marvel, Google Slides și chiar învechitul Adobe PDF) și dezvoltatori (Avocode, Zeplin, pluginuri fără aplicații independente precum Measure). În rare ocazii, am putut trimite fișiere direct inginerilor care au avut norocul să aibă combinația rară a unui MacBook și a unei licențe Sketch.
Când InVision a lansat plugin-ul Craft, ne-am bucurat nespus de bucuros – că am putut să prototipăm și să încărcăm ecrane din Sketch în InVision, partajând componente și stiluri în biblioteci în curs de dezvoltare între fișiere – a fost visul designerului devenit realitate.
În cele din urmă, am convergit cu toții către platforma InVision. Am creat și documentat procesele care au ajutat la reducerea multă frecare în colaborarea cu părțile interesate și transferul dezvoltatorilor. Cu toate acestea, din cauza structurii complexe de permisiuni, InVision a rămas un ecosistem închis - dacă nu erai designer, exista un lanț de aprobare care îngreuna obținerea unui cont InVision și, odată ce obții un cont, trebuia să fii adăugat. la grupurile potrivite.
Gestionarea manuală a versiunilor și fișierelor, stocarea și organizarea lor într-un drive partajat și gestionarea conflictelor de sincronizare au fost doar câteva dintre lucrurile care ne-au cauzat multe bătăi de cap.
Am putea avea într-adevăr un instrument all-in-one care să aibă toate cele mai bune funcții ale Sketch și InVision, cu funcțiile de colaborare și comunicare în timp real găsite în Google Docs? Pe lângă reducerea cheltuielilor generale de la schimbarea contextului, am putea, de asemenea, să simplificăm de la trei abonamente de instrumente (pentru machete, prototipuri și transfer de la dezvoltator) la doar una.
Procesul
Primii designeri din echipa noastră care au adoptat Figma au început să experimenteze cu acesta când prima Figma beta a fost lansată în 2016. Caracteristicile au fost limitate, dar au acoperit 80% din ceea ce aveam nevoie. Importul schițelor a fost greșit, dar am găsit totuși o valoare imensă în posibilitatea de a colabora în timp real și, cel mai important, am putea face 90% din munca de proiectare pentru un proiect într-un singur instrument. Feedback-ul părților interesate, revizuirile și transferul dezvoltatorului s-au îmbunătățit exponențial.
Până în 2017, câțiva designeri îl foloseau pentru cea mai mare parte a muncii lor, iar unul dintre designerii Lexicon (sistemul de design al lui Liferay), Emiliano Cicero, devenea rapid un evanghelist – ceea ce s-a dovedit a fi un factor cheie în a convinge restul echipa să facă schimbarea.
Când Figma 2.0 a debutat în vara lui 2017, cu funcții de prototipare adăugate și îmbunătățiri uriașe ale capabilităților de transfer al dezvoltatorului, știam că acesta ar putea fi un instrument viabil pentru echipa noastră globală. Dar cum convingi peste 20 de designeri să abandoneze instrumentele și fluxurile de lucru pe care le iubesc și pe care le-au folosit confortabil de ani de zile?
Aș putea să scriu o serie pe acest subiect, dar voi rezuma spunând că cele mai mari două lucruri au fost: a începe cu mic și a crea o infrastructură solidă .
Începând cu mic
În toamna lui 2017, am început prima noastră încercare a Figma cu o echipă de produs distribuită între Statele Unite și Brazilia. Am fost norocoși să avem o săptămână de start împreună în biroul nostru din Los Angeles. Proiectarea fluxurilor și wireframes-urilor împreună în Figma a fost mult mai rapidă și mai eficientă. Am reușit să împărțim sarcinile și să partajăm fișiere și componente fără să ne facem griji cu privire la sincronizarea constantă a unui folder sau a unei biblioteci.
La întâlnirea noastră globală din ianuarie 2018, am formulat un plan de adoptare încet a Figma, folosind experiențele acestei echipe pentru a ajuta la formarea infrastructurii de care avem nevoie pentru restul organizației, astfel încât migrarea să fie cât mai fluidă posibil.
Cea mai mare provocare cu care ne-am confruntat a fost un termen limită strâns – nu avea niciun sens să ne reelaborăm procesul de revizuire și transfer din cauza amplorii proiectului cu mai multe echipe de inginerie și manageri de produs distribuiți în întreaga lume. Chiar dacă rezultatul final ar fi fost mai bun, momentul nu a fost potrivit. Un alt factor a fost lipsa unei experiențe de design offline fiabile de către Figma (mai multe despre asta mai târziu) și, din aceste motive, echipa a decis să folosească Sketch și Figma pentru wireframes și machete, dar orice prototipare sau revizuire trebuia făcută în InVision.
Crearea unei structuri solide Figma
Unul dintre primii pași a fost formularea unor linii directoare pentru proiect, fișier și organizarea componentelor. Fundația pentru aceste lucruri a fost începută de doi designeri juniori (la acea vreme), Abel Hancock și Naoki Hisamoto, care nu au dezvoltat niciodată obiceiurile proaste de denumire a straturilor care par să vină de la designeri care își tăiau dinții în Photoshop. Această metodă de organizare, împreună cu un an petrecut în dezvoltarea unei biblioteci mici de componente pentru proprietățile Liferay.com, a fost esențială pentru a pregăti restul echipei globale pentru succes.
O îmbunătățire organizatorică timpurie creată de unul dintre designerii noștri Liferay.com, inspirat de tweet-ul lui Ben, a fost sistemul nostru de coperți .
Am pus la dispoziție acest fișier dacă doriți să-l copiați, altfel este un hack destul de simplu:
- Creați un singur cadru în prima pagină a fișierului dvs. de 620×320.
- Adăugați designul dvs. Dacă aveți text, am constatat că dimensiunea minimă este ~24, titlurile din exemplele noastre sunt setate la 48.
- Bucurați-vă!
Notă: va exista întotdeauna o mică marjă în jurul copertei, dar dacă setați pânza paginii la aceeași culoare ca și cardul, se va reduce aspectul acestei margini.
Acest lucru a ajutat la transformarea bibliotecii noastre, nu doar pentru designeri, ci și pentru managerii de proiect și de produs și ingineri care încearcă să găsească lucruri rapid. Funcționalitatea de căutare era deja foarte bună, dar coperțile i-au ajutat pe oameni să restrângă lucrurile și mai repede, plus ne-a permis să comunicăm instantaneu starea oricărui fișier dat.
Înainte de a utiliza Figma, pe lângă un fișier Sketch al sistemului de proiectare „Master”, majoritatea designerilor aveau fișiere de bază pe care le-au dezvoltat de-a lungul timpului, cu elemente precum elemente de wireframing și componente de bază. Pe măsură ce ne-am unit într-un singur model, am început să combinăm totul și să le rafinam într-o singură bibliotecă. Din moment ce făceam wireframes, machete și prototipuri în Figma, am început, de asemenea, să abandonăm aplicațiile de flux precum Lucidchart, în loc să ne facem propriile componente de flux de activități în Figma.
Alte utilități pe care le-am dezvoltat de-a lungul timpului au fost componente de linie roșie pentru realizarea de specificații precise de transfer, note lipicioase pentru diagramele de afinitate (și aproape orice) și noduri de flux.
Unul dintre cele mai mari beneficii de a face acest lucru în Figma a fost că îmbunătățirile aduse oricăreia dintre aceste componente pe care le-a făcut orice designer puteau fi introduse cu ușurință în bibliotecă și apoi expuse în toate cazurile. Având acest lucru într-un loc centralizat, întreținerea este mult mai ușoară, deoarece oricine din echipă poate contribui la îmbunătățiri printr-un proces relativ simplu.
Un document cu linie roșie este pentru a facilita dezvoltatorului cunoașterea dimensiunilor, specificațiilor vizuale și a altor proprietăți ale unei componente UI sau ale unui set de componente. Dacă sunteți interesat de subiect, puteți consulta și articolul lui Dmitriy Fabrikant despre planurile de design.
Câteva recomandări de care trebuie să țineți cont atunci când creați componente:
- Utilizarea de overrides și master pentru componente puternice de bază (mai multe despre asta aici);
- Stabiliți un model consistent pentru denumire (folosim modelul atomic);
- Documentați și etichetați totul - în special straturi.
Cu funcțiile de stil avansate lansate la începutul lunii iunie 2017, echipa de sisteme a finalizat o versiune completă a bibliotecii noastre Lexicon între lansările noastre mari de produse din iulie și intensificarea în august. Aceasta a fost ultima piesă de care aveam nevoie pentru a sprijini echipa globală. Designerii care lucrează în marketing și în alte departamente foloseau deja Figma de ceva timp, dar până în toamna trecută aproape toate celelalte echipe de produse finalizaseră trecerea la Figma.
Începând de astăzi, majoritatea designerilor de produse folosesc doar Figma, există și câțiva designeri care lucrează în sisteme vechi cu o mulțime de prototipuri Sketch existente, complicate, care nu merită importate în Figma. O altă excepție o reprezintă câțiva designeri care folosesc ocazional aplicații precum Principle sau Adobe After Effects pentru o animație mai avansată, ceea ce nu ar avea sens în Figma. Avem chiar și câțiva designeri care explorează Framer X pentru prototipuri și mai robuste, mai ales cu lucrări care necesită utilizarea oricărui tip de date la scară. Deși există unii designeri care folosesc mai multe instrumente în mod semi-regulat, 80% dintre designerii noștri de produse folosesc Figma pentru toate lucrările lor de proiectare și prototipare.
Îmbunătățiri continue
Lucrăm mereu la modalități de a funcționa mai eficient, iar unul dintre lucrurile curente pe care le repetăm este cele mai bune practici pentru denumirea paginilor. La început, am denumit paginile după numele paginii, dar asta s-a dovedit problematic, plus, pe măsură ce ne-am îmbunătățit bibliotecile, nevoia de fișiere mai mari cu mai multe pagini a fost redusă.
În prezent, utilizăm un sistem de numerotare în cadrul fișierelor, pagina cea mai de sus fiind ceea ce este livrat dezvoltatorilor. Următoarea fază pe care o discutăm în prezent este să facem versiunile mai semnificative cu etichete explicite (wireframes, machete, puncte de întrerupere etc.) și să folosim mai bine versiunea încorporată a Figma, stabilind cele mai bune practici pentru când și cum să salvați versiunile.
Final_Final_Last_2 — Gata!
În general, urăsc să folosesc termenul „modificator”, dar când Figma a lansat denumirea/adnotarea istoricului versiunilor în martie trecut, a schimbat dramatic modul în care ne organizam fișierele. Anterior, toți aveam moduri diferite de a salva iterațiile și versiunile.
De obicei, am crea pagini noi într-un singur fișier, uneori, cu fișiere mari, le-am duplicat și adăugam o literă la sfârșitul numelui fișierului pentru a semnala o iterație. Dacă urma să faceți modificări drastice, atunci s-ar putea să creați un fișier nou și să adăugați un număr de versiune. Acest lucru a fost foarte natural, venind din paradigma Photoshop/Sketch de gestionare a mai multor fișiere pentru orice.
Capacitatea de a lucra, întreruperea periodică pentru a denumi și adnota un punct în timp va fi foarte familiară pentru oricine a folosit înainte un control al versiunii precum Git. Puteți chiar să vă uitați la întregul istoric al fișierelor și să intrați în instantaneele anterioare, să alegeți unul și să îl denumiți și să îl adnotați.
Dacă doriți să reveniți și să reveniți la o versiune anterioară, o puteți restaura și lucra la acel fișier din acel punct din istoric. Cea mai bună parte este că nu ați pierdut nimic din munca deoarece versiunea pe care ați „restaurat-o” nu ștergea nimic; a fost pur și simplu să copieze acea stare și să o lipească în partea de sus.
În această ilustrație, designerul ajunge la final 3.0 după restaurarea final 1.1 , dar istoricul versiunilor fișierului este încă complet vizibil și accesibil.
În cazurile în care începeți un nou proiect sau doriți să faceți niște modificări dramatice la fișier, poate fi necesar să „furcați” fișierul. Figma vă permite să duplicați un fișier în orice moment al istoricului, dar este important să rețineți că istoricul fișierului nu va fi copiat.
Am descoperit că o modalitate bună de a lucra în acest sistem cu versiuni este să utilizați istoricul fișierelor într-un mod similar cu modul în care un dezvoltator folosește git - gândiți-vă la o versiune Figma ca la o commit sau la o cerere de tragere și denumiți-le și adnotați-le ca astfel de. Pentru mai multe și mai inteligente gânduri despre acest lucru, recomand Commit Often, Perfect Later, Publish Once: Git Best Practices al lui Seth Robertson - aceasta este o bună filozofie generală pentru cum să lucrați într-un ecosistem controlat de versiune. De asemenea, cum să scrieți un mesaj Git Commit de la Chris Beams este un ghid excelent pentru a scrie note semnificative și utile în timp ce lucrați.
Câteva sfaturi practice pe care le-am descoperit:
- Păstrați titlurile la 25 de caractere sau mai puțin .
Titlurile mai lungi sunt tăiate și trebuie să faceți dublu clic pe notă din istoricul versiunilor pentru a deschide modulul „Editați informațiile versiunii” pentru a o citi. - Păstrați descrierea la 140 de caractere sau mai puțin .
Descrierea completă este întotdeauna afișată, așa că păstrarea ei la obiect ajută la menținerea istoriei lizibilă. - Folosește dispoziția imperativă pentru titlu .
Acest lucru vă oferă viitorului o idee mai clară despre ceea ce se va întâmpla când faceți clic pe acel moment, de exemplu, „schimbarea culorilor butoanelor în albastru” versus „schimbarea butoanelor în albastru”. - Folosiți descrierea pentru a explica „ce” și „de ce” versus „cum” .
Răspunsul la „de ce” este o parte esențială a oricărui job de designer, așa că acest lucru vă ajută să vă concentrați pe ceea ce este important pe măsură ce lucrați, precum și să vă oferiți informații mai bune în viitor.
Lucrează offline
Disclaimer: Acest lucru se bazează pe propria noastră experiență și o mare parte este cea mai bună presupunere a noastră cu privire la modul în care funcționează.
După cum am menționat anterior, suportul offline în Figma este slab. Dacă aveți deja un fișier deschis înainte de a fi offline, puteți continua să lucrați la fișier. Se pare că fiecare modificare pe care o faceți este marcată de timp. În cazul în care altcineva lucrează la același fișier în timp ce ați fost offline, atunci cea mai recentă modificare va fi cea redată după ce veți reveni online.
În acest exemplu simplu, nu pare o afacere prea mare, dar în viața reală, acest lucru poate deveni foarte dezordonat, foarte rapid. Pe lângă posibilitatea mare ca cineva să-ți depășească munca, cadrele și grupurile ar putea fi stivuite una peste alta.
Fluxul nostru de lucru constă în duplicarea paginii înainte (sau după) de a fi offline, apoi faceți-vă munca în acea copie. În acest fel, va fi neatins când reveniți online și puteți face manual toate îmbinările necesare.
„F” este pentru viitor
Adoptarea unui nou instrument nu este niciodată ușoară, dar în cele din urmă, beneficiile pot depăși cu mult costurile.
Cele mai mari zone de îmbunătățire pe care le-a experimentat echipa noastră sunt:
- Colaborare
Este mult mai ușor să împărtășim munca și îmbunătățirile noastre cu echipa și comunitatea. - Transparenţă
Un sistem care este deschis implicit este în mod natural mai cuprinzător pentru oamenii din afara domeniului designului. - Evoluţie
Eliminarea „straturilor” dintre designeri și ingineri, permițându-ne să facem următorul pas în maturitatea designului. - Operațiuni
Adoptarea unui singur instrument pentru wireframes, machete, prototipuri și transferuri pentru dezvoltatori face viața mai ușoară pentru contabilitate, IT și management.
Reducerea numărului total de abonamente a fost cu adevărat utilă pentru echipa noastră, dar deoarece costurile pot varia de la „gratuit” la peste 500 USD pe an, acest lucru s-ar putea să nu aibă sens pentru contextul și nevoile dumneavoastră specifice. Pentru o defalcare completă, consultați pagina de prețuri Figma.
Creșteți și deveniți mai buni
Desigur, niciun instrument nu este perfect și există întotdeauna loc de îmbunătățiri. Câteva lucruri care lipseau din instrumentele anterioare pe care le-am folosit sunt:
- Fără ecosistem de pluginuri .
Extensibilitatea lui Sketch a fost un factor uriaș în a face trecerea de la Photoshop o simplă oboseală. Figma are un API web, dar în prezent nu există o funcționalitate de „scriere”. Pentru moment, Sketch rămâne lider de piață cu comunitatea sa vibrantă de extensii și pluginuri. (Desigur, lucrurile s-ar putea schimba în viitor, în cazul în care Figma deschide scena și pentru dezvoltarea pluginurilor.) - Importarea datelor web sau JSON în prototipuri .
Ne-ar fi mult mai ușor să proiectăm cu date reale. Sketch a introdus recent o caracteristică „Date” în v.52, pluginul Craft al InVision este încă standardul de aur atunci când vine vorba de adăugarea cu ușurință a unor cantități mari de date diferite – și deocamdată, suntem blocați să populam manual câmpurile de text. - Mai multă mișcare .
Integrarea Principle este bună (dacă aveți Principle), dar a avea animație de bază și funcții avansate de prototipare în Figma ar fi mult mai bine. - O experiență offline mai fluidă
După cum am menționat anterior, atâta timp cât aveți fișierul Figma deschis înainte de a merge offline, sunteți bine. Probabil că acest lucru este în regulă pentru majoritatea oamenilor - dar dacă vă place să închideți computerul în fiecare noapte, poate fi dureros când îl deschideți dimineața într-un tren sau avion și vă dați seama că ați uitat să lăsați Figma deschis.
Design open-source
În urmă cu câteva luni, mereu controversatul Dann Petty a scris recent pe Twitter despre dezvoltatorii care au GitHub, fotografi care au Unsplash – dar designerii nu au o platformă pentru partajarea gratuită a lucrurilor. Design Twitter️ a intervenit și și-a șters tweetul înainte de a putea obține o captură de ecran, dar un lucru pe care aș dori să menționez este că ceea ce suntem foarte pasionați la Liferay este open source. În acest scop, am creat un proiect Figma pentru resurse pentru a le împărtăși comunității de design.
Pentru a accesa oricare dintre aceste fișiere, accesați liferay.design/resources/figma și rămâneți la curent pe măsură ce creștem și distribuim mai multe!
Lectură suplimentară
- „Primele noastre 6 luni cu Figma”, Danny Saltaren
- „Așteptați un semn pentru a începe să construiți biblioteca de componente a echipei de proiectare?”, William Newton
- „Cum să vă simplificați fluxul de lucru UI/UX cu Figma”, a spus Nicole
- „Noțiuni introductive cu echipele din organizația Figma”, Thomas Lowry
- „5 moduri de a vă structura fluxul de lucru cu pagini în Figma”, Josh Dunsterville
- „Cele mai bune practici: componente, stiluri și biblioteci partajate”, Thomas Lowry
- „Figma: O abordare fluidă și modulară a tipografiei cu componente”, Mirko Santangelo
Alte resurse
- Comunitatea Figma pe Spectrum
- Manual de design Figma de David Ukauwa