Contoh desain prototype aplikasi interaktif

Contoh desain prototype aplikasi yang efektif di Indonesia menguji keputusan pengguna, bukan hanya perpindahan layar. Buat alur dari nomor telepon berkode +62 ke OTP, lalu pembayaran dengan QRIS, transfer bank, atau e-wallet. Tampilkan nominal harga dan saldo dalam Rupiah agar pengguna dapat menilai biaya, metode bayar, dan konfirmasi transaksi secara realistis.

Poin-poin utama

• •Mulai prototype dari skenario tugas pengguna, misalnya menyelesaikan pembayaran sampai bukti transaksi.
• •Gunakan format lokal: nomor telepon +62 serta harga, biaya, dan saldo dalam Rupiah.
• •Uji pilihan metode pembayaran sebelum layar OTP agar keputusan pengguna dapat diamati.
• •Hubungkan layar utama, kondisi gagal, kembali, ubah metode, dan konfirmasi; jangan hanya membuat jalur sukses.

Isi halaman ini

• •Tentukan tugas yang benar-benar ingin diuji
• •Susun layar prototype untuk alur pembayaran lokal
• •Buat interaksi dan keadaan gagal di Figma
• •Jalankan uji tugas dan catat keputusan pengguna

Tentukan tugas yang benar-benar ingin diuji

Dalam contoh desain aplikasi figma, kesalahan umum adalah langsung menghubungkan semua layar tanpa pertanyaan pengujian. Mulailah dari satu tugas: pengguna membeli produk, memilih metode pembayaran, memasukkan OTP bila diperlukan, lalu memastikan transaksi berhasil. Tugas ini cukup untuk melihat apakah urutan informasi dan tindakan sudah masuk akal.

Tuliskan keputusan pada tiap titik layar. Pada halaman ringkasan pesanan, pengguna perlu memutuskan apakah jumlah harga, ongkir, diskon, dan total sudah benar. Di layar pembayaran, pengguna memilih QRIS, transfer bank, atau e-wallet Indonesia. Sesudah pilihan dibuat, tampilkan instruksi yang sesuai, bukan layar pembayaran generik yang sama untuk semua metode.

Gunakan nilai yang terasa nyata, misalnya seluruh harga, biaya, dan saldo ditulis dalam Rupiah. Jangan memakai simbol mata uang asing atau angka tanpa konteks. Untuk masuk atau verifikasi, buat kolom nomor telepon yang menerima awalan +62, kemudian lanjutkan ke layar OTP. Dengan begitu, sesi uji mengungkap apakah pengguna memahami apa yang harus dilakukan sebelum transaksi dikonfirmasi.

Susun layar prototype untuk alur pembayaran lokal

Urutan minimum dapat dimulai dari keranjang, alamat atau detail pesanan, ringkasan pembayaran, pemilihan metode, instruksi pembayaran, status verifikasi, dan bukti transaksi. Rancang setiap layar sebagai satu keputusan utama. Tombol utama pada ringkasan dapat berbunyi Pilih metode pembayaran, bukan langsung Bayar, karena pengguna belum memilih cara bayar.

Untuk QRIS, tampilkan opsi QRIS di daftar metode dan lanjutkan ke layar yang memberi konteks pemindaian kode. QRIS merupakan standar pembayaran kode QR nasional yang dikelola Bank Indonesia; gunakan istilah QRIS secara konsisten dengan rujukan resmi Bank Indonesia. Untuk transfer bank, prototype dapat meminta pengguna memilih bank lalu melihat nominal dan batas waktu pembayaran. Untuk e-wallet Indonesia, tampilkan opsi e-wallet sebagai metode terpisah agar peserta uji tidak mengira prosesnya sama dengan transfer.

Setelah pengguna kembali dari metode pembayaran, perbarui ringkasan: metode terpilih, total dalam Rupiah, serta tombol konfirmasi. Buat juga jalur ketika pengguna mengganti metode. Jalur ini sering lebih penting daripada animasi perpindahan layar karena menunjukkan apakah pilihan sebelumnya tetap jelas.

Buat interaksi dan keadaan gagal di Figma

Pada proses desain ui ux aplikasi menggunakan figma, gunakan frame untuk setiap keadaan yang akan diuji, lalu sambungkan tombol, kartu metode, dan navigasi kembali melalui panel Prototype. Beri nama frame berdasarkan keadaan, misalnya pembayaran-pilih-metode, qris-instruksi, otp-salah, dan transaksi-berhasil. Penamaan ini memudahkan tim menelusuri alur saat hasil uji dibahas.

Jangan hanya menautkan jalur ideal. Siapkan setidaknya keadaan nomor telepon tidak lengkap setelah awalan +62, OTP salah atau kedaluwarsa, QRIS belum dibayar, transfer belum terverifikasi, dan e-wallet dibatalkan. Pada keadaan tersebut, jelaskan tindakan berikutnya dengan teks singkat: kirim ulang OTP, pilih metode lain, atau kembali ke ringkasan pesanan.

Tampilan harga perlu tetap konsisten pada semua cabang. Jika total berubah karena biaya metode, tampilkan perubahan itu sebelum pengguna menekan konfirmasi. Gunakan format Rupiah yang sama pada keranjang, halaman pembayaran, dan bukti transaksi. Figma menyediakan dokumentasi resmi untuk membuat koneksi prototype, mengatur titik awal alur, dan membagikan prototype untuk ditinjau; pakai fitur itu untuk menguji alur, bukan sekadar mempresentasikan gambar layar.

Jalankan uji tugas dan catat keputusan pengguna

Berikan peserta satu instruksi yang tidak mengarahkan, misalnya: “Bayar pesanan ini menggunakan metode yang menurut Anda paling sesuai, lalu pastikan transaksi selesai.” Jangan menyebut QRIS atau e-wallet sejak awal. Tujuannya adalah melihat metode apa yang dicari pengguna, informasi apa yang mereka periksa, dan pada titik mana mereka ragu.

Catat tiga hal pada setiap langkah: pilihan pengguna, alasan yang mereka ucapkan, dan layar tempat mereka berhenti. Jika pengguna membuka QRIS tetapi kembali ke transfer bank, tanyakan informasi apa yang kurang, bukan apakah desainnya bagus. Jika mereka tidak melanjutkan dari nomor +62 ke OTP, periksa label kolom, contoh format, dan pesan kesalahannya.

Prioritaskan perbaikan berdasarkan dampak pada penyelesaian tugas. Perjelas total Rupiah sebelum konfirmasi, bedakan tindakan bayar untuk QRIS, transfer bank, dan e-wallet, lalu uji ulang. Hindari mengubah seluruh visual setelah satu sesi; ubah keputusan atau informasi yang terbukti membingungkan. Prototype yang baik memberi bukti bahwa pengguna memahami urutan transaksi sebelum tim membangun integrasi pembayaran yang sebenarnya.

Rujukan isi layar untuk prototype pembayaran Indonesia

Kesalahan yang sering terjadi

Semua metode pembayaran diarahkan ke satu layar instruksi yang sama.

Buat cabang berbeda untuk QRIS, transfer bank, dan e-wallet agar peserta dapat menilai informasi serta tindakan yang relevan.

OTP hanya dibuat sebagai layar dekoratif tanpa kondisi salah atau kirim ulang.

Tambahkan keadaan OTP salah, kedaluwarsa, dan kirim ulang untuk menguji pemulihan pengguna.

Nominal pada ringkasan dan konfirmasi berbeda atau tidak menyebut Rupiah.

Pakai format Rupiah yang konsisten pada setiap layar dan tampilkan perubahan biaya sebelum konfirmasi.

Pengujian hanya meminta peserta menekan tombol yang sudah disebutkan.

Berikan tujuan transaksi tanpa menyebut metode pembayaran agar keputusan alami pengguna dapat diamati.

Pertanyaan yang sering diajukan

Apa bedanya prototype dan mockup aplikasi?

Mockup aplikasi adalah tampilan statis yang menunjukkan susunan visual sebuah layar, seperti halaman pembayaran atau halaman OTP. Prototype aplikasi menghubungkan layar dan respons interaksi sehingga pengguna dapat menjalankan tugas, misalnya memilih QRIS, kembali memilih transfer bank, memasukkan OTP, lalu melihat konfirmasi transaksi dalam Rupiah.

Alur apa yang perlu diuji dalam prototype?

Prototype aplikasi perlu menguji alur yang menentukan keberhasilan tugas pengguna: masuk dengan nomor telepon +62, verifikasi OTP, memilih QRIS, transfer bank, atau e-wallet, memeriksa total dalam Rupiah, mengonfirmasi pembayaran, dan menangani kegagalan. Sertakan juga jalur kembali, perubahan metode pembayaran, OTP salah, dan transaksi yang belum terverifikasi.

Bagaimana membuat prototype QRIS?

Untuk membuat prototype QRIS, buat layar pemilihan metode pembayaran dengan opsi QRIS, lalu hubungkan ke layar instruksi pemindaian kode QR dan status pembayaran. Tampilkan total transaksi dalam Rupiah sebelum pengguna melanjutkan, sediakan status belum dibayar atau gagal, dan beri jalur kembali untuk mengganti ke transfer bank atau e-wallet.

Apakah prototype pembayaran harus memakai data transaksi asli?

Prototype pembayaran tidak harus memakai data transaksi asli. Gunakan data contoh yang aman, tetapi pertahankan konteks Indonesia: format nomor +62, nominal dalam Rupiah, serta pilihan QRIS, transfer bank, dan e-wallet. Yang diuji adalah pemahaman pengguna terhadap urutan, biaya, status, dan konfirmasi transaksi, bukan pemrosesan pembayaran nyata.

Langkah selanjutnya

Rancang urutan layar interaktif dengan floow.design sebelum memindahkannya ke tool prototyping. Mulai dari keputusan pembayaran, OTP, dan konfirmasi transaksi, lalu gunakan hasil uji untuk menentukan layar serta keadaan yang benar-benar perlu dibuat.

---

Rancang layarnya terlebih dahulu

Jelaskan aplikasi Anda dengan bahasa sederhana, lalu floow.design akan membuatkan layar iOS dan Android yang siap Anda sempurnakan dan serahkan ke tim pengembang.

Mulai desain gratis →

---

Sumber

• •Bank Indonesia — QRIS
• •Figma Help Center — Prototype

Baca juga

• •Contoh desain aplikasi mobile figma
• •Contoh desain aplikasi android yang siap rilis
• •Contoh desain aplikasi kesehatan Indonesia