Jak skłonić użytkowników do czytania komunikatów o błędach?

Jeśli programujesz dla odbiorców nietechnicznych, narażasz się na duże ryzyko, że użytkownicy nie przeczytają starannie sformułowanych i pouczających komunikatów o błędach, ale po prostu klikną pierwszy dostępny przycisk, wzruszając ramionami.

Zastanawiam się więc, jakie dobre praktyki możesz polecić, aby pomóc użytkownikom faktycznie przeczytać komunikat o błędzie, zamiast po prostu go odkładać. Pomysły, które przychodzą mi do głowy, wyglądałyby następująco:

• Formatowanie oczywiście pomocy; może prosty, krótki komunikat z przyciskiem „Dowiedz się więcej”, który prowadzi do dłuższego, bardziej szczegółowego komunikatu o błędzie
• Czy wszystkie komunikaty o błędach prowadzą do jakiejś sekcji podręcznika użytkownika (nieco trudne do osiągnięcia)
• Po prostu nie wysyłaj komunikatów o błędach, po prostu odmawiaj wykonania zadania (nieco „Apple” sposób obsługi danych wejściowych użytkownika)

Edycja: mam na myśli dość szeroką bazę użytkowników, którzy nie używają oprogramowania zbyt często i nie są uwięzieni (tj. Nie ma oprogramowania wewnętrznego ani wąskiej społeczności). Bardziej ogólna forma tego pytania została zadana na slashdot , więc możesz sprawdzić tam niektóre odpowiedzi.

To doskonałe pytanie, które zasługuje na +1 ode mnie. Pytanie, mimo że jest proste, obejmuje wiele aspektów natury użytkowników końcowych. Sprowadza się to do wielu czynników, które przyniosłyby korzyści Tobie i samemu oprogramowaniu oraz oczywiście użytkownikom końcowym.

• Nie umieszczaj komunikatów o błędach na pasku stanu - nigdy ich nie przeczytają, mimo że są ożywione kolorami itp .... zawsze będą za nimi tęsknić! Bez względu na to, jak bardzo będziesz się starał ... Na pewnym etapie podczas testów interfejsu użytkownika w Win 95, zanim został uruchomiony, MS przeprowadził eksperyment, aby odczytać interfejs użytkownika ( red. - należy zauważyć, że wiadomość została wyraźnie określona w kontekście „Spójrz pod krzesło” ), z banknotem 100 dolarów przyklejonym do spodu krzesła, na którym siedzieli badani ... nikt nie zauważył wiadomości na pasku stanu!
• Niech wiadomości będą krótkie, nie używaj zastraszających słów, takich jak `` Ostrzeżenie: system napotkał problem '', użytkownik końcowy naciśnie przycisk paniki i zareaguje zbyt mocno ...
• Bez względu na to, jak bardzo się starasz, nie używaj kolorów do identyfikacji wiadomości ... z psychologicznego punktu widzenia jest to podobne do machania czerwoną flagą bykowi!
• Użyj neutralnie brzmiących słów, aby przekazać minimalną reakcję i jak postępować!
• Lepszym rozwiązaniem może być wyświetlenie okna dialogowego z neutralnym komunikatem o błędzie i zaznaczenie pola wyboru „Czy chcesz widzieć więcej tych komunikatów o błędach w przyszłości?”, Ostatnią rzeczą, jakiej oczekuje użytkownik końcowy, jest praca w środku oprogramowania, które mają być bombardowane wyskakującymi wiadomościami, będą sfrustrowane i zostaną wyłączone przez aplikację! Jeśli pole wyboru zostało zaznaczone, zaloguj się do pliku zamiast tego ...
• Informuj użytkowników końcowych o tym, jakie komunikaty o błędach się pojawią ... co oznacza ... szkolenie i dokumentację ... teraz jest to trudne do omówienia ... nie chcesz, aby myśleli, że być „problemami” lub „usterkami” i co robić w takim przypadku ... nie mogą wiedzieć, że będą możliwe błędy, a nawet trudne.
• Zawsze, zawsze, nie bój się poprosić o informację zwrotną, gdy wydarzy się coś bez zdarzeń - na przykład: „Kiedy pojawił się błąd numer 1304, jak zareagowałeś? Jaka była twoja interpretacja ”- premia związana z tym, że użytkownik końcowy może być w stanie podać bardziej spójne wyjaśnienie zamiast„ Błąd 1304, utracony obiekt bazy danych! ”, Zamiast tego może być w stanie powiedzieć„ Kliknąłem to, więc więc ktoś przypadkowo pociągnął za kabel sieciowy maszyny ”, to wskaże ci, że musisz sobie z tym poradzić i może zmodyfikować błąd, aby powiedzieć„ Ups, rozłączono połączenie sieciowe ”… masz problem.
• Wreszcie, jeśli chcesz dotrzeć do międzynarodowych odbiorców, weź pod uwagę umiędzynarodowienie komunikatów o błędach - dlatego zachowaj neutralność, bo wtedy będzie łatwiej tłumaczyć, unikać synonimów, slangowych słów itp. tłumaczenie bez znaczenia - na przykład Fiat Ford, firma motoryzacyjna, sprzedawała swoją markę Fiat Ford Pinto, ale zauważyła, że ​​w Ameryce Południowej nie ma sprzedaży, okazało się, że Pinto był tam slangiem oznaczającym `` małego penisa '', a zatem brak sprzedaży ...
• ( red ) Udokumentuj listę komunikatów o błędach, których można się spodziewać, w osobnej sekcji dokumentacji zatytułowanej „Komunikaty o błędach” lub „Działania naprawcze” lub podobnej, wymieniając numery błędów we właściwej kolejności wraz z oświadczeniem lub dwoma opisami postępowania. ..
• ( red. ) Dzięki Victorowi Hurdugaci za jego wkład, zachowaj uprzejmość wiadomości, nie sprawiaj, że użytkownicy końcowi poczują się głupio. Jest to sprzeczne z odpowiedzią Jacka Marchettiego, jeśli baza użytkowników jest międzynarodowa ...

Edycja: Specjalne podziękowanie dla gnibblera, który wspomniał również o innym niezwykle istotnym punkcie!

• Pozwól użytkownikowi końcowemu na wybranie / skopiowanie komunikatu o błędzie, aby mógł, jeśli sobie tego życzy, wysłać e-mail do zespołu pomocy technicznej lub zespołu programistów.

Edycja nr 2: Mój błąd! Ups, dzięki DanM, który wspomniał o tym samochodzie, pomyliłem nazwę, to był Ford Pinto ... moja wina ...

Edycja nr 3: Podkreślili przez ed, aby wskazać dodatkowe lub uzupełnienia i przypisać innym za ich wkład ...

Edycja # 4: W odpowiedzi na komentarz Kena - oto moje podejście ... Nie, nie, używaj neutralnych standardowych kolorów systemu Windows ... nie wybieraj jaskrawych kolorów! Trzymaj się normalnego szarego koloru tła z czarnym tekstem, który jest normalnym standardowym wytycznym GUI w specyfikacjach Microsoft… patrz Wytyczne UX ( wyd .).

Jeśli nalegasz na jaskrawe kolory, weź przynajmniej pod uwagę potencjalnych użytkowników niewidomych na kolory, tj. Dostępność, która jest kolejnym ważnym czynnikiem dla osób niepełnosprawnych, komunikaty o błędach przyjazne dla powiększenia ekranu, ślepota kolorów, osoby cierpiące na albinos, oni może być wrażliwy na jaskrawe kolory, a także epileptyków ... którzy mogą cierpieć na określone kolory, które mogą wywołać atak ...

Pokaż im wiadomość. Należyta staranność i wszystko, ale zapisuj każdy błąd do pliku. Użytkownicy nie pamiętają, co robili ani jaki był komunikat o błędzie kilka sekund po zdarzeniu, to jak relacje naocznych świadków.

Zapewnij im dobry sposób, aby umożliwić im wysłanie e-maila lub przesłanie dziennika, aby pomóc im w rozwiązaniu problemu. Jeśli jest to aplikacja internetowa: jeszcze lepiej, możesz otrzymywać informacje o sytuacji, zanim ktokolwiek zgłosi problem.

Krótka odpowiedź: nie możesz.

Mniej krótka odpowiedź: uczyń je widocznymi, istotnymi i kontekstowymi (podkreśl, co zawiedli). Ale nadal toczysz przegraną bitwę. Ludzie nie czytają na ekranach komputerów, tylko skanują i zostali wyszkoleni w klikaniu przycisków, aż znikną okna dialogowe.

W polu błędu umieściliśmy prostą, łatwą do zapamiętania grafikę: nie jest to ikona, dość duża mapa bitowa i nic nie przypomina standardowych ikon wiadomości systemu Windows. Nikt nigdy nie zapamięta treści skrzynki wiadomości (większość nawet jej nie przeczyta, jeśli na skrzynce znajduje się przycisk „OK”, który mogą nacisnąć), ale większość ludzi pamięta obraz, który zobaczyli. Aby nasi pracownicy obsługi mogli zapytać klienta „czy widziałeś gościa pijącego kawę?” lub „czy widziałeś puste biurko?”. Przynajmniej w ten sposób z grubsza wiemy, co poszło nie tak.

W zależności od bazy użytkowników pisanie śmiesznych / niegrzecznych / osobistych komunikatów o błędach może działać świetnie.

Na przykład napisałem aplikację, która pozwoliła naszym pracownikom HR lepiej śledzić daty zatrudnienia / zwolnień pracowników. [byliśmy małą firmą, bardzo wyluzowani].

Gdy wpisali błędne daty, napisałbym:

Hej głupku, naucz się jak wejść na randkę!

EDYCJA: Oczywiście bardziej pomocnym komunikatem jest powiedzenie: „Proszę wprowadzić datę jako mm / dd / rrrr” lub być może w kodzie, aby spróbować dowiedzieć się, co wpisali, a jeśli wpisali „blahblah”, aby wyświetlić błąd. Jednak była to bardzo mała aplikacja dla osoby z HR, którą znałem osobiście. Dlatego znowu ludzie, przeczytajcie pierwszą linię tego postu: W zależności od bazy użytkowników ...

Niedawno pracowałem nad projektem Art Institute, więc komunikaty o błędach były skierowane do odbiorców, takie jak:

Większość dzieł sztuki sprzed okresu baroku była niepodpisana. Jednak jesteśmy już poza okresem baroku, więc wszystkie pola muszą zostać wypełnione.

Zasadniczo dostosuj go do swoich odbiorców, jeśli to w ogóle możliwe, i unikaj nudnych, jak wszystkie nieziemskie błędy ogólne, takie jak: „wprowadź adres e-mail” lub „wprowadź prawidłowy adres e-mail”.

Alerty / wyskakujące okienka są denerwujące, dlatego wszyscy naciskają pierwszy przycisk, który widzą.

Uczyń to mniej irytującym . Przykład: jeśli użytkownik wprowadził niepoprawną datę lub wprowadził tekst, w którym oczekiwane są liczby, NIE wyskakuj wiadomości, po prostu zaznacz pole i napisz wiadomość gdzieś wokół niego.

Utwórz niestandardowe okno wiadomości . Nigdy nie używaj domyślnego okna komunikatów systemu, na przykład okna komunikatów systemu Windows XP same się denerwują. Utwórz nowe kolorowe okno komunikatu z innym kolorem tła niż domyślny system.

Bardzo ważne: nie nalegaj . Niektóre okna komunikatów używają okna dialogowego Modal i wymagają, abyś je przeczytał, jest to bardzo denerwujące. Jeśli możesz sprawić, by okno komunikatu pojawiało się jako komunikat ostrzegawczy, byłoby lepiej, na przykład komunikaty przepełnienia stosu, które pojawiają się u góry strony, informując, ale nie denerwując.

AKTUALIZACJA
Niech wiadomość będzie zrozumiała i pomocna . Na przykład nie pisz czegoś w stylu „Nie znaleziono klawiatury, naciśnij F1, aby kontynuować”.

Najlepszy projekt interfejsu użytkownika to miejsce, w którym praktycznie nigdy nie wyświetla się komunikatu o błędzie. Oprogramowanie powinno dostosowywać się do użytkownika. Przy tego rodzaju projekcie komunikat o błędzie będzie nowatorski i przyciągnie uwagę użytkowników. Jeśli zasypujesz użytkownika bezsensownymi oknami dialogowymi, wyraźnie szkolisz go, aby ignorował Twoje wiadomości.

Moim zdaniem i doświadczeniem to zaawansowani użytkownicy nie czytają komunikatów o błędach. Znana mi nietechniczna publiczność czyta najdokładniej każdą wiadomość na ekranie, a problem w tym momencie jest taki: oni tego nie rozumieją.

Ten punkt może być przyczyną twojego doświadczenia, ponieważ w pewnym momencie przestaną je czytać, ponieważ „i tak tego nie rozumieją”, więc twoje zadanie jest łatwe:

Postaraj się, aby komunikat o błędzie był jak najłatwiejszy do zrozumienia i pozostaw część techniczną pod maską.

Na przykład przesyłam taką wiadomość:

ORA-00237: operacja migawki niedozwolona: nowo utworzony plik kontrolny Przyczyna: Podjęto próbę wywołania cfileMakeAndUseSnapshot z aktualnie zamontowanym plikiem kontrolnym, który został nowo utworzony za pomocą CREATE CONTROLFILE. Akcja: Zamontuj bieżący plik sterujący i ponów operację.

na coś takiego:

Nie można wykonać tego kroku z powodu chwilowych problemów z bazą danych. Skontaktuj się (z administratorem | działem pomocy | każdym, kto może skontaktować się z programistą lub administratorem w celu rozwiązania problemu). Przepraszam za niedogodności.

Pokaż użytkownikom, że komunikat o błędzie ma znaczenie i jest sposobem udzielenia im pomocy, a oni go przeczytają. Jeśli to tylko żargonowa biblia lub ogólna bzdura, nauczą się szybko je odrzucać.

Dowiedziałem się, że bardzo dobrą praktyką jest dołączenie okna dialogowego błędu z domyślną akcją wysyłania (np. E-mailem) szczegółowych informacji diagnostycznych, jeśli szybko odpowiesz na te e-maile, podając cenne informacje lub obejście, będą Cię wielbić.

To także świetne narzędzie do nauki. W przyszłych wersjach możesz rozwiązać znane problemy lub przynajmniej podać informacje o obejściu w miejscu. Do tego czasu użytkownicy dowiedzą się, że ta wiadomość jest spowodowana przez X, a problem może rozwiązać Y - wszystko dlatego, że ktoś im to wyjaśnił.

Oczywiście nie zadziała to w przypadku aplikacji na dużą skalę, ale działa bardzo dobrze w aplikacjach korporacyjnych z kilkuset użytkownikami oraz w środowisku zwinnym, zwinnym, często udostępniającym wczesne wersje.

EDYTOWAĆ:

Ponieważ masz szeroką bazę użytkowników, polecam dostarczanie oprogramowania, które robi to, czego użytkownicy oczekują, np. nie pokazuj im wiadomości o błędzie, jeśli numer telefonu nie jest dobrze sformatowany, sformatuj ponownie, jeśli dla nich.

Osobiście lubię oprogramowanie, które nie każe mi myśleć , a kiedy czasami nie ma nic, co Ty (programista) nie możesz zrobić, aby zinterpretować moje zamiary, dostarczaj bardzo dobrze napisane (i sprawdzone przez rzeczywistych użytkowników) wiadomości.

Powszechnie wiadomo, że ludzie nie czytają dokumentacji (czy czytałeś instrukcje, jak robiłeś, kiedy podłączyłeś sprzęt AGD?), Próbują szybko uzyskać wyniki, gdy się nie udają, musisz zwrócić ich uwagę (np. wyłączyć na chwilę przycisk domyślny) ze znaczącymi i pomocnymi informacjami. Nie przejmują się twoją awarią oprogramowania, chcą teraz uzyskać wyniki.

Spraw, by byli zabawni . (Wydawało się to istotne, biorąc pod uwagę witrynę, na której się znajdujemy :))

Na początek napisz komunikaty o błędach, które użytkownicy będą w stanie zrozumieć. „Błąd: 1023” nie jest dobrym przykładem. Myślę, że lepszym sposobem jest zapisanie błędu niż pokazanie go użytkownikowi jakimś "wymyślnym" kodem. Lub jeśli logowanie nie jest możliwe, daj użytkownikom właściwy sposób wysłania szczegółów błędu do działu pomocy technicznej.

Bądź też wystarczająco krótki i zrozumiały. Nie podawaj niektórych szczegółów technicznych. Nie pokazuj im informacji, których nie mogą wykorzystać. Jeśli to możliwe, zastosuj obejście tego błędu. Jeśli nie, podaj domyślną trasę, którą należy wybrać.

Jeśli Twoja aplikacja jest aplikacją internetową, dobrym pomysłem jest zaprojektowanie niestandardowych stron błędów. Mniej stresują użytkowników, na przykład SO. Możesz znaleźć kilka pomysłów, jak zaprojektować dobrą stronę błędów tutaj: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Chciałbym dodać jedną rzecz.

Użyj czasowników dla przycisków akcji, aby zamknąć komunikaty o błędach zamiast wykrzykników, na przykład nie używaj „Ok!” „Zamknij” itp.

Jedną z dobrych wskazówek, których się nauczyłem, jest napisanie okna dialogowego jak artykuł w gazecie. Nie w sensie wielkości, ale w sensie ważności. Pozwól mi wyjaśnić.

Najpierw powinieneś napisać najważniejsze rzeczy do przeczytania, a następnie podać bardziej szczegółowe informacje.

Innymi słowy, to nie jest dobre:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Zamiast tego zmień kolejność:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

W ten sposób użytkownik może czytać tyle, ile chce lub przeszkadza, a mimo to ma pojęcie o pytaniu.

Zobacz także odpowiedzi użytkowników Slashdot tutaj .

Jeśli nie możesz zapewnić użytkownikowi prostego obejścia, nie przejmuj się wyświetlaniem użytkownikowi komunikatu o błędzie. Po prostu nie ma sensu, ponieważ 90% użytkowników nie będzie dbać o to, co mówi.

Z drugiej strony, jeśli CAN faktycznie pokazać użytkownikowi przydatne obejście, jednym ze sposobów zmuszenia go do przeczytania jest włączenie przycisku OK po około 10 sekundach. Tak jak Firefox to robi, gdy próbujesz zainstalować nową wtyczkę.

Jeśli jest to całkowita awaria, z której nie można wdzięcznie odzyskać, poinformuj użytkownika w bardzo laickich słowach:

„ Przykro mi, że schrzaniliśmy sprawę, chcielibyśmy przesłać informacje o tej awarii, czy pozwolisz nam to zrobić? TAK / NIE ”

Ponadto staraj się, aby komunikaty o błędach nie były dłuższe niż zdanie. Kiedy ludzie (łącznie ze mną) widzą cały akapit mówiący o błędzie, mój umysł po prostu się wyłącza.

Przy tak dużej ilości mediów społecznościowych i nadmiaru informacji, ludzie zamierają, gdy widzą ścianę tekstu.

EDYTOWAĆ:

Ktoś też niedawno zasugerował użycie komiksów wraz z dowolną wiadomością, którą chcesz pokazać. Na przykład coś od Dilberta, które może być zbliżone do rodzaju błędu, jaki możesz mieć.

Z mojego doświadczenia: Państwo nie dostać użytkownicy (szczególnie te nietechniczne) czytać komunikaty o błędach. Bez względu na to, jak wyraźna i zrozumiała, pogrubiona, czerwona i migająca jest wiadomość, którą wyświetlasz, większość użytkowników po prostu kliknie wszystko, do czego nie są przyzwyczajeni, nawet jeśli jest to „Czy naprawdę chcesz usunąć wszystko?”. Widziałem, jak użytkownicy klikali ikonę „zamknij okno” zamiast „OK” lub „anuluj”, mimo że nawet nie wiedzieli, którą opcję wybrali w ten sposób ...

Jeśli naprawdę chcesz zmusić użytkowników do przeczytania tego, co wyświetlasz, proponuję odliczanie JavaScript do kliknięcia przycisku. W ten sposób użytkownik, miejmy nadzieję, wykorzysta czas oczekiwania, aby naprawdę przeczytać to, co powinien. Uważaj jednak: większość użytkowników będzie tym bardziej zirytowana :)

Ponadto podoba mi się twój pomysł na link „czytaj więcej”, chociaż wątpię, czy zwiększy to zainteresowanie użytkowników, którzy chcą po prostu pozbyć się wiadomości za wszelką cenę ...

Dla przypomnienia: są użytkownicy, którzy czytają komunikaty o błędach, ale tak bardzo się boją, że nic z nimi nie zrobią. Kiedyś miałem telefon z pomocą techniczną, w którym klient przeczytał mi komunikat o błędzie, pytając mnie, co powinien zrobić. „Cóż, jakie masz opcje?” - zapytałem. „Okno ma tylko przycisk„ OK ”.” - odpowiedział. ... mmh, trudne :)

Często wyświetlam błąd na czerwono (jeśli projekt na to pozwala).

Czerwony oznacza „alert” itp., Więc jest częściej czytany.

Cóż, odpowiadając bezpośrednio na twoje pytanie: nie pozwól swoim programistom pisać komunikatów o błędach. Jeśli zastosujesz się do tej jednej rady, zaoszczędzisz łącznie tysiące godzin niepokoju i produktywności użytkowników oraz miliony dolarów kosztów pomocy technicznej.

Jednak prawdziwym celem powinno być takie zaprojektowanie aplikacji, aby użytkownicy nie popełnili błędów. Nie pozwól im podejmować działań, które prowadzą do komunikatów z błędami i wymagają ich tworzenia kopii zapasowych. Jako prosty przykład, w formularzu internetowym, który wymaga wypełnienia wszystkich pól, zamiast wyświetlać komunikat o błędzie, gdy użytkownik kliknie przycisk Wyślij, nie włączaj przycisku Wyślij, dopóki całe pole nie będzie zawierało prawidłowej treści. Oznacza to więcej pracy z tyłu, ale zapewnia lepsze wrażenia użytkownika.

Oczywiście to trochę idealny świat. Czasami błędy programu są nieuniknione. Kiedy już się pojawią, musisz podać jasne, kompletne i przydatne informacje, a co najważniejsze, nie ujawniać systemu użytkownikowi i nie winić użytkowników za ich działania.

Dobry komunikat o błędzie powinien zawierać:

1. Na czym polega problem i dlaczego tak się stało.
2. Jak rozwiązać problem.

Jedną z najgorszych rzeczy, jakie możesz zrobić, jest po prostu przekazanie użytkownikom komunikatów o błędach systemu. Na przykład, kiedy twój program Java zgłasza wyjątek, nie przekazuj po prostu programmer-ese do interfejsu użytkownika i nie ujawniaj go użytkownikowi. Złap to i miej jasny komunikat utworzony przez programistę pomocy dla użytkownika, który możesz przedstawić swojemu użytkownikowi.

W ostatniej pracy miałem szczęście pracować z zespołem programistów, który nie pomyślałby o pisaniu własnych komunikatów o błędach. Za każdym razem, gdy znaleźli się w sytuacji, w której było to wymagane, a programu nie można było zaprojektować tak, aby tego uniknąć (często z powodu ograniczonych zasobów), zawsze przychodzili do mnie, wyjaśniali, czego potrzebują, i pozwalali mi stworzyć komunikat o błędzie, który był jasny i zgodny ze stylem firmy. Gdyby taki był domyślny sposób myślenia każdego programisty, świat komputerów byłby o wiele, znacznie lepszym miejscem.

Mniej błędów

Jeśli aplikacja regularnie rzuca na ciebie wymiocinami, stajesz się na nie odporny, a błędy stają się irytującym tłem muzycznym. Jeśli błąd jest rzadkim zdarzeniem, będzie przyciągał więcej uwagi.

Cisz wszystko, co nie jest poważną transakcją, wyrzuć wszystkie te ostrzeżenia, znajdź sposoby zrozumienia intencji użytkownika, podejmuj decyzje, gdy tylko jest to możliwe. Mam kilka aplikacji, które nadal usprawniam w ten sposób. Programiści postrzegają każdy błąd jako ważny, ale nie jest to prawdą z punktu widzenia użytkownika. Poszukaj typowych reakcji użytkowników na problem i zarejestruj to, zastosuj jako swoją odpowiedź.

Jeśli musisz zgłosić błąd: krótki, zwięzły, niski współczynnik przerażenia, bez wykrzykników. Akapity zawiodły .

Nie ma srebrnej kuli, ale aby błędy były ważne, musisz być inżynierem społecznym.

Powiedzieliśmy użytkownikom, że skontaktowano się z ich menedżerem (co było kłamstwem). Działał trochę za dobrze i musiał zostać usunięty.

Dodanie przycisku „Zaawansowane”, który udostępnia bardziej techniczne szczegóły, będzie zachętą do przeczytania go dla tej części grupy docelowej, która uważa się za techniczną

Sugeruję, abyś przekazał informację zwrotną (stwierdzając, że użytkownik popełnił błąd) natychmiast po popełnieniu błędu. (Na przykład podczas wpisywania wartości pola daty sprawdź wartość i, jeśli jest błędna, zmień wizualnie pole wejściowe).

Jeśli na stronie są błędy (bardziej interesuję się tworzeniem stron internetowych, dlatego nazywam ją „stroną”, ale można ją również nazwać „formularzem”), pokaż „podsumowanie błędów”, wyjaśniając, że były błędy i wypunktowana lista opisująca dokładnie błędy. Jeśli jednak w wiadomości jest więcej niż 5-6 słów, nie zostaną one odczytane / zrozumiane.

Co powiesz na ustawienie stanu przycisku „Kliknij tutaj, aby porozmawiać z technikiem pomocy technicznej, który pomoże Ci rozwiązać ten problem”.

Istnieje wiele witryn internetowych, które umożliwiają rozmowę z prawdziwą osobą.

Przeczytałem kandydata na najbardziej przerażające rozwiązanie na slashdocie:

Odkryliśmy, że jedynym sposobem, aby zmusić użytkowników do wzięcia odpowiedzialności za błędy, jest nałożenie na nich kary za wymuszenie zniknięcia błędu. Na początek, jeśli to możliwe, błąd nie zamknie się dla nich, chyba że wprowadzimy hasło administratora, aby je usunąć, a jeśli uruchomią się ponownie, aby się go pozbyć (Menedżer zadań jest wyłączony na wszystkich komputerach klienckich), maszyna nie otworzy aplikacja, która powodowała awarię przez 15 minut. Oczywiście wszystko to zależy od rodzaju użytkowników, z którymi masz do czynienia, ponieważ bardziej biegli technicznie użytkownicy nie zaakceptowaliby tego rodzaju systemu, ale po dosłownie LATACH, aby użytkownicy ponosili odpowiedzialność za awarie i upewnili się, że dział IT jest świadomy w celu rozwiązania problemu, zanim stanie się on zbyt trudny do zarządzania, są to jedyne kroki, które zadziałały. Teraz,

„UWAGA! UWAGA! Jeśli nie przeczytasz komunikatu o błędzie, ZGINESZ!”

Pomimo wszystkich zaleceń zawartych w zaakceptowanej odpowiedzi, moi użytkownicy nadal klikali pierwszy przycisk, jaki mogli znaleźć. Więc teraz pokazuję to:

Użytkownik musi dokonać wyboru, zanim pojawi się przycisk OK

Jeśli wybierze trzecią opcję, może kontynuować, w przeciwnym razie aplikacja zostanie zamknięta.