it-swarm-eu.dev

Mají se chybové zprávy omluvit?

V našem týmu diskutujeme o chybové zprávě s nápisem „Litujeme, nemáte oprávnění k přístupu k této funkci. Požádejte o pomoc svého správce.“

Je v tomto případě vhodné použít jazyk „omluvy“? Důvodem je, že by bylo vhodnější „omluvit se“ za něco, co by bylo považováno pouze za „zavinění“ aplikace, jako je prostoje. („Je nám líto, ale náš web je momentálně nedostupný ... zkuste to znovu později.“)

521
JoelFan

Důvod, proč si myslím, že je důležité mít apologetický tón, je zajistit, že komunikujete s uživatelem, že ačkoli došlo k chybě a v tomto případě interaguje se strojem nebo aplikací, stále respektujete jeho jednání a humanizujete chyba.

Citovat tento článek od UXMatters :

"Chystáte se zobrazit svou chybovou zprávu osobě, tak ji napište do tónu hlasu, který byste použili, kdybyste této osobě přímo oznamovali chybovou zprávu."

Doporučuji také podívat se na tento vynikající článek, Říkáte „Ne“, když můžete ve svých webových formulářích říci „Ano“? :

Chybové zprávy se zdají být nedůležité a neuvěřitelně nudnou součástí vytváření uživatelského prostředí. Tonalita chybových zpráv však může ovlivnit zážitek z téměř jistého opuštění k převodu.

Tento článek zdůrazňuje, že chybové zprávy by měly nést pozitivní tón, a proto může apologetická reakce pomoci uživatelům rychle se zotavit a ne okamžitě se stát defenzivním kvůli chybě, kterou mohli udělat.

Psaní chybových zpráv s pozitivním tónem není raketovou vědou. Postupujte podle několika jednoduchých pravidel:

  1. Nejprve se zbavte technologických žargonů, jako je „nekompatibilní“. Většina uživatelů neví, co to znamená. Mluvte s nimi ve svém vlastním jazyce a ne v jazyce svých vývojářů. Například „nekompatibilní“ se překládá na „nefunguje spolu“ v prosté angličtině.

  2. Nepoužívejte záporná slova

  3. Jasně identifikujte chybu, aby uživatel věděl, co má opravit.

  4. Dejte uživateli nápovědu, jak lze problém vyřešit.

  5. Vinu na sebe, ne na uživatele.

Doporučuji také podívat se na Vliv apologetických chybových zpráv a stavů nálady na sebehodnocení výkonu uživatelů počítačů pro studii, která analyzovala dopad použití apologetických chybových zpráv na stavy nálady uživatelů a na to, jak člověk jako apologetické tóny jsou účinné v počítačových rozhraních. Citovat výňatek z článku

V HHI se omluvy obvykle používají k vyjádření lítosti (Leech, 1983; Schlenker a Darby, 1981) nebo ke zmírnění hněvu jednotlivců způsobeného jejich nesouhlasem s jednáním druhých. Jinými slovy se omluvy zmírňují frustrace a zlost, když se pokus o interakce nezdaří. Podobně , Nielsen (1998) tvrdí, že chybové zprávy reagující na akci uživatele počítače by měly zahrnovat jednoduché apologetické prohlášení, když důvodem chyby je omezení rozhraní počítače k ​​provedení zamýšlené úlohy. Tzeng (2006) provedl studii, která zkoumala vnímání online systémů uživateli, obsahující tři různé chybové zprávy, z nichž každá obsahuje odlišné strategie zdvořilosti. Ve studii byly nejprve získány orientace na zdvořilost uživatelů a poté byli účastníci požádáni o interakci s webovými stránkami včetně předem určených problémů. Když uživatelé narazili na problémy, systém poskytl určité chybové zprávy představující jednu pozitivní zdvořilostní strategii (tj. Vtip), jednu negativní zdvořilostní strategii (tj. Jednoduchou omluvu) a mechanickou zprávu o chybě (tj. Stránka je dočasně nedostupná). Výsledky studie ukázaly, že uživatelé, kteří se zabývají společenskými událostmi se zdvořilými výrazy, raději přijímali apologetické zprávy výrazně více než mechanické nebo vtipné zprávy a preferovali apologetické zprávy výrazně více než ty zprávy, které jsou méně orientovány na zdvořilé výrazy.

článek také upozorňuje na to, jak apologetický tón na rozdíl od negativního tónu ovlivňuje vnímání, které uživatelé z nich mají, a jak pozitivní apologetické vnímání může pomoci při zvyšování pozitivního výkonu

De Laere, Lundgren a Howe (1998) porovnávali styly interakcí typu člověk versus stroj jako u počítačových rozhraní. Nepozorovali významný rozdíl mezi různými styly, pokud jde o hodnocení uživatelů. Výsledky studie rovněž ukázaly, že negativní zpětná vazba ovlivňuje sebepojetí účastníků jinak než pozitivní zpětná vazba.

Tzeng (2004) zkoumal, zda apologetická zpětná vazba ovlivňuje vnímání výkonu uživatelů v počítačovém prostředí. Tato studie naznačovala, že uživatelé nemusí očekávat, že počítače budou zdvořilí, ale apologetická prohlášení přiměla subjekty, aby se cítily lépe, pokud jde o jejich interakce s programem.

Výzkumný příspěvek Počítačová omluva: Vliv apologetické zpětné vazby na uživatele v počítačovém prostředí také uvádí, proč apologetická negativní zpětná vazba navazuje na uživatelský zážitek ze sociálního hlediska

Použití apologetických příkazů s chybovou zprávou přispívá k interakci člověk-počítač. Pokud vezmeme v úvahu, že hlavním cílem návrhu zaměřeného na uživatele je vytvoření prostředí pro uživatele, ve kterém se cítí pohodlně, použití apologetických prohlášení v návrhu uživatelského rozhraní se stává velmi důležitou otázkou. Kromě toho může být v interakci člověk-člověk jedním z nejdůležitějších nejdůležitější chovat se ohleduplně. Ve většině společností, kdy se člověk nechová ohleduplně nebo nedělá chybu vůči druhému, je omlouvání tradičním a nejúčinnějším způsobem, jak tento problém překonat. Tato studie rovněž ukazuje, že většina subjektů si myslí, že apologetické zpětné vazby se jim nezdají trapné, a 95% z nich, kteří dostávají apologetickou zpětnou vazbu, cítilo, že apologetická zpětná vazba na ně připadala citlivá. Zdá se, že zde je zajímavé setkat se s ohleduplným chováním, jako je omlouvání, když narazí na chybu způsobenou nemožností počítačů, jako by narazili na problém v lidské interakci. Výsledky této studie ukazují, že reprezentace afektivního stavu člověka v návrhu rozhraní je v interakci člověk-počítač velmi důležitá, protože lidé jsou více sympatičtí k vidění emočních aspektů v rozhraní, jako je citlivost, respekt a pocit lidskosti. Tyto výsledky by proto mohly být použity jako důkaz pro tvrzení, že počítače, které uživatelům nabízejí apologetická prohlášení, mohou odůvodnit myšlenku skutečného designu zaměřeného na uživatele.

Na druhou stranu společnost Microsoft doporučuje pomocí omlouvajícího nebo apologetického tónu pouze v případě závažné chyby:

Slovo „ Sorry “ používejte pouze v chybových zprávách, které mají pro uživatele vážné problémy (například ztráta dat nebo nemožnost používat počítač). Neomlouvejte se, pokud k problému došlo během normálního fungování programu (například pokud uživatel potřebuje počkat na nalezení síťového připojení).

450

Zatímco Mervinova odpověď je vynikající, já bych šel dál a řekl, že je „přijatelný“ nebo „preferovaný“. Řekl bych, že musíte použít apologetický tón z jednoho velmi dobrého důvodu: pokud uživatel udělá chybu, je to proto, že uživatel nerozumí pravidlům nebo logice systému. To není chyba uživatele! Je odpovědností systému přesně vysvětlit logiku systému uživatelům. Uživatelská chyba je tedy nesoulad mezi tím, co si uživatel myslí, že by měl být proveden, a tím, co systém umožňuje.

I když by člověk nikdy nebyl tak otravný, pokud to všechno vysvětlíme, vaše apologetická chybová zpráva je: "Je nám líto, že uživatelské rozhraní tohoto programu, vaše minulé zkušenosti s ním nebo zkušenosti s jinými podobnými programy , vás přimělo věřit, že byste v tuto chvíli mohli podniknout takovou akci, ale nemůžete, protože .... "

Konkrétní pro uvedený případ: uživatel si myslel, že přístup může být dostupný. Omlouváme se za nedorozumění, které uživatel měl, protože systém dosud nesdělil, že oprávnění nebylo k dispozici.

Co to znamená říci, že chyba může být chyba uživatele? Uživatelé nechodí a dělají věci, o kterých vědí nebudou fungovat (což by jen plýtvalo vlastním časem). Jediný důvod, proč dělají něco špatného, ​​je proto, že nevědí, že to nebude fungovat. Pokud uživatel něco neví, není to vlastně chyba systému, protože to nevede k transparentnosti? Bez ohledu na to, jak zřejmé si programátor může myslet, že je to velká většina chyb, je chyba systému, proto si napište chybové zprávy v souladu a budete mít šťastnější uživatele.

106
AgilePro

Krok zpět: Proč byla tato funkce uživateli zpřístupněna (viditelná) na prvním místě?

Pokud je funkce nedostupná konkrétnímu uživateli (nebo třídě uživatele), skryjte ji.

Pokud se jedná o prémiovou funkci, kterou chcete rozšířit - udělejte to.

Export historie je skvělý způsob, jak zálohovat data, ale je k dispozici pouze na prémiových účtech. Spojte se s administrátorem a požádejte ho, aby upgradoval váš účet na Premium.

Pokud jde o prostoje nebo chyby (když odpovědnost spadá výhradně na aplikaci), cítím tón, který je druhoradý v tom, že:

Tento problém byl zaznamenán a teplé tělo někde ví, že máte problémy.

Je tu někdo, koho mohu kontaktovat.

Můžu to zkusit znovu.

Něco se strašně strašně pokazilo!
Protokolovali jsme chybu.
Zkuste to prosím znovu nebo kontaktujte [email protected] a my se vám ozveme co nejdříve.

62
Max

Nezdá se mi, že se z počítače omlouvám velmi humanizovaným, o nic víc než o automatizovaný systém přidržení telefonní sítě mě nutí cítit se, že je můj hovor důležitý, když řeknu: „Váš hovor je pro nás velmi důležitý! Prosím, zůstaňte na lince pro další dostupný zástupce. “

Nemyslím si, že omluvy jsou hlavním problémem. Mnohem důležitější je, že jsou dostatečně jasné, aby uživateli pomohly vyřešit problém, aniž by je ohromily.

Dobrá chybová zpráva je podrobně popsána přesně o tom, co způsobilo problém a jak jej opravit. Je to také naprosto srozumitelné a nevystresuje uživatele pomocí žargonu, kterému nerozumí.

Tyto dva cíle jsou samozřejmě v konfliktu. Řeknutí uživateli, že došlo k fatální výjimce při diskombobulaci jádra na řádku 47 a je zaznamenána výpis stavu paměti, je pro vývojáře velmi užitečné, ale pro uživatele je zcela ztraceno a přináší uživateli větší stres než samotná chyba. Přesto je stejně chybné mít chybovou zprávu, která říká: „Promiň! Jak mám jako uživatel vědět, co se pokazilo? Jak mohu začít řešit svůj problém?

Jedná se o kompromis, který je ohleduplný k uživateli (jsou to pravděpodobně mocní uživatelé? Je tato skutečnost ve vzduchu? Je angličtina jejich prvním jazykem? Atd.).

Považuji za vhodnější vyhnout se chmýří a nepřehlednosti omluv za chybu, kterou si uživatel přinesl, a místo toho napsat chybové zprávy, které jsou skutečně ohleduplné k uživateli tím, že je zcela jasné, jak to vyřešit.

36
Ben Mordecai

Ano, chybové zprávy by se měly omluvit, je-li to možné. Lidé připisují lidské emoce počítačům , takže počítače by měly být zdvořilé, zejména uživatelům, kteří očekávají, že lidé budou zdvořilí.

Například pro weby určené pro starší občany by byly přínosem velmi slušné zprávy

  1. ukázat, že web a ne uživatel je zaviněn
  2. přizpůsobit se sociálním očekáváním těchto uživatelů. (Předpokládám, že starší lidé s větší pravděpodobností očekávají zdvořilost při normální sociální interakci mezi lidmi.)

Kapitola " Přinášející ovlivnění interakce člověka s počítačem " obsahuje sekci o apologetické zpětné vazbě (důrazný důl):

Nielsen (1998) tvrdil, že když uživatel narazí na problém a obdrží chybovou zprávu, měl by obsahovat jednoduchý apologetický příkaz , že příčinou chyby je omezení rozhraní pro provedení příkazu pro zamýšlenou úlohu, nikoli akce uživatele. [...]

Tzeng (2004) ukázal, že subjekty v apologetických zpětnovazebních skupinách nevnímaly jejich výkon a schopnosti jako lepší než ty v neaplikujících skupinách. Dále prokázal, že uživatelé počítačů nemusí očekávat, že počítače budou slušné; přesto apologetická prohlášení umožňují subjektům cítit se lépe o jejich interakci s programem. Na základě myšlenky, že orientace účastníků na zdvořilost by mohla mít vliv na jejich vnímání apologetických počítačových chybových zpráv, provedla Tzeng (2006) další studii zkoumající vnímání uživatelů o online systémech obsahující tři různé chybové zprávy, z nichž každá obsahuje různé strategie zdvořilosti. Vyvolal orientaci zdvořilosti uživatelů a požádal je, aby komunikovali s webovými stránkami, z nichž každý obsahuje předem určené problémy. V případě problémů jsou uživatelům poskytovány určité chybové zprávy představující tři různé strategie zdvořilosti, což byla pozitivní strategie zdvořilosti (tj. Vtip), negativní strategie zdvořilosti (tj. Jednoduchá omluva) a mechanická zpráva o chybě (tj. Stránka je dočasně) nedostupné). Zjištění odhalila, že uživatelé, kteří při jednání se společenskými událostmi používají zdvořilé výrazy, upřednostňovali apologetické zprávy výrazně více než ostatní mechanické nebo vtipné zprávy a ostatní uživatelé, kteří jsou méně orientovaní na zdvořilé výrazy.

Existují také důkazy, že reakce uživatelů na náladu chybových zpráv závisí na jejich vlastní náladě . Pokud víte, jakou náladu budou uživatelé pravděpodobně mít, můžete ji použít ke strukturování zpětné vazby k chybě.

29
Graham Herrli

Buďte přirození, může to být nepříjemné, pokud se omlouváte příliš často napište svou zprávu v jasném jazyce - jako člověk mluví s jiným člověkem . Pokud je chyba způsobena vámi (vaše aplikace, váš server e.t.c.), omluvte se, jinak ponechejte pouze prohlášení o skutečnosti a jak problém vyřešit.

Například:

  • „Litujeme, ale nemohli jsme poslat vaši zprávu kvůli [nějakému] problému na našem serveru. Zkuste to prosím znovu.“
  • "Nemohli jsme poslat vaši zprávu; vyplňte prosím pole pro e-mail."

Další:

  • "Litujeme, už k tomu nemáte oprávnění. Váš zůstatek byl nízký a váš plán jsme snížili."
  • "K této funkci nemáte přístup; je k dispozici pouze v našem rozšířeném plánu."

Když odeberete všechny tyto „omlouváme se“ ze zprávy - zkrátíte, což znamená, že uživatel může číst a vyřešit problém rychleji . Pokud dáte jasné pokyny a problém lze snadno vyřešit - nikdo se nemusí omlouvat.

20
Dmitry Semenov

Věřím, že ve většině případů lze použít dvě zásady:

  1. Pokud uživatel udělal chyb, omlouvejte se za jeho chybu. Spíše instruujte, jak se problému vyhnout/napravit příští nebo v budoucnosti. Poskytněte zdroje pomoci, pokud je to možné/použitelné.

  2. Pokud byl problém způsoben programem, udělejte jednoduchou omluvu za nepříjemnosti ze zdvořilosti, ale je důležitější informovat uživatele o tom, co se ve skutečnosti stane, co se stane dále, co lze udělat pro opravu nabídnout šanci na nápravu problému (tj. vydat zprávu o chybě) atd.

13
epistemex

Software nemá pocity ani ego, ale lidé ano. Pokud například uděláte chybu při používání obchodní pobočkové ústředny AMEX, systém řekne „Omlouváme se, moje chyba“ příjemným lidským hlasem. Někteří to mohou považovat za patronizaci, ale je to také humanizace a podle mého názoru velmi chytrá.

Je lepší se mýlit na straně toho, že je příliš apologetický, než příliš ovládající nebo střední (např. „Zadejte číslo, stooopid!“) Nebo ještě horší: vůbec žádná zpětná vazba). Lidé jsou často hierarchičtí a bohužel se omluvy často pokládají za podřízené činy. Lidé chtějí mít pocit, že jsou lepší než počítače, které používají, takže omluva bude fungovat tímto směrem.

Stručně řečeno, dívat se na to jako na věc „kdo je na vině?“ je velmi logický způsob, jak přistupovat k velmi logickému problému, a to: jak pomůžete uživateli cítit se v pořádku ohledně překážky v používání softwaru?

9
Brian Duncan

Apologetický tón pomáhá udržovat správnou, lidskou komunikaci. Něco, co by nemělo být podceňováno!

Interakce s rozhraním by měla být vždy porovnávána s lidskou konverzací tváří v tvář. Představte si, že se pokoušíte koupit jízdenku se slevou, která se nevztahuje na váš případ. Chtěli byste raději slyšet „Přístup zakázán!“ od pokladníka, než něco poučného a zdvořilého?

Kromě toho, pokud má uživatel přístup na místo, s nímž ho nemůžete nechat komunikovat - to je v mnoha případech fatální chyba návrháře. Nic za vinu uživatele.

4
marcintreder

Ano, dávejte pozor na uživatele, ale mějte na paměti, že uživatelé nečtou - zejména text uprostřed. Ujistěte se tedy, že skutečné informace lze snadno zjistit. A může to být skutečná bolest, když máte formuláře s několika chybovými zprávami a každý z nich začíná slovy „Promiň ...“ nebo „Jejda ...“

3
Steffen Kastner

Vaše tvrzení se mi zdá v pořádku. Není to příliš apologetické, protože by nemělo být. A velmi dobře doplňujete omluvu s příslušným řešením v nejbližší řadě. V některých situacích se ospravedlnění stává nezbytným, protože některé chybové zprávy jsou příliš tupé a negativní, což může vést k demotivaci uživatelů.

I když je to chyba uživatele, nechcete být tak drsní a necitliví, protože software nikdy nemůže vědět, jak konkrétní uživatel přijme konkrétní chybovou zprávu, zejména když to omezuje jeho produktivitu. Přidání malé omluvy a možného řešení neutralizuje celou chybovou zprávu a umožňuje uživateli soustředit se spíše na řešení než na problém.

3
Mohit

Závisí na záměru webu nebo aplikací. Chcete, aby uživatel cítil, že jsou se ztrátou? Například; Chcete, aby upgradovali svůj účet a zvýšili tak příjmy? Domnívám se, že uživatelé často upgradují, když čelí pocitu ztráty nebo „nedělání“ funkce. Chybová zpráva je další cenná příležitost, jak na uživatele udělat dojem. Pokud chyba není důležitá pro cíle rozhraní; Z chyby bych nevydělal větší „věc“. Rychle si všimněte chyby a pomozte uživateli vrátit se k zamýšlenému úkolu.

3
code-blind

Stejně jako všechna rozhodnutí UX zvažte kontext použití. Nemyslím si, že se omlouvám za cokoli, co uživatel udělal, je vhodné, ale pokud se jim systém nebo aplikace staly nedostupnými nebo selhaly v důsledku problému jiného uživatele (výpadek, selhání infrastruktury atd.), Pak stojí za zvážení, pokud k tomu dojde s dalšími užitečnými informacemi o známém problému, o opravě ETA, o tom, co dělat dále, zástupná řešení - cokoli, aby uživatel zůstal v chodu nebo aby je přivedl zpět.

V souvislosti s tím, co uživatele nutí, není omluva nebo nedostatek, ale pokyny, jak kontaktovat správce systému. Spousta uživatelů to nemůže udělat ani vědět, jak a co je systémový administrátor! V takových případech selhání aplikace je lepší kontaktovat je (řekněte oddělení podpory nebo týmu podpory) a sdělte jim, že je hotovo, spoléháme se na správu incidentů a automatické protokolování. Poté sdělte uživateli, jak postupovat, pokud je jejich práce bezpečná, jaké je číslo incidentu, jak se o něj podělit atd.

Možná to bude užitečné: https://blogs.Oracle.com/userassistance/entry/unexpected_errors_are_they_ever_expected_anyway

3
uobroin

Možná zdůvodnění není nejlepší způsob, jak postupovat, pokud jde o chybové zprávy. Pokud se řídíme univerzální logikou, neměli bychom se omlouvat za něco, co není naší vinou.

Měli bychom však vždy ocenit přístup zaměřený na uživatele s konečným cílem, aby se uživatel cítil pohodlně bez ohledu na to, co. V tomto ohledu je nejlepším řešením apologetický přístup.

Přemýšlejte o tom, co uživatel v daném okamžiku cítí:

"Sakra, nemám dovoleno tuto funkci používat!"

Chyba je klíčovým okamžikem, kdy můžete snadno ztratit návštěvníka, a proto musíte situaci pečlivě zacházet s ohledem na všechny kognitivní a psychologické důsledky. To je to, na čem opravdu záleží, ne logika každodenního života.

Ať už je to jeho chyba, nebo ne, když dojde k chybě, bude se uživatel cítit frustrovaný. Když se cítíte frustrovaní, chcete někoho omluvit. Ano, obviňujete všechny a všechno kolem vás, ale sami sebe.

Je to dětské, ale přiznávám, že se to stalo i mně. Když mě aplikace kvůli své chybě selhala a omluvila se, opravdu se na mě usmála a přiměla mě myslet:

"Fajn, odpouštím ti. Vím, že jsi stejně neudělal nic špatného."

Pokud se zaměřujete na všechny náklady za určitou politickou jádro a nechcete se omlouvat za něco, co není vaší vinou, zvažte neutrálnější tón, například:

" Bohužel nemáte oprávnění k přístupu k této funkci."

Slovo „bohužel“ považuji za klíčové. Jinak by to znělo jako inkriminace, která za chvilku vytrhne frustrovaného uživatele:

"Nemáte oprávnění k přístupu k této funkci." (přidejte vykřičník a tohoto uživatele už neuvidíte)

Celá zpráva je mi nějak nějak formální (je to pravda, záleží na kontextu vaší aplikace). Chtěl bych jít na něco krátkého a vtipného, ​​které doručí zprávu ne-robotickým způsobem. Zní to jednoduše, ale je velmi obtížné přijít s takovými texty, strýci jste tak školeni, abyste se vyhnuli dalšímu dilematu, jako je tato:

Měli byste také poskytnout možné vysvětlení chyby a některé způsoby, jak se z ní zotavit. Tím se sníží frustrace uživatele tolik!

4 H je psaní chybových zpráv

2
Mircea

Pracuji pro společnost SAS), řekl bych, že je nutná apologetika, za předpokladu, že nepředpokládáte chybu.

U společností jako Starbucks, Apple a Zappos jsou lidé nezajímá, o jakou chybu to jde, pokud to není jejich. Spotřebitel, koncový uživatel a kupující je králem nebo královnou.

Takže se omlouvejte, pokud vaše aplikace/web odstraní všechna data ... To je vítání soudního procesu s otevřenou náručí, ale lidé milují pocit, že svět je jejich ústřicí. A pokud máte apologetickou zprávu S prostředky k rychlému nalezení řešení - jděte na to.

2
Peter

měli byste se omluvit za to, že jim nedali odkaz nebo telefonní číslo, ani jiným způsobem „požádejte o pomoc svého správce“

Uživatel se nechává zajímat „správce co?“, „Správce mé kanceláře nebo správce vaší společnosti?“

1
Steve Whetstone