Ja man būtu jauna digitāla produkta ideja, es vispirms meklētu vienu jautājumu, uz kuru vajag atbildi. Tādu, kura atbilde tiešām mainītu to, ko būvēsim tālāk.

Piemēram: vai cilvēks spēj atrast apstiprināto video versiju bez jautāšanas kolēģim? Tas ir pietiekami konkrēti, lai izveidotu nelielu prototipu un pavērotu, kas notiek.

Viena situācija no darba plūsmas

Iedomāsimies komandu ar trim video versijām un komentāriem vairākās sarakstēs. Pirms publicēšanas kāds mēģina saprast, kurš fails ir apstiprināts.

Mana ideja būtu vienā vietā parādīt versiju, statusu un apstiprinātāju. Pieņēmums: ar to pietiks, lai cilvēks atrastu pareizo failu pats.

Pirms taisīt ekrānus, es aprunātos ar dažiem cilvēkiem, kas šādu darbu veic. Palūgtu izstāstīt pēdējo reizi, kad viņi meklēja gala versiju. Kur skatījās? Kas nebija skaidrs? Kā beigās saprata, kuru failu ņemt? Šis ir izdomāts piemērs; īstā sarunā gribētu dzirdēt viņu konkrēto situāciju.

Tik daudz prototipa, cik vajag jautājumam

Šeit pietiktu ar vienu projektu, trim versijām, komentāriem un apstiprinājumu. Varētu iztikt ar savienotiem ekrāniem vai vienkāršu HTML lapu.

Saites un statusi, kas vajadzīgi šim uzdevumam, gan būtu jāsagatavo. Maksājumus un citas funkcijas atstātu vēlākam laikam. Šobrīd gribu saprast, vai ir nolasāms pats apstiprinājums.

Lietotājam dotu šādu uzdevumu:

Tev jāsagatavo video publicēšanai.
Projektā ir trīs versijas un vairāki komentāri.
Atrodi failu, kuru šobrīd drīkst publicēt.
Parādi, kas to apstiprinājis un kur to var pārbaudīt.
Ja informācijas nepietiek, pasaki, kā pietrūkst.

Es sākumā neskaidrotu, kur ko spiest. Ja cilvēks apstājas, pierakstītu vietu un jautājumu. Ja palīdzēju, atzīmētu arī to — tad vēlāk redzu, kas izdevās patstāvīgi.

Par šādu uzdevumu veidošanu un novērošanu vairāk ir GOV.UK lietojamības pārbaudes aprakstā.

Ko no šī varētu uzzināt?

Pirmajam mēģinājumam varētu pieaicināt piecus cilvēkus, kuri šo darbu pazīst. Ar tik mazu grupu meklētu konkrētas neskaidrības, nevis secinātu, ko domā visa auditorija.

Pierakstītu, kuru versiju katrs izvēlas, kā pamato izvēli un vai vajag palīdzību. Vēl gribētu zināt, kā viņš šo pašu darbu dara pašlaik.

Šim testam varam vienoties: vismaz četriem no pieciem jāatrod pareizais fails bez palīdzības. Tas būtu mūsu lēmuma kritērijs. Arī vienu neapstiprināta faila izvēli es skatītos uzmanīgi — publicēšanā tā var būt būtiska kļūda.

Ja cilvēki jauc versiju ar statusu, pārtaisām attēlojumu un mēģinām vēlreiz. Ja viss ir saprotams, bet šāda problēma viņu darbā gandrīz nerodas, jāpadomā par pašu vajadzību.

Ar veiksmīgu uzdevumu vēl nepietiek, lai zinātu, vai komanda mainīs paradumus vai maksās par produktu. Nākamais solis varētu būt neliels izmēģinājums īstā projektā: vai cilvēki pie tā atgriežas arī tad, kad neesam blakus?

Man patiktu šo posmu noslēgt ar vienu lapu: ko gribējām pārbaudīt, ko ieraudzījām un ko darām tālāk. Tas palīdzētu nākamo versiju būvēt ar skaidrāku domu.