Pesan Kesalahan di Windows 7

Catatan

Panduan desain ini dibuat untuk Windows 7 dan belum diperbarui untuk versi Windows yang lebih baru. Sebagian besar panduan masih berlaku pada prinsipnya, tetapi presentasi dan contoh tidak mencerminkan panduan desain kita saat ini.

Pesan kesalahan di Windows 7 memperingatkan pengguna tentang masalah yang telah terjadi. Sebaliknya, pesan peringatan memperingatkan pengguna tentang kondisi yang dapat menyebabkan masalah di masa mendatang. Pesan kesalahan dapat disajikan menggunakan kotak dialog modal, pesan di tempat, pemberitahuan, atau balon.

Pesan kesalahan modal umum.

Pesan kesalahan yang efektif memberi tahu pengguna bahwa masalah terjadi, menjelaskan mengapa itu terjadi, dan memberikan solusi sehingga pengguna dapat memperbaiki masalah. Pengguna harus melakukan tindakan atau mengubah perilaku mereka sebagai akibat dari pesan kesalahan.

Pesan kesalahan yang ditulis dengan baik dan bermanfaat sangat penting untuk pengalaman pengguna yang berkualitas. Pesan kesalahan yang ditulis dengan buruk mengakibatkan kepuasan produk yang rendah, dan merupakan penyebab utama biaya dukungan teknis yang dapat dihindari. Pesan kesalahan yang tidak perlu memutus alur pengguna.

Catatan: Panduan yang terkait dengan kotak dialog, pesan peringatan, konfirmasi, ikon standar, pemberitahuan, dan tata letak disajikan dalam artikel terpisah.

Apakah ini antarmuka pengguna yang tepat?

Untuk memutuskan, pertimbangkan pertanyaan-pertanyaan ini:

• Apakah antarmuka pengguna (UI) menyajikan masalah yang telah terjadi? Jika tidak, pesan bukan kesalahan. Jika pengguna diberi tahu tentang kondisi yang dapat menyebabkan masalah di masa mendatang, gunakan pesan peringatan.
• Dapatkah masalah dicegah tanpa menyebabkan kebingungan? Jika demikian, cegah masalah sebagai gantinya. Misalnya, gunakan kontrol yang dibatasi ke nilai yang valid alih-alih menggunakan kontrol yang tidak dibatasi yang mungkin memerlukan pesan kesalahan. Selain itu, nonaktifkan kontrol saat mengklik akan mengakibatkan kesalahan, selama sudah jelas mengapa kontrol dinonaktifkan.
• Dapatkah masalah dikoreksi secara otomatis? Jika demikian, tangani masalah dan tekan pesan kesalahan.
• Apakah pengguna cenderung melakukan tindakan atau mengubah perilaku mereka sebagai hasil dari pesan? Jika tidak, kondisi tidak membenarkan mengganggu pengguna sehingga lebih baik menekan kesalahan.
• Apakah masalahnya relevan ketika pengguna secara aktif menggunakan program lain? Jika demikian, pertimbangkan untuk menampilkan masalah menggunakan ikon area pemberitahuan.
• Apakah masalahnya tidak terkait dengan aktivitas pengguna saat ini, apakah tidak memerlukan tindakan pengguna segera, dan dapatkah pengguna mengabaikannya secara bebas? Jika demikian, gunakan pemberitahuan kegagalan tindakan sebagai gantinya.
• Apakah masalah terkait dengan status tugas latar belakang dalam jendela utama? Jika demikian, pertimbangkan untuk menunjukkan masalah menggunakan bilah status.
• Apakah pengguna target utama profesional TI? Jika demikian, pertimbangkan untuk menggunakan mekanisme umpan balik alternatif, seperti entri file log atau pemberitahuan email. Profesional TI sangat lebih suka file log untuk informasi non-kritis.

Konsep desain

Karakteristik pesan kesalahan yang buruk

Seharusnya tidak mengherankan bahwa ada banyak pesan kesalahan yang mengganggu, tidak membantu, dan ditulis dengan buruk. Dan karena pesan kesalahan sering disajikan menggunakan dialog modal, mereka mengganggu aktivitas pengguna saat ini dan permintaan untuk diakui sebelum memungkinkan pengguna untuk melanjutkan.

Bagian dari masalahnya adalah ada begitu banyak cara untuk melakukannya dengan salah. Pertimbangkan contoh-contoh ini dari Error Message Hall of Shame:

Pesan kesalahan yang tidak perlu

Salah:

Contoh dari Windows XP ini mungkin pesan kesalahan terburuk yang pernah ada. Ini menunjukkan bahwa program tidak dapat diluncurkan karena Windows itu sendiri sedang dalam proses mematikan. Tidak ada yang dapat dilakukan pengguna tentang ini atau bahkan ingin melakukan hal ini (pengguna memilih untuk mematikan Windows, setelah semua). Dan dengan menampilkan pesan kesalahan ini, Windows mencegah dirinya dimatikan!

Masalahnya: Pesan kesalahan itu sendiri adalah masalahnya. Selain mengabaikan pesan kesalahan, tidak ada yang dapat dilakukan pengguna.

Penyebab: Melaporkan semua kasus kesalahan, terlepas dari tujuan atau sudut pandang pengguna.

Alternatif yang direkomendasikan: Jangan melaporkan kesalahan yang tidak dipedulikan pengguna.

Pesan kesalahan "Berhasil"

Salah:

Pesan kesalahan ini dihasilkan dari pengguna yang memilih untuk tidak segera memulai ulang Windows setelah penghapusan program. Penghapusan program berhasil dari sudut pandang pengguna.

Masalahnya: Tidak ada kesalahan dari sudut pandang pengguna. Selain mengabaikan pesan kesalahan, tidak ada yang dapat dilakukan pengguna.

Penyebab: Tugas berhasil diselesaikan dari sudut pandang pengguna, tetapi gagal dari sudut pandang program penghapusan instalasi.

Alternatif yang direkomendasikan: Jangan melaporkan kesalahan untuk kondisi yang dianggap dapat diterima pengguna.

Pesan kesalahan yang sepenuhnya tidak berguna

Salah:

Pengguna mengetahui bahwa ada kesalahan, tetapi tidak tahu apa kesalahannya atau apa yang harus dilakukan tentang hal itu. Dan tidak, tidak apa-apa!

Masalahnya: Pesan kesalahan tidak memberikan masalah tertentu dan tidak ada yang dapat dilakukan pengguna tentang hal itu.

Penyebab: Kemungkinan besar, program ini memiliki penanganan kesalahan yang buruk.

Alternatif yang direkomendasikan: Rancang penanganan kesalahan yang baik ke dalam program.

Pesan kesalahan yang tidak dapat dipahami

Salah:

Dalam contoh ini, pernyataan masalah jelas, tetapi penjelasan tambahan benar-benar memalingkan.

Masalahnya: Pernyataan atau solusi masalah tidak dapat dimengerti.

Penyebab: Menjelaskan masalah dari sudut pandang kode alih-alih tampilan pengguna.

Alternatif yang direkomendasikan: Tulis teks pesan kesalahan yang dapat dipahami pengguna target Anda dengan mudah. Berikan solusi yang benar-benar dapat dilakukan pengguna. Desain pengalaman pesan kesalahan program Anda tidak memiliki programmer yang menyusun pesan kesalahan di tempat.

Pesan kesalahan yang overcommunicate

Salah:

Dalam contoh ini, pesan kesalahan rupanya mencoba menjelaskan setiap langkah pemecahan masalah.

Masalahnya: Terlalu banyak informasi.

Penyebab: Memberikan terlalu banyak detail atau mencoba menjelaskan proses pemecahan masalah yang rumit dalam pesan kesalahan.

Alternatif yang direkomendasikan: Hindari detail yang tidak perlu. Selain itu, hindari pemecah masalah. Jika pemecah masalah diperlukan, fokuslah pada solusi yang paling mungkin dan jelaskan sisanya dengan menautkan ke topik yang sesuai di Bantuan.

Pesan kesalahan yang tidak perlu

Salah:

Ketidakmampuan program untuk menemukan objek hampir tidak terdengar bencana. Dan dengan asumsi itu bencana, mengapa ok responsnya?

Masalahnya: Nada program ini tidak perlu keras atau dramatis.

Penyebab: Masalahnya adalah karena bug yang muncul bencana dari sudut pandang program.

Alternatif yang direkomendasikan: Pilih bahasa dengan cermat berdasarkan sudut pandang pengguna.

Pesan kesalahan yang menyalahkan pengguna

Salah:

Mengapa membuat pengguna merasa seperti penjahat?

Masalahnya: Pesan kesalahan diungkapkan dengan cara yang menuduh pengguna melakukan kesalahan.

Penyebab: Pembuatan frasa tidak sensitif yang berfokus pada perilaku pengguna alih-alih masalah.

Alternatif yang direkomendasikan: Fokus pada masalah, bukan tindakan pengguna yang menyebabkan masalah, menggunakan suara pasif seperlunya.

Pesan kesalahan bodoh

Salah:

Dalam contoh ini, pernyataan masalah cukup ironis dan tidak ada solusi yang disediakan.

Masalahnya: Pernyataan pesan kesalahan yang konyol atau non-pemisah.

Penyebab: Membuat pesan kesalahan tanpa memperhatikan konteksnya.

Alternatif yang direkomendasikan: Buat pesan kesalahan Anda dibuat dan ditinjau oleh penulis. Pertimbangkan konteks dan status pikiran pengguna saat meninjau kesalahan.

Pesan kesalahan programmer

Salah:

Dalam contoh ini, pesan kesalahan menunjukkan bahwa ada bug dalam program. Pesan kesalahan ini hanya berarti untuk programmer.

Masalahnya: Pesan yang dimaksudkan untuk membantu pengembang program menemukan bug yang tersisa dalam versi rilis program. Pesan kesalahan ini tidak memiliki arti atau nilai bagi pengguna.

Penyebab: Programmer yang menggunakan UI normal untuk membuat pesan untuk diri mereka sendiri.

Alternatif yang direkomendasikan: Pengembang harus mengkompilasi semua pesan tersebut secara kondisional sehingga secara otomatis dihapus dari versi rilis produk. Jangan buang-buang waktu untuk mencoba membuat kesalahan seperti ini dapat dipahami oleh pengguna karena satu-satunya audiens mereka adalah programmer.

Pesan kesalahan yang disajikan dengan buruk

Salah:

Contoh ini memiliki banyak kesalahan presentasi umum.

Masalahnya: Mendapatkan semua detail yang salah dalam presentasi pesan kesalahan.

Penyebab: Tidak mengetahui dan menerapkan pedoman pesan kesalahan. Tidak menggunakan penulis dan editor untuk membuat dan meninjau pesan kesalahan.

Sifat penanganan kesalahan sih sehingga banyak dari kesalahan ini sangat mudah dibuat. Sangat mengganggu untuk menyadari bahwa sebagian besar pesan kesalahan bisa menjadi nominasi untuk Hall of Shame.

Karakteristik pesan kesalahan yang baik

Berbeda dengan contoh buruk sebelumnya, pesan kesalahan yang baik memiliki:

• Sebuah masalah. Menyatakan bahwa terjadi masalah.
• Sebuah penyebab. Menjelaskan mengapa masalah terjadi.
• Sebuah solusi. Menyediakan solusi sehingga pengguna dapat memperbaiki masalah.

Selain itu, pesan kesalahan yang baik disajikan dengan cara yang:

• Relevan. Pesan menyajikan masalah yang menjadi perhatian pengguna.
• Ditindaklanjuti. Pengguna harus melakukan tindakan atau mengubah perilaku mereka sebagai hasil dari pesan.
• Berpusat pada pengguna. Pesan menjelaskan masalah dalam hal tindakan atau tujuan pengguna target, bukan dalam hal apa kode tidak bahagia.
• Singkat. Pesan sesingkat mungkin, tetapi tidak lebih pendek.
• Jelas. Pesan menggunakan bahasa polos sehingga pengguna target dapat dengan mudah memahami masalah dan solusi.
• Tertentu. Pesan menjelaskan masalah menggunakan bahasa tertentu, memberikan nama, lokasi, dan nilai tertentu dari objek yang terlibat.
• Sopan. Pengguna tidak boleh disalahkan atau dibuat merasa bodoh.
• Jarang. Jarang ditampilkan. Pesan kesalahan yang sering ditampilkan adalah tanda desain yang buruk.

Dengan merancang pengalaman penanganan kesalahan Anda untuk memiliki karakteristik ini, Anda dapat menyimpan pesan kesalahan program Anda dari Error Message Hall of Shame.

Menghindari pesan kesalahan yang tidak perlu

Seringkali pesan kesalahan terbaik adalah tidak ada pesan kesalahan. Banyak kesalahan dapat dihindari melalui desain yang lebih baik, dan seringkali ada alternatif yang lebih baik untuk pesan kesalahan. Biasanya lebih baik mencegah kesalahan daripada melaporkannya.

Pesan kesalahan yang paling jelas untuk dihindari adalah pesan yang tidak dapat ditindakkan. Jika pengguna cenderung menutup pesan tanpa melakukan atau mengubah apa pun, hilangkan pesan kesalahan.

Beberapa pesan kesalahan dapat dihilangkan karena tidak bermasalah dari sudut pandang pengguna. Misalnya, pengguna mencoba menghapus file yang sudah dalam proses dihapus. Meskipun ini mungkin kasus yang tidak terduga dari sudut pandang kode, pengguna tidak menganggap ini sebagai kesalahan karena hasil yang mereka inginkan tercapai.

Salah:

Pesan kesalahan ini harus dihilangkan karena tindakan berhasil dari sudut pandang pengguna.

Untuk contoh lain, misalkan pengguna secara eksplisit membatalkan tugas. Untuk sudut pandang pengguna, kondisi berikut ini bukan kesalahan.

Salah:

Pesan kesalahan ini juga harus dihilangkan karena tindakan berhasil dari sudut pandang pengguna.

Terkadang pesan kesalahan dapat dihilangkan dengan berfokus pada tujuan pengguna alih-alih teknologi. Dalam melakukannya, pertimbangkan kembali apa kesalahan sebenarnya. Apakah masalah dengan tujuan pengguna, atau dengan kemampuan program Anda untuk memenuhinya? Jika tindakan pengguna masuk akal di dunia nyata, seharusnya masuk akal dalam perangkat lunak juga.

Misalnya, dalam program e-niaga, pengguna mencoba menemukan produk menggunakan pencarian, tetapi kueri pencarian harfiah tidak memiliki kecocokan dan produk yang diinginkan kehabisan stok. Secara teknis, ini adalah kesalahan, tetapi alih-alih memberikan pesan kesalahan, program dapat:

• Terus cari produk yang paling cocok dengan kueri.
• Jika pencarian memiliki kesalahan yang jelas, secara otomatis merekomendasikan kueri yang dikoreksi.
• Secara otomatis menangani masalah umum seperti kesalahan ejaan, ejaan alternatif, dan kasus pluralisasi dan kata kerja yang tidak cocok.
• Tunjukkan kapan produk akan berada dalam stok.

Selama permintaan pengguna masuk akal, program e-niaga yang dirancang dengan baik harus mengembalikan hasil yang wajar bukan kesalahan.

Cara lain yang bagus untuk menghindari pesan kesalahan adalah dengan mencegah masalah di tempat pertama. Anda dapat mencegah kesalahan dengan:

• Menggunakan kontrol yang dibatasi. Gunakan kontrol yang dibatasi ke nilai yang valid. Kontrol seperti daftar, penggeser, kotak centang, tombol radio, dan pemilih tanggal dan waktu dibatasi untuk nilai yang valid, sedangkan kotak teks sering tidak dan mungkin memerlukan pesan kesalahan. Namun, Anda dapat membatasi kotak teks untuk hanya menerima karakter tertentu dan menerima jumlah karakter maksimum.
• Menggunakan interaksi yang dibatasi. Untuk operasi seret, izinkan pengguna untuk menghilangkan hanya pada target yang valid.
• Menggunakan kontrol dan item menu yang dinonaktifkan. Nonaktifkan kontrol dan item menu saat pengguna dapat dengan mudah menyimpulkan mengapa item kontrol atau menu dinonaktifkan.
• Memberikan nilai default yang baik. Pengguna cenderung tidak membuat kesalahan input jika mereka dapat menerima nilai default. Bahkan jika pengguna memutuskan untuk mengubah nilai, nilai default memungkinkan pengguna mengetahui format input yang diharapkan.
• Membuat segalanya berjalan dengan baik. Pengguna cenderung tidak membuat kesalahan jika tugas tidak perlu atau dilakukan secara otomatis untuk mereka. Atau jika pengguna membuat kesalahan kecil tetapi niat mereka jelas, masalahnya diperbaiki secara otomatis. Misalnya, Anda dapat memperbaiki masalah pemformatan kecil secara otomatis.

Menyediakan pesan kesalahan yang diperlukan

Terkadang Anda benar-benar perlu memberikan pesan kesalahan. Pengguna membuat kesalahan, jaringan dan perangkat berhenti berfungsi, objek tidak dapat ditemukan atau dimodifikasi, tugas tidak dapat diselesaikan, dan program memiliki bug. Idealnya, masalah ini akan terjadi lebih jarang misalnya, kita dapat merancang perangkat lunak kita untuk mencegah banyak jenis kesalahan pengguna tetapi tidak realistis untuk mencegah semua masalah ini. Dan ketika salah satu masalah ini terjadi, pesan kesalahan yang bermanfaat membuat pengguna kembali berjalan dengan cepat.

Keyakinan umum adalah bahwa pesan kesalahan adalah pengalaman pengguna terburuk dan harus dihindari dengan segala biaya, tetapi lebih akurat untuk mengatakan bahwa kebingungan pengguna adalah pengalaman terburuk dan harus dihindari dengan segala biaya. Terkadang biaya tersebut adalah pesan kesalahan yang bermanfaat.

Pertimbangkan kontrol yang dinonaktifkan. Sebagian besar waktu, jelas mengapa kontrol dinonaktifkan, jadi menonaktifkan kontrol adalah cara yang bagus untuk menghindari pesan kesalahan. Namun, bagaimana jika alasan kontrol dinonaktifkan tidak jelas? Pengguna tidak dapat melanjutkan dan tidak ada umpan balik untuk menentukan masalah. Sekarang pengguna macet dan harus menyimpulkan masalah atau mendapatkan dukungan teknis. Dalam kasus seperti itu, jauh lebih baik untuk membiarkan kontrol diaktifkan dan memberikan pesan kesalahan yang bermanfaat sebagai gantinya.

Salah:

Mengapa tombol Berikutnya dinonaktifkan di sini? Lebih baik membiarkannya diaktifkan dan menghindari kebingungan pengguna dengan memberikan pesan kesalahan yang bermanfaat.

Jika Anda tidak yakin apakah Anda harus memberikan pesan kesalahan, mulailah dengan membuat pesan kesalahan yang mungkin Anda berikan. Jika pengguna kemungkinan akan melakukan tindakan atau mengubah perilaku mereka sebagai hasilnya, berikan pesan kesalahan. Sebaliknya, jika pengguna cenderung menutup pesan tanpa melakukan atau mengubah apa pun, hilangkan pesan kesalahan.

Merancang untuk penanganan kesalahan yang baik

Meskipun membuat teks pesan kesalahan yang baik bisa menjadi tantangan, terkadang tidak mungkin tanpa dukungan penanganan kesalahan yang baik dari program. Pertimbangkan pesan kesalahan ini:

Salah:

Kemungkinan, masalahnya benar-benar tidak diketahui karena dukungan penanganan kesalahan program kurang.

Meskipun ada kemungkinan bahwa ini adalah pesan kesalahan yang sangat buruk, kemungkinan besar ini mencerminkan kurangnya penanganan kesalahan yang baik oleh kode yang mendasar tidak ada informasi spesifik yang diketahui tentang masalah tersebut.

Untuk membuat pesan kesalahan tertentu yang dapat ditindaklanjuti dan berpusat pada pengguna, kode penanganan kesalahan program Anda harus memberikan informasi kesalahan tingkat tinggi tertentu:

• Setiap masalah harus memiliki kode kesalahan unik yang ditetapkan.
• Jika masalah memiliki beberapa penyebab, program harus menentukan penyebab spesifik jika memungkinkan.
• Jika masalah memiliki parameter, parameter harus dipertahankan.
• Masalah tingkat rendah harus ditangani pada tingkat yang cukup tinggi sehingga pesan kesalahan dapat disajikan dari sudut pandang pengguna.

Pesan kesalahan yang baik bukan hanya masalah UI, pesan tersebut adalah masalah desain perangkat lunak. Pengalaman pesan kesalahan yang baik bukanlah sesuatu yang dapat ditangguhkan nanti.

Pemecahan masalah (dan cara menghindarinya)

Pemecahan masalah hasil ketika masalah dengan beberapa penyebab berbeda dilaporkan dengan satu pesan kesalahan.

Salah:

Benar:

Pemecahan masalah hasil ketika beberapa masalah dilaporkan dengan satu pesan kesalahan.

Dalam contoh berikut, item tidak dapat dipindahkan karena sudah dipindahkan atau dihapus, atau akses ditolak. Jika program dapat dengan mudah menentukan penyebabnya, mengapa membebani pengguna untuk menentukan penyebab spesifiknya?

Salah:

Nah, yang itu? Sekarang pengguna harus memecahkan masalah.

Program ini dapat menentukan apakah akses ditolak, sehingga masalah ini harus dilaporkan dengan pesan kesalahan tertentu.

Benar:

Dengan penyebab tertentu, tidak diperlukan pemecahan masalah.

Gunakan pesan dengan beberapa penyebab hanya ketika penyebab spesifik tidak dapat ditentukan. Dalam contoh ini, akan sulit bagi program untuk menentukan apakah item dipindahkan atau dihapus, sehingga satu pesan kesalahan dengan beberapa penyebab mungkin digunakan di sini. Namun, tidak mungkin pengguna akan peduli jika, misalnya, mereka tidak dapat memindahkan file yang dihapus. Untuk penyebab ini, pesan kesalahan bahkan tidak diperlukan.

Menangani kesalahan yang tidak diketahui

Dalam beberapa kasus, Anda benar-benar tidak akan tahu masalah, penyebab, atau solusinya. Jika tidak bijak untuk menekan kesalahan, lebih baik berada di depan tentang kurangnya informasi daripada menyajikan masalah, penyebab, atau solusi yang mungkin tidak benar.

Misalnya, jika program Anda memiliki pengecualian yang tidak tertangani, pesan kesalahan berikut ini cocok:

Jika Anda tidak dapat menekan kesalahan yang tidak diketahui, lebih baik berada di depan tentang kurangnya informasi.

Di sisi lain, berikan informasi spesifik yang dapat ditindak lanjuti jika kemungkinan akan membantu sebagian besar waktu.

Pesan kesalahan ini cocok untuk kesalahan yang tidak diketahui jika konektivitas jaringan biasanya menjadi masalah.

Menentukan jenis pesan yang sesuai

Beberapa masalah dapat disajikan sebagai kesalahan, peringatan, atau informasi, tergantung pada penekanan dan frasa. Misalnya, halaman Web tidak dapat memuat kontrol ActiveX yang tidak ditandatangani berdasarkan konfigurasi Windows Internet Explorer saat ini:

• Kesalahan. "Halaman ini tidak dapat memuat kontrol ActiveX yang tidak ditandatangani." (Diungkapkan sebagai masalah yang ada.)
• Peringatan. "Halaman ini mungkin tidak berakibat seperti yang diharapkan karena Windows Internet Explorer tidak dikonfigurasi untuk memuat kontrol ActiveX yang tidak ditandatangani." atau "Izinkan halaman ini menginstal Kontrol ActiveX yang tidak ditandatangani? Melakukannya dari sumber yang tidak tepercaya dapat membahayakan komputer Anda." (Keduanya diungkapkan sebagai kondisi yang dapat menyebabkan masalah di masa mendatang.)
• Informasi. "Anda telah mengonfigurasi Windows Internet Explorer untuk memblokir kontrol ActiveX yang tidak ditandatangani." (Diungkapkan sebagai pernyataan fakta.)

Untuk menentukan jenis pesan yang sesuai, fokuslah pada aspek terpenting dari masalah yang perlu diketahui atau ditindak lanjuti pengguna. Biasanya, jika masalah memblokir pengguna untuk melanjutkan, Anda harus menyajikannya sebagai kesalahan; jika pengguna dapat melanjutkan, berikan sebagai peringatan. Buat instruksi utama atau teks terkait lainnya berdasarkan fokus tersebut, lalu pilih ikon (standar atau sebaliknya) yang cocok dengan teks. Teks instruksi utama dan ikon harus selalu cocok.

Presentasi pesan kesalahan

Sebagian besar pesan kesalahan dalam program Windows disajikan menggunakan kotak dialog modal (seperti kebanyakan contoh dalam artikel ini), tetapi ada opsi lain:

• Lokal
• Balon
• Pemberitahuan
• Ikon area pemberitahuan
• Bilah status
• File log (untuk kesalahan yang ditargetkan pada profesional TI)

Menempatkan pesan kesalahan dalam kotak dialog modal memiliki manfaat menuntut perhatian dan pengakuan langsung pengguna. Namun, ini juga merupakan kelemahan utama mereka jika perhatian itu tidak diperlukan.

Apakah Anda benar-benar perlu mengganggu pengguna sehingga mereka dapat mengklik tombol Tutup? Jika tidak, pertimbangkan alternatif untuk menggunakan kotak dialog modal.

Dialog modal adalah pilihan yang bagus ketika pengguna harus segera mengakui masalah sebelum melanjutkan, tetapi sering kali pilihan yang buruk sebaliknya. Umumnya, Anda harus lebih suka menggunakan presentasi dengan bobot paling ringan yang melakukan pekerjaan dengan baik.

Hindari overcommunicating

Umumnya, pengguna tidak membaca, mereka memindai. Semakin banyak teks, semakin sulit teks untuk dipindai, dan semakin besar kemungkinan pengguna tidak akan membaca teks sama sekali. Akibatnya, penting untuk mengurangi teks ke hal-hal pentingnya, dan menggunakan pengungkapan progresif dan tautan Bantuan bila perlu untuk memberikan informasi tambahan.

Ada banyak contoh ekstrem, tetapi mari kita lihat satu yang lebih khas. Contoh berikut memiliki sebagian besar atribut pesan kesalahan yang baik, tetapi teksnya tidak ringkas dan memerlukan motivasi untuk membaca.

Salah:

Contoh ini adalah pesan kesalahan yang baik, tetapi overcommunicates.

Apa semua teks ini benar-benar mengatakan? Sesuatu seperti ini:

Benar:

Pesan kesalahan ini pada dasarnya memiliki informasi yang sama, tetapi jauh lebih ringkas.

Dengan menggunakan Bantuan untuk memberikan detailnya, pesan kesalahan ini memiliki gaya presentasi piramida terbalik .

Untuk panduan dan contoh selengkapnya tentang berkomunikasi secara berlebihan, lihat Teks Antarmuka Pengguna.

Jika Anda hanya melakukan delapan hal

1. Rancang program Anda untuk penanganan kesalahan.
2. Jangan berikan pesan kesalahan yang tidak perlu.
3. Hindari kebingungan pengguna dengan memberikan pesan kesalahan yang diperlukan.
4. Pastikan pesan kesalahan memberikan masalah, penyebab, dan solusi.
5. Pastikan pesan kesalahan relevan, dapat ditindaklanjuti, singkat, jelas, spesifik, sopan, dan langka.
6. Mendesain pesan kesalahan dari sudut pandang pengguna, bukan sudut pandang program.
7. Hindari melibatkan pengguna dalam pemecahan masalah, gunakan pesan kesalahan yang berbeda untuk setiap penyebab yang dapat dideteksi.
8. Gunakan metode presentasi dengan bobot paling ringan yang melakukan pekerjaan dengan baik.

Pola penggunaan

Pesan kesalahan memiliki beberapa pola penggunaan:

Label	Nilai
Masalah sistem Sistem operasi, perangkat keras, jaringan, atau program telah gagal atau tidak dalam status diperlukan untuk melakukan tugas.	Banyak masalah sistem yang dapat diselesaikan oleh pengguna: Masalah perangkat dapat diselesaikan dengan menyalakan perangkat, menyambungkan kembali perangkat, dan menyisipkan media. Masalah jaringan dapat diselesaikan dengan memeriksa koneksi jaringan fisik, dan menjalankan diagnosis dan perbaikan Jaringan. Masalah program dapat diselesaikan dengan mengubah opsi program atau memulai ulang program. Dalam contoh ini, program tidak dapat menemukan kamera untuk melakukan tugas pengguna. Dalam contoh ini, fitur yang diperlukan untuk melakukan tugas perlu diaktifkan.
Masalah file File atau folder yang diperlukan untuk tugas yang dimulai oleh pengguna tidak ditemukan, sudah digunakan, atau tidak memiliki format yang diharapkan.	Dalam contoh ini, file atau folder tidak dapat dihapus karena tidak ditemukan. Dalam contoh ini, program tidak mendukung format file yang diberikan.
Masalah keamanan Pengguna tidak memiliki izin untuk mengakses sumber daya, atau hak istimewa yang memadai untuk melakukan tugas yang dimulai oleh pengguna.	Dalam contoh ini, pengguna tidak memiliki izin untuk mengakses sumber daya. Dalam contoh ini, pengguna tidak memiliki hak istimewa untuk melakukan tugas.
Masalah tugas Ada masalah khusus saat melakukan tugas yang dimulai oleh pengguna (selain sistem, file tidak ditemukan, format file, atau masalah keamanan).	Dalam contoh ini, data Clipboard tidak dapat ditempelkan ke Paint. Dalam contoh ini, pengguna tidak dapat menginstal peningkatan perangkat lunak.
Masalah input pengguna Pengguna memasukkan nilai yang salah atau tidak konsisten dengan input pengguna lain.	Dalam contoh ini, pengguna memasukkan nilai waktu yang salah. Dalam contoh ini, input pengguna tidak dalam format yang benar.

Panduan

Presentasi

• Gunakan dialog tugas kapan pun sesuai untuk mencapai tampilan dan tata letak yang konsisten. Dialog tugas memerlukan Windows Vista atau yang lebih baru, sehingga tidak cocok untuk versi Windows sebelumnya. Jika Anda harus menggunakan kotak pesan, pisahkan instruksi utama dari instruksi tambahan dengan dua jeda baris.

Kesalahan input pengguna

• Jika memungkinkan, cegah atau kurangi kesalahan input pengguna dengan:
  • Menggunakan kontrol yang dibatasi ke nilai yang valid.
  • Menonaktifkan kontrol dan item menu saat mengklik akan mengakibatkan kesalahan, selama sudah jelas mengapa kontrol atau item menu dinonaktifkan.
  • Memberikan nilai default yang baik.

Salah:

Dalam contoh ini, kotak teks yang tidak dibatasi digunakan untuk input yang dibatasi. Gunakan pengguncur sebagai gantinya.

• Gunakan penanganan kesalahan tanpa mode (kesalahan atau balon di tempat) untuk masalah input pengguna kontekstual.
• Gunakan balon untuk masalah input pengguna non-kritis dan satu titik yang terdeteksi saat berada dalam kotak teks atau segera setelah kotak teks kehilangan fokus.Balon tidak memerlukan ruang layar yang tersedia atau tata letak dinamis yang diperlukan untuk menampilkan pesan di tempat. Hanya menampilkan satu balon pada satu waktu. Karena masalahnya tidak kritis, tidak ada ikon kesalahan yang diperlukan. Balon hilang saat diklik, ketika masalah diselesaikan, atau setelah waktu habis.

Dalam contoh ini, balon menunjukkan masalah input saat masih dalam kontrol.

• Gunakan kesalahan di tempat untuk deteksi kesalahan tertunda, biasanya kesalahan yang ditemukan dengan mengklik tombol penerapan. (Jangan gunakan kesalahan di tempat untuk pengaturan yang segera diterapkan.) Mungkin ada beberapa kesalahan di tempat pada satu waktu. Gunakan teks normal dan ikon kesalahan 16x16 piksel, tempatkan langsung di samping masalah jika memungkinkan. Kesalahan di tempat tidak hilang kecuali pengguna melakukan dan tidak ada kesalahan lain yang ditemukan.

Dalam contoh ini, kesalahan di tempat digunakan untuk kesalahan yang ditemukan dengan mengklik tombol penerapan.

• Gunakan penanganan kesalahan modal (dialog tugas atau kotak pesan) untuk semua masalah lainnya, termasuk kesalahan yang melibatkan beberapa kontrol atau kesalahan non-kontekstual atau non-input yang ditemukan dengan mengklik tombol penerapan.
• Saat masalah input pengguna dilaporkan, atur fokus input ke kontrol pertama dengan data yang salah. Gulir kontrol ke tampilan jika perlu. Jika kontrol adalah kotak teks, pilih seluruh konten. Seharusnya selalu jelas apa yang dimaksud oleh pesan kesalahan.
• Jangan hapus input yang salah. Sebaliknya, biarkan sehingga pengguna dapat melihat dan memperbaiki masalah tanpa memulai kembali.
  • Pengecualian: Hapus kata sandi dan kotak teks PIN yang salah karena pengguna tidak dapat memperbaiki input bertopeng secara efektif.

Pemecahan Masalah

• Hindari membuat masalah pemecahan masalah. Jangan mengandalkan satu pesan kesalahan untuk melaporkan masalah dengan beberapa penyebab berbeda yang dapat dideteksi.
• Gunakan pesan kesalahan yang berbeda (biasanya instruksi tambahan yang berbeda) untuk setiap penyebab yang dapat dideteksi. Misalnya, jika file tidak dapat dibuka karena beberapa alasan, berikan instruksi tambahan terpisah untuk setiap alasan.
• Gunakan pesan dengan beberapa penyebab hanya ketika penyebab tertentu tidak dapat ditentukan. Dalam hal ini, sajikan solusi dalam rangka kemungkinan memperbaiki masalah. Melakukannya membantu pengguna menyelesaikan masalah dengan lebih efisien.

Ikon

• Dialog pesan kesalahan modal tidak memiliki ikon bilah judul. Ikon bilah judul digunakan sebagai perbedaan visual antara jendela utama dan jendela sekunder.

• Gunakan ikon kesalahan. Pengecualian:

  • Jika kesalahan adalah masalah input pengguna yang ditampilkan menggunakan kotak dialog modal atau balon, jangan gunakan ikon. Melakukannya adalah penghitung nada mendorong Windows. Namun, pesan kesalahan di tempat harus menggunakan ikon kesalahan kecil (16x16 piksel) untuk mengidentifikasinya dengan jelas sebagai pesan kesalahan.

    

    

    Dalam contoh ini, masalah input pengguna tidak memerlukan ikon kesalahan.

    

    Dalam contoh ini, pesan kesalahan di tempat memerlukan ikon kesalahan kecil untuk mengidentifikasinya dengan jelas sebagai pesan kesalahan.

• Jika masalahnya adalah untuk fitur yang memiliki ikon (dan bukan masalah input pengguna), Anda dapat menggunakan ikon fitur dengan overlay kesalahan. Jika Anda melakukan ini, gunakan juga nama fitur sebagai subjek kesalahan.

  

  Dalam contoh ini, ikon fitur memiliki overlay kesalahan, dan fitur tersebut adalah subjek kesalahan.

• Jangan gunakan ikon peringatan untuk kesalahan. Hal ini sering dilakukan untuk membuat presentasi terasa kurang parah. Kesalahan bukan peringatan.

  Salah:

  

  Dalam contoh ini, ikon peringatan salah digunakan untuk membuat kesalahan terasa kurang parah.

Untuk panduan dan contoh lainnya, lihat Ikon Standar.

Pengungkapan progresif

• Gunakan tombol Perlihatkan/Sembunyikan pengungkapan progresif detail untuk menyembunyikan informasi tingkat lanjut atau terperinci dalam pesan kesalahan. Melakukannya menyederhanakan pesan kesalahan untuk penggunaan umum. Jangan menyembunyikan informasi yang diperlukan, karena pengguna mungkin tidak menemukannya.

Dalam contoh ini, tombol pengungkapan progresif membantu pengguna menelusuri lebih detail jika mereka menginginkannya, atau menyederhanakan UI jika tidak.

• Jangan gunakan detail Tampilkan/Sembunyikan kecuali benar-benar ada detail lebih lanjut. Jangan hanya mengembalikan informasi yang ada dalam format yang lebih verbose.
• Jangan gunakan Perlihatkan/Sembunyikan detail untuk menampilkan informasi Bantuan. Gunakan tautan Bantuan sebagai gantinya.

Untuk panduan pelabelan, lihat Kontrol Pengungkapan Progresif.

Jangan perlihatkan pesan ini lagi

• Jika pesan kesalahan memerlukan opsi ini, pertimbangkan kembali kesalahan dan frekuensinya. Jika memiliki semua karakteristik kesalahan yang baik (relevan, dapat ditindak lanjuti, dan jarang), seharusnya tidak masuk akal bagi pengguna untuk menekannya.

Untuk panduan selengkapnya, lihat Kotak Dialog.

Nilai default

• Pilih respons paling aman, paling tidak merusak, atau paling aman untuk menjadi default. Jika keamanan bukan faktor, pilih perintah yang paling mungkin atau nyaman.

Bantuan

• Mendesain pesan kesalahan untuk menghindari kebutuhan bantuan. Biasanya pengguna tidak perlu membaca teks eksternal untuk memahami dan menyelesaikan masalah, kecuali solusinya memerlukan beberapa langkah.
• Pastikan konten Bantuan relevan dan bermanfaat. Seharusnya bukan merupakan pemulihan verbose dari pesan kesalahan, melainkan harus berisi informasi berguna yang berada di luar cakupan pesan kesalahan, seperti cara untuk menghindari masalah di masa depan. Jangan berikan tautan Bantuan hanya karena Anda bisa.
• Gunakan tautan Bantuan tertentu, ringkas, dan relevan untuk mengakses konten Bantuan. Jangan gunakan tombol perintah atau pengungkapan progresif untuk tujuan ini.
• Untuk pesan kesalahan yang tidak dapat Anda buat spesifik dan dapat ditindakkan, pertimbangkan untuk menyediakan tautan ke konten Bantuan online. Dengan demikian, Anda dapat memberi pengguna informasi tambahan yang dapat Anda perbarui setelah program dirilis.

Untuk panduan selengkapnya, lihat Bantuan.

Kode kesalahan

• Untuk pesan kesalahan yang tidak dapat Anda buat spesifik dan dapat ditindakkan atau mereka mendapat manfaat dari Bantuan, pertimbangkan juga untuk memberikan kode kesalahan. Pengguna sering menggunakan kode kesalahan ini untuk mencari informasi tambahan di Internet.
• Selalu berikan deskripsi teks tentang masalah dan solusi. Jangan hanya bergantung pada kode kesalahan untuk tujuan ini.

Salah:

Dalam contoh ini, kode kesalahan digunakan sebagai pengganti teks solusi.

• Tetapkan kode kesalahan unik untuk setiap penyebab yang berbeda. Melakukannya menghindari pemecahan masalah.
• Pilih kode galat yang mudah dicari di Internet. Jika Anda menggunakan kode 32-bit, gunakan representasi heksadesimal dengan karakter "0x" dan huruf besar di depannya.

Benar:

1234

0xC0001234

Salah:

-1

-67113524

• Gunakan Tampilkan/Sembunyikan detail untuk menampilkan kode kesalahan. Frasa sebagai Kode kesalahan: <error code>.

Dalam contoh ini, kode kesalahan digunakan untuk melengkapi pesan kesalahan yang dapat memperoleh manfaat dari informasi lebih lanjut.

Suarakan

• Jangan menyertai pesan kesalahan dengan efek suara atau bip. Melakukannya adalah jarring dan tidak perlu.
  • Pengecualian: Mainkan efek suara Critical Stop jika masalahnya sangat penting untuk pengoperasian komputer, dan pengguna harus segera mengambil tindakan untuk mencegah konsekuensi serius.

Teks

Umum

• Hapus teks yang berlebihan. Cari di judul, instruksi utama, instruksi tambahan, tautan perintah, dan tombol penerapan. Umumnya, biarkan teks lengkap dalam instruksi dan kontrol interaktif, dan hapus redundansi apa pun dari tempat lain.
• Gunakan penjelasan yang berpusat pada pengguna. Jelaskan masalah dalam hal tindakan atau tujuan pengguna, bukan dalam hal apa yang tidak disarankan oleh perangkat lunak. Gunakan bahasa yang dipahami dan digunakan pengguna target. Hindari jargon teknis.

Salah:

Benar:

Dalam contoh ini, versi yang benar berbicara bahasa pengguna sedangkan versi yang salah terlalu teknis.

• Jangan gunakan kata-kata berikut:
  • Kesalahan, kegagalan (gunakan masalah sebagai gantinya)
  • Gagal (gunakan sebagai gantinya tidak dapat)
  • Ilegal, tidak valid, buruk (gunakan salah sebagai gantinya)
  • Membatalkan, membunuh, mengakhiri (gunakan berhenti sebagai gantinya)
  • Bencana, fatal (gunakan serius sebagai gantinya)

Istilah-istilah ini tidak perlu dan bertentangan dengan nada mendorong Windows. Ketika digunakan dengan benar, ikon kesalahan cukup mengomunikasikan bahwa ada masalah.

Salah:

Benar:

Dalam contoh yang salah, istilah "bencana" dan "kegagalan" tidak perlu.

• Jangan gunakan frasa yang menyalahkan pengguna atau menyiratkan kesalahan pengguna. Hindari menggunakan Anda dan Anda dalam pembuatan frasa. Meskipun suara aktif umumnya lebih disukai, gunakan suara pasif ketika pengguna adalah subjek dan mungkin merasa disalahkan atas kesalahan jika suara aktif digunakan.

Salah:

Benar:

Contoh yang salah menyalahkan pengguna dengan menggunakan suara aktif.

• Membuatnya spesifik. Hindari kata-kata yang tidak jelas, seperti kesalahan sintaksis dan operasi ilegal. Berikan nama, lokasi, dan nilai tertentu dari objek yang terlibat.

Salah:

File tidak ditemukan.

Disk penuh.

Nilai di luar rentang.

Karakter tidak valid.

Perangkat tidak tersedia.

Masalah ini akan jauh lebih mudah dipecahkan dengan nama, lokasi, dan nilai tertentu.

• Jangan memberikan kemungkinan masalah, penyebab, atau solusi yang mungkin terjadi dalam upaya untuk menjadi spesifik. Jangan berikan masalah, penyebab, atau solusi kecuali kemungkinan tepat. Misalnya, lebih baik mengatakan Kesalahan yang tidak diketahui terjadi daripada sesuatu yang kemungkinan tidak akurat.
• Hindari kata "please," kecuali dalam situasi di mana pengguna diminta untuk melakukan sesuatu yang tidak nyaman (seperti menunggu) atau perangkat lunak harus disalahkan atas situasi tersebut.

Benar:

Harap tunggu sementara Windows menyalin berkas ke komputer Anda.

• Gunakan kata "maaf" hanya dalam pesan kesalahan yang mengakibatkan masalah serius bagi pengguna (misalnya, kehilangan data atau ketidakmampuan untuk menggunakan komputer). Jangan minta maaf jika masalah terjadi selama fungsi normal program (misalnya, jika pengguna perlu menunggu koneksi jaringan ditemukan).

Benar:

Maaf, tetapi Fabrikam Backup mendeteksi masalah yang tidak dapat dipulihkan dan dimatikan untuk melindungi file di komputer Anda.

• Lihat produk menggunakan nama pendek mereka. Jangan gunakan nama produk lengkap atau simbol merek dagang. Jangan sertakan nama perusahaan kecuali pengguna mengaitkan nama perusahaan dengan produk. Jangan sertakan nomor versi program.

Salah:

Benar:

Dalam contoh yang salah, nama produk lengkap dan simbol merek dagang digunakan.

• Gunakan tanda kutip ganda di sekitar nama objek. Melakukannya membuat teks lebih mudah diurai dan menghindari pernyataan yang berpotensi memalukan.
  • Pengecualian: Jalur file, URL, dan nama domain yang sepenuhnya memenuhi syarat tidak perlu berada dalam tanda kutip ganda.

Benar:

Dalam contoh ini, pesan kesalahan akan membingungkan jika nama objek tidak dalam tanda kutip.

• Hindari memulai kalimat dengan nama objek. Melakukannya sering sulit diurai.
• Jangan gunakan tanda seru atau kata-kata dengan semua huruf kapital. Tanda seru dan huruf kapital membuatnya merasa seperti Anda berteriak kepada pengguna.

Untuk panduan dan contoh lainnya, lihat Gaya dan Nada.

Judul

• Gunakan judul untuk mengidentifikasi perintah atau fitur asal kesalahan. Pengecualian:
  • Jika kesalahan ditampilkan oleh banyak perintah yang berbeda, pertimbangkan untuk menggunakan nama program sebagai gantinya.
  • Jika judul itu akan berlebihan atau membingungkan dengan instruksi utama, gunakan nama program sebagai gantinya.
• Jangan gunakan judul untuk menjelaskan atau meringkas masalah yang menjadi tujuan instruksi utama.

Salah:

Dalam contoh ini, judul salah digunakan untuk menjelaskan masalah.

• Gunakan kapitalisasi gaya judul, tanpa tanda baca akhir.

Instruksi utama

• Gunakan instruksi utama untuk menjelaskan masalah dalam bahasa yang jelas, polos, dan spesifik.
• Ringkas gunakan hanya satu kalimat lengkap. Pare instruksi utama ke informasi penting. Anda dapat membiarkan subjek implisit jika itu adalah program Atau pengguna Anda. Sertakan alasan masalah jika Anda dapat melakukannya dengan ringkas. Jika Anda harus menjelaskan sesuatu yang lebih, gunakan instruksi tambahan.

Salah:

Dalam contoh ini, seluruh pesan kesalahan dimasukkan ke dalam instruksi utama, sehingga sulit dibaca.

• Jadilah spesifik jika ada objek yang terlibat, berikan nama mereka.
• Hindari menempatkan jalur file lengkap dan URL dalam instruksi utama. Sebaliknya, gunakan nama pendek (seperti nama file) dan letakkan nama lengkap (seperti jalur file) dalam instruksi tambahan. Namun, Anda dapat menempatkan satu jalur file lengkap atau URL dalam instruksi utama jika pesan kesalahan tidak memerlukan instruksi tambahan.

Dalam contoh ini, hanya nama file yang ada dalam instruksi utama. Jalur lengkap ada dalam instruksi tambahan.

• Jangan berikan jalur file lengkap dan URL sama sekali jika jelas dari konteks.

Dalam contoh ini, pengguna mengganti nama file dari Windows Explorer. Dalam hal ini, jalur file lengkap tidak diperlukan karena jelas dari konteks.

• Gunakan present tense bila memungkinkan.
• Gunakan kapitalisasi gaya kalimat.
• Jangan sertakan periode akhir jika instruksi adalah pernyataan. Jika instruksi adalah pertanyaan, sertakan tanda tanya akhir.

Templat instruksi utama

Meskipun tidak ada aturan ketat untuk pembuatan frasa, coba gunakan templat instruksi utama berikut jika memungkinkan:

• [nama subjek opsional] tidak dapat [melakukan tindakan]
• [nama subjek opsional] tidak dapat [melakukan tindakan] karena [alasan]
• [nama subjek opsional] tidak dapat [melakukan tindakan] ke "[nama objek]"
• [nama subjek opsional] tidak dapat [melakukan tindakan] ke "[nama objek]" karena [alasan]
• Tidak cukup [sumber daya] untuk [melakukan tindakan]
• [Nama subjek] tidak memiliki [nama objek] yang diperlukan untuk [tujuan]
• [Perangkat atau pengaturan] dimatikan sehingga [hasil yang tidak diinginkan]
• [Perangkat atau pengaturan] tidak [tersedia | ditemukan | diaktifkan | diaktifkan]
• "[nama objek]" saat ini tidak tersedia
• Nama pengguna atau kata sandi salah
• Anda tidak memiliki izin untuk mengakses "[nama objek]"
• Anda tidak memiliki hak istimewa untuk [melakukan tindakan]
• [nama program] mengalami masalah serius dan harus segera ditutup

Tentu saja, buat perubahan sesuai kebutuhan agar instruksi utama benar secara tata bahasa dan mematuhi pedoman instruksi utama.

Instruksi tambahan

• Gunakan instruksi tambahan untuk:
  • Berikan detail tambahan tentang masalah tersebut.
  • Jelaskan penyebab masalahnya.
  • Mencantumkan langkah-langkah yang dapat dilakukan pengguna untuk memperbaiki masalah.
  • Berikan langkah-langkah untuk mencegah masalah terulang kembali.
• Jika memungkinkan, usulkan solusi praktis dan bermanfaat sehingga pengguna dapat memperbaiki masalah. Namun, pastikan solusi yang diusulkan kemungkinan akan menyelesaikan masalah. Jangan buang-buang waktu pengguna dengan menyarankan solusi yang mungkin, tetapi tidak mungkin.

Salah:

Dalam contoh ini, sementara masalah dan solusi yang direkomendasikan dimungkinkan, mereka sangat tidak mungkin.

• Jika masalahnya adalah nilai yang salah yang dimasukkan pengguna, gunakan instruksi tambahan untuk menjelaskan nilai yang benar. Pengguna seharusnya tidak perlu menentukan informasi ini dari sumber lain.
• Jangan memberikan solusi jika dapat disimpulkan secara sepele dari pernyataan masalah.

Dalam contoh ini, tidak ada instruksi tambahan yang diperlukan; solusinya dapat disimpulkan secara sepele dari pernyataan masalah.

• Jika solusi memiliki beberapa langkah, sajikan langkah-langkah dalam urutan penyelesaiannya. Namun, hindari solusi multi-langkah karena pengguna mengalami kesulitan mengingat lebih dari dua atau tiga langkah sederhana. Jika diperlukan lebih banyak langkah, lihat topik Bantuan yang sesuai.
• Pertahankan instruksi tambahan tetap ringkas. Berikan hanya apa yang perlu diketahui pengguna. Hilangkan detail yang tidak perlu. Bertujuan untuk maksimal tiga kalimat dengan panjang sedang.
• Untuk menghindari kesalahan saat pengguna melakukan instruksi, letakkan hasilnya sebelum tindakan.

Benar:

Untuk memulai ulang Windows, klik OK.

Salah:

Klik OK untuk memulai ulang Windows.

Dalam contoh yang salah, pengguna lebih cenderung mengklik OK secara tidak sengaja.

• Jangan merekomendasikan menghubungi administrator kecuali melakukannya adalah salah satu solusi yang paling mungkin untuk masalah tersebut. Cadangkan solusi tersebut untuk masalah yang benar-benar hanya dapat diselesaikan oleh administrator.

Salah:

Dalam contoh ini, kemungkinan besar masalahnya adalah dengan koneksi jaringan pengguna, sehingga tidak layak menghubungi administrator.

• Jangan merekomendasikan menghubungi dukungan teknis. Opsi untuk menghubungi dukungan teknis untuk menyelesaikan masalah selalu tersedia, dan tidak perlu dipromosikan melalui pesan kesalahan. Sebagai gantinya, fokus pada penulisan pesan kesalahan yang bermanfaat sehingga pengguna dapat menyelesaikan masalah tanpa menghubungi dukungan teknis.

Salah:

Dalam contoh ini, pesan kesalahan salah merekomendasikan untuk menghubungi dukungan teknis.

• Gunakan kalimat lengkap, kapitalisasi gaya kalimat, dan tanda baca akhir.

Tombol Terapkan

• Jika pesan kesalahan menyediakan tombol perintah atau tautan perintah yang menyelesaikan masalah, ikuti panduan masing-masing dalam Kotak Dialog.
• Jika program harus dihentikan sebagai akibat dari kesalahan, berikan tombol Keluar program. Untuk menghindari kebingungan, jangan gunakan Tutup untuk tujuan ini.
• Jika tidak, berikan tombol Tutup. Jangan gunakan OK untuk pesan kesalahan, karena kata-kata ini menyiratkan bahwa masalah baik-baik saja.
  • Pengecualian: Gunakan OK jika mekanisme pelaporan kesalahan Anda memiliki label tetap (seperti halnya MESSAGEBox API.)

Dokumentasi

Jika mengacu pada kesalahan:

• Lihat kesalahan berdasarkan instruksi utamanya. Jika instruksi utama panjang atau terperinci, ringkaslah.
• Jika perlu, Anda dapat merujuk ke kotak dialog pesan kesalahan sebagai pesan. Lihat sebagai pesan kesalahan hanya dalam pemrograman dan dokumentasi teknis lainnya.
• Jika memungkinkan, format teks menggunakan tebal. Jika tidak, letakkan teks dalam tanda kutip hanya jika diperlukan untuk mencegah kebingungan.

Contoh: Jika Anda menerima cakram Tidak ada CD dalam pesan kandar , masukkan cakram CD baru ke dalam kandar, lalu coba lagi.