Moarte pentru Wireframe. Direct la înaltă fidelitate!

Designul UX este o disciplină fascinantă. Pentru a o face bine, practicienii trebuie să fie bine versați într-o mare varietate de subiecte și abilități. Pentru a practica metodologia de proiectare centrată pe utilizator și pentru a crea soluții inovatoare și ușor de utilizat pentru provocările de zi cu zi de proiectare a produselor, meșteșugul și înțelegerea unui practician UX implică totul, de la desenul de bază la proiectarea narativă/călătorie până la psihologia cognitivă.

Există o mare varietate de instrumente utilizate, artefacte generate și descoperiri descoperite în procesul de proiectare UX/UI și sunt capturate într-un sortiment de documente sau chiar într-un prototip. Cele mai recunoscute artefacte ale noastre sunt vechiul wireframe.

Wireframes - de obicei schelete monocrome ale modelelor create pentru o evaluare rapidă - sunt grozave. Ele ne permit să traducem contribuțiile de la multe părți neafiliate într-un singur document pe care toată lumea îl poate examina. Multe funcții diferite evaluează wireframes; analiști de afaceri, manageri de proiect, directori de marketing, tot felul de designeri și dezvoltatori, diverși alți furnizori și furnizori de servicii - chiar și publicul țintă atunci când testează produsul. Wireframe permite tuturor să vadă cum vor fi abordate nevoile lor individuale și oferă întregii echipe șansa de a rezolva toate problemele înainte de a avea loc orice ridicare grea.

Există argumente pro și contra, dar în anumite cazuri, este logic să săriți peste faza de wireframing. S-ar putea economisi mult timp prin gestionarea UX și a designului vizual la nivel de înaltă fidelitate imediat după descoperire sau în timpul pregătirii pentru prototip. Acest lucru le-ar oferi celorlalți oportunitatea de a evalua atât funcționalitatea, cât și aspectul și senzația produsului în același timp, de la participanții la testarea utilizatorilor până la clienți și colegi.

Să aflăm de ce wireframe pot fi uneori problematice, atunci când omiterea lor are sens și cum să adaptăm un proces fără wireframe la un flux de lucru.

Problema cu Wireframes

Fie într-un mediu în cascadă sau agil, procesul tipic de proiectare implică faze de cercetare, definire, idee, prototipare, testare și implementare, precum și multe puncte de contact pentru revizuire cu părțile interesate pe parcurs.

Să ne uităm la procesul de proiectare pentru exemple în care designul wireframe poate fi un blocaj:

Motivul 1: Clienții nu înțeleg la ce se uită

Procesul de proiectare începe de obicei cu un fel de cercetare a problemei. Cercetarea documentară, interviurile cu părțile interesate și interviurile cu utilizatorii sunt doar câteva dintre activitățile care pot fi întreprinse pentru a obține o înțelegere mai profundă. După cercetare, echipa de proiectare începe să evalueze o serie de idei și concepte pentru a găsi cea mai bună soluție.

Când un concept este mai concretizat, echipa de proiectare va împărtăși adesea o serie de wireframes cu clientul în timpul unei sesiuni de revizuire.

Problema este că wireframes-urile sunt foarte abstracte.

Ei descriu ceva care seamănă cu acel lucru, dar nu lucrul real care va fi construit. În această etapă, wireframes-urile ar conține imagini de substituent și tot felul de TK-uri (care urmează), FPO-uri (doar pentru plasare) și TBD-uri (de decis), cum ar fi exemplul de mai jos.

Probabil că există detalii despre funcționalitate, cerințele de afaceri și gestionarea erorilor care vor fi indicate într-o listă imensă de adnotări. De obicei, nu este niciodată suficient timp pentru a le parcurge în detaliu, așa că clientul va fi lăsat să le citească singur.

În timpul revizuirii wireframe, le rugăm clienților noștri să se concentreze pe conceptul care este descris și să evalueze dacă pare să rezolve sau nu problemele de afaceri și ale utilizatorilor. Cu toate acestea, încă primim întrebări despre lucruri care, pentru noi, nu par să aibă legătură. Clienții doresc să știe dacă wireframe este „copia finală” sau dacă ar putea vedea exemple de fotografii care urmează să fie afișate în imaginea eroului – sau o altă întrebare despre ceva care va fi tratat în designul vizual, prototipul ui sau dezvoltarea.

Wireframes-urile ar putea fi prea abstracte pentru ca clienții și chiar părțile interesate interne să le evalueze în mod eficient. Wireframes-urile le spun oamenilor cum va fi un design atunci când este gata, dar ei trebuie totuși să muncească mult din punct de vedere mental pentru a-l face împreună în capul lor. Clienții noștri pot fi sau nu gânditori vizuali și poate fi prea mult să ne așteptăm să se uite la un plan și să-și imagineze un produs sau un site de succes.

Au fost câțiva clienți care au solicitat în mod special să revizuiască design-urile vizuale adnotate, deoarece le este mult mai ușor să conecteze punctele, să aibă o discuție atentă și să ofere feedback bine gândit.

Motivul 2: Nu sunt întotdeauna potrivite pentru testarea utilizatorilor

Sperăm că unele teste de utilizator au fost programate în procesul de proiectare, deoarece este o modalitate bună de a testa totul, de la fezabilitatea unui întreg concept până la nivelul de detaliu de afișat într-o tranzacție.

O modalitate tipică de a testa astfel de lucruri este prin prototipare.

Wireframes-urile pot – și funcționează – pentru prototipare. Echipa de proiectare se limitează doar la testarea fluxului și funcționalității și, deoarece îi lipsește un strat de design vizual, stilurile vizuale care afectează comportamentul utilizatorului pot fi ușor ignorate.

Este asta înțelept? Designul UX, vizual și de copiere se influențează reciproc. Este greu să le despărțiți și să le izolați într-un mediu de testare. Similar unui studiu științific, rezultatele unei funcții testate izolat nu pot controla sau prezice cum se va comporta în sălbăticie.

Uneori, este mai eficient să testați toate aceste lucruri împreună în mod holistic.

Caz concret: un produs sau serviciu multilingv. Limbile pot avea diferite gramatici, alfabete și lățimi de caractere care ar putea afecta designul general.

Mai mult, deoarece conținutul copierii afectează UX-ul, traducerea în sine poate afecta UX-ul.

De exemplu, am avut o misiune în care ni s-a cerut să testăm câteva arhitecturi informaționale diferite din cauza modului în care diferitele concepte trebuiau explicate în limba locală. Nu am fi descoperit impactul asupra redactării și traducerii fără a testa copia efectivă în interfața de utilizare.

Am descoperit că sunt necesare mai multe cuvinte pentru a descrie concepte similare în limba locală și că va trebui să modificăm dimensiunile și formele butoanelor la nivel global pentru a se potrivi cuvintelor detaliate necesare pentru limba respectivă. Fără să ne concentrăm asupra problemelor de text în timpul testării componentelor vizuale reale în interfața de utilizare, nu am fi descoperit că butoanele trebuiau să ocupe întreaga lățime a ecranului mobil, ceea ce a afectat designul nostru UX în continuare.

Element cheie: este logic să pregătiți interfețe de utilizare de înaltă fidelitate chiar de la început, în special pentru un proiect multilingv.

Motivul 3: Ei fac viața un iad pentru dezvoltatori și QA

Ceea ce se întâmplă inevitabil în timpul fazei de design vizual este că totul se mișcă. Imaginile stivuite devin plăci. Textul centrat devine aliniat la stânga. Pictogramele declanșatorului acordeonului erau + și - , dar acum sunt câteva chevrone.

Aceasta este o parte normală a procesului de proiectare vizuală. Ceea ce este, de asemenea, normal este că orice modificări făcute în designul vizual nu vor fi reflectate în wireframes, deoarece wireframes-urile au fost „dezactivate”.

Când toate imaginile sunt aprobate, este timpul să predați totul dezvoltatorilor. În cele mai multe cazuri, vor primi un set de wireframes detaliate, adnotate și un set de modele vizuale frumoase, împreună cu un ghid de stil. Acum depinde de ei să facă referințe încrucișate între aceste două documente și să le aducă la viață.

Acesta este un domeniu în care procesul de proiectare poate eșua cu adevărat. Oferim dezvoltatorilor prea multe documente la care să se refere și le lăsăm la latitudinea lor să determine care informații au prioritate. Acest lucru crește timpul necesar pentru apelurile de asistență și QA, influențând în mod natural timpul necesar pentru a aduce pe piață un produs sau o actualizare.

De ce să nu oferi dezvoltatorilor un document precis care să includă totul? Majoritatea clienților ar aprecia, de asemenea, o copie pe care să o folosească ca referință completă pentru lucrare.

Soluția: Omiteți Wireframes

În mod clar, există momente în care este necesară o fază de cadru complet și există momente când nu este. Există chiar și momente în care trecerea directă la înaltă fidelitate depășește cu totul faza wireframe.

S-ar putea să vă gândiți să săriți peste faza cadru fir dacă oricare dintre acestea este adevărată:

Există un material de referință solid.

Aruncă o privire la lucrările existente. S-ar putea să fie deja disponibile referințe detaliate ale UI. Dacă faceți actualizări la un site web existent sau adăugați o funcție nouă la o aplicație existentă, priviți site-ul web și aplicația actuale pentru a găsi modele și stiluri de reutilizat.

Ar fi chiar mai bine dacă ați avea acces la fișierele sursă pentru lucrarea existentă. Unele caracteristici și elemente s-ar fi putut pierde în traducere, ca să spunem așa, în timpul procesului de dezvoltare și ați putea să vă referiți la fișierul sursă pentru a vedea cum ar fi trebuit să fie făcută această caracteristică.

În plus față de (sau în absența) unui produs sau site existent, verificați pentru a vedea dacă există un ghid de stil sau o bibliotecă de modele. Este posibil ca clientul să fi plătit deja pentru unele lucrări de branding și design vizual, iar aceste resurse ar putea fi reutilizate pentru proiectul dvs.

Utilizați cât mai multe stiluri și modele pe care le puteți găsi, astfel încât rezultatele dvs. de înaltă fidelitate să fie cât mai precise posibil.

Ați programat o mulțime de prototipuri și teste iterative pe parcurs.

Economisiți efort în săptămânile de prototipare și testare. Dacă configurați documentul cu atenție prima dată și utilizați inteligent stilurile, modelele și simbolurile repetate, puteți face cu ușurință actualizări incrementale de înaltă fidelitate și le puteți publica direct în fluxul dvs. de lucru de prototipare. Nu este nevoie de wireframing.

Ca un mare plus, puteți ucide două păsări dintr-o singură lovitură. Puteți obține feedback vizual și UI alături de feedback-ul dvs. UX și puteți face toate aceste modificări dintr-o singură mișcare.

Participanții tăi la test sunt foarte literali.

Așa cum clienții și colegii tăi pot necesita uneori exemple concrete, la fel și publicul țintă al proiectului tău.

Un concert recent m-a făcut să creez ecrane financiare pentru un public țintă cu nivel scăzut de alfabetizare. Înțelegerea cititului nu a fost singura problemă – conceptele abstracte erau adesea foarte greu de abordat. Acest public țintă trebuia de obicei să discute concepte financiare folosind exemple concrete; în caz contrar, nu au putut să urmărească cu adevărat conversația.

Pentru a înțelege conceptele financiare, participanții la test din această audiență trebuiau să simtă că realizează tranzacții. Și pentru a înțelege cum funcționează produsul, trebuia să arate și să se simtă ca o aplicație reală.

Uită de wireframes pentru un public ca acesta! Veți sfârși prin a petrece mult timp explicând ceea ce sunt, iar publicul dvs. nu se va concentra asupra sarcinilor și nici asupra felului în care se simte despre ele, deoarece nu se pot relaționa cu folosirea a ceva atât de necunoscut în viața lor.

Clientul dumneavoastră are timp și/sau buget limitat.

Este rar să ai timpul, resursele și bugetul în favoarea ta. Vă puteți găsi adesea încercând să reduceți domeniul de aplicare și prețul sau încercând să vedeți unde puteți scăpa și economisi și încă oferiți un serviciu excelent clientului dvs.

Dacă aveți un client care nu își poate permite (sau care nu este probabil să cumpere) un proces UX complet, vă pot sugera reducerea timpului de wireframing? Creați unele în interior dacă aveți nevoie, dar mențineți proiectul în mișcare pentru clientul dvs. Testați modele reale, tangibile și puneți-vă clientul să reacționeze la munca reală.

Cum să omorâți faza Wireframe

Această parte este mai degrabă subiectivă, deoarece va depinde de fluxul de lucru personal și de nevoile specifice ale clientului.

Acestea fiind spuse, acesta este un „șablon” de proces pe care l-ați putea încerca inițial să îl adaptați la fluxul dvs. de lucru și apoi să îl modificați pe măsură ce vă exersați mai mult lucrul în acest fel.

Pasul 1: Începeți cu procesul obișnuit de cercetare și descoperire.

Interviuri, observații pe teren, cercetări de birou, analize competitive - orice lucru pe care îl faceți în mod normal (sau ați programat să faceți), finalizați această fază așa cum ați proceda în mod normal.

Pasul 2: Schițați puțin pe parcurs.

În timp ce desfășurați cercetări, probabil obțineți câteva idei pentru machete și modele utile, fluxuri captivante și altele asemenea. Înregistrați-le oricum le faceți de obicei. Îmi place să fac schițe în miniatură în caiet, cu note scrise lângă ele. S-ar putea să preferați să schițați pe o tablă albă sau să faceți capturi de ecran cu modele interesante de UI. Orice te ajută să-ți amintești ideile bune, fă-o.

Pasul 3: Pregătiți-vă documentul de înaltă fidelitate

Deschideți instrumentul de design dorit și configurați-vă documentul în mod corespunzător. Alegeți câteva dimensiuni de planșe și începeți să creați forme, grupuri și simboluri repetabile.

Fă-ți timp pentru a salva paleta de culori a mărcii ca mostre individuale, pentru a crea și a organiza stiluri de tipare și pentru a crea umbre și filtre standard pe care le poți aplica în toate formele, după cum este necesar.

Petrece mult timp pentru ca simbolurile tale să fie corecte. Este posibil să aveți un buton care, în funcție de starea sa, ar putea avea patru culori diferite. Folosiți suprascrieri de simboluri, dacă puteți, astfel încât să puteți aplica cu ușurință diferite culori și etichete de text după cum este necesar.

Dacă sunt folosite pictograme personalizate, salvați-le ca simboluri individuale pe o panou de desen pătrat (sau orice formă este potrivită). În acest fel, vă va fi ușor să le scalați în sus și în jos, menținând totuși distanța și alinierea corespunzătoare.

Pasul 4: Începeți să proiectați.

Prima ta rundă poate fi puțin dificilă pe măsură ce te obișnuiești să lucrezi în acest mod și să vezi unde ține ghidul tău de stil (și unde nu). Pe lângă crearea de soluții pentru modele care nu au deja un stil definit, așteptați-vă să faceți destul de puține ajustări pentru a obține toate stilurile corecte.

Pe tot parcursul acestui proces, mergeți cu o „direcție de copiere” bună sau cu o copie reală, dacă o aveți. Nu creați titluri care spun „Titlul paginii este aici”. Oferă spectatorului o idee despre ce s- ar întâmpla aici dacă ar fi real.

De asemenea, nu creați o listă de nume pe care toate spun John Smith cu numărul de telefon 555-1212. Utilizați un generator de liste aleatorii sau un plug-in pentru a crea nume și numere diferite sau creați orice set de date pe care trebuie să îl afișați. Acest lucru poate părea exagerat, dar vă permite să rezolvați probleme cu aspectul și lățimea caracterelor și vă ajută spectatorul să înțeleagă că aceste cinci intrări sunt toate diferite.

Pasul 5: Aflați când să opriți proiectarea.

Există câteva detalii de care nu ar trebui să ai grijă în acest moment, deoarece într-adevăr vor dura prea mult. Poate că este alegerea imaginii exacte pentru a intra într-un erou sau proiectarea unei pictograme personalizată pentru a indica starea de descărcare. Acestea sunt câteva cazuri în care ați putea alege să utilizați o imagine sau o pictogramă substituent și să testați imaginile reale sau iconografia la o dată ulterioară.

Va trebui să apelați la ceea ce este potrivit aici, deoarece va depinde de obiectivele proiectului, precum și de cât de departe sunteți cu el.

Rețineți că poate depinde de ceea ce au nevoie participanții la testul utilizatorului pentru a evalua corect munca. Pentru publicul țintă cu nivel scăzut de alfabetizare pe care l-am menționat mai sus, nimic nu a fost prea detaliat. Pentru fiecare participant, am realizat o variantă a prototipului cu numele lor real și numărul de telefon folosite pe tot parcursul, astfel încât aplicația să se simtă cu adevărat ca și cum ar fi „a lor”. Cu cât trebuiau să își asume mai puțin, cu atât le era mai ușor să urmărească și cu atât rezultatele mele erau mai bune.

Pasul 6: Bucurați-vă de feedback de înaltă calitate și de rezultate ale testelor.

Publicați-vă modelele direct în instrumentul de prototipare ales și aduceți-le pe teren pentru testare. Acum puteți primi feedback despre mai mult decât doar funcționalitate. Puteți descoperi potențiale probleme vizuale, cum ar fi probleme cu contrastul culorilor sau lizibilitatea și puteți descoperi probleme cu direcția copierii sau traducerea. Puteți, de asemenea, să dezvăluiți sentimentele pozitive sau negative pe care utilizatorii le pot avea despre aspectul și senzația sau despre branding.

Acestea sunt toate lucrurile despre care probabil aveai să primești feedback oricum când ai ajuns la faza de design vizual. De ce să nu primești toate aceste feedback-uri acum? O parte din feedback-ul asupra imaginilor ar putea afecta direct UX-ul și invers, așa că este bine să rezolvi toate acestea în același timp, dacă poți.

Încheierea

Fără îndoială, există multe cazuri în care o fază wireframe completă este necesară pentru succesul proiectului. Un design complex, cum ar fi o aplicație web receptivă, necesită o concentrare separată și dedicată pe wireframes. Ar economisi timp și bani pentru a rezolva toate cerințele de afaceri, cazurile marginale și gestionarea erorilor în stadiul de wireframe, decât ar fi dacă un strat vizual complet ar fi fost deja conceput și aplicat.

Cu toate acestea, în cazurile potrivite, trecerea direct la înaltă fidelitate vă poate îmbunătăți procesul:

• Îmbunătățiți feedbackul părților interesate . Clienții, dezvoltatorii, alți designeri și participanții la testare din publicul țintă pot vedea exact ce vor obține, permițându-le să ofere feedback de calitate superioară.
• Accelerează-ți fluxul de lucru de prototipare . Nu numai că design-urile dvs. vor fi gata de testat imediat, dar puteți obține feedback cu privire la o serie de lucruri simultan: UX, copie și imagini.
• Livrați un singur document clienților și dezvoltatorilor . Eliminați necesitatea de a face referințe încrucișate și de a verifica o varietate de documente pentru a înțelege cum ar trebui să funcționeze un buton. Aceasta este, de asemenea, o modalitate excelentă pentru clientul dvs. de a discuta despre lucru cu părțile interesate interne pentru a vă obține și mai mult feedback.
• Economisiți timp și bani . Și asta este aproape întotdeauna un lucru bun!

Dați o șansă acestei abordări data viitoare când aveți un proiect în care aveți unele materiale de design existente la care să vă referiți sau unde va face o mare diferență pentru publicul dvs. dacă lucrarea este în fidelitate scăzută sau înaltă.

• • •

Citiri suplimentare pe Blogul Toptal Design:

• eCommerce UX – O privire de ansamblu asupra celor mai bune practici (cu infografic)
• Importanța designului centrat pe om în proiectarea produsului
• Cele mai bune portofolii de designeri UX – Studii de caz și exemple inspiratoare
• Principii euristice pentru interfețele mobile
• Design anticipator: Cum să creați experiențe magice pentru utilizator