Viitorul proiectării interfeței cu utilizatorul: instrumente UI de ultimă generație

Instrumentele de design UI au parcurs un drum lung de la prima generație de Adobe Photoshop, un program destinat editarii fotografiilor, nu creării de interfețe dinamice de utilizator. Generația actuală de instrumente, cum ar fi Adobe XD, Figma și Sketch, ne-au făcut munca mai ușoară și mai rapidă.

Cu toate acestea, ineficiența fluxurilor noastre de lucru de zi cu zi abundă și pierdem timp și resurse prețioase atunci când am putea proiecta produse pe care oamenii doresc să le folosească. Programele de design disponibile astăzi sunt superioare celor cu care am început, dar nu reușesc să valorifice tehnologia actuală și ne împiedică să realizăm întregul nostru potențial ca designeri de UI.

Este timpul pentru o nouă generație de instrumente UI.

Integrarea designului și codului

Viitoarele instrumente de interfață cu utilizatorul vor aduce designul și codul împreună pentru a oferi o experiență mai simplă pentru designeri și dezvoltatori. Instrumentele noastre actuale nu ne ajută să proiectăm interfețe de utilizare web; ne ajută să proiectăm reprezentări abstracte ale interfețelor de utilizare web. Machetele realizate în Figma și Sketch sunt deconectate de la codul sursă.

Astăzi, mulți designeri cunosc elementele de bază ale HTML și CSS. Unii hard-lineers proiectează în cod, dar acest lucru nu este eficient pentru proiecte complexe; designerii au nevoie de capacitatea de a explora rapid o dovadă a conceptului înainte de a se angaja în aceasta.

Dezvoltatorii de software au Visual Studio Code, un instrument care unește editarea și dezvoltarea codului și le permite inginerilor să construiască, să testeze și să depaneze codul în același mediu. În mod similar, designerii au nevoie de un mediu de dezvoltare vizuală care să ofere capabilități complete de proiectare, dar și să genereze cod gata de producție.

Iată ce ne rezervă viitorul.

Crearea paralelă va înlocui transferurile pentru proiectant/dezvoltator

Există prea mult timp înainte și înapoi între designeri și dezvoltatori, mai ales în faza de transfer. În unele cazuri, transferul este atât de consumator de timp și de obositor, încât calitatea muncii are de suferit. Cu instrumentele de proiectare de ultimă generație care se interfață cu codul sursă, dezvoltatorii nu vor mai fi singurii responsabili pentru construirea interfețelor de utilizare. În schimb, ei se vor putea concentra pe dezvoltarea arhitecturii logice care conectează interfața de utilizare a unui produs la back end și îl face să funcționeze corect.

Designerii vor pune bazele interfețelor de utilizare cu codul încorporat, iar dezvoltatorii vor construi pe acest cod pentru a da viață produselor. Designerii nu vor mai fi nevoiți să-i sâcâie pe dezvoltatori cu solicitări precum „Vă rugăm să adăugați 16 px de umplutură în loc de 8 px, așa cum se arată în machetă”. Și dezvoltatorii nu vor trebui să se oprească pentru a pune întrebări de proiectare, cum ar fi „Cum ar trebui să se scaleze această componentă între punctele de întrerupere pentru tabletă și desktop?”

În schimb, designerii și dezvoltatorii vor colabora pentru probleme mai importante, cum ar fi dacă o abordare de proiectare este viabilă, având în vedere timpul și bugetul sau dacă toate stările unei componente ale UI au fost abordate.

Instrumentele UI de proiectare și software-ul pentru dezvoltatori se vor alinia

Instrumentele actuale se bazează pe modele de programare personalizate pentru a genera componente de proiectare. Aceste modele, în general, nu sunt la fel de robuste ca CSS și nu permit designerilor să vadă codul generat automat care stă la baza fișierelor lor de design - cod care trebuie să fie exportat în cele din urmă în HTML, CSS sau JavaScript. Ar fi mult mai simplu dacă instrumentele noastre ar folosi HTML și CSS în mod nativ.

De exemplu, CSS utilizează modelul casetei, care solicită plasarea elementelor HTML pe fiecare pagină într-o casetă care este codificată pentru a-i defini înălțimea, lățimea, chenarul și umplutura. Figma este aproape de a oferi această capacitate cu caracteristica sa de aranjare automată. Dar dacă Figma ar folosi modelul cutie care alimentează deja majoritatea interfețelor de utilizare web, dezvoltatorii ar trebui să traducă și să exporte mai puțin.

Același lucru este valabil și pentru moștenirea stilului, care controlează ce se întâmplă atunci când nu este specificat niciun stil pentru un anumit element - similar cu un implicit. CSS îl folosește, dar majoritatea instrumentelor de design, care nu au fost create pentru a fi specifice web, nu o folosesc.

Avem nevoie de instrumentele noastre pentru a afișa vizualizări web, nu planșe statice sau machete. Nu avem nevoie de simulatoare HTML și CSS. Avem nevoie de HTML și CSS.

Machetele vor deveni învechite

În loc de machete de aruncat, haideți să aruncăm machete pe ușă.

Machetele lasă prea multe întrebări fără răspuns. Este imposibil să proiectați unul pentru fiecare mediu digital. Astăzi, designerii creează layout-uri pentru lățimi de ecran de 320 px, 834 px și 1440 px; dar ce se întâmplă dacă o parte a aspectului se rupe pe o fereastră de vizualizare de 1220 px? Și de ce să nu optimizați pentru 375 px, o dimensiune comună pentru telefoanele mai mari de astăzi?

Crearea unei planșe pentru fiecare scenariu este nepractică, mai ales când se iau în considerare toate punctele de întrerupere și vizualizările, ca să nu mai vorbim de temele întunecate. Proiectarea pentru toate aceste variabile crește numărul de planșe de artă dincolo de rațiune.

Machetele sunt, de asemenea, o risipă de resurse. Construirea lor necesită mult timp și au devenit mai puțin importante în designul de produse digitale. Webflow a eliminat modelele și, în schimb, pledează pentru prototipuri interactive, receptive. (Din păcate, Webflow se limitează la soluții bazate pe web și se adresează site-urilor web simple). Și, în timp ce livrabilele de aruncat ar putea avea sens în timpul ideii, sunt o risipă în timpul fazei de soluție.

Toate statele sistemului vor fi luate în considerare

Toate produsele digitale au stări care corespund cu ceea ce fac la un moment dat, de exemplu, blocarea în timpul încărcării sau afișarea unui mesaj de eroare.

Fiecare stare trebuie luată în considerare, dar instrumentele actuale de UI lasă această sarcină în seama designerilor, obligându-i să creeze numeroase variante ale unei singure componente. Instrumentele de dezvoltare React și Vue.js permit dezvoltatorilor să se adapteze cu ușurință la toate stările posibile ale unei componente. Instrumentele de proiectare trebuie să urmeze exemplul și să-i încurajeze pe designeri — chiar să-i sâcâie — pentru a se asigura că toate stările componente sunt proiectate pentru.

Datele reale vor înlocui conținutul substituent

Așa cum designerii creează componente pentru mai multe stări, ei proiectează și pentru o mare varietate de date. Designerii de interfață de utilizare trebuie să poată testa componentele lor cu intrarea reală - copia, imaginile, datele, numele, titlurile și multe altele - care în cele din urmă vor popula componentele din designul lor. În prezent, designerii pot simula datele doar prin copierea și lipirea manuală a acestora în tablouri de artă, o sarcină extrem de obositoare. Există pluginuri care pot ajuta la automatizarea acestui proces, dar sunt greoaie.

Cererea dezvoltatorilor să evalueze modul în care componentele gestionează datele nu este nici un răspuns. Până când componentele ajung la testare, este nevoie de prea mult timp pentru a le reproiecta. Și dacă designerii nu pot testa și repeta componente cu date reale, de unde vor ști dacă un card funcționează cu un titlu lung sau fără titlu? Cum vor descoperi că un font nu acceptă caractere arabe sau că un site nu găzduiește limbi care sunt citite de la dreapta la stânga?

Testarea Edge-case va deveni mai ușoară

Atunci când instrumentele UI se potrivesc în sfârșit tuturor statelor și permit testarea datelor reale, designerii vor putea anticipa mai bine cazurile marginale. Odată ce o componentă este creată, designerii vor testa diferitele stări ale acesteia, explodând-o cu date diverse pentru a vedea cum funcționează în diferite scenarii. În acest fel, interfața de utilizare va deveni domeniul designerului, eliberând dezvoltatorilor să se concentreze pe sarcini precum repararea JavaScript-ului sau testarea API-urilor.

Se va deschide o lume de instrumente pentru dezvoltatori și extensii de browser terță parte

Odată ce munca noastră trăiește în HTML și CSS, un întreg ecosistem de extensii va deveni disponibil în timpul fazei de proiectare, cum ar fi indispensabilul Lighthouse pentru audituri de performanță, SEO și accesibilitate, sau diferitele instrumente pentru dezvoltatori de browser care simulează punctele de întrerupere a dispozitivului și vitezele reduse ale rețelei. Setul de instrumente de browser este mult mai valoros pentru crearea și testarea interfețelor de utilizare pregătite pentru producție decât oricare dintre pluginurile din Figma, Sketch sau Adobe XD.

Designerii și dezvoltatorii vor lucra în paralel

Asamăn starea actuală a dezvoltării produsului cu o bucătărie în care un bucătar încearcă să gătească un fel de mâncare dictând altui bucătar ce trebuie să facă: ar putea funcționa, dar va dura mult mai mult și va fi mult mai puțin eficient. Există companii care dezvoltă instrumente de proiectare bazate pe cod – Hadron, Modulz și Relate au produse în versiune beta. Adoptarea pe scară largă a acestor instrumente va marca începutul unei revoluții în crearea de produse digitale.

De asemenea, va semnala o schimbare radicală în relația designer-dezvoltator. Cu cele două părți lucrând în paralel, echipele de produse vor deveni exponențial mai eficiente. Dezvoltatorii vor fi liberi să abordeze logica complexă a arhitecturii UI în loc să piardă timpul interpretând machetele sau să se împotmolească de către designeri, cerându-le să împingă pixelii la perfecțiune. Iar designerii vor fi mai valoroși pentru echipele și companiile lor, pe măsură ce devin co-constructori ai produselor digitale de succes.