Cara Menguji Apakah Sebuah Artikel Menyelesaikan Masalah Pembaca
Sebuah artikel benar-benar menyelesaikan masalah pembaca ketika orang yang didefinisikan dapat menyelesaikan tugas yang didefinisikan dengan informasi yang disediakan. Audit ini memberi editor uji praktis: nyatakan maksud pembaca, petakan langkah-langkah yang diperlukan, periksa input dan bukti, inspeksi kegunaan, lalu minta pembaca perwakilan untuk melakukan tugas tersebut. Jumlah kata dan analitik di kemudian hari mungkin menambah konteks, tetapi keduanya tidak membuktikan bahwa draf tersebut berguna.
Mulai dengan satu pembaca, satu maksud, dan satu tugas yang dapat diamati
Tulis pernyataan awal audit sebelum meninjau teks:
Pembaca: [tipe orang tertentu]. Maksud: [apa yang ingin mereka pahami atau putuskan]. Tugas: Setelah membaca, mereka dapat [tindakan yang dapat diamati] tanpa memerlukan langkah atau sumber yang tidak disebutkan.
Sebagai contoh:
Pembaca: Seorang editor yang meninjau artikel web praktis. Maksud: Menentukan apakah draf tersebut membantu pembaca yang dituju. Tugas: Menerapkan audit alur penyelesaian dan mencatat keputusan publikasikan, revisi, atau tolak beserta alasannya.
Perbedaan ini penting. "Mempelajari kualitas konten" adalah topik informasi, bukan tugas yang dapat diuji. "Mengidentifikasi prasyarat yang hilang dalam artikel panduan praktis dan merevisi bagian yang relevan" dapat diuji.
Pertahankan cakupan cukup sempit agar penyelesaian memiliki titik akhir yang jelas. Sebuah panduan mungkin menjelaskan cara membandingkan dua produk, menyiapkan dokumen, memecahkan masalah pengaturan, atau memilih di antara opsi. Panduan tersebut tidak perlu menjawab setiap pertanyaan yang berdekatan untuk menyelesaikan tugas yang dinyatakannya.
Panduan konten dan penerbitan GOV.UK merekomendasikan untuk mengidentifikasi kebutuhan pengguna dan merencanakan konten di sekitarnya. Pertanyaan penilaian mandiri dari Google juga menanyakan apakah audiens yang dituju akan menganggap konten tersebut berguna, apakah pembaca akan belajar cukup banyak untuk mencapai tujuan mereka, dan apakah mereka akan pergi dengan pengalaman yang memuaskan (Google Search Central). Ini adalah dorongan yang berguna, tetapi editor tetap perlu mengubahnya menjadi uji penyelesaian yang konkret.
Petakan alur penyelesaian sebelum menilai penulisan
Buat daftar tindakan yang harus diambil pembaca, secara berurutan, untuk menyelesaikan tugas. Sertakan keputusan, perhitungan, input, pemeriksaan, dan serah terima—bukan hanya judul artikel.
Peta praktis mungkin terlihat seperti ini:
Kemudian tandai setiap langkah sebagai tercakup, tercakup sebagian, atau hilang. "Tercakup" berarti pembaca dapat bertindak dari artikel tersebut, bukan hanya topik tersebut disebutkan.
Misalnya, artikel lembar kerja penganggaran mungkin menjelaskan cara menjumlahkan pengeluaran tetapi menghilangkan periode waktu yang digunakan, apakah pajak termasuk dalam total, atau cara menangani tagihan yang tidak teratur. Perhitungan utamanya ada, namun alur penyelesaiannya terputus pada tahap input.
Tabel audit yang berguna adalah:
Tabel ini menunjukkan apakah draf tersebut lengkap sebagai sebuah alat. Ini juga mencegah editor memberikan pujian untuk pengantar yang rapi sembari mengabaikan prasyarat yang hilang.
Periksa input, asumsi, dan kondisi henti yang hilang
Banyak artikel praktis gagal sebelum petunjuk pertama karena mereka mengasumsikan pengetahuan, akses, atau kondisi yang tidak dimiliki pembaca. Audit setiap langkah dengan mengajukan empat pertanyaan:
Nyatakan asumsi secara eksplisit. Jika perhitungan menggunakan persentase, tentukan dasarnya. Jika panduan penyiapan bergantung pada versi perangkat lunak tertentu, identifikasi versi atau fitur yang relevan. Jika sebuah artikel membandingkan opsi, sebutkan kondisi mana yang membuat setiap opsi cocok.
Pisahkan input yang diperlukan dari perbaikan opsional. Pembaca harus dapat membedakan apakah suatu item diperlukan untuk melanjutkan atau hanya sekadar membantu. Letakkan prasyarat sebelum prosedur, di mana prasyarat tersebut dapat mencegah usaha yang sia-sia.
Cari juga transformasi tersembunyi. Apakah pembaca perlu mengonversi satuan, menghapus spasi, memilih rentang tanggal, atau menafsirkan pesan kesalahan? Jika ya, berikan aturannya atau contoh ilustrasi kecil. Jangan diam-diam mengarang nilai untuk input yang tidak ada. Beri tahu pembaca apa yang harus diperoleh, asumsi apa yang harus didokumentasikan, atau kapan metode tersebut tidak dapat diselesaikan.
Sebuah artikel lebih dapat dipercaya jika artikel tersebut menjelaskan kondisi kegagalan secara gamblang. "Jika hasilnya kosong, periksa apakah kolom sumber terisi" lebih berguna daripada menyiratkan metode tersebut selalu berhasil. Audit harus mencatat setiap titik di mana pembaca dapat mengalami kebuntuan secara wajar.
Uji cakupan bukti, bukan hiasan sitasi
Untuk setiap klaim yang berdampak penting, tanyakan jenis dukungan apa yang dibutuhkannya. Definisi mungkin memerlukan rujukan yang otoritatif. Petunjuk prosedural mungkin memerlukan panduan pihak pertama atau spesifikasi terdokumentasi. Rekomendasi mungkin memerlukan kriteria yang dinyatakan dan penjelasan yang jelas tentang bagaimana kriteria tersebut mengarah pada rekomendasi.
Buat buku catatan klaim dengan empat kolom: klaim, keputusan pembaca yang terpengaruh, bukti yang digunakan, dan kekuatan rumusan kata. Kolom terakhir penting. Bukti mungkin mendukung "dapat," "biasanya," atau "diperlukan," tetapi tidak secara otomatis "selalu," "terbaik," atau "pasti." Pertahankan kondisi dan batasan dari sumber.
Pilihlah sumber asli atau pihak pertama jika mereka mendokumentasikan hal itu sendiri. Penjelasan W3C mengenai WCAG 2.2 Reading Level, misalnya, menyatakan bahwa teks kompleks harus memiliki versi yang lebih mudah dipahami atau konten tambahan ketika tuntutan membaca yang ditentukan terlampaui. Seorang editor dapat menggunakan sumber tersebut untuk membenarkan pemeriksaan kompleksitas, sambil menghindari kesimpulan yang tidak berdasar bahwa satu skor keterbacaan membuat setiap artikel dapat diakses.
Bukti harus muncul di samping klaim yang didukungnya, seperti dalam contoh tersebut, daripada dalam daftar sumber yang tidak terkait. Daftar sumber berguna untuk peninjauan, tetapi tidak dapat memperbaiki paragraf yang rumusan katanya melampaui buktinya. Periksa tanggal, versi, dan cakupan, terutama untuk instruksi yang terikat dengan perangkat lunak, standar, atau kebijakan.
Tinjau kegunaan dan keterbacaan sebagai bagian dari penyelesaian tugas
Artikel yang mudah dibaca bukan sekadar menyenangkan; artikel ini mengurangi upaya yang diperlukan untuk menemukan, memahami, dan menerapkan instruksi. Tinjau draf pada titik penggunaan:
Panduan W3C menjelaskan bahwa kata-kata pendek dan umum serta kalimat yang lebih pendek umumnya lebih mudah diuraikan, sementara juga mencatat bahwa materi pelajaran yang kompleks mungkin sesuai untuk audiens khusus. Itu berarti penyuntingan harus mengurangi kesulitan yang dapat dihindari tanpa menghilangkan presisi yang diperlukan. Jangan menyederhanakan sampai menghilangkan kondisi yang mengubah hasilnya.
Gunakan tabel untuk perbandingan berulang, daftar bernomor untuk urutan, dan paragraf pendek untuk penalaran. Jika suatu langkah membutuhkan keputusan, letakkan kondisinya tepat sebelum tindakan. Jika suatu istilah tidak dapat dihindari, definisikan saat pertama kali digunakan dan gunakan istilah yang sama setelahnya.
Bacalah artikel sekali sebagai pembaca cepat (skimmer) dan sekali sebagai pelaku (doer). Skimmer harus dapat mengidentifikasi hasil yang dijanjikan, prasyarat, dan rute menuju jawaban. Pelaku harus dapat melakukan langkah-langkah tanpa merekonstruksi urutan yang dimaksudkan oleh penulis.
Jalankan uji pembaca sebelum publikasi
Pemeriksaan pra-publikasi terkuat adalah uji tugas kecil dengan orang yang menyerupai pembaca yang dituju tetapi tidak menulis draf tersebut. Beri mereka pernyataan tugas dan artikel tersebut. Minta mereka untuk bekerja secara mandiri, hanya menuturkan ke mana mereka melihat atau apa yang mereka butuhkan—bukan apakah mereka menyukai artikel tersebut.
Amati apakah mereka:
Catat titik-titik kendala yang tepat: kolom yang hilang, label yang ambigu, kondisi yang terlewati, hasil yang tidak dapat dijelaskan, atau ketergantungan eksternal. Jangan menganggap tebakan pembaca yang berhasil sebagai bukti bahwa artikel tersebut jelas. Tanyakan, "Apa di dalam artikel yang memberi tahu Anda untuk melakukan itu?" Jika jawabannya adalah "Saya sudah tahu," draf tersebut mungkin masih memiliki celah.
Setelah pengujian, klasifikasikan setiap masalah sebagai memblokir, memperlambat, atau kosmetik. Perbaiki masalah yang memblokir terlebih dahulu: prasyarat yang hilang, ambiguitas yang berisiko, urutan yang salah, dan alur pengecualian yang tidak ada. Kemudian uji ulang alur yang telah diubah. Uji pembaca tidak menetapkan kegunaan universal, tetapi dapat menunjukkan apakah tugas yang dinyatakan dapat dicapai oleh orang lain selain penulis.
Gunakan analitik di kemudian hari dan tafsirkan dengan cermat
Analitik dapat menunjukkan apa yang terjadi setelah publikasi—seperti kunjungan, pencarian, keluar, atau interaksi—tetapi metrik ini saja tidak membuktikan bahwa pembaca menyelesaikan tugas. Kunjungan yang singkat mungkin berarti jawaban ditemukan dengan cepat; kunjungan yang lama mungkin berarti pembaca bingung. Anggaplah data perilaku sebagai dorongan untuk penyelidikan, bukan sebagai pengganti audit alur penyelesaian.
Jika data tersedia, hubungkan ke hipotesis tertentu: "Pembaca mungkin tidak menemukan prasyarat," atau "Cabang pemecahan masalah mungkin tidak jelas." Periksa bagian yang relevan, ulangi uji tugas, dan revisi hanya jika bukti mendukung perubahan tersebut. Hindari mengubah metrik menjadi klaim tentang kegunaan tanpa mengamati atau memverifikasi hasil pembaca.
Panduan Google yang mengutamakan orang (people-first) meminta pembuat konten untuk mengevaluasi kualitas konten, sumber, kelengkapan, dan apakah pembaca mencapai tujuan mereka. Pertanyaan-pertanyaan tersebut selaras dengan audit ini, tetapi tidak ada dokumen sistem penelusuran yang dapat menyatakan bahwa draf tertentu menyelesaikan tugas tertentu. Keputusan editorial tetap didasarkan pada draf, buktinya, dan alur yang diamati.
Pertanyaan umum
Berapa lama audit alur penyelesaian harus dilakukan?
Waktunya harus sesuai dengan kompleksitas tugas. Artikel prosedural pendek mungkin memerlukan buku catatan klaim dan satu uji pembaca; panduan multi-cabang mungkin memerlukan peta langkah untuk setiap rute. Audit selesai ketika alur yang diperlukan dan pengecualiannya telah diperiksa, bukan ketika waktu yang ditentukan telah berlalu.
Apakah jumlah kata yang tinggi merupakan bukti bahwa artikel tersebut berguna?
Tidak. Penjelasan tambahan hanya membantu bila mendukung keputusan atau tindakan yang diperlukan. Artikel yang lebih pendek dapat menyelesaikan tugas yang sempit secara lengkap, sementara artikel yang panjang dapat menghilangkan satu input penting.
Haruskah setiap artikel menyertakan uji pembaca?
Untuk artikel praktis, uji tugas sebelum publikasi sangat informatif jika memungkinkan. Jika tidak ada pembaca uji yang tersedia, lakukan langkah-langkahnya sendiri menggunakan input yang dinyatakan dan dokumentasikan asumsi apa pun; anggap itu sebagai bukti yang lebih lemah daripada uji pembaca independen.
Apa aturan keputusan publikasi yang paling sederhana?
Publikasikan ketika pembaca yang dituju dapat mengidentifikasi keterterapan, memperoleh input yang diperlukan, menyelesaikan alur utama, menafsirkan hasil, dan menangani pengecualian yang relevan—dengan klaim yang didukung pada tingkat kekuatan yang dinyatakan. Jika tidak, revisi langkah rusak yang spesifik dan uji lagi.
