Pencari yang mengetik kebutuhan spesifik sering sudah memahami pekerjaan yang ingin diselesaikan. Ia membutuhkan bantuan untuk menilai apakah suatu produk cocok, apa yang harus disiapkan, dan langkah berikutnya. Halaman use-case dapat membantu keputusan itu jika isinya menunjukkan kemampuan nyata produk.
BOFU adalah istilah untuk kebutuhan yang dekat dengan keputusan pembelian atau penggunaan. Kedekatan ini tetap perlu dibaca dari konteks. Kata seperti aplikasi atau software belum otomatis berarti seseorang siap membeli; ia mungkin masih mempelajari pilihan dan batasnya.
Cocokkan kebutuhan dengan kemampuan nyata
Mulai dengan satu tugas, bukan daftar keyword. Contoh ilustratif: layanan berbagi file ingin membuat halaman untuk desainer lepas yang mengirim pratinjau kepada klien tanpa meminta klien memasang aplikasi desain.
Pertanyaan utama bukan sekadar apakah produk memiliki fitur berbagi. Periksa apakah format yang dibutuhkan dapat dipratinjau, apakah penerima memerlukan akun, bagaimana akses diberikan, dan batas apa yang berlaku. Semua jawaban harus mengikuti kemampuan produk yang benar-benar tersedia.
Jika fitur yang dibutuhkan belum ada, jangan membuat halaman yang menyiratkan sebaliknya. Kamu bisa menjelaskan alternatif yang memang didukung, tetapi pembaca perlu mengetahui perbedaannya sebelum mengambil keputusan.
Buat matriks kebutuhan, fitur, dan bukti
| Kebutuhan pembaca | Kemampuan yang harus diperiksa | Bukti yang cocok |
|---|---|---|
| Klien melihat pratinjau | Format dan perangkat yang didukung | Contoh alur dengan berkas yang relevan |
| Berkas hanya untuk penerima tertentu | Pengaturan akses yang tersedia | Tampilan pengaturan dan penjelasan batas |
| Pengirim mengenali versi final | Cara penamaan atau pengelolaan versi | Contoh sebelum dan sesudah revisi |
| Memulai tanpa kebingungan | Prasyarat dan langkah awal | Instruksi yang dapat diikuti |
Tabel ini adalah alat perencanaan. Ia tidak menyatakan bahwa semua layanan berbagi file mempunyai fitur tersebut. Isi kolom kemampuan dari pemeriksaan produk sendiri dan tandai hal yang belum diketahui.
Setiap fitur perlu terhubung ke tugas pembaca. Daftar panjang kemampuan yang tidak berkaitan dapat menutupi jawaban inti. Jika suatu fitur hanya tersedia dalam paket tertentu, letakkan penjelasan itu dekat dengan klaimnya.
Susun bagian awal agar kecocokan cepat dipahami
Judul utama sebaiknya menyebut tugas dengan bahasa yang wajar. Untuk contoh tadi, konsep judulnya dapat berbunyi “Kirim pratinjau desain yang bisa dibuka klien”. Kalimat pendukung kemudian menjelaskan bagaimana produk membantu, dengan batas yang telah diverifikasi.
Hindari menumpuk kata “terbaik”, “termurah”, atau “pasti berhasil” tanpa dasar. Pembaca lebih terbantu oleh informasi konkret: apa yang bisa dibuka, langkah yang dibutuhkan penerima, serta kapan solusi itu kurang sesuai.
Letakkan langkah berikutnya sesuai kesiapan pembaca. Jika ada contoh yang bisa dilihat tanpa akun, ajakan “Lihat contoh pratinjau” dapat membantu evaluasi. Jika perlu akun untuk mulai, label tindakan harus mengatakannya dengan jelas. Jangan menjanjikan unduhan langsung bila tautan sebenarnya membawa ke formulir penjualan.
Tunjukkan alur penggunaan yang relevan
Setelah kecocokan awal, jelaskan alur singkat dari kondisi sebelum memakai produk hingga hasil yang dapat diperiksa. Dalam contoh ini, alurnya dapat berupa menyiapkan berkas yang didukung, membuat tautan dengan akses yang sesuai, lalu memeriksa tampilan dari sisi penerima.
Gunakan screenshot atau demonstrasi nyata ketika tersedia. Ilustrasi dapat menjelaskan konsep, tetapi jangan tampilkan seolah merupakan tangkapan layar fitur yang sudah ada. Nama berkas dan isi contoh perlu aman untuk dibagikan.
Jelaskan pula kegagalan yang mungkin membatasi tugas: format tidak didukung, ukuran melewati batas, atau pengaturan akses belum sesuai. Beri rute bantuan yang benar-benar tersedia. Halaman yang hanya menunjukkan kondisi ideal menyisakan pekerjaan penting bagi pembaca.
Tentukan bagian yang perlu unik
Beberapa bagian seperti identitas perusahaan dan kebijakan umum dapat sama di berbagai halaman. Namun, kebutuhan utama, alur penggunaan, bukti, serta pertanyaan keputusan harus sesuai use-case yang sedang dibahas.
Jangan membuat halaman baru hanya dengan mengganti kata desainer menjadi fotografer atau konsultan. Periksa apakah kebutuhan, berkas, langkah, dan batasnya benar-benar berbeda. Jika jawaban sama, satu halaman dengan contoh tambahan mungkin lebih jelas dan lebih mudah dipelihara.
Tidak ada panjang tulisan atau persentase teks unik yang otomatis membuat halaman berguna. Ukuran yang lebih operasional adalah apakah pembaca bisa menilai kecocokan dan memahami langkah berikutnya tanpa mencari informasi dasar yang hilang.
Periksa kelengkapan sebelum menilai hasil
Minta pemeriksa yang belum menulis halaman untuk menjawab empat pertanyaan: untuk siapa halaman ini, tugas apa yang didukung, batas apa yang penting, dan apa yang terjadi ketika tombol ditekan? Jika jawabannya berbeda dari kemampuan produk, revisi pesan sebelum memperluas distribusi.
Catat pertanyaan yang masih harus dijawab melalui dukungan pelanggan. Pola berulang dapat menunjukkan informasi yang perlu ditambahkan. Perubahan hasil penggunaan atau konversi tetap perlu dianalisis dengan konteks; jangan menganggap setiap perubahan berasal dari tulisan saja.
Halaman siap ketika klaim dapat diperiksa, contoh sesuai tugas, batas terlihat, dan langkah berikutnya bekerja seperti yang dijanjikan. Mulai dari satu use-case yang benar-benar didukung, lalu gunakan temuan pemeriksaan untuk menentukan apakah halaman tambahan memang dibutuhkan.
