Teknik Menulis Hebat: Pedang Dua Tepi dari Pengalaman Pembaca

Pratinjau

Saat kami menulis Dokumen Pengguna, kami mengandalkan pengalaman Reader's / User kami untuk menyederhanakan pekerjaan kami. Hal ini dapat menyebabkan masalah bagi Pembaca. Artikel ini akan membahas pengaruh pengalaman Reader dan bagaimana meminimalkan efek negatif dari pengalaman yang tidak sesuai, dan bagaimana menangani asumsi penulis tentang Reader.
Baca juga artikel tentang Teknik Menulis Hebat: Beritahu Users Anda Apa yang Diharapkan.

Manfaat Penulis: Bergantung pada Pengalaman Pustaka

Saat kami menulis, kami mengandalkan pengalaman Reader kami untuk memberi kami "titik awal" untuk Dokumen Pengguna kami. Seringkali kita membuat asumsi tersembunyi tentang pengalaman Reader kita.

Berikut adalah beberapa contoh di mana mengandalkan pengalaman Reader kami membuat segalanya menjadi mudah (dan menyebabkan masalah) bagi kita sebagai penulis:

Contoh: Menggunakan Mouse Komputer

Dalam penulisan User Documentation for Graphical User Interface berbasis produk komputer (seperti antarmuka pengguna Windows atau Mac), kami berasumsi bahwa Reader mengetahui bagaimana menggunakan mouse untuk mengklik item, drag, dll. Ini menghemat banyak penulisan latar belakang.

Contoh: Memasak: Cara Mengukur Bahan; Ketentuan

Buku masak menghemat ruang dengan (biasanya benar) dengan asumsi bahwa Reader dapat melakukan operasi memasak dasar (seperti bahan pengukur), dan istilah (seperti pure atau irisan).

Contoh: Akronim Biasa

Kami mengandalkan akronim "umum" seperti AM dan PM untuk mempermudah penulisan kehidupan kita. Namun, banyak Pembaca menggunakan jam 24 jam, dan dengan demikian AM dan PM tidak ada artinya bagi mereka.

Waspadalah terhadap akronim mana pun yang Anda asumsikan Reader Anda tahu. Cara terbaik adalah menentukan akronim yang sesuai (mungkin dalam tanda kurung) saat pertama kali disajikan di bagian Dokumen Pengguna.

Anda tidak dapat menentukan mereka hanya pertama kali muncul di Dokumen Pengguna. Ini mengasumsikan - tidak benar - Pengguna membaca Dokumen Pengguna Anda dari awal sampai akhir.

Masalah Penulis Penyebab Ketika Menganggap Pengalaman Pengguna

Asumsi kita sebagai penulis bisa membuat kita bermasalah.

Contoh: Kata-kata yang tidak asing

Inilah contoh berkebun: Acme's (perusahaan fiktif) Panduan Illustrated untuk Berkebun di Kanada (1979) membuat asumsi yang salah tentang Pembacanya:

Dalam salah satu definisi mereka, mereka menggunakan sebuah istilah, "tangkai daun" untuk menentukan istilah lain. "Axil of a leaf" tidak tercantum dalam indeks buku ini, dan tidak ada glossary dalam buku ini. Jelas buku ini mengasumsikan bahwa Pembaca memahami istilah "tangkai daun." Saya tidak, dan karena itu saya tidak senang dengan presentasi ini.

Solusi: Berikan daftar istilah berkebun atau referensi ke halaman di buku yang istilahnya ditentukan.

Contoh: Mengasumsikan Pengalaman Siswa

Berikut adalah contoh di mana asumsi (tidak tertulis) oleh perusahaan pelatihan membuat salah satu mata kuliah mereka tidak berguna.

Untuk melakukan latihan dalam kursus pemrograman komputer, siswa harus bisa menggunakan editor (pengolah kata sederhana) untuk memprogram sistem. Satu-satunya editor yang tersedia pada mesin kursus adalah editor UNIX yang dikenal sebagai vi.

Sayangnya, para siswa tidak diberitahu bahwa mereka perlu menggunakan editor vi. Presenter kursus berasumsi bahwa para siswa mengetahui vi. Para siswa tidak, dan mereka menghabiskan setengah waktu untuk belajar dan menghadapi vi.

Asumsi tersembunyi oleh perusahaan pelatihan menghasilkan pengalaman belajar yang gagal (siswa tidak perlu lagi menggunakan vi). Ini menghabiskan dua hari dalam empat hari kursus.

Jangan Hadir Asumsi dengan cara yang licik

Jika perusahaan pelatihan mengatakan bahwa, "Kami melatih sistem UNIX," maka mereka meninggalkan jalan keluar untuk diri mereka sendiri saat mereka mengecewakan siswa yang tidak mengenal editor vi. Ketika dihadapkan, perusahaan bisa merespons, "Kami memberi tahu Anda bahwa itu adalah sistem UNIX. Anda harus tahu bahwa vi adalah editor yang tersedia di sistem itu."

Pernyataan sembunyi-sembunyi dari anggapan ini bodoh. Ini akan berakibat pada situasi kalah kalah.

Garis bawah

Sebagai penulis, kami membuat asumsi tentang pengalaman Reader kami. Namun, jika Anda membuat asumsi, maka pastikan Anda memberi tahu Pembaca apa pendapat Anda tentang dia.

Pikirkan tentang asumsi yang Anda buat tentang Pembaca Anda. Apakah asumsi ini valid (maksudnya, bisakah Anda benar-benar mengharapkan Pembaca Anda memenuhi asumsi Anda)? Jika ada keraguan dalam pikiran Anda, sertakan informasi yang menjelaskan persyaratan dan prosedur yang Anda asumsikan.

Pastikan bahwa ketika Anda menyatakan asumsi, bahwa Anda mempresentasikannya dengan cara yang Reader (siswa) dapat mengerti apa arti asumsi tersebut bagi mereka. Jangan licik saat mempresentasikan asumsi.

Pengalaman Pengguna Dapat Menyebabkan Masalah bagi Penulis

Pengalaman Reader Anda dapat menyebabkan kebingungan. Berikut adalah beberapa contohnya:

Contoh: Produk Shampoo / Conditioner

Salah satu contoh favorit saya adalah produk sampo dan kondisioner rambut gabungan. Jika Pengguna memiliki pengalaman dengan produk terpisah, maka pengalaman mereka adalah:

* Shampoo: Basahi kemudian. Pijat sampo ke rambut, lalu bilas.
* Conditioner: Cuci rambut. Pijat kondisioner ke rambut basah, biarkan di rambut selama dua atau tiga menit, lalu bilas.

Masalahnya timbul dengan produk gabungan. Jika Pengguna membiarkan produk di rambut selama dua atau tiga menit (seperti yang dilakukan dengan kondisioner), atau bilas dengan segera (seperti yang dilakukan dengan sampo)?

Dokumen Pengguna (label produk) untuk conditioner sampo gabungan harus memberi tahu Pengguna cara menggunakan produk dua-dalam-satu. Sebagian besar label seperti itu tidak.

Contoh: Kata yang Digunakan dengan Cara yang Tak Terduga

Tulisan Anda bisa memberi harapan pada Pembaca, sehingga membingungkan saat kata-kata digunakan tanpa diduga.

Sebuah artikel di Bagian Teknologi (dari sebuah surat kabar pada tanggal 10 Juni 2004, halaman B14) menjelaskan, "Bagaimana si kecil bisa membuat cadangan data komputer". Artikelnya tentang komputer. Ketika saya sampai pada kalimat: "Ayo hadapi: backup membosankan dan merepotkan untuk boot." Aku bertanya-tanya tentang kalimat "untuk boot."

Dalam jargon komputer, "boot" adalah proses di mana komputer dinyalakan ("diangkat sendiri oleh bootstrapsnya" ... oleh program yang awalnya disebut "bootstrap loader"). Apakah kutipan penulis tentang "kerumitan untuk boot" berarti bahwa jika saya melakukan backup, komputer saya akan menjadi lebih lambat ("membosankan") dan membutuhkan lebih banyak pekerjaan dari saya untuk memulai ("kerumitan untuk booting")?

Penggunaan frase "untuk boot" tidak sesuai dalam artikel ini, mengingat bahwa "boot" memiliki banyak arti. Penulis menggunakannya sebagai slang untuk "selain". Karena artikelnya tentang komputer, saya memikirkan arti komputer "untuk boot." Kalimatnya akan sedikit membingungkan jika penulis meninggalkan "untuk boot," seperti: "Mari kita hadapi: backup itu membosankan dan merepotkan." Kami akan segera kembali ke contoh ini.

Contoh: Fixedness Fungsional

Fungsi objek adalah tetap dalam pikiran seseorang. Misalnya, fungsi palu adalah memompa barang. Percobaan telah menunjukkan bahwa orang memiliki waktu yang sulit menggunakan palu untuk fungsi yang tidak biasa, seperti pemberat kertas, alat pengikat, atau pengungkit. Ini disebut fungsional fixedness.

Fungsional tetap bisa membatasi kegunaan produk anda. Dokumen Pengguna Anda harus berusaha untuk mengatasi fungsionalitas tetap. Mungkin contoh ini akan menunjukkan betapa pentingnya saya dalam User Documents.

Saya memiliki perangkat satelit posisi global (GPS) yang melacak perjalanan panjang saya. Sweater dan mantel tebal, yang dibutuhkan untuk berjalan di musim dingin, menyulitkan memakai perangkat GPS di pergelangan tangan. Tapi itu adalah perangkat WRIST. Fungsional tetap muncul, menyebabkan saya berjuang untuk menggunakan GPS di pergelangan tangan saya. Tapi ternyata GPS bekerja dengan baik saat digunakan di saku.

Dokumen Pengguna GPS harus menyebutkan kemampuan (jelas?) Ini, sehingga mengurangi fungsionalitas tetap yang terkait dengan GPS WRIST. Dalam pertahanan saya: Saya tidak yakin bahwa meletakkan pergelangan tangan GPS di saku lebih jelas daripada menggunakan palu sebagai pemberat kertas.

Contoh: Humor

Humor mengandalkan:

. pengetahuan halus tentang bahasa (misalnya sebuah pun)
. atau pengetahuan tentang sebuah acara (mungkin acara saat ini atau acara hiburan)

di mana humor berbasis. Inilah contohnya, dari sebuah lelucon lama:

"Anda sangat lucu, Anda harus berada di atas panggung, ada satu yang tertinggal dalam 15 menit."

Lelucon ini bergantung pada Reader yang mengetahui dua makna "panggung": (1) tempat untuk pertunjukan, dan (2) transportasi yang digunakan di Amerika Serikat bagian barat pada tahun 1800an. Kebanyakan Pembaca mungkin tidak tahu arti kedua, membuat humor menjadi pemborosan kata-kata yang membingungkan.

Sebelumnya kami memeriksa kalimatnya: "Mari kita hadapi: backup membosankan dan merepotkan untuk boot." Penulis menggunakan ungkapan "untuk boot" sebagai beberapa bentuk obrolan atau humor orang. Ini membingungkan Reader.

Hilangkan Humor dari Dokumen Pengguna Anda

. Humor hanya akan membingungkan User yang tidak memahaminya.
. Humor itu sulit, kalau bukan tidak mungkin, untuk diterjemahkan ke bahasa lain.

Saya menyarankan agar Anda menggunakan gaya penulisan yang informal dan percakapan, namun tanpa usaha humor. Hapus upaya humor saat Anda meninjau dan merevisi tulisan Anda.

Jika Anda ingin menulis humor, lakukan di tempat lain (Anda harus berada di atas panggung). Dokumen Pengguna bukanlah tempat untuk mempraktikkan humor Anda.

Garis bawah

Asumsi
Hati-hati dengan apa yang Anda kira tentang Reader Anda. Bila ragu apakah Reader mengetahui sesuatu atau tidak,

Nyatakan asumsi Anda tentang Pembaca Anda
Nyatakan asumsi dengan cara yang dapat diketahui oleh Pembaca
Bila ragu, tambahkan informasi yang Anda asumsikan, atau
Beritahu Pembaca Anda untuk mendapatkan informasi yang diasumsikan
Dengan memberikan atau menunjuk pada informasi yang diasumsikan ini, Anda meningkatkan audiens Anda

Pengalaman Pembaca

Sadarilah bagaimana pengalaman Reader Anda mempengaruhi bagaimana dia menafsirkan Dokumen Pengguna Anda atau menggunakan produk Anda. Jika perlu tambahkan materi ke Dokumen Pengguna Anda untuk mengatasi pengalaman Reader yang tidak kompatibel.

Posted by Unknown

Tweet