Cara Membuat PRD Aplikasi Mobile: Kasus Tepi yang Sering Dilewatkan

Aplikasinya lolos testing di kantor: wifi kencang, semua izin sudah di-allow dari awal. Begitu dipakai user beneran di lapangan, sinyalnya putus-putus, dia pencet "Jangan Izinkan" pas diminta akses lokasi, layarnya putih, atau macet di loading, atau data yang tadi diisi hilang begitu saja. Bukan karena AI codingnya jelek. Karena PRD-nya cuma menjelaskan alur mulus, dan tidak satu pun kasus tepi ini ada di dalamnya.

Aplikasi mobile itu beda dari aplikasi web dalam satu hal penting: dipakai di perangkat yang koneksinya tidak stabil, izinnya bisa ditolak kapan saja, dan sesi penggunanya bisa berakhir tanpa pemberitahuan. PRD yang bagus menuliskan bagaimana aplikasi bersikap di kondisi-kondisi itu, bukan cuma di kondisi ideal.

Tulis alur layar, bukan daftar fitur lepas

Pengguna tidak mengalami aplikasi mobile sebagai kumpulan fitur, mereka mengalaminya sebagai urutan layar yang berpindah satu ke lainnya. PRD yang cuma mendaftar "ada fitur login, ada fitur checkout, ada fitur riwayat" membuat agent bebas menebak transisi antar layarnya, dan hasilnya sering ganjil: tombol back yang salah arah, atau layar sukses yang tidak jelas harus kembali ke mana.

1. Splash screen mengecek status login
2. Kalau belum login, masuk ke layar Login atau Daftar
3. Kalau sudah login, langsung ke Home
4. Dari Home, pengguna membuka Detail Item
5. Dari Detail, pengguna melakukan aksi lalu diarahkan ke layar Konfirmasi
6. Layar Sukses atau Gagal, masing-masing dengan tombol lanjutan yang jelas arahnya

Peta seperti ini memaksa kamu memutuskan hal-hal yang biasanya baru ketahuan pas testing: layar apa yang muncul kalau aksinya gagal, tombol back di layar konfirmasi mengarah ke mana, dan apakah pengguna bisa "nyasar" ke layar yang seharusnya tidak bisa diakses langsung.

Perhatikan juga titik masuk yang tidak lewat Home, misalnya pengguna membuka aplikasi lewat notifikasi atau lewat tautan berbagi dari teman. PRD perlu menyebutkan langsung meloncat ke layar mana untuk tiap titik masuk itu, bukan selalu balik ke Home dulu baru pengguna mencari sendiri ke mana harus pergi.

Kondisi offline lalu sinkron ulang

Sinyal hilang di tengah pemakaian itu kondisi normal, bukan kondisi darurat, jadi PRD wajib menjelaskan sikap aplikasi saat itu terjadi. Contoh acceptance criteria yang konkret: kalau pengguna mengisi form saat offline, data disimpan dulu di perangkat dan diberi label "menunggu sinkron", lalu terkirim otomatis begitu koneksi kembali, bukan hilang dan bukan juga gagal diam-diam tanpa pemberitahuan.

Tuliskan juga apa yang pengguna lihat selama menunggu sinkron itu, dan apa yang terjadi kalau data itu ternyata gagal terkirim setelah online lagi, misalnya karena sudah kedaluwarsa atau bentrok dengan data lain. Tanpa aturan ini, agent biasanya cuma menangani jalur "koneksi selalu lancar" dan diam-diam mengabaikan sisanya.

Kalau aplikasimu bisa dibuka dari lebih satu perangkat, atau datanya bisa berubah karena aksi orang lain sementara satu pengguna sedang offline, PRD juga perlu menjawab siapa yang menang kalau dua perubahan bentrok saat sinkron: versi yang tersimpan lebih dulu, versi paling baru, atau pengguna diminta memilih sendiri. Jarang jadi prioritas di awal, tapi begitu ada laporan "data saya berubah sendiri", biasanya inilah penyebabnya.

Sesi login kedaluwarsa di tengah pemakaian

Bayangkan pengguna sedang mengisi form panjang, lalu token sesinya kedaluwarsa sebelum sempat submit. PRD harus menentukan apakah sesi diperpanjang otomatis secara diam-diam selama pengguna masih aktif, atau pengguna diarahkan ke layar login lagi, dan kalau diarahkan ke login, apakah isian form yang belum ter-submit itu disimpan supaya tidak perlu diulang dari nol.

Pola yang umum dipakai: coba perbarui sesi di belakang layar tanpa mengganggu pengguna, dan baru tampilkan layar login kalau upaya itu sendiri gagal. Sebutkan juga apakah prosesnya berupa modal kecil di atas layar yang sedang dibuka, atau harus pindah ke halaman penuh, karena dua pilihan itu terasa sangat berbeda bagi pengguna yang sedang di tengah mengisi sesuatu.

Izin kamera, lokasi, dan notifikasi yang bisa ditolak

Setiap izin yang diminta aplikasi punya kemungkinan ditolak, dan ini bukan skenario langka - banyak pengguna, terutama di iOS, terbiasa menolak izin apa pun secara refleks saat pertama kali diminta. PRD harus menuliskan apa yang terjadi di setiap penolakan itu sebagai acceptance criteria, bukan dibiarkan jadi keputusan agent saat ngoding. Aturan umumnya sama: aplikasi tetap bisa dipakai tanpa fitur itu, bukan crash, blank, atau macet.

• Izin lokasi ditolak - tampilkan pesan yang menjelaskan fitur mana yang jadi tidak tersedia, lalu tetap izinkan pengguna melanjutkan tanpa fitur lokasi itu
• Izin kamera ditolak - alihkan ke opsi input manual atau upload dari galeri, bukan menutup seluruh alur
• Izin notifikasi ditolak - aplikasi tetap berjalan normal, hanya saja pengingat penting perlu ditampilkan juga di dalam aplikasi, bukan cuma mengandalkan push

Detail sekecil ini yang membedakan PRD yang acceptance criteria-nya bisa dicek, bukan PRD yang cuma menyebut nama fitur dan berharap agent menebak sendiri perilaku yang benar.

Notifikasi push: kapan, isi, dan reaksi saat di-tap

Push notification sering ditulis di PRD sebagai satu baris, "kirim notifikasi ke pengguna", padahal ada tiga keputusan yang perlu eksplisit: kapan notifikasi itu dikirim dan event apa yang memicunya, apa isi pesannya termasuk data dinamis seperti nama produk atau nomor pesanan, dan layar mana yang terbuka kalau pengguna men-tap notifikasi itu.

Kenapa detail ini bukan sekadar polish akhir

Kelima hal di atas, alur layar, offline, sesi, izin, dan notifikasi, biasanya tidak kelihatan waktu demo di kantor karena kondisi demo selalu ideal: wifi kencang, izin sudah di-allow, sesi baru login. Masalahnya baru muncul begitu aplikasi dipakai pengguna sungguhan dengan kondisi HP dan jaringan yang tidak kamu kendalikan. PRD yang menuliskan acceptance criteria untuk kondisi-kondisi ini dari awal berarti agent membangunnya sekali dengan benar, bukan menambal satu per satu setelah laporan bug mulai masuk.