Atsiprašymo menas: patogių ir prieinamų klaidų pranešimų kūrimas globaliai auditorijai

Skaitmeniniame pasaulyje klaidos yra neišvengiamos. Sutrinka tinklo ryšys, vartotojas įveda duomenis netikėtu formatu arba serveriui tiesiog nesiseka. Dešimtmečius programuotojai klaidas laikė techninėmis problemomis, rodydami mįslingus pranešimus, tokius kaip „Error 500: Internal Server Error“ ar „Invalid Input Exception“. Tačiau toks požiūris ignoruoja esminę tiesą: klaidos yra svarbi vartotojo patirties dalis.

Tai, kaip programa praneša apie nesėkmę, gali lemti skirtumą tarp vartotojo, kuris kantriai ištaiso klaidą, ir to, kuris nusivylęs palieka jūsų paslaugą. Gerai suformuluotas klaidos pranešimas yra daugiau nei tik pranešimas; tai pokalbis. Tai atsiprašymas, patarimas ir galimybė kurti pasitikėjimą. Kai kuriame globaliai auditorijai, aiškaus, pagarbaus ir prieinamo klaidų tvarkymo svarba tampa didžiausia.

Šiame vadove nagrinėsime patogių ir prieinamų klaidų pranešimų kūrimo principus, ypatingą dėmesį skirdami iššūkiams ir geriausioms praktikoms, aptarnaujant tarptautinę vartotojų bazę.

Tobulo klaidos pranešimo anatomija: trys ramsčiai

Sėkmingas klaidos pranešimas ne tik konstatuoja problemą, bet ir įgalina vartotoją ją išspręsti. Norint tai pasiekti, kiekvienas pranešimas turėtų būti pagrįstas trimis pagrindiniais ramsčiais: aiškumu, glaustumu ir konstruktyvumu.

1. Būkite aiškūs, o ne mįslingi

Vartotojas turėtų iš karto suprasti, kas nutiko ne taip. Tai reiškia techninio žargono vertimą į paprastą, žmogui suprantamą kalbą. Jūsų tikslas – pašalinti dviprasmiškumą ir kognityvinę apkrovą.

• Venkite techninio žargono: Pakeiskite duomenų bazių klaidų kodus, išimčių pavadinimus ir HTTP būsenos kodus paprastais paaiškinimais. Vietoj „Klaida 404“ naudokite „Puslapis nerastas“. Vietoj „SMTP Connection Failed“ naudokite „Nepavyko išsiųsti el. laiško. Patikrinkite ryšį ir bandykite dar kartą.“
• Būkite konkretūs: Bendro pobūdžio pranešimas, pvz., „Neteisingas įrašas“, yra nenaudingas. Nurodykite vartotojui, kuris įrašas yra neteisingas ir kodėl. Pavyzdžiui, „Slaptažodį turi sudaryti ne mažiau kaip 8 simboliai.“
• Naudokite paprastą kalbą: Rašykite plačiajai auditorijai, o ne savo programuotojų komandai. Įsivaizduokite, kad aiškinate problemą techninių žinių neturinčiam draugui.

2. Būkite glausti, o ne išsamūs

Nors aiškumas yra būtinas, glaustumas taip pat svarbus. Vartotojai dažnai skuba arba yra nusivylę, kai susiduria su klaida. Ilga, paini pastraipa greičiausiai bus ignoruojama. Gerbkite jų laiką, pereidami tiesiai prie esmės.

• Sutelkkite dėmesį į esmę: Įtraukite tik tą informaciją, kurios reikia problemai suprasti ir išspręsti.
• Svarbiausią informaciją pateikite pradžioje: Pačią svarbiausią informaciją rašykite pranešimo pradžioje.
• Naudokite formatavimą: Sudėtingesnėms klaidoms naudokite sąrašo punktus ar paryškintą tekstą, kad pabrėžtumėte pagrindines detales ir pranešimą būtų lengva peržvelgti.

3. Būkite konstruktyvūs, o ne kaltinantys

Klaidos pranešimas turėtų būti naudingas patarimas, o ne aklavietė. Tonas turėtų būti palaikantis ir empatiškas, niekada nekaltinantis vartotojo. Pagrindinis tikslas – pateikti aiškų kelią į priekį.

• Paaiškinkite, kaip tai ištaisyti: Tai pats svarbiausias elementas. Ne tik pasakykite, kas blogai, bet ir pasiūlykite sprendimą. Vietoj „Neteisingas datos formatas“ naudokite „Įveskite datą YYYY-MM-DD formatu.“
• Naudokite pozityvų toną: Suformuluokite pranešimą mandagiai. Venkite žodžių, tokių kaip „nepavyko“, „neteisingas“ ar „neleistinas“. Palyginkite „Įvedėte neteisingą slaptažodį“ su švelnesniu variantu „Atrodo, kad šis slaptažodis neatitinka mūsų įrašų. Ar norėtumėte bandyti dar kartą arba nustatyti slaptažodį iš naujo?“
• Pasiūlykite alternatyvų: Jei įmanoma, pasiūlykite išeitį. Tai gali būti nuoroda į pagalbos puslapį, kontaktinis numeris arba galimybė išsaugoti progresą ir bandyti vėliau.

Prieinamumas: užtikrinkime, kad visi suprastų, kai kažkas nepavyksta

Klaidos pranešimas yra nenaudingas, jei vartotojas negali jo suvokti ar suprasti. Skaitmeninis prieinamumas užtikrina, kad žmonės su negalia, įskaitant regos, klausos, motorikos ir kognityvinius sutrikimus, galėtų naudotis jūsų produktu. Žiniatinklio turinio prieinamumo gairės (WCAG) suteikia pagrindą prieinamų patirčių kūrimui, o klaidų tvarkymas yra pagrindinis komponentas.

Suvokiamos klaidos: ne tik raudonas tekstas

Viena iš dažniausiai pasitaikančių klaidų interneto dizaine yra pasikliovimas vien spalva klaidai nurodyti. Maždaug 1 iš 12 vyrų ir 1 iš 200 moterų turi tam tikrą spalvų matymo sutrikimą. Jiems raudonas rėmelis aplink formos laukelį gali būti nematomas.

WCAG 1.4.1 - Spalvos naudojimas: Spalva neturėtų būti vienintelė vizualinė priemonė informacijai perteikti. Kad klaidos būtų suvokiamos, derinkite spalvą su kitais indikatoriais:

• Piktogramos: Šalia laukelio padėkite aiškią klaidos piktogramą (pvz., šauktuką apskritime). Užtikrinkite, kad ši piktograma turėtų tinkamą alternatyvų tekstą ekrano skaitytuvams (pvz., `alt="Klaida"`).
• Tekstinės etiketės: Prieš klaidos pranešimą pridėkite aiškią etiketę, pvz., „Klaida:“ arba „Dėmesio:“.
• Storesni rėmeliai ar kontūrai: Pakeiskite įvesties laukelio vizualinį stilių taip, kad jis nepriklausytų vien nuo spalvos.

Valdomos klaidos: navigacija klaviatūra ir ekrano skaitytuvu

Pagalbinių technologijų, tokių kaip ekrano skaitytuvai, vartotojams reikia, kad klaidos būtų perduodamos programiškai. Jei ekrane pasirodo klaida, bet ji nėra perskaitoma, tai tolygu tam, lyg jos niekada ir nebuvo.

• Programinis susiejimas: Klaidos pranešimas turi būti programiškai susietas su formos laukeliu, kurį jis apibūdina. Geriausias būdas tai padaryti – naudoti `aria-describedby` atributą. Šis atributas priskiriamas formos įvesties laukeliui, o jo vertė yra elemento, kuriame yra klaidos pranešimas, `id`.
• Praneškite apie dinamines klaidas: Klaidoms, kurios atsiranda be puslapio perkrovimo (pvz., tiesioginis validavimas), naudokite ARIA „gyvąjį regioną“ (`aria-live="assertive"`), kad ekrano skaitytuvai nedelsdami perskaitytų pranešimą.
• Valdykite fokusą: Vartotojui pateikus formą su klaidomis, programiškai perkelkite klaviatūros fokusą į pirmąjį laukelį su klaida. Tai taupo tik klaviatūra besinaudojančių vartotojų laiką, nes jiems nereikia naršyti per visą formą ieškant klaidos.

Prieinamo HTML klaidos pranešimo pavyzdys:

<label for="email">El. pašto adresas</label> <input type="email" id="email" name="email" aria-invalid="true" aria-describedby="email-error"> <div id="email-error" role="alert" style="color: red;"> Klaida: įveskite galiojantį el. pašto adresą. </div>

Suprantamos klaidos: aiškumas yra prieinamumas

Aiškių ir konstruktyvių pranešimų principai patys savaime yra prieinamumo principai. Neaiški ar paini kalba gali būti didelė kliūtis vartotojams su kognityvinėmis negaliomis, mokymosi sutrikimais ar tiems, kuriems kalba nėra gimtoji.

• WCAG 3.3.1 - Klaidos identifikavimas: Jei įvesties klaida aptinkama automatiškai, klaidingas elementas yra identifikuojamas ir klaida aprašoma vartotojui tekstu.
• WCAG 3.3.3 - Pasiūlymas dėl klaidos: Jei įvesties klaida aptinkama automatiškai ir yra žinomi pasiūlymai, kaip ją ištaisyti, tuomet pasiūlymai pateikiami vartotojui, nebent tai keltų pavojų turinio saugumui ar tikslui. Pavyzdžiui, pasiūlant vartotojo vardą, panašų į tą, kurį vartotojas įvedė.

Globalus kontekstas: klaidų tvarkymas skirtingose kultūrose

Norint sukurti sklandžią patirtį globaliai auditorijai, reikia daugiau nei paprasto vertimo. Lokalizacija (l10n) ir internacionalizacija (i18n) yra labai svarbios, kad klaidų pranešimai būtų tikrai veiksmingi visame pasaulyje.

Lokalizacija yra daugiau nei vertimas

Tiesioginis angliško klaidos pranešimo vertimas gali lemti keistas formuluotes, kultūrinius nesusipratimus ar tiesiog neteisingus pranešimus.

• Kultūriniai tono niuansai: Draugiškas, neformalus tonas, kuris puikiai tinka Šiaurės Amerikos kontekste, gali būti suvokiamas kaip neprofesionalus ar nepagarbus tokiose šalyse kaip Japonija ar Vokietija. Jūsų klaidų pranešimų strategija turėtų prisitaikyti prie tikslinės vietovės kultūrinių lūkesčių.
• Duomenų formatai: Daugelis klaidų yra susijusios su duomenų formatais. Pranešimas, pvz., „Prašome naudoti MM/DD/YYYY formatą“, yra neteisingas didžiajai pasaulio daliai. Jūsų sistema idealiu atveju turėtų priimti vietinius formatus, bet jei ne, klaidos pranešime turi būti aiškiai nurodytas reikalingas formatas ir pateiktas vartotojui aktualus pavyzdys (pvz., „Prašome įvesti datą kaip YYYY-MM-DD“). Tai taikoma datoms, laikams, valiutoms, telefono numeriams ir adresams.
• Vardai ir asmeninė informacija: Forma, reikalaujanti „Vardo“ ir „Pavardės“, neveiks vartotojams iš kultūrų, kuriose pavardės rašomos pirmiausia arba kur žmonės gali turėti tik vieną vardą. Jūsų klaidų pranešimai neturėtų daryti prielaidos apie vakarietišką vardų struktūrą.

Piktogramų universalumas (ir rizika)

Piktogramos gali būti galinga priemonė kalbos barjerams įveikti, tačiau jų reikšmės ne visada yra universalios. Nykščio į viršų piktograma daugelyje Vakarų šalių yra teigiama, tačiau kai kuriose Vidurinių Rytų ir Vakarų Afrikos dalyse tai yra labai įžeidžiantis gestas. Naudojant piktogramas klaidoms:

• Laikykitės plačiai pripažintų simbolių: Šauktukas trikampyje ar apskritime yra vienas iš universaliausiai suprantamų įspėjimo ar klaidos simbolių.
• Visada derinkite su tekstu: Niekada nepasikliaukite vien piktograma. Aiškus, lokalizuotas tekstas užtikrina, kad reikšmė bus suprasta, ir yra būtinas prieinamumui.

Praktinis įgyvendinimas: nuo dizaino iki kodo

Efektyvus klaidų tvarkymas yra komandinis sportas, reikalaujantis dizainerių, rašytojų, programuotojų ir produktų vadovų bendradarbiavimo.

Dizaineriams ir UX tekstų kūrėjams: pranešimų matrica

Nepalikite klaidų pranešimų paskutinei minutei. Proaktyviai projektuokite nesėkmės atvejus, sukurdami „Klaidų pranešimų matricą“. Tai dokumentas, dažnai skaičiuoklė, kuriame nurodomi galimi nesėkmės taškai vartotojo kelionėje.

Paprastą matricą galėtų sudaryti šie stulpeliai:

• Klaidos ID: Unikalus klaidos identifikatorius.
• Paleidiklis: Vartotojo veiksmas ar sistemos būsena, sukelianti klaidą.
• Vieta: Kur atsiranda klaida (pvz., registracijos forma, atsiskaitymo puslapis).
• Poveikis vartotojui: Problemos sunkumas vartotojui (žemas, vidutinis, aukštas).
• Pranešimo tekstas (kiekvienai kalbai): Tikslus, vartotojui skirtas tekstas, parašytas laikantis aiškumo, glaustumo ir konstruktyvumo principų.
• Prieinamumo pastabos: Instrukcijos programuotojams dėl ARIA atributų, fokuso valdymo ir pan.

Programuotojams: geriausios techninės praktikos

Programuotojai yra atsakingi už dizaino įgyvendinimą patikimu ir prieinamu būdu.

• Tiesioginis vs. pateikimo metu atliekamas validavimas: Naudokite tiesioginį validavimą (tikrinant laukelį, kai vartotojas jį palieka) paprastiems formato patikrinimams, tokiems kaip el. paštas ar slaptažodžio stiprumas. Tai suteikia momentinį grįžtamąjį ryšį. Naudokite pateikimo metu atliekamą validavimą sudėtingesnėms taisyklėms, kurioms reikalingas serverio patikrinimas (pvz., „vartotojo vardas jau naudojamas“). Dažnai geriausias požiūris yra abiejų derinys.
• Pateikite konkrečias serverio klaidas: Serveris turėtų grąžinti skirtingus klaidų kodus ar pranešimus skirtingoms nesėkmės būsenoms. Vietoj bendro „400 Bad Request“, API turėtų atsakyti su konkrečia informacija, pvz., `{"error": "email_in_use"}` ar `{"error": "password_too_short"}`. Tai leidžia vartotojo sąsajai parodyti teisingą, patogų pranešimą.
• Sklandus veikimo prastėjimas: Užtikrinkite, kad jūsų forma ir jos validavimas veiktų bent jau baziniu lygiu, jei JavaScript neįsikelia. HTML5 validavimo atributai (`required`, `pattern`, `type="email"`) suteikia tvirtą pagrindą.

Klaidų pranešimų audito kontrolinis sąrašas

Naudokite šį kontrolinį sąrašą, kad peržiūrėtumėte esamą klaidų tvarkymą arba vadovautumėtės kurdami naujus dizainus:

• Aiškumas: Ar pranešimas parašytas paprasta kalba, be techninio žargono?
• Specifiškumas: Ar jame nurodytas konkretus laukelis ir problema?
• Konstruktyvumas: Ar jame paaiškinta, kaip ištaisyti problemą?
• Tonas: Ar tonas yra paslaugus ir pagarbus, o ne kaltinantis?
• Vaizdinės priemonės: Ar klaidai nurodyti naudojama daugiau nei vien spalva?
• Prieinamumas: Ar klaida programiškai susieta su jos įvesties laukeliu ir ar ją perskaito ekrano skaitytuvai?
• Fokusas: Ar teisingai valdomas klaviatūros fokusas?
• Globalizacija: Ar pranešimas teisingai lokalizuotas, atsižvelgiant į kultūrinį toną ir duomenų formatus?

Pažangios koncepcijos: pakelkite klaidų tvarkymą į aukštesnį lygį

Klaidų suvestinės

Ilgose ar sudėtingose formose vienas visų klaidų sąrašas puslapio viršuje gali būti labai naudingas. Šis „Klaidų suvestinės“ laukelis turėtų pasirodyti vartotojui paspaudus pateikimo mygtuką. Siekiant maksimalaus patogumo ir prieinamumo:

• Perkelkite fokusą į klaidų suvestinės laukelį, kai jis atsiranda.
• Aiškiai išvardykite kiekvieną klaidą.
• Paverskite kiekvieną klaidą sąraše nuoroda, kurią paspaudus, vartotojas nukreipiamas tiesiai į atitinkamą formos laukelį.

Mikrotekstai ir prekės ženklo tonas

Klaidų pranešimai yra mikrotekstų forma – maži tekstai, kurie vadovauja vartotojo patirčiai. Jie suteikia galimybę sustiprinti jūsų prekės ženklo balsą. Žaismingas prekės ženklas gali panaudoti šiek tiek humoro 404 puslapyje, tačiau esant kritinėms validavimo klaidoms (pvz., mokėjimo formoje), tonas visada turėtų būti aiškus ir rimtas. Tinkamą toną diktuoja klaidos kontekstas.

Registravimas ir analizė

Vartotojų klaidas laikykite vertingais duomenimis. Registruodami vartotojo sąsajos ir serverio validavimo klaidas, galite nustatyti dažnas trinties vietas. Ar daug vartotojų susiduria su slaptažodžio reikalavimais? Ar tam tikras formos laukelis dažnai sukelia validavimo nesėkmes? Šie duomenys suteikia galingų įžvalgų, kurias galima panaudoti tobulinant formos dizainą, aiškinant instrukcijas ar sprendžiant pagrindines patogumo problemas.

Išvada: paverskite klaidas galimybėmis

Klaidų tvarkymas nėra antraeilis uždavinys, kurį reikia spręsti projekto pabaigoje. Tai yra esminė įtraukaus, į vartotoją orientuoto dizaino dalis. Laikydami kiekvieną klaidos pranešimą galimybe padėti, nukreipti ir pagarbiai bendrauti su savo vartotojais, jūs darote daugiau nei tiesiog sprendžiate techninę problemą.

Jūs kuriate pasitikėjimą. Jūs mažinate nusivylimą. Jūs kuriate atsparesnę ir malonesnę vartotojo patirtį. Gerai sutvarkyta klaida gali sustiprinti vartotojo pasitikėjimą jūsų produktu, parodydama jam, kad numatėte jo poreikius ir esate pasirengę padėti, kai viskas vyksta ne pagal planą. Konkurencingoje pasaulinėje rinkoje toks apgalvotas dizainas nebėra prabanga – tai būtinybė.