Smashing Podcast Episodul 9 cu Stephanie Walter: Cum pot lucra cu cadrele UI?

În calitate de dezvoltator, unul dintre lucrurile care îmi plac la cadrele UI este că deseori vin cu un stil implicit, dar este ceva pe care ar trebui să ne bazăm în proiecte? Folosind pur și simplu stilul implicit și ai încredere că cine a produs cadrul a făcut o treabă foarte bună în proiectarea acelor componente? Vino alături de mine pentru episodul de podcast de astăzi, în care vorbesc cu designerul UX Stephanie Walter despre lucruri pe care ar trebui să le luăm în considerare atunci când construim pe un cadru UI.

Afișați note

• Site-ul lui Stephanie
• Stephanie pe Twitter

Actualizare săptămânală

• „Cum se creează un joc de potrivire a cărților folosind Angular și RxJS” de Anna Prenzel
• „Cum să creezi un site WordPress fără cap pe JAMstack” de Sarah Drasner
• „Magic Flip Cards: Rezolvarea unei probleme comune de dimensionare” de Dan Halliday
• „Repere Django: Modele de utilizator și autentificare (Partea 1)” de Philip Kiely
• „Cum se creează hărți cu React și pliant” de Shajia Abidi

Transcriere

Drew McLellan: Ea este un designer centrat pe utilizator și expertă în experiența mobilă, care a încrucișat produse și interfețe încântătoare, cu un accent special pe performanță. Ea a lucrat la proiecte pentru clienți precum Universitatea din Luxemburg, Banca Europeană de Investiții, BMW și Microsoft, pentru a numi doar câteva, și îi ajută pe acești clienți să livreze proiecte de succes publicului lor, de la strategie până la produsul final. Ea este un dezvoltator Google expert în design de produse și o profesoară pasionată care își împărtășește cunoștințele în numeroase postări de blog, articole, ateliere și prezentări la conferințe. Așa că știm că este un designer expert în experiența utilizatorului, dar știai că a avut odată un loc de muncă la montarea covoarelor cu Sir Elton John? Prietenii mei Smashing, vă rog bun venit lui Stephanie Walter. Salut Stephanie, ce mai faci?

Stephanie Walter: Bună, sunt zdrobitoare și mi-a plăcut prezentarea.

Drew: Așa că am vrut să vă vorbesc astăzi despre o anumită problemă și acesta este subiectul utilizării cadrelor de interfață cu utilizatorul disponibile. Acum ești un designer de experiență de utilizator și lucrezi cu o mulțime de clienți diferiți, iar munca ta este să îi ajuți pe acești clienți să creeze cele mai bune experiențe de utilizator posibile prin crearea de interfețe de utilizator extrem de utilizabile. Așa că ideea de a putea face asta cu un set de instrumente de la raft mi se pare puțin exagerat. Utilizarea cadrului UI este ceva pe care îl vedeți foarte des pe parcursul muncii dvs.?

Stephanie: Da, este ceva ce am văzut mult, mai ales în ultimii ani pentru că am început să lucrez cu o agenție și acum lucrez în cadrul companiei. Deci, în acele echipe de tehnologie IT foarte mari și da, în acest moment există o mulțime de interfețe de utilizare cadru, cum ar fi cea pe care am văzut-o cel mai mult este Material-UI, în principiu, Material design este un fel de linii directoare și chestii de design Google, și Material. -UI este echipa de la Angular, dar și echipa de la React. Ei și-au creat propriul cadru folosind un fel de aspect și senzație de design Material de la Google. Dar nu mai are nimic de-a face cu Google. E ca și ei, nu știu, cred că le-a plăcut aspectul și senzația. Deci, în acest moment, acestea sunt cele două cadre principale de UI cu care lucrez. Și, de asemenea, există ceva numit Ant Design, care a devenit destul de popular.

Stephanie: Este un framework React. Nu știu dacă au și Angular. Cred că a fost făcut de o echipă din China. Și este interesant pentru că nu numai că furnizează componentele, totul în React, dar dacă intri pe site-ul lor, vei primi și fișierele scratch, ceea ce este de fapt destul de interesant pentru că apoi motivează sau ajută designerul să construiască sau să modeleze interfața în componentele UI utilizate de acel cadru. Așa că da, este ceva ce am văzut mult, mai ales în echipele mari de IT pentru că de cele mai multe ori acestea nu au un designer. În acest moment, sunt practic o echipă de UX dintr-o echipă mică la o bancă europeană de investiții. Deci sunt eu ca designer UX. Lucrez cu o echipă de dezvoltatori, analiști de afaceri, toți oamenii buni, dar sunt totuși un designer pentru întreg proiectul.

Stephanie: Până să ajung eu nu era designer. Deci este un fel de soluție implementată în multe companii, în special pe produsele interne, de exemplu. Acolo unde se spune de obicei, bine, nu prea avem nevoie de un designer pentru asta. Avem nevoie doar de ceva care să funcționeze pentru utilizatorii noștri interni și să folosim doar un cadru pentru că este convenabil pentru dezvoltatori. Majoritatea componentelor sunt deja acolo și din moment ce nu au designeri în echipă, atunci se cam înlocuiește, ca să zicem, rolul unui designer de UI. Da, problema cu asta este că, bine, atunci ai componentele, dar rolul designerului UI nu este doar să decidă dacă butonul ar fi roșu, verde, portocaliu, albastru, orice altceva. De obicei, rolul designerului UI este arhitectura informației, înțelegerea nevoilor utilizatorilor. Deci tot ce trece dincolo de interfață. Deci, chiar dacă aveți acest tip de cadru, acesta are grijă de întreaga interfață, deci vizual ceea ce vedeți pe ecran.

Stephanie: Mai ai nevoie de cineva la un moment dat care să facă treaba de a înțelege ce punem pe ecran, cum se va comporta? Ce se întâmplă când facem clic aici? Cum își atinge utilizatorul scopul? Cum mergem de la punctul A la punctul B? Pentru că putem folosi un model, putem folosi file, putem folosi toate componentele. Deci, de aceea, este întotdeauna un pic complex și complicat.

Drew: Este posibil, crezi că poți crea o interfață de utilizator utilizabilă folosind un cadru de interfață de utilizare de la raft sau va fi întotdeauna un pic de compromis?

Stephanie: Sper că da. Sper că da, pentru că altfel construiesc interfețe care nu pot fi utilizate. Deci acest răspuns este total părtinitor, dar da, cred că este, dar depinde și de nivelul de compromis pe care ești dispus să-l faci și există compromisuri de ambele părți. Momentan compromit o mulțime de butoane, de exemplu, pentru că aveți niște butoane cu adevărat specifice în Material-UI și nu prea îmi place efectul de ondulare pe buton. Cred că funcționează grozav pe mobil, deoarece pe mobil aveți nevoie de un fel de feedback mare atunci când utilizatorul face clic pe sau atinge butonul. Dar apoi pașii sunt un fel de efect de ondulare care merge până la buton. Este puțin exagerat, mai ales când sunt multe butoane. Dar totuși vom păstra acest efect de ondulare, deoarece ar fi foarte complex să îl eliminam, deoarece acesta a fost integrat în cadrul React. Și pentru a avea un alt efect de hover pe acest buton, ceva mai subtil, care nu va fi acest tip de chestie grozavă aici. Ar fi super complex.

Stephanie: Deci, acesta este genul de compromisuri pe care le faci. Dar, între timp, nu fac compromisuri în anumite lucruri, care sunt componente personalizate. Unde lucram înainte, clientul actual al unei companii de călătorii și linii aeriene. Și compania aeriană are niște nevoi foarte, foarte specifice. Calendarul companiei aeriene de exemplu, vrei sa pui preturi, vrei sa pui... daca nu calatoresti la aceasta destinatie la o data anume, nu stii cand sa pui asta, ai aceasta plecare si sosire si calendarul de bază al majorității acestor cadre de UI nu oferă astfel de lucruri. Deci, la un moment dat, puteți spune, bine, vom folosi doar calendarul pe care îl au. Si asta e. Trebuie să treci dincolo de asta. Deci, majoritatea compromisurilor sunt construite pe baza, folosim componenta de bază? Creăm unul personalizat care să se potrivească nevoilor utilizatorului? Sau facem un amestec dintre cele două? În cazul calendarului, de exemplu, folosim grila calendarului, așa că folosim componenta de bază și apoi am îmbunătățit-o cu personalizare pe deasupra. Deci a fost o mulțime de dezvoltare React pentru asta.

Stephanie: Și da, așa că de obicei faci multe compromisuri.

Drew: Deci, se pare că folosirea unui cadru de interfață cu utilizatorul vă poate ajuta să ajungeți într-o anumită măsură, dar pentru a avea cu adevărat o interfață de utilizator bună ca urmare a acesteia, trebuie să faceți o personalizare destul de mare pe deasupra?

Stephanie: De obicei. Da.

Drew: Această personalizare depășește tematica?

Stephanie: Da, dezvoltatorul meu și-a dorit să nu depășească tematica. Eugene Dacă mă asculți. Cred că ar fi super fericit dacă am schimba doar câteva culori pe toate. Dar da, la un moment dat trebuie să treceți dincolo de personalizare, pentru că mai întâi, ca și cadrele UI, instrumentele Lego sunt un fel de cutie de instrumente. Deci aveți o mulțime de componente diferite în cutie, dar aceasta nu construiește o pagină. Mai aveți nevoie de un antet, mai aveți nevoie de un subsol. Mai aveți nevoie de conținut suplimentar care nu a fost în cadru. Deci, uneori, puteți modifica o componentă în ceea ce aveți nevoie. Din câte am înțeles, folosim componenta cardului pentru a construi o fereastră modală, dar treaba cu ferestrele modale este că nu prea se comportă ca un card.

Stephanie: Treci puțin peste asta. Ai nevoie de un fundal cu obscurificare. Trebuie să-l declanșați la clic, în timp ce de obicei cardul dvs. este deja acolo în interfață. Așa că folosim această componentă a cardului pentru că are multe dintre lucrurile de care avem nevoie, cum ar fi fundalul, un antet și un titlu în partea de sus, câteva butoane în partea de jos. Deci avem structura și apoi o modificăm puțin. Dar ajungem să avem un conflict uneori despre semantică, și despre HTML. Pentru că, de exemplu, am vrut să am butoane care să nu aibă forme de buton, așa că la fel ca butonul de link și dezvoltatorul a spus: „Bine, deci folosim un link precum linkul tău href”. Am spus: „Nu, acesta nu este un link. Este un buton. Când fac clic pe el, nu deschide o pagină nouă. Curăță tot ce este în formă.”

Stephanie: Deci ar trebui să fie tehnic din punct de vedere semantic, ar trebui să fie un buton. „Da. Dar nu există în cadru.” Eu spun „Deci bine, știu, deci ce facem?” Așa că, de obicei, începeți să discutați despre aceste lucruri mărunte și, din moment ce îmi enervez cu adevărat dezvoltatorii și cu accesibilitatea, acesta este un alt nivel suplimentar de încercare de a ne asigura că avem componentele de bază cu care funcționează bine. Dar și că sunt semantic ca și cum nu vreau să am butoane cu gif-uri în gif-uri în gif-uri. Altfel vom avea probleme până la urmă.

Drew: Bănuiesc că pentru a începe un nou proiect care va folosi un cadru UI, probabil că trebuie să începeți cu un fel de cercetare a utilizatorilor.

Stephanie: Da.

Drew: E corect?

Stephanie: Ar trebui. Trebuie să. Deci da, de obicei poți avea toate componentele pe care le dorești. Încă mai trebuie să știi de ce au nevoie utilizatorii tăi pe pagini, cum vor naviga? Trebuie să construiți un flux. Deci, de obicei, chiar înainte de a ne decide asupra unui cadru, ceea ce facem este să mergem la utilizatorii noștri, să vorbim cu ei, să încercăm să le înțelegem nevoile. Deci, în acest moment sunt destul de norocos pentru că utilizatorii sunt intern în cadrul băncii. Așa că facem o mulțime de ateliere cu ei și trebuie să vă imaginați că este o interfață super complexă. Migrem de la ceva care a fost construit, nu știu, cred că acum 10 sau chiar 15 ani la ceva cu totul nou strălucitor folosind Material-UI React. Deci este o schimbare destul de mare și trebuie să înțelegi că în acești 15 ani, toți cei care și-au dorit ceva au putut merge la suport și apoi au cerut echipei IT să o implementeze. Deci, în acest moment, interfața mea este ca 400 de pagini cu tabele, în tabele, în tabele, cu alte tabele și lucruri care nici măcar nu ar trebui să fie în tabele.

Stephanie: De parcă avem o mulțime de lucruri care sunt doar valoare cheie, valoare cheie, valoare cheie. Așa că ei construiesc tabelul cu două coloane. Eu zic: „Nu, poate putem face ceva mai bun cu asta.” Deci, în acest moment, ceea ce facem este că am făcut câteva cercetări asupra utilizatorilor pentru a înțelege diferitele obiective ale utilizatorilor. Deci, ceea ce am identificat este că ceea ce fac ei cu interfața, au niște obiective de planificare. Trebuie să-și planifice munca. Așa că vreau să știu că această operațiune va merge la această întâlnire, așa că am nevoie de asta în acel program, chestii de genul ăsta. Vor să monitorizeze un lucru, vor să raporteze datele. Prin urmare, monitorizarea este ca și cum ați privi datele și vă asigurați că totul este în regulă. Raportarea înseamnă a putea exploata datele, a face ceva cu ele pe care doresc să le împărtășească și să colaboreze cu colegii și toate acestea le-am descoperit discutând direct cu utilizatorii.

Stephanie: Și ceea ce am descoperit este că, de fapt, unele dintre lucrurile pe care plănuiam să le migrăm la sfârșit sunt unele dintre cele mai importante lucruri zilnice pentru utilizator. Deci, obiectivul utilizatorului de planificare este unul dintre cele mai mari în acest moment. Deci lucrăm cu adevărat la asta. Deci, da, folosim interviul și acum suntem în faza în care momentan suntem la un nivel foarte înalt și spunem că trebuie să construim shell-ul, trebuie să înțelegem navigația. Dar în acest moment nu am trecut cu adevărat prin toate datele și asta este acum ceea ce vom face. Și este interesant pentru că avem o mulțime de tabele și am spus că putem fie să mergem într-un mod care nu este inteligent și să punem tabelele în noua interfață și am terminat, sau putem spune, bine, să încercăm să înțelegem ce aceste tabele sunt: ​​Pentru ce folosesc utilizatorii noștri acest tabel?

Stephanie: Și atunci poate că unele dintre tabele ar putea fi afișate ca vizualizare a datelor și apoi pentru a face asta trebuie să înțelegeți întreaga afacere, astfel încât datele să aibă sens. Deci, dacă aveți un cadru frumos și spuneți, bine, să folosim această diagramă... Cred că se numește cadru grafic JS. Ai o mulțime de lucruri, poți avea histogramă, diagrame circulare și grafice și tot, dar la un moment dat tot ai nevoie de un designer care să te ajute să te decizi. Bine, aceste date, au sens dacă le arătăm într-un grafic sau este mai logic să le arătăm ca o plăcintă pentru că vrem să arătăm o parte din întreg sau vrem să comparăm evoluția unei țări în ultimele 10 ani, atunci o histogramă este mai interesantă. Deci, pe baza a ceea ce utilizatorul dorește să facă cu datele, le veți afișa într-un alt mod.

Stephanie: Și de obicei nu este o sarcină de dezvoltator să faci asta. Dezvoltatorul nostru, sunt un tip super inteligent. Îmi pare rău, dar sincer lucrez cu dezvoltatori băieți, mi-aș dori să am niște doamne, dar nu. Niciuna dintre ele nu este femeie. Deci, băieți super inteligenți, dar nu sunt super calificați să spună, bine, aceste date ar trebui să fie afișate așa, asta, asta și asta. Așa că, în cele din urmă, mai aveți nevoie de niște designeri să vorbească cu utilizatorii, să înțeleagă ce puteți face cu datele și acest lucru merge mult dincolo de a spune, bine, aceasta ar trebui să fie o bară de file sau aceasta ar trebui să fie o navigare în stânga.

Drew: Și după ce am luat astfel de decizii bazate pe discuția cu utilizatorii. De obicei, ați duce prototipurile sau modelele rezultate înapoi utilizatorilor pentru a le testa din nou pentru a vedea dacă înțeleg tipul dvs. de alegere pentru diagramă, de exemplu?

Stephanie: Da, am făcut asta de fapt multe, ceea ce este foarte frumos pentru că atunci nu dezvolți ceva până nu știi că va fi util și utilizabil. Deci depinde. Dacă este mai rapid să dezvolți lucrul, deoarece au deja majoritatea componentelor, ceea ce fac de obicei este să fac prototip de hârtie foarte rapid și apoi dezvoltăm lucrul pentru că este rapid, chiar și fără date. Dacă este ceva complex, ceva cu adevărat, cu adevărat nou, care va dura mult timp pentru a se dezvolta, atunci spunem, bine, proiectăm câteva ecrane și facem niște teste direct pe ecran. Deci avem un instrument care se numește InVision, în care, practic, puneți tot designul, puteți crea legături între diferitele părți. Chestia este că depinde și ce vrei să testezi. Dacă doriți să testați telefoane, de exemplu, este un coșmar să le testați pe cele din InVision pentru că oamenii nu le simt cu adevărat și mai ales pe telefonul mobil, de exemplu.

Stephanie: Deci este întotdeauna să fii inteligent. Care este cel mai rapid și mai ieftin mod? Este mai rapid și mai ieftin să testați numai modele? Este suficient? Pentru formulare, de obicei, nu chiar pentru că ați finalizat automat toate sarcinile grele pe care le puneți în partea din față, care au de fapt utilizatorul să completeze un formular, așa că pentru formulare, poate este mai eficient să construiți un formular și să îl testați. Dar pentru lucruri noi, da, facem o mulțime de modele. Mergem la utilizatori. Deci, momentan fie facem unu-la-unu, dar utilizatorii mei sunt oameni foarte ocupați. Este o bancă europeană de investiții, așa că nu au atât de mult timp. Deci, ceea ce facem de obicei este că, dacă venim la unu-la-unu cu utilizatorii, facem câteva întâlniri mici, ca mai degrabă focus grupuri. Și este, de asemenea, interesant pentru că atunci ai un fel de confruntare uneori. Unii oameni spun: „Da, cred că funcționează pentru mine pentru că lucrez așa și așa”, iar apoi vor mai fi alți oameni care vor spune: „O, tu lucrezi așa? De fapt, nu, o fac așa și așa.”

Stephanie: Așa că este, de asemenea, interesant să am câțiva oameni în cameră și să ascult doar conversația, luând notițe și să spunem: „Oh, poate atunci am putea face asta” și „Această componentă ar fi mai bună pe baza a ceea ce tocmai am făcut. auzit." Și lucruri de genul ăsta.

Drew: Dacă lucrați cu un public mai general pentru produsul dvs. Deci, poate nu utilizatorii interni ca dvs., ci mai mult publicul larg, există modalități ieftine prin care designerii pot folosi cercetarea? Există modalități mai ușoare dacă nu știi direct cine vor fi utilizatorii tăi?

Stephanie: Ar trebui să știi cine vor fi, altfel face treaba oamenilor de marketing înainte de a construi produsul. Dar da, am făcut niște teste pentru utilizatorii de gherilă, de exemplu, puteți folosi în continuare InVision, de exemplu. Deci, puteți construi câteva prototipuri în InVision și apoi puteți recruta utilizatorii prin intermediul rețelelor sociale, de exemplu. Lucram pentru un produs care a ajutat, cum se numeste, mecanici dealeri auto care repară lucrurile și apoi să informeze și clientul despre reparații suplimentare, lucruri de genul ăsta. Deci aveam deja o comunitate în creștere pe LinkedIn și Facebook. Deci ceea ce poți face este să poți recruta acești oameni. Puteți face testarea de la distanță, ca și cum am avea o conversație într-un instrument precum un instrument online. Puteți face niște partajări de ecran. Așa că am făcut asta și pentru un proiect.

Stephanie: V-aș da doar un sfat este să testați instrumentul înainte, pentru că îl foloseam, se numea appear.in. Dar cred că au schimbat numele în Whereby sau ceva de genul ăsta, dar chiar în browser am spus, bine, e frumos pentru că atunci utilizatorii nu trebuie să instaleze nimic, dar utilizatorii nu erau pe un computer real. Erau în VM, într-un Citrix și nu aveau microfoane, așa că ceea ce am ajuns să facem este ca și cum ar folosi instrumentul meu pentru a partaja ecranul. Făceau clic pe prototip și, în același timp, îi aveam la telefon, ca pe un telefon fix, pentru a vorbi direct cu ei. Așa că există întotdeauna, asta a fost destul de ieftin pentru că a fost o zi minunată de recrutare, cred că am avut 10 utilizatori sau ceva de genul ăsta. Da, poți face o mulțime de lucruri chiar dacă nu poți merge față în față, am făcut multe teste de utilizare direct pe Skype sau lucruri de genul ăsta. Deci, există întotdeauna câteva modalități ieftine de a face asta.

Drew: Când vine vorba de alegerea unui cadru UI cu care să lucrați, dacă acesta este calea pe care o urmați, este ceva pe care l-ați lăsa doar dezvoltatorilor sau este ceva în care ar trebui să se implice și designerii?

Stephanie: Pentru mine, ar trebui să implici întreaga echipă. La fel ca designerii, dezvoltatorii, poate și arhitecții dacă aveți unii, pentru că modul în care este construit cadrul ar putea influența și acest gen de lucruri. Din păcate, de cele mai multe ori când ajung pe proiect, cadrul era deja decis. Nu, de fapt este amuzant, fie e deja decis, fie îmi cer să validez alegerea lor asupra cadrului, dar nu am făcut nicio recenzie sau cercetare. Nu am nicio idee ce este în proiect pentru că nici măcar nu mi-au arătat ecranele lor. Ei spun: „Da, fă-ți treaba. Putem folosi acest cadru.” Nu știu. Ei bine, avem un ecran? Așa că au ajuns să îți arate câteva ecrane, care era o aplicație nativă Windows pe care doreau să o migreze în cloud. Ei au spus: „Da, avem nevoie doar de butoane și mai ales forme și lucruri de genul ăsta”.

Stephanie: Dar este foarte greu de spus: „Da, alege acest cadru, avem toate componentele de care avem nevoie.” Sau de genul „Nu mergeți dacă nu aveți o idee aproximativă despre ce va fi conținutul dvs., care este navigarea.” Deci, cred că ar trebui să aveți în continuare o imagine de ansamblu globală înainte de a vă alege cadrele, dacă nu sunteți 100% sigur că aveți toate componentele. Dar am sentimentul că de cele mai multe ori alegerea cadrului se bazează în principal pe ce tehnologii le plac dezvoltatorilor în acest moment, au experiență cu un cadru înainte de asta? Am folosit Ant în unele proiecte doar pentru că câțiva dezvoltatori aveau experiență cu asta și le-a plăcut foarte mult și au fost oarecum eficienți folosind Ant. Și pentru Material React UI este același. Este ca și cum dezvoltatorul l-a folosit deja pe proiectele anterioare, așa că sunt eficienți cu el.

Drew: Deci, trebuie să existe un echilibru între ceea ce dezvoltatorii sunt confortabili, ceea ce știu ei, ce va funcționa cu tehnologia lor și apoi care sunt cerințele produsului în ceea ce privește crearea unei interfețe bune de utilizator. Și cumva trebuie să le echilibrezi pe cele două pentru a găsi cadrul ideal pentru asta.

Stephanie: Da. Am un fel de cerință specifică pentru un anumit proiect, care este... Sunt în Luxemburg, avem o mulțime de instituții europene și lucruri de genul ăsta, așa că avem o cerință suplimentară de accesibilitate pentru unele dintre acestea. Și, de obicei, când a fost decis cadrul, ei nu au verificat cu adevărat accesibilitatea cadrului lor și apoi revin la câteva luni după începutul proiectului spunând: „Oh, tocmai ne-a spus că există această nouă lege și ar trebui să fie accesibil, dar nu știm cum să facem asta.” Ca da, e puțin prea târziu. Deci, pentru mine, pentru a alege un cadru, trebuie să cunoașteți cu adevărat toate constrângerile de la începutul proiectului și, dacă accesibilitatea este una dintre ele, trebuie să vă testați componentele și să vă asigurați că vor fi accesibile. Dar nu sunt un dezvoltator React sau Angular, dar sunt destul de sigur că este super complex să transformi un cadru UI inaccesibil în ceva accesibil. Cred că ar putea fi puțin complex să reconstruiești toate componentele, așa că lucruri de genul ăsta.

Drew: Dacă te trezești că lucrezi la un proiect în care acel proces nu a avut loc și a fost deja ales un cadru UI, există pericolul ca interfața cu utilizatorul să înceapă să fie influențată de componentele care există deja în acel cadru, mai degrabă decât de fiind condus de nevoile utilizatorului?

Stephanie: Cu adevărat, sincer, majoritatea proiectelor la care am lucrat, în cele din urmă ajungi să ai multe compromisuri, chiar dacă încerci cu adevărat să împingi. Deci este vorba în principal despre echilibru și discuții cu dezvoltatorii. Deci, de obicei, ceea ce fac este să facem niște rame de sârmă, chiar și rame de sârmă de hârtie rapide, spuneți bine, pe această pagină vom avea nevoie de asta și aia și acea componentă, primul lucru pe care îl fac este să întreb dezvoltatorul dacă avem asta în cadru momentan? Cu ce ​​seamănă? Și apoi decidem împreună, bine, aceasta este o componentă care ar face treaba sau bine aceasta nu va face treaba. Îl ajustăm? Mai păstrăm componenta, dar o schimbăm puțin, astfel încât să facă treaba, sau construim ceva de la zero?

Stephanie: Și la sfârșitul zilei va depinde de buget desigur. Deci ai ajuns să faci schimburi. Ca și cum aș fi în regulă pentru componentele mici care nu sunt aproape niciodată folosite dacă nu sunt perfecte și există puține probleme. Dar pentru navigația principală, structura principală, lucrurile pe care le vedeți tot timpul pe ecran, de exemplu, acest lucru chiar trebuie să funcționeze. Nevoile utilizatorului să înțeleagă cum funcționează eficient și da, este, așa cum ați spus, găsirea unui echilibru între experiența ideală pe care v-ați dori să o aveți dacă nu ați avea niciun cadru și ceea ce aveți la îndemână și buget și, de asemenea, sincronizare. Dacă spunem, bine, pentru aceste sprinturi, caracteristica trebuie să fie terminată la sfârșitul acestui sprint, iar apoi ei spun, bine, dar dacă doriți componentele dvs., nu vom termina niciodată caracteristica la sfârșitul acestui sprint, atunci dvs. începeți să discutați, bine, terminăm această funcție în ecranul următor, luăm mai mult timp pentru a o face corect? Și, de obicei, chiar depinde.

Stephanie: Lucrurile care mă frustrează cel mai mult sunt atunci când știu că folosim o componentă crop fix și îmi spun: Oh, nu, nu-ți face griji. Vom repara asta mai târziu. Și știam că, din păcate, s-ar putea să nu se întâmple niciodată. Deci depinde de echipa. Dar după un timp ai experiența și știi, asta va ajunge mai târziu și sau nu? Da, este vorba de compromisuri. Când lucrați cu astfel de instrumente.

Drew: În calitate de dezvoltator, unul dintre lucrurile care îmi plac la cadrele UI este că deseori vin cu stil implicit. Deci, asta înseamnă că nu trebuie neapărat să am un designer, poate să mă ajute cu aspectul și senzația tuturor componentelor. Este ceva pe care ar trebui să ne bazăm în proiecte? Doar stilul implicit și încrederea că cine a produs cadrul a făcut o treabă foarte bună în proiectarea acelor componente? Sau ai stila singur acele componente?

Stephanie: Cred că depinde cu adevărat. Problema, de exemplu, cu Material-UI este aspectul și senzația aplicației dvs. web vor fi în principiu produsele Google configurate. Deci, dacă nu schimbați fontul, schimbați câteva culori și aduceți propria identitate de marcă și faceți asta, veți avea un produs care va arăta ca orice produs Google, ceea ce ar putea fi un lucru bun, deoarece dacă utilizatorii dvs. sunt obișnuiți cu produsele Google, ceea ce i-ar putea ajuta să le înțeleagă. Deci, de obicei, dacă nu aveți un designer în echipă, aveți de ales? La fel ca multe dintre lucrările diferite pe care le-am văzut, acestea vin cu teme personalizate, astfel încât cel puțin să puteți schimba culorile. Cred că puteți schimba și fonturile destul de ușor. Dar din nou, ca dacă schimbi culorile și nu ești super bun la design sau chiar accesibilitate, poate culorile pe care le vei folosi se vor ciocni, s-ar putea să aibă probleme de contrast.

Stephanie: De exemplu, iubesc portocaliul, dar este una dintre cele mai enervante culori cu care să lucrez pentru că pentru a avea un portocaliu real accesibil, de exemplu, ca buton cu text alb, aproape că arată maronie. Și dacă doriți să aveți acest portocaliu cu adevărat strălucitor, aveți nevoie de text întunecat deasupra lui pentru a-l face lizibil, dar face ca interfața dvs. să arate ca Halloween la sfârșitul zilei. Da, te văd râzând. Dar e adevărat. Așa că este întotdeauna vorba despre astfel de compromisuri și spuneți că dacă ești dezvoltator și vrei să folosești cadrul așa cum este și nu ai un designer, cred că este mai bine decât să nu ai nimic și să-l construiești de la zero și atunci este super complex de folosit. Dar lucrul este că doar pentru că ai componentele nu înseamnă că vei construi o interfață grozavă. Este ca și cărămizile Lego. Dacă ai cărămizile Lego, bine, e în regulă, dar poți face o navă spațială cu adevărat drăguță sau poți face ceva care nu se ține împreună și se va destrama pentru că nu aveai cu adevărat un plan.

Stephanie: Deci designul este mai mult decât atât. Designul este despre înțelegerea cu adevărat a ceea ce va fi pe ecran, cum va funcționa. Și cunosc niște dezvoltatori care de fapt au capacitatea de a face asta. Deci, sunt foarte buni cu liniile directoare de utilizare și înțeleg o mulțime de reguli de proiectare, de exemplu. Deci, când vine vorba de alegerea componentelor, acestea sunt foarte bune la asta. Și cunosc dezvoltatori care habar nu au ce componente să aleagă și o aleg pe prima care face treaba. Dar după un timp nu mai merge. Ca și filele, de exemplu, aveam o interfață în care unii dezvoltatori alegeau file. Cred că are sens la început când ai doar trei articole. Dar apoi au fost 12 elemente pe ecran și apoi aveți file care sunt trei linii de file și toate acestea sunt file de același nivel, și există file în file. Deci aveau componenta, arăta bine pentru că folosesc cadrul, dar nu era chiar utilizabilă.

Stephanie: Și eu am avut același lucru cu un modal windows, de exemplu. Unde ei construiesc proiectele fără designer și după un timp cred că clientul a cerut din ce în ce mai multe lucruri în acest mod. Așa că au ajuns să aibă un ecran cu un tabel și când dai clic pe adăugare un rând, deschizi un modal, iar în acest modal ai două file, iar apoi într-una dintre acele file ai chiar și un alt tabel și apoi au vrut să facă. adăugați ceva în plus, am spus că, bine, poate putem pune un modal peste un modal. Și la un moment dat, designerul ar răspunde, bine, dacă aveți atât de mult conținut în modal, nu ar trebui să fie o fereastră modală. Ar trebui să fie o pagină. Deci, chiar dacă aveți componenta, aveți nevoie de un fel de arhitect care să facă planul și să vă asigurați că toate aceste componente funcționează bine împreună.

Drew: Deci, dacă în calitate de designer, ți se cere să schimbi stilul unor componente, ai încerca doar să schimbi tot stilul? Le-ai personaliza pe toate sau există anumite zone pe care te-ai concentra?

Stephanie: Culorile cred că pentru că este primul lucru pe care îl vezi, culorile îți pot aduce identitate. Dacă aveți o identitate de marcă puternică, cel puțin să aveți culorile produsului pe butoane sau pictograme și lucruri de genul acesta, vă ajută deja să personalizați cadrul. Fonturi pentru că cred că este ușor, dacă cadrul este bine construit, de obicei schimbi întreaga familie de fonturi undeva și atunci ar trebui să se oarecum în cascadă pe restul site-ului. Deci, culorile și fonturile sunt două moduri ușoare de a personaliza rapid cadrul. Pictogramele este un alt mod frumos de a aduce personalitate, dar ar putea fi dificil pentru că, din ceea ce am văzut, majoritatea cadrului vin cu pictograme personalizate sau Font Awesome sau ca o bibliotecă deja încorporată. Deci, pentru a le înlocui, mai întâi aveți nevoie de un multe pictograme dacă doriți să le înlocuiți pe toate. Deci ar putea fi puțin complex. Am văzut, de asemenea, cadre care vă permit să alegeți ce pachet de pictograme doriți să utilizați. precum Font Awesome, Glyphicons și unele dintre celelalte. Deci, acesta este genul de lucruri pe care le puteți personaliza destul de ușor.

Stephanie: Și apoi este vorba despre aspect și simț, de exemplu antetul, de obicei aveți diferite tipuri de anteturi, subsol. Cum navighezi în astfel de lucruri. Deci, există deja o mulțime de personalizări mici pe care le puteți aduce, astfel încât să nu arate Material-UI-ish, să arate mai mult ca marca dvs. și apoi vă puteți juca cu raza de frontieră, de exemplu. Fie că vrei butoane complet rotunjite, fie că vrei butoane pătrate, fie că vrei ceva la mijloc precum umbrele. Așadar, câteva lucruri mici care sunt de obicei ușor de personalizat, deoarece majoritatea acestor cadre le au în variabile CSS. Acesta este genul de lucruri mici pe care le puteți personaliza fără prea mult efort cred, cu excepția acestor efecte de ondulare. Urăsc. O să mă lupt. Sper că până la urmă o vor schimba.

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. Do you know?

Drew: Yup.

Stephanie: It does. Bine. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.