Bagaimana cara membuat pengguna membaca pesan kesalahan?

Jika Anda memprogram untuk audiens nonteknis, Anda mendapati diri Anda pada risiko tinggi bahwa pengguna tidak akan membaca pesan kesalahan yang dengan hati-hati Anda sebutkan dan mencerahkan, tetapi cukup klik tombol pertama yang tersedia dengan sedikit rasa frustrasi.

Jadi, saya bertanya-tanya praktik apa yang dapat Anda rekomendasikan untuk membantu pengguna benar-benar membaca pesan kesalahan Anda, alih-alih hanya mengesampingkannya. Gagasan yang bisa saya pikirkan akan jatuh di sepanjang garis:

• Pemformatan tentu saja membantu; mungkin pesan singkat dan sederhana, dengan tombol "pelajari lebih lanjut" yang mengarah ke pesan kesalahan yang lebih panjang dan lebih terperinci
• Minta semua pesan kesalahan tertaut ke beberapa bagian panduan pengguna (agak sulit untuk dicapai)
• Hanya saja, jangan mengeluarkan pesan kesalahan, cukup menolak untuk melakukan tugas (cara yang agak "Apple" menangani input pengguna)

Sunting: audiens yang ada dalam pikiran saya adalah basis pengguna yang agak luas yang tidak terlalu sering menggunakan perangkat lunak dan tidak tertawan (yaitu, tidak ada perangkat lunak internal atau komunitas sempit). Bentuk yang lebih umum dari pertanyaan ini ditanyakan pada slashdot , jadi Anda mungkin ingin memeriksa beberapa jawaban di sana.

Itu adalah pertanyaan bagus yang layak diberi +1 dari saya. Pertanyaannya meskipun sederhana, mencakup banyak aspek sifat pengguna akhir. Itu bermuara pada sejumlah faktor di sini yang akan menguntungkan Anda dan perangkat lunak itu sendiri, dan tentu saja untuk pengguna akhir.

• Jangan letakkan pesan kesalahan di bilah status - mereka tidak akan pernah membacanya meskipun telah dihancurkan dengan warna dll ... mereka akan selalu merindukannya! Tidak peduli seberapa keras Anda akan mencoba ... Pada satu tahap selama pengujian UI Win 95 sebelum diluncurkan, MS melakukan percobaan untuk membaca UI ( ed - harus dicatat bahwa pesan secara eksplisit dinyatakan dalam konteks 'Lihat di bawah kursi' ), dengan selembar uang $ 100 yang ditempelkan di bawah kursi tempat para subjek duduk ... tidak ada yang melihat pesan di status bar!
• Buat pesan singkat, jangan gunakan kata-kata menakutkan seperti 'Peringatan: sistem mengalami masalah', pengguna akhir akan menekan tombol panik dan akan bereaksi berlebihan ...
• Tidak peduli seberapa keras Anda mencoba, jangan gunakan warna untuk mengidentifikasi pesan ... secara psikologis, itu mirip dengan mengibarkan bendera merah ke banteng!
• Gunakan kata-kata yang terdengar netral untuk menyampaikan reaksi minimal dan bagaimana melanjutkan!
• Mungkin lebih baik untuk menampilkan kotak dialog yang mencantumkan pesan kesalahan netral dan menyertakan kotak centang yang menunjukkan 'Apakah Anda ingin melihat lebih banyak dari pesan kesalahan ini di masa mendatang?', Hal terakhir yang diinginkan pengguna akhir, adalah dapat berfungsi di tengah perangkat lunak yang akan dibombardir dengan pesan popup, mereka akan frustrasi dan akan dimatikan oleh aplikasi! Jika kotak centang dicentang, catat ke file ...
• Terus beri tahu pengguna akhir tentang pesan kesalahan apa yang akan ada ... yang menyiratkan ... pelatihan dan dokumentasi ... sekarang ini adalah hal yang sulit untuk dibeberkan ... Anda tidak ingin mereka berpikir bahwa akan ada menjadi 'masalah' atau 'gangguan' dan apa yang harus dilakukan jika itu terjadi ... mereka tidak boleh tahu bahwa akan ada kemungkinan kesalahan, memang rumit.
• Selalu, selalu, jangan takut untuk meminta umpan balik ketika kejadian lancar - seperti 'Ketika nomor kesalahan 1304 itu muncul, bagaimana reaksi Anda? Apa interpretasi Anda '- bonus dengan itu, pengguna akhir mungkin dapat memberi Anda penjelasan yang lebih koheren alih-alih' Kesalahan 1304, objek basis data hilang! ', Sebaliknya mereka mungkin bisa mengatakan' Saya mengklik ini jadi jadi, kemudian seseorang menarik kabel jaringan mesin secara tidak sengaja ', ini akan memberi petunjuk kepada Anda karena harus menghadapinya dan dapat memodifikasi kesalahan dengan mengatakan' Ups, Sambungan jaringan terputus '... Anda mendapatkan maksud.
• Last but not least, jika Anda ingin menargetkan audiens internasional, pertimbangkan internasionalisasi pesan kesalahan - maka itu sebabnya tetap netral, karena itu akan lebih mudah untuk diterjemahkan, menghindari sinonim, kata-kata slang, dll yang akan membuat terjemahannya tidak berarti - misalnya, Fiat Ford, perusahaan mobil itu menjual merek mereka Fiat Ford Pinto, tetapi menyadari tidak ada penjualan yang terjadi di Amerika Selatan, ternyata, Pinto adalah bahasa gaul di sana untuk 'penis kecil' dan karenanya tidak ada penjualan ...
• ( ed ) Dokumentasikan daftar pesan kesalahan yang diharapkan di bagian terpisah dari dokumentasi berjudul 'Pesan Kesalahan' atau 'Tindakan Korektif' atau serupa, yang mencantumkan nomor kesalahan dalam urutan yang benar dengan satu atau dua pernyataan tentang cara melanjutkan. ..
• ( ed ) Terima kasih kepada Victor Hurdugaci untuk masukannya, jaga pesan tetap sopan, jangan membuat pengguna akhir merasa bodoh. Ini bertentangan dengan jawaban oleh Jack Marchetti jika basis pengguna adalah internasional ...

Sunting: Ucapan terima kasih khusus kepada gnibbler yang menyebutkan poin penting lainnya juga!

• Izinkan pengguna akhir untuk dapat memilih / menyalin pesan kesalahan sehingga mereka bisa jika mereka mau, untuk mengirim email ke tim dukungan bantuan atau tim pengembangan.

Sunting # 2: Badaku! Ups, terima kasih kepada DanM yang menyebutkan tentang mobil itu, nama saya campur aduk, itu Ford Pinto ... yang buruk ...

Sunting # 3: Telah disorot oleh ed untuk menunjukkan tambahan atau tambahan dan dikreditkan ke orang lain untuk masukan mereka ...

Sunting # 4: Menanggapi komentar Ken - inilah pendapat saya ... Tidak, bukan, gunakan warna Windows standar netral ... jangan gunakan warna mencolok! Tetap berpegang pada warna abu-abu normal dengan teks hitam, yang merupakan pedoman GUI standar normal dalam spesifikasi Microsoft..lihat Panduan UX ( ed ).

Jika Anda bersikeras pada warna mencolok, setidaknya, pertimbangkan potensi pengguna buta warna yaitu aksesibilitas yang merupakan faktor penting bagi mereka yang memiliki cacat, pesan kesalahan pembesaran ramah layar, buta warna, mereka yang menderita albino, mereka mungkin sensitif terhadap warna mencolok, dan juga epilepsi ... yang mungkin menderita warna tertentu yang dapat memicu kejang ...

Tunjukkan pada mereka pesannya. Karena ketekunan dan semua, tetapi catat setiap kesalahan ke file. Pengguna tidak dapat mengingat apa yang mereka lakukan atau apa pesan kesalahannya hanya beberapa detik setelah acara, itu seperti akun saksi mata pelaku perpatrator.

Berikan cara yang baik untuk memungkinkan mereka mengirim email atau mengunggah log kepada Anda sehingga Anda dapat membantu mereka mendamaikan masalah. Jika itu adalah aplikasi web: lebih baik lagi, Anda dapat menerima informasi tentang situasi di depan siapa pun yang melaporkan masalah.

Jawaban singkat: Anda tidak bisa.

Jawaban yang lebih singkat: Jadikan mereka terlihat, relevan, dan kontekstual (sorot apa yang mereka buat kacau). Tapi tetap saja, Anda kalah dalam pertempuran. Orang tidak membaca di layar komputer, mereka memindai, dan mereka telah dilatih untuk mengklik tombol sampai kotak dialog hilang.

Kami menempatkan grafik mudah diingat sederhana di kotak kesalahan: bukan ikon, bitmap yang cukup besar, dan tidak seperti ikon pesan Windows standar. Tidak ada yang bisa mengingat kata-kata dari kotak pesan (kebanyakan bahkan tidak akan membacanya jika kotak memiliki tombol "OK" yang dapat mereka tekan), tetapi kebanyakan orang TIDAK ingat gambar yang mereka lihat. Jadi orang-orang pendukung kami dapat bertanya kepada pelanggan "apakah Anda melihat pria peminum kopi?" atau "apakah Anda melihat meja kosong?". Setidaknya dengan begitu kita tahu kira-kira apa yang salah.

Tergantung pada basis pengguna Anda, menulis pesan kesalahan lucu / kasar / pribadi dapat bekerja dengan baik.

Sebagai contoh, saya menulis sebuah aplikasi yang memungkinkan orang-orang SDM kami untuk melacak tanggal perekrutan / pemecatan karyawan dengan lebih baik. [kami adalah perusahaan kecil, sangat santai].

Ketika mereka memasukkan tanggal yang salah saya akan menulis:

Hei bodoh, pelajari cara memasukkan tanggal!

EDIT: Tentu saja pesan yang lebih bermanfaat adalah untuk mengatakan: "Silakan masukkan tanggal sebagai mm / hh / tttt" atau mungkin dalam kode untuk mencoba dan mencari tahu apa yang mereka masukkan dan jika mereka memasukkan "blahblah" untuk menunjukkan kesalahan. Namun, ini adalah aplikasi yang sangat kecil untuk orang SDM yang saya kenal secara pribadi. Karenanya sekali lagi orang-orang, baca baris pertama posting ini: Tergantung pada basis pengguna Anda ...

Baru-baru ini saya mengerjakan proyek Institut Seni, jadi pesan-pesan kesalahannya ditujukan kepada audiens, seperti:

Kebanyakan karya seni sebelum periode Barok tidak ditandatangani. Namun, kami berada di luar periode Barok sekarang, sehingga semua bidang harus diselesaikan.

Pada dasarnya persiapkan untuk audiens Anda jika memungkinkan, dan hindari membosankan karena semua kesalahan umum yang tidak wajar seperti: "silakan masukkan email" atau "silakan masukkan email yang valid".

Peringatan / munculan mengganggu, itu sebabnya semua orang menekan tombol pertama yang mereka lihat.

Buat tidak terlalu mengganggu . Contoh: jika pengguna memasukkan tanggal yang salah, atau memasukkan teks di mana angka diharapkan, maka JANGAN popup pesan, cukup sorot bidang dan tulis pesan di suatu tempat di sekitarnya.

Buat kotak pesan khusus . Jangan pernah menggunakan kotak pesan default sistem, misalnya kotak pesan Windows XP mengganggu dirinya sendiri. Buat kotak pesan berwarna baru, dengan warna latar berbeda dari standar sistem.

Sangat Penting: jangan ngotot . Beberapa kotak pesan menggunakan dialog Modal dan bersikeras membuat Anda membacanya, ini sangat menjengkelkan. Jika Anda dapat membuat kotak pesan muncul sebagai pesan peringatan, akan lebih baik, misalnya, pesan Stack Overflow yang muncul tepat di bagian atas halaman, memberi informasi tetapi tidak mengganggu.

PEMBARUAN
Jadikan pesan itu bermakna dan bermanfaat . Misalnya, jangan menulis sesuatu seperti, "Tidak ada Papan Ketik yang ditemukan, tekan F1 untuk melanjutkan."

Desain UI terbaik adalah tempat Anda hampir tidak pernah menampilkan pesan kesalahan. Perangkat lunak harus beradaptasi dengan pengguna. Dengan desain semacam itu, pesan kesalahan akan menjadi novel dan akan menarik perhatian pengguna. Jika Anda membumbui pengguna dengan dialog tidak masuk akal seperti itu, Anda secara eksplisit melatih mereka untuk mengabaikan pesan Anda.

Menurut pendapat dan pengalaman saya, itu adalah pengguna yang kuat, yang tidak membaca pesan kesalahan. Audiens nonteknis yang saya kenal membaca setiap pesan di layar dengan sangat hati-hati dan masalah pada titik ini kebanyakan adalah: Mereka tidak memahaminya.

Poin ini mungkin menjadi penyebab pengalaman Anda, karena pada titik tertentu mereka akan berhenti membacanya, karena "mereka tidak memahaminya", jadi tugas Anda mudah:

Buat pesan kesalahan semudah mungkin dimengerti dan simpan bagian teknis di bawah tenda.

Misalnya saya mentransfer pesan seperti ini:

ORA-00237: operasi snapshot dianulir: file kontrol yang baru dibuat Penyebab: Upaya untuk memanggil cfileMakeAndUseSnapshot dengan file kontrol yang terpasang saat ini yang baru dibuat dengan CREATE CONTROLFILE. Tindakan: Pasang file kontrol saat ini dan coba lagi operasi.

untuk sesuatu seperti:

Langkah ini tidak dapat diproses karena masalah sesaat dengan database. Silakan hubungi (admin Anda | helpdesk | siapa pun yang dapat menghubungi pengembang atau admin untuk menyelesaikan masalah). Maaf untuk ketidaknyamanannya.

Tunjukkan kepada pengguna bahwa pesan kesalahan memiliki arti , dan itu adalah cara untuk memberikan bantuan kepada mereka dan mereka akan membacanya. Jika itu hanya pesan jargon-bable atau generik, mereka akan belajar untuk mengabaikannya dengan cepat.

Saya telah belajar bahwa ini adalah praktik yang sangat baik untuk memasukkan dialog kesalahan dengan tindakan default untuk mengirim (misalnya melalui email) info diagnostik terperinci, jika Anda dengan cepat menanggapi email-email itu dengan informasi atau solusi yang berharga, mereka akan memujamu.

Ini juga merupakan alat belajar yang hebat. Dalam versi yang akan datang Anda dapat memecahkan masalah yang diketahui atau setidaknya memberikan info penyelesaian masalah di tempat. Sampai saat itu pengguna akan belajar bahwa pesan ini disebabkan oleh X dan masalahnya dapat diselesaikan oleh Y - semua karena seseorang memang menjelaskannya kepada mereka.

Tentu saja ini tidak akan bekerja pada aplikasi skala besar, tetapi bekerja dengan sangat baik dalam aplikasi perusahaan dengan beberapa ratus pengguna, dan dengan lincah, rilis rilis awal sering, lingkungan.

EDIT:

Karena Anda memiliki basis pengguna yang luas, saya sarankan untuk menyediakan perangkat lunak yang melakukan apa yang diharapkan / dilakukan oleh pengguna, misalnya. jangan tampilkan pesan eroror kepada mereka jika nomor telepon tidak diformat dengan baik, format ulang jika untuk mereka.

Saya pribadi menyukai perangkat lunak yang tidak membuat saya berpikir , dan ketika sesekali tidak ada yang dapat Anda (pengembang) lakukan untuk menginterpretasikan niat saya, memberikan pesan yang ditulis dengan sangat baik (dan ditinjau oleh pengguna sebenarnya).

Sudah menjadi rahasia umum bahwa orang tidak membaca dokumentasi (apakah Anda membaca instruksi back-to-back lakukan ketika Anda terhubung ke alat rumah tangga?), Mereka mencoba cara untuk mendapatkan hasil dengan cepat, ketika gagal Anda harus menarik perhatian mereka (mis. nonaktifkan tombol default untuk sementara waktu) dengan info yang bermakna dan bermanfaat . Mereka tidak peduli dengan kegagalan perangkat lunak Anda, mereka ingin mendapatkan hasil, sekarang.

Buat mereka menyenangkan . (Tampaknya relevan, mengingat situs kami berada di :))

Untuk memulai, tulis pesan kesalahan yang benar-benar dapat dimengerti pengguna. "Kesalahan: 1023" bukan contoh yang baik. Saya pikir cara yang lebih baik adalah mencatat kesalahan, daripada menunjukkannya kepada pengguna dengan beberapa kode "mewah". Atau jika logging tidak memungkinkan, berikan pengguna cara yang tepat untuk mengirim detail kesalahan ke departemen dukungan.

Juga, singkat dan cukup jelas. Jangan sertakan beberapa detail teknis. Jangan perlihatkan kepada mereka informasi yang tidak dapat mereka gunakan. Jika mungkin berikan solusi untuk kesalahan tersebut. Jika tidak memberikan rute default, itu harus diambil.

Jika aplikasi Anda adalah aplikasi web, merancang halaman kesalahan khusus adalah ide yang bagus. Mereka kurang menekankan pengguna, misalnya SO. Anda bisa mendapatkan beberapa ide bagaimana merancang halaman kesalahan yang bagus di sini: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Satu hal yang ingin saya tambahkan.

Gunakan kata kerja untuk tombol tindakan Anda untuk menutup pesan kesalahan Anda daripada tanda seru, misalnya jangan gunakan "Oke!" "Tutup" dll.

Satu tip bagus yang saya pelajari adalah Anda harus menulis kotak dialog seperti artikel surat kabar. Bukan dalam arti ukuran, tetapi dalam arti penting. Biarkan saya jelaskan.

Anda harus menulis hal-hal yang paling penting untuk dibaca, pertama, dan berikan informasi yang lebih rinci kedua.

Dengan kata lain, ini tidak baik:

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?

Alih-alih, ubah urutan:

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.

Dengan cara ini, pengguna dapat membaca sebanyak yang dia inginkan, atau mengganggu, dan masih memiliki ide tentang apa yang ditanyakan.

Lihat juga respons pengguna Slashdot di sini .

Kecuali Anda dapat memberikan pengguna beberapa solusi sederhana, jangan repot-repot menunjukkan kepada pengguna pesan kesalahan sama sekali. Tidak ada gunanya, karena 90% pengguna tidak akan peduli apa yang dikatakannya.

Di sisi lain Jika Anda BISA benar-benar menunjukkan kepada pengguna solusi yang bermanfaat, maka salah satu cara untuk memaksa mereka membacanya adalah membuat tombol OK menjadi diaktifkan setelah sekitar 10 detik. Semacam bagaimana Firefox melakukannya kapan pun Anda mencoba memasang plug-in baru.

Jika ini adalah kerusakan total yang tidak dapat Anda pulihkan dengan anggun, beri tahu pengguna dengan istilah yang sangat awam dengan mengatakan:

" Maaf kami mengacau, kami ingin mengirim beberapa informasi tentang kecelakaan ini, apakah Anda mengizinkan kami melakukannya? YA / TIDAK "

Selain itu, cobalah untuk tidak membuat pesan kesalahan Anda lebih lama dari kalimat. Ketika orang (termasuk saya) melihat seluruh paragraf berbicara tentang kesalahan, pikiran saya mati begitu saja.

Dengan begitu banyak media sosial dan informasi yang berlebihan, pikiran orang membeku ketika mereka melihat dinding teks.

EDIT:

Seseorang juga baru-baru ini menyarankan untuk menggunakan komik bersama dengan pesan apa pun yang ingin Anda tampilkan. Seperti sesuatu dari Dilbert yang mungkin dekat dengan jenis kesalahan yang mungkin Anda miliki.

Dari pengalaman saya: Anda tidak mendapatkan pengguna (terutama yang non-teknis) untuk membaca pesan kesalahan. Tidak peduli seberapa jelas dan dapat dimengerti, tebal, merah, dan mem-flash pesan, yang Anda tampilkan, sebagian besar pengguna hanya akan mengklik sesuatu yang tidak biasa mereka gunakan, bahkan jika itu "Apakah Anda benar-benar ingin menghapus semuanya?". Saya telah melihat pengguna mengklik "window close" -icon alih-alih "OK" atau "membatalkan" meskipun mereka bahkan tidak tahu opsi mana yang mereka pilih dengan melakukannya ...

Jika Anda benar-benar perlu memaksa pengguna untuk membaca apa yang Anda tampilkan, saya akan menyarankan JavaScript-Countdown sampai sebuah tombol dapat diklik. Dengan begitu pengguna diharapkan akan menggunakan waktu tunggu untuk benar-benar membaca apa yang seharusnya. Berhati-hatilah: sebagian besar pengguna akan lebih jengkel karenanya :)

Saya juga lebih suka ide Anda tentang "baca lebih lanjut" -tautan, meskipun saya ragu itu akan membuat pengguna lebih tertarik yang hanya ingin menyingkirkan pesan dengan segala cara ...

Sebagai catatan: ada pengguna yang DO membaca pesan kesalahan tetapi sangat takut mereka tidak akan melakukan apa-apa dengannya. Saya pernah memiliki panggilan dukungan di mana pelanggan akan membacakan pesan kesalahan kepada saya, bertanya kepada saya, apa yang harus dia lakukan. "Yah, apa pilihanmu?", Tanyaku. "Jendela itu hanya memiliki tombol 'OK'.", Jawabnya. ... mmh, susah :)

Saya sering menampilkan kesalahan dengan warna merah (ketika desain memungkinkannya).

Merah berarti "waspada", dll. Jadi lebih sering dibaca.

Nah, untuk menjawab pertanyaan Anda secara langsung: Jangan programer Anda menulis pesan kesalahan Anda. Jika Anda mengikuti saran ini, Anda akan menghemat, secara kumulatif, ribuan jam kecemasan pengguna dan produktivitas dan jutaan dolar dalam biaya dukungan teknis.

Namun, tujuan sebenarnya adalah mendesain aplikasi Anda sehingga pengguna tidak dapat membuat kesalahan. Jangan biarkan mereka mengambil tindakan yang mengarah pada kesalahan pijat dan meminta mereka untuk membuat cadangan. Sebagai contoh sederhana, dalam formulir web yang mengharuskan semua bidangnya diisi, alih-alih memunculkan pesan kesalahan saat pengguna mengklik tombol Kirim, jangan aktifkan tombol Kirim sampai semua bidang berisi konten yang valid. Ini berarti lebih banyak pekerjaan di sisi belakang, tetapi menghasilkan pengalaman pengguna yang lebih baik.

Tentu saja, itu adalah dunia yang ideal. Terkadang, kesalahan program tidak dapat dihindari. Ketika hal itu terjadi, Anda perlu memberikan informasi yang jelas, lengkap, dan bermanfaat, dan yang paling penting, jangan memaparkan sistem kepada pengguna dan jangan salahkan pengguna atas tindakan mereka.

Pesan kesalahan yang baik harus berisi:

1. Apa masalahnya dan mengapa itu terjadi.
2. Bagaimana mengatasi masalah tersebut.

Salah satu hal terburuk yang dapat Anda lakukan adalah hanya mengirimkan pesan kesalahan sistem kepada pengguna. Misalnya, ketika program Java Anda melempar pengecualian, jangan hanya meneruskan programmer-ese ke UI dan memaparkannya kepada pengguna. Tangkap, dan pesan yang jelas dibuat oleh pengembang bantuan pengguna Anda yang dapat Anda presentasikan kepada pengguna Anda.

Saya cukup beruntung, pada pekerjaan terakhir saya, untuk bekerja dengan tim programmer yang tidak akan berpikir untuk menulis pesan kesalahan mereka sendiri. Setiap kali mereka menemukan diri mereka dalam situasi di mana seseorang diperlukan dan program tidak dapat dirancang untuk menghindarinya (seringkali karena sumber daya yang terbatas), mereka selalu mendatangi saya, menjelaskan apa yang mereka butuhkan, dan biarkan saya membuat pesan kesalahan yang jelas dan mengikuti gaya perusahaan. Jika itu adalah pola pikir default setiap programmer, dunia komputasi akan menjadi tempat yang jauh, jauh lebih baik.

Lebih sedikit kesalahan

Jika aplikasi melempar muntah pada Anda secara teratur, Anda menjadi kebal terhadapnya, dan kesalahan menjadi muzak latar menjengkelkan. Jika kesalahan adalah peristiwa langka, itu akan mendapat lebih banyak perhatian.

Cepat apa pun yang bukan masalah besar, buang semua peringatan itu, temukan cara untuk memahami maksud pengguna, ambil keputusan jika memungkinkan. Saya memiliki beberapa aplikasi yang terus saya rampingkan dengan cara ini. Pengembang melihat setiap kesalahan sebagai hal yang penting, tetapi ini tidak benar dari sudut pandang pengguna. Cari respons umum pengguna terhadap masalah dan tangkap itu, sebarkan itu sebagai respons Anda .

Jika Anda perlu meningkatkan kesalahan: singkat, singkat, faktor teror rendah, tidak ada tanda seru. Paragraf gagal .

Tidak ada peluru perak, tetapi Anda perlu merekayasa sosial untuk membuat kesalahan penting.

Kami memberi tahu pengguna bahwa manajer mereka telah dihubungi (yang bohong). Itu bekerja sedikit terlalu baik dan harus dipindahkan.

Menambahkan tombol "Advanced" yang memungkinkan beberapa detail teknis lebih lanjut akan memberikan insentif untuk membacanya bagi bagian dari audiens target yang menganggap dirinya sebagai teknis

Saya menyarankan agar Anda memberikan umpan balik (menyatakan bahwa pengguna melakukan kesalahan) segera setelah kesalahan terjadi. (Misalnya, saat memasukkan nilai bidang tanggal, periksa nilainya dan, jika salah, buat bidang input berbeda secara visual).

Jika ada kesalahan pada halaman (saya lebih ke pengembangan web, maka saya menyebutnya sebagai "halaman", tetapi bisa juga disebut "formulir"), tampilkan "ringkasan kesalahan", menjelaskan bahwa ada adalah kesalahan dan daftar poin tentang apa yang sebenarnya terjadi kesalahan. Namun, jika ada lebih dari 5-6 kata per pesan, itu tidak akan dibaca / dipahami.

Bagaimana dengan menyatakan tombol "Klik di sini untuk berbicara dengan teknisi pendukung yang akan membantu Anda dengan masalah ini."

Ada banyak situs web yang menyediakan opsi untuk berbicara dengan orang sungguhan.

Saya membaca kandidat untuk solusi paling mengerikan di slashdot:

Kami telah menemukan bahwa satu-satunya cara untuk membuat pengguna bertanggung jawab atas kesalahan adalah dengan memberi mereka penalti karena memaksa kesalahan itu hilang. Sebagai permulaan, jika memungkinkan, kesalahan tidak akan benar-benar menutup untuk mereka kecuali kita memasukkan kata sandi admin untuk membuatnya hilang, dan jika mereka reboot untuk menyingkirkannya (Task Manager dinonaktifkan pada semua PC klien) mesin tidak akan membuka aplikasi yang macet selama 15 menit. Tentu saja, ini semua tergantung pada jenis pengguna yang Anda hadapi, karena pengguna yang lebih mahir secara teknis tidak akan menerima sistem semacam ini, tetapi setelah mencoba secara harfiah TAHUN untuk membuat pengguna bertanggung jawab atas kerusakan dan memastikan departemen TI mengetahui mereka untuk memperbaiki masalah sebelum terlalu sulit untuk dikelola, ini adalah satu-satunya langkah yang berhasil. Sekarang,

"PERHATIAN! PERHATIAN! Jika Anda tidak membaca pesan kesalahan Anda AKAN MATI!"

Terlepas dari semua rekomendasi dalam jawaban yang diterima, pengguna saya terus mengklik tombol pertama yang bisa mereka temukan. Jadi sekarang saya tunjukkan ini:

Pengguna harus membuat pilihan sebelum tombol OK muncul

Jika ia memilih opsi ke-3, ia dapat melanjutkan, jika tidak, aplikasi akan berhenti.