Proiectare cu cod: o abordare modernă a proiectării (provocări de dezvoltare)

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la UXPin, a căror misiune este de a oferi cele mai bune experiențe utilizatorilor prin îmbinarea designului și a ingineriei într-o singură lume a dezvoltării produselor mai bune și mai rapide. Mulțumesc!

Frecvența în cooperarea dintre designeri și dezvoltatori alimentează o discuție în continuă evoluție, la fel de veche ca industria în sine. Am parcurs un drum lung până unde suntem astăzi. Instrumentele noastre s-au schimbat. Procesele și metodologiile noastre s-au schimbat. Dar problemele de bază au rămas adesea aceleași.

Una dintre problemele recurente pe care tind să le văd adesea, indiferent de tipul și dimensiunea echipei, este menținerea unei surse de încredere de adevăr . Chiar și angajarea celor mai buni oameni și utilizarea unor soluții dovedite standard din industrie ne lasă adesea cu dezgust că ceva cu siguranță ar fi putut fi făcut mai bine. Infama „versiunea finală” este adesea răspândită în documentație tehnică, fișiere de proiectare, foi de calcul și alte locuri. Menținerea lor pe toate sincronizate este de obicei o sarcină obositoare și descurajantă.

Notă : Acest articol a fost scris în colaborare cu echipa UXPin. Exemplele prezentate în acest articol au fost create în aplicația UXPin. Unele dintre funcții sunt disponibile numai pentru planurile plătite. Prezentarea completă a prețurilor UXPin poate fi găsită aici.

Problema cu instrumentele de proiectare

Vorbind despre menținerea unei surse de adevăr, ineficiența instrumentelor de proiectare este adesea indicată ca fiind unul dintre cele mai uzătoare puncte de durere. Instrumentele moderne de design evoluează și evoluează rapid cu eforturi extraordinare. Dar când vine vorba de construirea unei punți între design și dezvoltare, nu este rar să ai impresia că multe dintre aceste eforturi se bazează pe presupuneri greșite.

Cele mai multe dintre instrumentele moderne de design se bazează pe modele diferite decât tehnologiile utilizate pentru implementarea proiectelor mai târziu. Sunt construite ca editori grafici și se comportă ca atare. Modul în care layout-urile sunt construite și procesate în instrumentele de proiectare este în cele din urmă diferit de orice CSS, JavaScript și alte limbaje de programare au de oferit. Construirea de interfețe cu utilizatorul folosind grafică vectorială (sau chiar raster) este o presupunere constantă despre cum și dacă ceea ce faceți ar trebui transformat în cod mai târziu.

Designerii ajung adesea să se plângă de faptul că creațiile lor nu sunt implementate așa cum s-a prevăzut. Chiar și cele mai curajoase eforturi către design-uri perfecte pentru pixeli nu rezolvă toate problemele. În instrumentele de proiectare, este aproape imposibil de imaginat și acoperit toate cazurile posibile. Sprijinirea diferitelor stări, modificarea copiei, diferite dimensiuni ale ferestrelor de vizualizare, rezoluții de ecran și așa mai departe, pur și simplu furnizează prea multe variabile de schimbare pentru a le acoperi pe toate.

În plus, vin și unele constrângeri și limitări tehnice . Fiind un designer fără experiență anterioară în dezvoltare, este extrem de greu să luați în considerare toți factorii tehnici. Amintiți-vă toate stările posibile ale intrărilor. Înțelegeți limitările suportului pentru browser. Preziceți implicațiile de performanță ale muncii dvs. Design pentru accesibilitate, cel puțin într-un sens mult mai larg decât contrastul culorilor și dimensiunile fonturilor. Fiind conștienți de aceste provocări, acceptăm o anumită cantitate de presupuneri ca un rău necesar.

Dar dezvoltatorii trebuie adesea să se bazeze și pe presupuneri. Interfețele de utilizator simulate cu editori grafici rareori răspund la toate întrebările lor. Este aceeași componentă cu cea pe care o avem deja sau nu? Ar trebui să-l tratez ca pe un stat diferit sau ca pe o entitate separată? Cum ar trebui să se comporte acest design când X, Y sau Z? Putem să o facem puțin diferit, deoarece ar fi mai rapid și mai ieftin? În mod ironic, să întrebi pe cine a creat desenele nu este întotdeauna util. Nu rar, nici ei nu știu.

Și, de obicei, nu aici se termină sfera frustrării în creștere . Pentru că atunci sunt și toți ceilalți . Manageri, părți interesate, lideri de echipă, agenți de vânzări. Cu atenția și capacitatea mentală întinse printre toate instrumentele și locurile în care trăiesc diverse părți ale produsului, ei se luptă mai mult decât oricine altcineva să-l înțeleagă bine.

Navigarea prototipurilor, înțelegerea de ce lipsesc anumite caracteristici și stări din design și distingerea între ceea ce lipsește, ceea ce este o lucrare în curs și ceea ce a fost exclus în mod conștient din domeniul de aplicare se pare aproape imposibil. Iterarea rapidă a ceea ce s-a făcut deja, vizualizarea feedback-ului și prezentarea propriilor idei se simt de asemenea cu greu posibile. În mod ironic, instrumentele și procesele din ce în ce mai sofisticate sunt destinate designerilor și dezvoltatorilor să lucreze mai bine împreună ; ei pun ștacheta și mai sus, iar participarea activă la procese pentru alți oameni și mai greu.

Soluțiile

Nenumărați șefi ai industriei noastre au lucrat la soluționarea acestor probleme, rezultând noi paradigme, instrumente și concepte. Și într-adevăr multe s-au schimbat în bine. Să aruncăm o privire rapidă și care sunt unele dintre cele mai comune abordări față de provocările subliniate.

Designeri de codare

„Ar trebui ca designerii să codifice?” este o întrebare clișeică discutată de nenumărate ori prin articole, discuții la conferințe și prin toate celelalte mass-media cu voci noi în discuție care apar cu regularitate stabilă din când în când. Există o presupunere comună că, dacă designerii „ar fi știut să codifice” (să nu începem nici măcar să ne oprim asupra modului de a defini „a ști să codificați” în primul rând), le-ar fi mai ușor să creeze modele care preiau tehnologia. țin cont de constrângeri și sunt mai ușor de implementat.

Unii ar merge chiar mai departe și ar spune că ar trebui să aibă un rol activ în implementare. În această etapă, este ușor să trageți la concluzii că nu ar fi lipsit de sens să săriți peste folosirea instrumentelor de proiectare și să „proiectați în cod”.

Oricât de tentantă ar suna ideea, se dovedește rareori în realitate. Toți cei mai buni designeri de codare pe care îi cunosc încă folosesc instrumente de proiectare. Și asta cu siguranță nu se datorează lipsei de abilități tehnice. Pentru a explica de ce este important să evidențiezi o diferență între idee, schiță și construirea faptului.

Atâta timp cât există multe cazuri de utilizare valide pentru „proiectarea în cod” , cum ar fi utilizarea stilurilor și componentelor predefinite pentru a construi rapid o interfață complet funcțională, fără a vă deranja deloc cu instrumentele de proiectare, promisiunea unei libertăți vizuale neconstrânse este oferită de instrumentele de proiectare. încă mai are o valoare incontestabilă. Mulți oameni consideră că schițarea de idei noi într-un format oferit de instrumentele de proiectare este mai ușoară și mai potrivită pentru natura unui proces creativ. Și asta nu se va schimba prea curând. Instrumentele de design sunt aici pentru a rămâne și pentru a rămâne definitiv.

Sisteme de proiectare

Marea misiune a sistemelor de proiectare, unul dintre cele mai mari cuvinte la modă ale lumii designului digital din ultimii ani, a fost întotdeauna exact aceea: limitarea presupunerilor și repetarea, îmbunătățirea eficienței și mentenabilitatea și unificarea surselor de adevăr. Sistemele corporative, cum ar fi Fluent sau Material Design, au depus o mulțime de eforturi în susținerea ideii și au dat impuls adoptării conceptului atât pentru jucătorii mari, cât și pentru cei mici. Și într-adevăr, sistemele de proiectare au ajutat la schimbarea mult în bine. O abordare mai structurată a dezvoltării unei colecții definite de principii de design, modele și componente a ajutat nenumărate companii să construiască produse mai bune și mai ușor de întreținut .

Unele provocări nu fuseseră însă rezolvate imediat. Proiectarea sistemelor de proiectare în instrumente de design populare a împiedicat eforturile multora pentru a obține o singură sursă de adevăr. În schimb, au fost create o multitudine de sisteme care, deși unificate, există încă în două surse separate, incompatibile: o sursă de proiectare și o sursă de dezvoltare. Menținerea parității reciproce între cei doi se dovedește de obicei a fi o corvoadă dureroasă, repetând toate punctele dureroase cele mai urâte pe care sistemele de proiectare încercau să le rezolve în primul rând.

Proiectare și integrări de cod

Pentru a rezolva problemele de mentenanță ale sistemelor de proiectare, a sosit curând un alt val de soluții. Concepte precum jetoanele de design au început să câștige teren. Unele au fost menite să sincronizeze starea codului cu design-urile, cum ar fi API-urile deschise care permit preluarea anumitor valori direct din fișierele de proiectare. Altele au fost menite să sincronizeze design-urile cu codul, de exemplu prin generarea de componente în instrumentele de proiectare din cod.

Puține dintre aceste idei au câștigat vreodată adoptarea pe scară largă. Acest lucru se datorează cel mai probabil avantajului discutabil al posibilelor beneficii față de costurile necesare de intrare a soluțiilor încă foarte imperfecte. Traducerea automată a desenelor în cod reprezintă încă provocări imense pentru majoritatea cazurilor de utilizare profesională. Soluțiile care vă permit să îmbinați codul existent cu modelele au fost, de asemenea, foarte limitate.

De exemplu, niciuna dintre soluțiile care vă permit să importați componente codificate în instrumentele de proiectare, chiar dacă vizual sunt fidele sursei, nu ar replica pe deplin comportamentul acestor componente. Niciuna până acum.

Îmbinând designul și codul cu UXPin

UXPin, fiind o aplicație de design matură și cu caracteristici complete, nu este un jucător nou pe scena instrumentelor de proiectare. Dar progresele sale recente, cum ar fi tehnologia Merge, sunt ceea ce poate schimba șansele despre modul în care gândim instrumentele de proiectare și dezvoltare.

UXPin cu tehnologia Merge ne permite să aducem componente reale, vii în design, păstrându-le atât elementele vizuale, cât și funcționalitatea - totul fără a scrie o singură linie de cod. Componentele, chiar dacă sunt încorporate în fișierele de proiectare, se vor comporta exact ca omologii lor reale - deoarece sunt omologii lor reale. Acest lucru ne permite nu numai să obținem o paritate perfectă între cod și design , ci și să le menținem pe cele două în sincronizare neîntreruptă.

UXPin acceptă biblioteci de design ale componentelor React stocate în depozitele git, precum și o integrare robustă cu Storybook, care permite utilizarea componentelor din aproape orice cadru front-end popular. Dacă doriți să încercați singuri, puteți solicita accesul la acesta pe site-ul web UXPin:

• Solicitați acces la UXPin cu tehnologia Merge →

Îmbinarea componentelor active cu design-urile în UXPin necesită surprinzător de câțiva pași. După ce ați găsit componenta potrivită, o puteți plasa pe pânza de design cu un clic. Se va comporta ca orice alt obiect din designul dvs. Ceea ce îl va face special este că, deși este parte integrantă a design-urilor, acum îl puteți utiliza și personaliza la fel ca în cod .

UXPin vă oferă acces la proprietățile componentei, vă permite să modificați valorile și variabilele acesteia și să o completați cu propriile date. Odată pornit prototipul, componenta se va comporta exact conform așteptărilor, menținând toate comportamentele și interacțiunile.

În design-urile dvs., puteți combina și potrivi un număr nelimitat de biblioteci și sisteme de design . Pe lângă adăugarea unei biblioteci proprii, puteți alege dintr-o mare varietate de biblioteci open-source disponibile imediat, cum ar fi Material Design, Fluent UI sau Carbon.

Utilizarea unei componente „ca atare” înseamnă, de asemenea, că aceasta ar trebui să se comporte în funcție de schimbarea contextului, cum ar fi lățimea ferestrei de vizualizare. Cu alte cuvinte, astfel de componente sunt pe deplin receptive și adaptabile.

Notă : dacă doriți să aflați mai multe despre crearea de design-uri cu adevărat receptive cu UXPin, vă încurajez cu tărie să consultați acest articol.

Contextul poate însemna și tematică. Oricine a încercat să construiască (și să întrețină!) un sistem de design tematic într-un instrument de proiectare, sau cel puțin să creeze un sistem care vă permite să comutați cu ușurință între o temă deschisă și una întunecată, știe cât de dificilă este o sarcină și cât de imperfectă este aceasta. rezultatele sunt de obicei. Niciunul dintre instrumentele de proiectare nu este bine optimizat pentru tematică, iar pluginurile disponibile care vizează rezolvarea acestei probleme sunt departe de a o rezolva pe deplin.

Deoarece UXPin cu tehnologia Merge utilizează componente reale, live, le puteți, de asemenea, să le temați ca componente reale, live . Nu numai că puteți crea atâtea teme câte aveți nevoie, dar schimbarea acestora poate fi la fel de rapidă ca și alegerea temei potrivite dintr-un meniu vertical. (Puteți citi mai multe despre schimbarea temei cu UXPin aici.)

Avantaje

UXPin cu tehnologia Merge permite un nivel de paritate între design și cod rar întâlnit înainte. A fi fidel sursei într-un proces de proiectare aduce avantaje impecabile pentru toate părțile procesului. Designerii pot proiecta cu încredere știind că ceea ce fac ei nu va fi interpretat greșit sau dezvoltat greșit. Dezvoltatorii nu trebuie să traducă design-urile în cod și să se încurce prin cazuri marginale inexplicite și scenarii neacoperite. În plus, toată lumea poate participa la lucru și își poate prototipa rapid ideile folosind componente live, fără nicio cunoștință despre codul de bază. Realizarea unor procese mai democratice și participative este mult mai la îndemână.

Îmbinarea designului dvs. cu codul ar putea nu numai să îmbunătățească modul în care designerii cooperează cu ceilalți constituenți ai echipei, ci și să le rafinați procesele și practicile interne. UXPin cu tehnologia Merge poate schimba jocul pentru cei care se concentrează pe optimizarea eforturilor de proiectare la scară , denumite uneori DesignOps.

Utilizarea sursei corecte de adevăr face inexplicabil de mai ușoară menținerea coerenței între lucrările produse de diferiți oameni din echipă, ajută la menținerea lor aliniate și rezolvă problemele potrivite împreună cu un set comun de instrumente. Gata cu „simboluri detașate” cu o mână de variații nesolicitate.

În concluzie, ceea ce obținem sunt economii enorme de timp . Designerii își economisesc timp folosind componentele cu încredere și funcționalitățile lor care ies din cutie. Nu trebuie să actualizeze fișierele de proiectare pe măsură ce componentele se schimbă, nici să-și documenteze munca și să-și facă semne cu mâna pentru a-și explica viziunile restului echipei. Dezvoltatorii economisesc timp prin obținerea componentelor de la designeri într-o manieră digerabilă instantaneu, care nu necesită presupuneri și reparații suplimentare.

Persoanele responsabile cu testarea și QA economisesc timp în căutarea inconsecvențelor dintre design și cod și pentru a afla dacă implantarea s-a produs conform intenției. Părțile interesate și alți membri ai echipei economisesc timp printr-un management mai eficient și o navigare mai ușoară a unor astfel de echipe. Mai puține frecări și procesele fără întreruperi limitează frustrarea în rândul membrilor echipei.

Dezavantaje

Profitarea de aceste beneficii presupune totuși anumite costuri de intrare. Pentru a utiliza eficient instrumente precum UXPin în procesul dumneavoastră, trebuie să aveți un sistem de proiectare existent sau o bibliotecă de componente . Alternativ, vă puteți baza munca pe unul dintre sistemele open-source care ar oferi întotdeauna un anumit nivel de limitare.

Cu toate acestea, dacă sunteți angajat să construiți un sistem de proiectare în primul rând, utilizarea UXPin cu tehnologia Merge în procesul dvs. ar avea un cost suplimentar mic sau deloc. Cu un sistem de design bine construit, adoptarea UXPin nu ar trebui să fie o luptă, în timp ce beneficiile unei astfel de schimbări s-ar putea dovedi drastic.

rezumat

Adoptarea pe scară largă a sistemelor de proiectare a abordat problemele cu care lucrează dezvoltatorii media și designerii. În prezent, putem observa o schimbare către procese mai unificate care nu numai că transformă mediul, ci și modul în care îl creăm. Utilizarea instrumentelor potrivite este crucială pentru această schimbare. UXPin cu tehnologia Merge este un instrument de proiectare care permite combinarea designului cu componentele de cod live și restrânge drastic decalajul dintre domeniile în care operează proiectarea și dezvoltarea.

Unde urmează?

• UXPin Merge: Integrare Storybook
  Aflați cum integrarea Storybook vă poate ajuta echipa de produse și încercați-l!
• UXPin Merge: integrare Git
  Solicitați acces pentru a vedea cum funcționează integrarea cu depozitul Git.
• Scurt video explicativ despre UXPin Merge
  Ca parte a „Interactive Design Systems: Webinar with Johnson & Johnson”.
• Proiectați cu cod: Tutorial UXPin Merge
  Un tutorial introductiv la UXPin cu tehnologia Merge.
• Design receptiv cu UXPin Merge
  Un ghid pentru prototiparea experiențelor pe deplin receptive cu UXPin cu tehnologia Merge.