Ide aplikasi sering terasa sederhana ketika masih berupa satu kalimat. Begitu mulai dikerjakan, muncul daftar baru: akun pengguna, pengingat, laporan, pembayaran, dan fitur lain yang kelihatannya sayang dilewatkan.
Untuk Daddy yang membangun di sela pekerjaan, daftar itu perlu diberi batas. Mulailah dari pekerjaan pengguna yang ingin dibantu, lalu buat bentuk paling sederhana yang cukup untuk menguji dugaanmu.
Saya akan memisahkan prosesnya menjadi beberapa tahap. Setiap tahap menghasilkan sesuatu yang bisa diperiksa sebelum waktu dan biaya ditambah. Jadwalnya mengikuti kebutuhan pekerjaan, termasuk waktu belajar dan bantuan teknis yang tersedia.
Tulis masalah dan calon pengguna secara konkret
Contoh rekaan: seorang pemilik jasa ingin melihat permintaan jadwal yang belum ditanggapi. Saat ini ia menyimpan catatan di beberapa percakapan sehingga harus memeriksa ulang satu per satu.
Sebelum membangun aplikasi, pelajari bagaimana pekerjaan itu dilakukan sekarang. Tanyakan kejadian terakhir, cara mengatasinya, dan bagian yang masih menyulitkan. Orang yang bersedia diwawancarai belum tentu membutuhkan produk yang kamu bayangkan.
Periksa juga apakah alat atau proses yang sudah ada dapat membantu. Bisa jadi kebutuhan awal cukup ditangani dengan perubahan pencatatan. Aplikasi baru perlu mempunyai alasan untuk menambah biaya dan pekerjaan pengguna.
Catat yang sudah diketahui dan yang masih berupa dugaan. Validasi ide sebelum membuat produk membahas cara membedakan respons positif dari bukti kebutuhan.
Buat sketsa alur yang dapat dibicarakan
Untuk contoh tadi, sketsa dapat menunjukkan daftar permintaan, halaman rincian, dan cara menandai bahwa permintaan sudah ditanggapi. Bentuk awalnya boleh berupa gambar sederhana.
Tunjukkan dari mana pengguna mulai, informasi yang dibutuhkan, tindakan yang dilakukan, dan hasil yang seharusnya terlihat. Wireframe membantu membahas susunan tersebut tanpa harus menyelesaikan tampilan akhir.
Ajak calon pengguna yang relevan melihat alurnya. Berikan tugas yang jelas, misalnya mencari permintaan yang belum dijawab. Amati bagian yang dipahami dan yang membingungkan, lalu tanyakan alasannya.
Sketsa belum membuktikan bahwa data tersimpan atau pengingat terkirim. Beri tahu bagian yang masih berupa simulasi agar percobaan tidak menimbulkan kesan bahwa layanan sudah berjalan penuh.
Ubah alur menjadi catatan kebutuhan
Setelah alurnya cukup jelas, tulis catatan yang dapat dipakai saat membangun. Tidak harus panjang, tetapi perlu mengurangi tebakan.
| Bagian | Yang perlu dijelaskan |
|---|---|
| Pengguna dan tugas | Siapa yang memakai dan pekerjaan yang harus selesai |
| Informasi masuk | Data yang diperlukan, asalnya, dan yang tidak perlu dikumpulkan |
| Hasil | Perubahan yang dapat dilihat atau diperiksa pengguna |
| Akses | Siapa yang boleh melihat atau mengubah bagian tertentu |
| Keadaan gagal | Respons ketika data kosong, jaringan bermasalah, atau tindakan terulang |
| Batas versi awal | Fungsi yang tersedia dan yang belum dijanjikan |
| Pemeriksaan | Cara menunjukkan bahwa kebutuhan utama bekerja |
Untuk contoh jadwal, “bisa mengubah status” masih kurang jelas. Status apa yang tersedia, siapa yang boleh mengubah, dan bagaimana memastikan perubahan tidak menghilangkan catatan lama?
Jika memakai pengembang atau bantuan AI, baca kembali hasil yang dibuat terhadap catatan tersebut. Tampilan yang sudah mirip sketsa belum membuktikan seluruh aturan bekerja.
Bangun bagian yang diperlukan untuk mencoba pekerjaan utama
Pilih lingkup yang sanggup kamu buat dan uji. Tidak ada kewajiban membatasi versi awal tepat tiga fitur. Satu alur sederhana pun bisa memerlukan beberapa fungsi pendukung agar dapat digunakan dengan benar.
Pisahkan gagasan tambahan ke catatan lain. Tinjau apakah gagasan itu memang dibutuhkan untuk menyelesaikan tugas utama, memperbaiki masalah yang ditemukan, atau masih sekadar kemungkinan.
Boleh memakai alat yang sudah tersedia jika sesuai kebutuhan dan kemampuanmu. Periksa biaya, ketergantungan layanan, pemindahan data, dan siapa yang bisa merawatnya. Alat tanpa kode tidak menghilangkan pekerjaan memahami akses, data, serta kegagalan.
Gunakan data contoh ketika itu cukup untuk tahap awal. Sebelum menerima data nyata, pastikan pengelolaannya memang siap. Jika belum mampu menilai bagian teknis yang penting, cari bantuan yang sesuai atau perkecil lingkup percobaan.
Uji dari awal sampai hasilnya tersimpan
Coba seluruh tugas, bukan hanya tombol satu per satu. Dalam contoh ini: masukkan permintaan, buka rinciannya, ubah status, keluar, lalu periksa lagi dengan akses yang sesuai.
Coba juga keadaan yang bisa mengganggu penggunaan: kolom kosong, pengiriman ganda, waktu yang keliru, dan koneksi yang putus. Periksa apakah kegagalan terlihat dan pengguna tahu langkah berikutnya.
Untuk layanan dengan beberapa pengguna, periksa batas akses antarakun. Untuk fungsi pembayaran, gunakan fasilitas pengujian yang disediakan penyedia. Jangan mencatat transaksi uji sebagai pembelian pelanggan.
Simpan temuan beserta langkah untuk mengulang masalahnya. Prioritaskan kesalahan yang menghambat tugas utama, membuka data kepada pihak yang salah, atau menghasilkan janji yang tidak dapat dipenuhi.
Perhatikan orang lain saat mencoba
Pengujian oleh pembuat dan percobaan oleh calon pengguna menjawab pertanyaan yang berbeda. Pembuat sudah mengetahui letak tombol dan maksud istilahnya.
Pedoman pengujian kegunaan GOV.UK menjelaskan pengamatan ketika peserta mencoba menyelesaikan tugas. Pilih tugas yang relevan dan sampaikan tujuan tanpa membocorkan langkah jawabannya. Amati serta dengarkan, lalu tanyakan bagian yang belum jelas.
Jelaskan bahwa yang sedang diperiksa adalah layanan, bukan kemampuan peserta. Jika merekam, jelaskan dan minta persetujuan yang sesuai. Gunakan data serta kondisi uji yang dapat kamu kelola dengan layak.
Jumlah peserta mengikuti pertanyaan dan variasi pengguna yang perlu dipahami. Beberapa percobaan bisa menemukan masalah, tetapi belum membuktikan seluruh aplikasi bebas kesalahan.
Buka percobaan terbatas sesuai kesiapan
Setelah bagian utama diperiksa, kamu dapat mengundang pengguna yang memahami status percobaannya. Jelaskan fungsi yang tersedia, batas penggunaan, masalah yang sudah diketahui, dan cara meminta bantuan.
Bedakan orang yang tertarik, bersedia mencoba, memesan, dan sudah membayar. Kalimat “kalau ada, saya mau beli” belum menjadi pembayaran di muka.
Jika menerima pembayaran, jelaskan apa yang diterima, waktunya, biaya, serta ketentuan pembatalan dan pengembalian. Panduan meluncurkan produk digital pertama membahas kesiapan penawaran dan alur pembeli.
Tanggal yang sudah direncanakan membantu mengatur pekerjaan. Jika fungsi penting belum siap, ubah lingkup atau jadwal dan komunikasikan dampaknya. Jangan membuka layanan apa pun kondisinya hanya untuk memenuhi kalender.
Tentukan pekerjaan setelah percobaan dimulai
Catat siapa yang menangani pertanyaan, pemeriksaan gangguan, biaya layanan, dan perubahan yang diperlukan. Tentukan juga cara menghentikan percobaan tanpa meninggalkan pengguna dengan kewajiban yang tidak jelas.
Pelajari apa yang benar-benar dipakai dan mengapa. Permintaan fitur boleh dicatat, tetapi periksa kebutuhan di baliknya sebelum menambah pekerjaan. Satu permintaan tidak selalu mewakili seluruh pengguna.
Gabungkan pengamatan penggunaan, pertanyaan, dan data yang tersedia. Jika informasi masih sedikit, katakan batasnya. Kamu bisa melanjutkan, mengubah arah, memperkecil, atau menghentikan produk berdasarkan temuan.
Langkah awalnya cukup konkret: tulis satu pekerjaan pengguna, gambar alurnya, dan tentukan hal yang belum kamu ketahui. Rencana membangun kemudian mengikuti pertanyaan itu, bukan daftar fitur yang terus bertambah.
