Nilai Tebakan Bukan Data: Tandai Placeholder di Mockup

Waktu meninjau mockup formulir peminjaman bersama klien, saya menyadari sesuatu di layar. Beberapa angka, seperti rentang harga paket dan daftar fasilitas pendukung, tidak pernah keluar dari mulut klien. Saya yang menebaknya supaya mockup terlihat lengkap dan profesional. Tidak ada satu penanda pun di layar yang membedakan mana data asli klien dan mana asumsi saya.

Awalnya saya menganggap mockup hanyalah gambar sementara. Detail yang dibuat-buat tidak berbahaya karena tujuannya memberi gambaran visual awal. Klien pasti paham ini ilustrasi desain, begitu pikir saya.

Kenyataannya, tebakan yang tidak ditandai bisa bertahan sampai jadi tangkapan layar presentasi resmi. Cukup satu kalimat "tapi di mockup tertulis demikian" untuk memindahkan angka tebakan itu ke daftar ekspektasi. Sebuah deliverable yang mencampur nilai verbatim dari sumber dengan tebakan tanpa penanda sebenarnya berbohong tentang tingkat kepastiannya sendiri.

Ilusi Kepastian di Mockup

Pada proyek sistem KotaPortal, mockup formulir peminjaman punya daftar fasilitas pendukung dan dropdown tingkat kegiatan yang tidak sepenuhnya ditentukan dokumen sumber. Dokumen sumbernya terpotong di tengah daftar, jadi opsi yang tampil di mockup sebagian adalah tebakan masuk akal dari saya supaya tampilan tetap utuh dan bisa dievaluasi.

Perbaikannya: setiap nilai yang bukan dari sumber ditandai sebagai placeholder yang terikat pada pertanyaan terbuka bernomor ke klien, butir 7 sampai 10. Pertanyaannya spesifik: paket harga dan basis penetapannya, daftar lengkap fasilitas pendukung, daftar resmi nama fasilitas yang bisa dipinjam, dan opsi tingkat kegiatan. Seksi formulir yang verbatim dari sumber, bagian A sampai G, tidak disentuh sama sekali. Satu kalimat ditambahkan ke dokumen desain: nilai yang bukan dari sumber jangan dianggap data klien sebelum dijawab.

Praktiknya bisa dimulai sesederhana ini. Saat menyalin nilai dari dokumen sumber ke mockup, saya biasakan menyalin dalam keadaan terotori oleh label asalnya: satu keterangan kecil di file kerja yang menyebut butir katalog asalnya. Nilai yang sengaja diisi tebakan dapat label berbeda plus nomor pertanyaan. Dua label itu yang kemudian menentukan nasib tiap nilai: label sumber tinggal dipakai, label tebakan wajib punya tiket jawaban sebelum mockup dipakai sebagai acuan.

Bentuk paling sederhana dari penanda ini cuma dua label. "Sumber: katalog" untuk nilai yang disalin verbatim, dan "PLACEHOLDER, pertanyaan #9" untuk tebakan. Label itu bahkan tidak perlu tampil di presentasi final; cukup hidup di file kerja dan di catatan pertanyaan. Yang penting setiap angka bisa dilacak balik: ia datang dari dokumen mana, atau ia menunggu jawaban butir nomor berapa.

Kalau developer menerima mockup tanpa penanda, mereka akan membangun logika di atas angka tebakan itu. Kalau angkanya salah, validasi formulir ditulis ulang. Biayanya jauh lebih mahal daripada satu label penanda di tahap desain.

Penanda TBC: Kebiasaan Rekayasa yang Sering Dilewat

Panduan rekayasa dokumen persyaratan punya designation baku untuk nilai yang belum dikonfirmasi: To Be Confirmed untuk yang masih dievaluasi, To Be Determined atau To Be Supplied untuk yang keberadaannya diketahui tapi belum tersedia [5]. Kebiasaan menandai asal-usul nilai ini sering dilewatkan developer karena dianggap birokrasi yang memperlambat. Padahal ini praktik penjaminan mutu termurah di seluruh alur kerja. Prinsipnya satu kalimat: nilai tebakan bukan data.

Kalau kamu pernah lihat demo yang angka-angkanya terlalu rapi, kemungkinan besar kamu sedang melihat kumpulan placeholder yang lupa dipangkas labelnya. Itu bukan alasan untuk malu-malu mengisi mockup dengan dugaan; mockup justru butuh angka supaya proporsi layarnya bisa dinilai. Yang dibutuhkan hanya kejujuran soal asal angkanya, dan itu biayanya cuma satu label.

Aturan Meja Kerja

Mulai sekarang, mockup atau spesifikasi yang tidak bisa menunjukkan nilai mana yang verbatim dari sumber dan mana tebakan tidak akan meninggalkan meja saya. Setiap tebakan dapat nomor pertanyaan yang bisa dilacak, lalu dihapus begitu jawaban resmi masuk dan dokumen diperbarui.

Disiplin ini menghilangkan ambiguitas sebelum satu baris kode pun ditulis. Ketika sebuah angka muncul di layar, semua orang tahu itu fakta dari klien atau pengisi ruang sementara. Kalau pengisi ruang, ia bukan dasar keputusan bisnis.

Sumber

• [5] QRACorp — 21 Top Engineering Tips for Writing an Exceptionally Clear Requirements Document