UX dizaino procesas: nuo poreikių išsiaiškinimo iki perdavimo programuotojams

Svetainė gali atrodyti užbaigta, nors svarbūs klausimai dar liko neatsakyti. Kas nutinka, jei žmogus negali užpildyti formos? Kokios informacijos komandai reikia ją gavus? Ir ar programuotojui aišku, kaip dizainas turi veikti už pristatyme parodyto ekrano ribų?

UX dizaino procesas padeda į šiuos klausimus atsakyti. Pradedama nuo problemos supratimo, tada kuriama struktūra, nagrinėjamos sąveikos, tikrinamos idėjos ir paruošiamos įgyvendinimui reikalingos detalės. Klientui naudinga suprasti, ką turi išspręsti kiekvienas etapas ir kur jo indėlis svarbus.

Tikras projektas: kai svetainės atnaujinimas peržengia jos ribas

Goway į „Flair“ kreipėsi jau turėdami naują pavadinimą ir vizualinį identitetą. Svetainė turėjo atspindėti prekės ženklą ir padėti lengviau rasti informaciją apie automobilių finansavimą. Darbai taip pat išsiplėtė į paraiškų infrastruktūrą, apimdami privačių klientų, verslo ir partnerių eigas.

Tai suteikia šiam gidui konkretų kontekstą: klientui reikia aiškaus būdo susipažinti su galimybėmis ir pateikti paraišką, o ją gaunančiai komandai — naudingos informacijos. Svarbios abi pusės. Toliau paaiškinama, kokių sprendimų ir darbo rezultatų reikia sprendžiant tokio pobūdžio užduotį. Tai nėra visų „Goway“ projekto dirbtuvių ar testų aprašymas.

UX dizaino proceso etapai trumpai

Nėra vieno visiems projektams privalomo rezultatų rinkinio. Nedideliam svetainės patobulinimui ir sudėtingai skaitmeninei paslaugai reikia skirtingo detalumo. Šie etapai padeda praktiškai aptarti darbus su dizaino partneriu.

„Design Council“ metodikoje dizainas taip pat suprantamas kaip iteratyvus procesas. Nauja informacija gali paskatinti grįžti prie ankstesnio sprendimo. Toliau pateikti etapai yra darbo struktūra, o ne vienakryptė patvirtinimų seka.

Poreikių išsiaiškinimas: supraskite užduotį prieš kurdami ekraną

Pradedama nuo to, ką žmonės nori atlikti ir ką verslas turi padėti įgyvendinti. Naudingos gali būti esamos analitikos įžvalgos, klientų aptarnavimo klausimai, pokalbiai su suinteresuotais žmonėmis, interviu su naudotojais ir dabartinės patirties peržiūra. Metodus rinkitės pagal neatsakytus projekto klausimus; ne kiekviena tyrimo veikla privaloma.

Nagrinėjant paraiškos eigą verta klausti, ką klientui reikia žinoti prieš pradedant, kokią informaciją jis realiai gali pateikti ir ko reikia ją gaunančiai komandai, kad galėtų veikti. Čia svarbūs ir techniniai apribojimai. Jei eiga remiasi neprieinamais duomenimis, reikės kitokio sprendimo.

Ką peržiūrite: aiškią problemos, turimų įrodymų, prielaidų, apribojimų ir dar neišsiaiškintų klausimų santrauką.

Jūsų vaidmuo: paaiškinti, kaip veikia verslas, pasidalyti turima informacija ir padėti pasiekti tinkamus naudotojus ar kolegas. Aiškiai įvardykite norimą rezultatą. „Padėti lengviau užpildyti paraišką“ yra naudingesnis pradinis tikslas nei „padaryti formą modernią“.

Problemos apibrėžimas ir struktūra: sutarkite, kas svarbiausia

Toliau tai, ką komanda sužinojo, paverčiama prioritetais. Kurią auditoriją ir užduotį projektas turi aptarnauti pirmiausia? Kas įeina į pirmąją versiją? Ką dar reikia ištirti?

Svetainės medis susistemina puslapius ir turinį. Naudotojo eiga parodo žingsnius, kuriais žmogus atlieka užduotį, įskaitant sprendimus ir alternatyvius kelius. Tai skirtingi klausimai, todėl vien navigacijos meniu nepakanka paraiškos eigai aprašyti.

„Goway“ projekte buvo atskiros paraiškų eigos privatiems klientams, verslui ir partneriams. Tai parodo, kodėl auditorijų skirtumus svarbu numatyti struktūroje, o ne palikti vien galutiniams formos tekstams.

Ką peržiūrite: siūlomą svetainės medį, svarbiausias eigas ir sutartos darbų apimties ribas.

Jūsų vaidmuo: patvirtinti paslaugų pavadinimus, verslo taisykles ir tai, kam kokios informacijos reikia. Paskirkite žmogų, galintį išspręsti prieštaringas pastabas. Patvirtinti struktūrą reiškia sutarti, kaip patirtis veiks, o ne patvirtinti spalvas ar tipografiją.

Struktūriniai maketai ir prototipai: paverskite eigą apčiuopiama

Struktūriniai maketai parodo, kas turi būti ekrane ir kaip išdėstomi informacijos prioritetai. Jie gali būti sąmoningai paprasti, kad komanda aptartų turinį ir seką, neužstrigdama ties vizualinėmis detalėmis.

Prototipas sujungia ekranus ar būsenas, kad būtų galima išbandyti sąveiką. Jis gali apimti tik tą patirties dalį, kurią reikia patikrinti. Tai nebūtinai veikiantis produktas, todėl peržiūrintiems žmonėms turi būti aišku, kuris veikimas tik imituojamas.

Paraiškos eigoje šiame etape verta paklausti, kas nutinka neužpildžius lauko, norint grįžti atgal ar nepavykus pateikti duomenų. Žemiau esantis pavyzdys iliustruoja šiuos klausimus; tai nėra „Goway“ formos atkūrimas.

Ką peržiūrite: maketus su tikrovišku turiniu ir, kai naudinga, svarbios eigos prototipą.

Jūsų vaidmuo: patikrinti, ar seka atitinka tikrąją paslaugą ir ar turinys tikslus. Atsakomybę už tekstus paskirkite anksti. Galutinės formuluotės gali atskleisti reikalavimus, kuriuos laikini tekstai paslepia.

Testavimas ir tobulinimas: stebėkite, ką žmonės daro

Pristatymas gali patvirtinti, kad suinteresuoti žmonės supranta pasiūlymą. Naudojimo patogumo testavimas atsako į kitą klausimą: ar tiksliniai naudotojai su juo gali atlikti tikrovišką užduotį?

Sesijoje dalyviai atlieka užduotis, o tyrėjas stebi, kur jie dvejoja, neteisingai supranta ar užstringa. „Nielsen Norman Group“ rekomenduoja tikroviškus scenarijus, kurie nepasako, kaip naudotis sąsaja. Tikrinant paraiškos prototipą galima paprašyti pradėti užklausą pagal žmogaus situaciją, užuot nurodžius, kurį mygtuką spausti.

Įžvalgos turi virsti sprendimais: ką keisti, kodėl tai svarbu ir ką reikėtų patikrinti dar kartą. Prototipas gali atskleisti, kad reikia keisti struktūrą, o ne vien mygtuko tekstą. Testavimo išsamumą sutarkite apibrėždami darbų apimtį; vidinė peržiūra ir testai su tiksliniais naudotojais suteikia skirtingą grįžtamąjį ryšį.

Ką peržiūrite: pagal svarbą išdėstytas problemas, jas pagrindžiančius pastebėjimus, pataisas ir likusius neaiškumus.

Jūsų vaidmuo: prireikus padėti surasti tinkamus dalyvius, stebėti nenukreipiant jų atsakymų ir numatyti vietos įrodymais pagrįstiems pakeitimams.

UI ir sąveikos detalės: kurkite nuoseklų dizainą

Vizualinis dizainas sujungia prekės ženklą, hierarchiją ir sąveikos principus. Pakartotinai naudojami komponentai padeda išlaikyti nuoseklias formas, mygtukus, navigaciją ir grįžtamąjį ryšį. Skirtingiems ekranams pritaikyti maketai paaiškina, kaip patirtis keičiasi priklausomai nuo ekrano.

Svarbios detalės: fokuso būsenos, laukų tikrinimo pranešimai, įkėlimo indikatoriai, tuščios būsenos ir patvirtinimo tekstai daro įtaką naudojimo patogumui. Viešai aprašytas „Goway“ rezultatas apėmė esamo identiteto pritaikymą svetainei kompiuteriuose ir mobiliuosiuose įrenginiuose. Tai primena, kad prekės ženklo išraiška turi veikti žmonių naudojamoje patirtyje.

Prieinamumą svarbu vertinti viso darbo metu. W3C rekomenduoja pradėti anksti ir tęsti per visą kūrimo procesą; vien vizualinis maketas neparodo, kaip įgyvendinta svetainė veiks su pagalbinėmis technologijomis.

Ką peržiūrite: pagrindinius ekranus, pakartotinai naudojamus komponentus, reikalingas būsenas, prisitaikymą prie ekranų ir įgyvendinimui paruoštą turinį.

Jūsų vaidmuo: patvirtinti prekės ženklo kryptį ir turinį, pastabas siejant su naudotojų užduotimis. Programuotojai jau turėtų kartu su dizaineriais vertinti įgyvendinamumą ir veikimą.

Perdavimas programuotojams: paruoškite sprendimus įgyvendinimui

Perdavimo etape sutartas dizainas tampa pakankamai aiškus, kad jį būtų galima įgyvendinti. Tvarkingas failas padeda, tačiau programuotojams taip pat reikia suprasti, kas vyksta tarp ekranų ir ne tokiose sklandžiose situacijose.

Tokioje eigoje, kokia aprašyta „Goway“ projekte, matoma forma susijusi su tuo, kaip paraiškos informacija gaunama ir tvarkoma. Todėl bendra perdavimo rekomendacija — kartu su sąsaja išsiaiškinti duomenų reikalavimus ir sistemos atsakus. Nebūtina visko dokumentuoti viename įrankyje; svarbu, kad būtų lengva rasti kiekvieno sprendimo šaltinį.

Naudingas perdavimas gali apimti:

• Sutartas eigas ir ekranus su aiškiai pažymėta būsena bei versija.
• Komponentus, vizualinius stilius ir pakartotinai naudojamas dizaino taisykles.
• Prisitaikymą prie skirtingų ekranų ir svarbias sąveikos būsenas.
• Patvirtintus tekstus, failus ir eksporto reikalavimus.
• Pastabas apie duomenų tikrinimą, prieinamumą ir aktualų sistemos veikimą.
• Priėmimo kriterijus, atvirus klausimus ir už sprendimus atsakingus žmones.

Medžiagą aptarkite kartu. Jei programavimo metu kas nors keičiasi, atnaujinkite sutartą dokumentaciją ir praneškite apie pakeitimą. Į apimtį įtraukite suprogramuoto rezultato dizaino peržiūrą, kad komanda galėtų patikrinti įgyvendintą patirtį, o ne vien pradinį dizainą.

Nuo ko priklauso UX projekto grafikas?

Naudingas UX projekto grafikas parodo ne tik dizaino darbus, bet ir jų priklausomybes. Galimybė pasiekti naudotojus, auditorijų bei eigų skaičius, techninis vertinimas, turinio pasirengimas ir sprendimus priimančių žmonių užimtumas gali keisti planą.

Paprašykite numatyti peržiūros taškus ir paaiškinkite, kas kiekviename iš jų gali priimti sprendimus. Dalis darbų gali vykti kartu: programuotojai gali vertinti siūlomą sąveiką, kol dizaineriai nagrinėja išdėstymus, o turinys gali būti tikslinamas kartu su struktūriniais maketais. Kiti darbai priklauso nuo ankstesnio sprendimo. Detalius dar besikeičiančios eigos ekranus tikriausiai teks taisyti.

Prieš pradėdami sutarkite, kas pateikia turimą informaciją, kas atsako už turinį, kas sujungia pastabas ir kas patvirtina apimtį. Taip pat aptarkite, kaip vertinsite naujus reikalavimus. Grafikas naudingesnis, kai abi pusės mato, kuo turi prisidėti, kad darbas judėtų pirmyn.

Procesas, padedantis aiškiau priimti kitą sprendimą

Naudotojo patirties dizaino procesas kiekvienam etapui suteikia paskirtį: suprasti problemą, sutarti dėl struktūros, išnagrinėti sąveiką, ją patikrinti ir pakankamai aiškiai apibrėžti sprendimus įgyvendinimui.

„Goway“ parodo, kaip svetainės užduotis gali apimti ir už ekrano veikiančią paslaugą. Būsimam klientui praktinė mintis — vertinti visą užduotį ir joje dalyvaujančius žmones, ne vien dizaino pristatymo puslapius.

Turite svetainės ar produkto eigą, kurią reikėtų permąstyti? Papasakokite, ką žmonės nori atlikti ir kur kyla sunkumų. Nuo to galime pradėti.