Kā savākt kļūdu pieteikumus, ko izstrādātājs saprot

Labs kļūdu pieteikums nav garš — tam ir konteksts. Kas tieši izstrādātājam jāzina, kāpēc e-pasta sarakste to nekad nesavāc un ko no tā var savākt automātiski.

Katrā aģentūrā ir viena un tā pati vēstule. Tēmā rakstīts „Problēma“, tekstā — „Lapa nestrādā, lūdzu, salabojiet“. Pielikumā ekrānuzņēmums, kurā redzams tikai pārlūka logs bez adreses joslas. Izstrādātājs atbild ar trim jautājumiem, klients atbild uz vienu no tiem, un pēc trim dienām izrādās, ka runa bija par pavisam citu lapu citā pārlūkā.

Problēma nav klienta slinkums. Problēma ir tā, ka mēs prasām cilvēkam uzrakstīt informāciju, kuru viņš neredz un kuras esamību pat nenojauš. Neviens klients nezina, ka konsolē ir sarkans uzraksts. Tāpēc labs kļūdu ziņojums nav tas, kurā klients ir vairāk pacenties, — tas ir tāds, kurā pareizās lietas savāktas bez viņa līdzdalības.

Kļūdas ziņojuma anatomija

Neatkarīgi no rīka, izstrādātājam vajag atbildes uz sešiem jautājumiem. Ja trūkst kaut viena, sākas sarakste.

• Ko tu darīji? Konkrēti soļi, ne apraksts. „Atvēru grozu, nospiedu Apmaksāt, izvēlējos Swedbank“ ir soļi. „Mēģināju nopirkt“ nav.
• Ko tu sagaidīji? Tas izklausās lieki, bet tieši šeit atklājas puse „kļūdu“, kas patiesībā ir nesaprašanās par to, kā funkcija ir domāta.
• Kas notika? Kļūdas paziņojuma teksts burtiski, nevis pārstāstīts. „Radās kļūda“ un „Payment declined“ ir divi dažādi uzdevumi.
• Kur? Precīza lapas adrese. Nevis „veikalā“, bet visa adrese ar parametriem — filtrs vai valodas prefikss adresē mēdz būt tieši tā detaļa, kas kļūdu izraisa.
• Ar ko? Pārlūks un tā versija, operētājsistēma, ekrāna platums. Puse dizaina kļūdu eksistē tikai vienā platuma diapazonā vai vienā pārlūkā.
• Vai atkārtojas? Vienreiz vai katru reizi. Vienreizēja kļūda un stabili atkārtojama kļūda ir divi dažādi pieteikumi ar dažādu prioritāti.

Papildus tam ir konteksts, ko klients nevar uzrakstīt, jo neredz: pārlūka konsoles izvade, neizdevušies tīkla pieprasījumi, sesijas valoda, laika zona. Tas ir tieši tas slānis, kurā parasti atrodas atbilde.

Kāpēc e-pasts šo nekad nesavāks

E-pasta sarakste ir sinhrons process, kas izliekas par asinhronu. Katrs precizējošais jautājums maksā vienu dienu, jo klients atbild tad, kad viņam ir laiks. Trīs jautājumi — nedēļa. Turklāt e-pasts nesaglabā struktūru: pēc pusgada neviens neatradīs, kurā vēstulē bija tā versija, kas darbojās.

Tāpat nedarbojas arī „uzrakstiet detalizētu ziņojumu“ instrukcija klienta rokasgrāmatā. Cilvēks, kurš tikko atrada kļūdu, ir neapmierināts un vēlas to pieteikt trīsdesmit sekundēs. Ja pieteikšana prasa vairāk, viņš vai nu neko neziņos, vai uzrakstīs vienu teikumu. Pilns konteksts droši nonāk pie tevis tad, ja to savāc automātiski brīdī, kad cilvēks nospiež pogu.

Ko var savākt automātiski

Šeit godīgi par to, ko dara mūsu logrīks — un ko tas nedara. Kad apmeklētājs nospiež atsauksmju pogu, kopā ar aprakstu tiek nosūtīts:

• Lapas adrese tieši tāda, kāda bija adreses joslā, ieskaitot parametrus.
• Ekrānuzņēmums, kuru pirms nosūtīšanas var apzīmēt — apvilkt problēmvietu, aizmiglot personas datus.
• Pārlūks, versija, operētājsistēma un ierīces tips. Kur pārlūks to atbalsta, versija tiek ņemta no Client Hints, nevis minēta no User-Agent teksta.
• Ekrāna un loga izmērs, orientācija, krāsu dziļums, laika zonas nobīde un pārlūka valodas.
• Konsoles izvade un JavaScript kļūdas. Pārtvērēji tiek uzstādīti jau ielādes sākumā, tāpēc redzamas arī kļūdas, kas notika, pirms cilvēks vispār paguva kaut ko nospiest.
• Neizdevušies tīkla pieprasījumi — metode, adrese, statusa kods un ilgums. Tieši šī rinda parasti izšķir, vai vaina ir priekšpusē vai serverī.
• Pēc izvēles — ekrāna ieraksts un balss komentārs, ja soļus vieglāk parādīt nekā aprakstīt.

Un tagad ierobežojumi, jo tie ir tikpat svarīgi. Konsoles un tīkla buferis ir ierobežots ar pēdējiem 120 ierakstiem, tāpēc lapa, kas minūtēm ilgi bēra brīdinājumus, agrākos ierakstus vairs nesatur. Redzam tikai to, kas notiek pārlūkā: servera žurnāli, datubāzes vaicājumi un fona uzdevumi paliek tavā pusē. Un logrīks nesavāc ievadlauku saturu — ja kļūda ir atkarīga no konkrētiem datiem, tie joprojām jāapraksta ar vārdiem.

Kā beigt ping-pongu praksē

Automātiskais konteksts atrisina tehnisko pusi. Cilvēcisko pusi atrisina trīs vienošanās, kuras vērts noteikt pirms projekta sākuma.

Pirmkārt, viena vieta. Ja klients drīkst ziņot pa e-pastu, WhatsApp un telefonu, tev ir trīs nesavienoti saraksti un neviena kopaina. Vienojies, ka pieteikums, kas nav sistēmā, nav pieteikums — un tad padari ziņošanu tik vienkāršu, ka alternatīva nav vajadzīga. Ja ziņotāju skaits ir neierobežots, nav arī iemesla kādu no procesa izslēgt: testētājs, satura redaktors un klienta mārketinga cilvēks var ziņot tieši.

Otrkārt, viens pieteikums — viena problēma. Vēstule ar septiņām problēmām sarakstā nav prioritizējama un nav slēdzama. Labāk septiņi īsi pieteikumi.

Treškārt, atbildība par statusu. Klientam jāredz, kas ar pieteikumu notiek, citādi viņš pārjautās pa citu kanālu — un ping-pongs sākas no jauna. Ja pieteikumi automātiski nonāk tajā pašā uzdevumu sistēmā, kur strādā komanda, statuss atjaunojas pats, nevis pēc atgādinājuma.

Ar ko sākt

Ja šobrīd kļūdas pienāk pa e-pastu, nav jāpārbūvē viss process. Pietiek ar vienu izmaiņu: pievieno ziņošanas pogu testa vidē un lūdz klientam nākamajā pieņemšanas kārtā izmantot tikai to. Pēc nedēļas salīdzini, cik daudz precizējošu jautājumu vajadzēja uzdot. Šis skaitlis parasti atbild uz jautājumu par to, vai rīks bija vajadzīgs.