Contoh desain aplikasi berdasarkan masalah pengguna

Contoh desain aplikasi yang kuat dimulai dari tugas nyata pengguna, bukan dari warna atau komponen UI. Untuk Indonesia, buat alur pesan perjalanan seperti konteks Gojek atau Grab, pembayaran Rupiah dengan QRIS, atau cek antrean dan kepesertaan seperti pola Mobile JKN. Dari satu tugas, susun layar masuk, aksi utama, status, dan bukti selesai.

Poin-poin utama

• •Pilih satu masalah dengan kata kerja jelas: pesan, bayar, lacak, atau daftar.
• •Rancang urutan layar dan status kegagalan sebelum menentukan warna, tipografi, atau ilustrasi.
• •Gunakan konteks lokal secara fungsional: Rupiah dan QRIS untuk pembayaran, serta antrean dan kepesertaan untuk layanan publik.
• •Untuk portofolio atau produk awal, satu alur lengkap lebih berguna daripada banyak layar yang tidak terhubung.

Isi halaman ini

• •Galeri: pesan perjalanan saat pengguna butuh berangkat
• •Galeri: bayar tagihan dengan Rupiah dan QRIS
• •Galeri: daftar layanan publik dan cek antrean
• •Cara memilih struktur sebelum gaya visual

Galeri: pesan perjalanan saat pengguna butuh berangkat

Masalahnya bukan “membuat aplikasi transportasi”, melainkan membantu pengguna mendapatkan kendaraan saat perlu pergi. Contoh desain aplikasi sederhana untuk kasus ini dapat memakai konteks layanan mobilitas seperti Gojek dan Grab di Indonesia: pengguna membuka aplikasi, menentukan titik jemput, memilih tujuan, melihat pilihan perjalanan, lalu memantau penjemputan.

Susun layar mobile dengan urutan berikut:

1. •Beranda peta dengan kolom lokasi jemput dan tujuan sebagai aksi paling dominan.
2. •Konfirmasi rute yang menunjukkan titik jemput, tujuan, dan opsi untuk mengubahnya.
3. •Pilihan layanan dengan informasi yang diperlukan untuk mengambil keputusan, tanpa memenuhi layar dengan variasi kartu.
4. •Pencarian pengemudi dengan status yang mudah dibaca dan aksi batal bila memang tersedia.
5. •Dalam perjalanan dengan detail pengemudi, rute, serta tombol bantuan yang tidak mengganggu aksi utama.
6. •Selesai untuk ringkasan perjalanan dan penilaian.

Fokus desainnya adalah perubahan status: mencari, pengemudi ditemukan, pengemudi tiba, perjalanan berlangsung, dan selesai. Jangan hanya membuat layar peta yang menarik; pengguna harus selalu tahu apa yang sedang terjadi dan tindakan berikutnya.

Galeri: bayar tagihan dengan Rupiah dan QRIS

Masalah pembayaran yang baik untuk latihan adalah: pengguna ingin membayar nominal tertentu dan membutuhkan bukti bahwa transaksi sudah berhasil. Dalam konteks Indonesia, gunakan Rupiah pada input dan ringkasan nominal, serta QRIS bila skenarionya adalah pembayaran melalui kode QR.

Alur layar yang ringkas dimulai dari pilih jenis pembayaran, lalu masukkan atau tinjau nominal, pilih metode, konfirmasi, dan status transaksi. Untuk skenario QRIS, layar pemindaian perlu memberi izin kamera dengan penjelasan singkat, menyediakan jalur alternatif bila kode tidak dapat dipindai, dan menampilkan hasil setelah kode terbaca. Jangan meminta pengguna mengingat nominal atau penerima dari layar sebelumnya; tampilkan kembali keduanya sebelum konfirmasi.

Pada layar konfirmasi, tonjolkan penerima, nominal dalam Rupiah, sumber dana, dan tombol bayar. Setelah pembayaran, bedakan keadaan berhasil, diproses, dan gagal. Status “diproses” penting karena transaksi tidak selalu langsung memiliki hasil akhir. Layar bukti sebaiknya memuat detail yang dapat dirujuk pengguna, bukan sekadar ikon centang besar.

Gunakan istilah QRIS sesuai materi Bank Indonesia dan jangan menggambarkan QRIS sebagai merek dompet digital tertentu. Desain harus membantu pengguna memahami tindakan bayar, bukan mengaburkan metode yang dipakai.

Galeri: daftar layanan publik dan cek antrean

Untuk ide desain aplikasi yang dekat dengan kebutuhan sehari-hari, ambil masalah: peserta ingin mengetahui status kepesertaan dan mengatur kunjungan layanan. Pola ini dapat merujuk pada Mobile JKN, yang menyediakan konteks kepesertaan dan antrean layanan kesehatan. Jangan menyalin tampilan aplikasinya; gunakan masalah dan struktur tugasnya sebagai bahan latihan.

Mulailah dari beranda yang menjawab dua pertanyaan: “Apakah kepesertaan saya aktif?” dan “Apa yang perlu saya lakukan untuk kunjungan berikutnya?” Dari sana, buat dua jalur yang terpisah tetapi mudah dijangkau: cek kepesertaan dan ambil atau lihat antrean.

Jalur kepesertaan dapat berisi identitas peserta secara ringkas, status, serta langkah lanjut bila data perlu diperbarui. Jalur antrean membutuhkan pilihan fasilitas atau layanan, tanggal kunjungan, konfirmasi, lalu tiket antrean. Tiket tersebut harus memprioritaskan informasi praktis: tempat, waktu atau jadwal, nomor antrean bila tersedia, dan instruksi tiba di lokasi.

Rancang pula keadaan yang sering terlewat: peserta belum memilih layanan, jadwal tidak tersedia, koneksi terputus, atau data belum dapat dimuat. Bahasa layar harus administratif tetapi tetap mudah dipindai. Hindari meminta pengguna mengisi data yang sebenarnya sudah ada di profil, kecuali diperlukan untuk konfirmasi.

Cara memilih struktur sebelum gaya visual

Pilih masalah yang dapat ditulis dalam satu kalimat: “Saya ingin memesan perjalanan”, “Saya ingin membayar”, atau “Saya ingin mengambil antrean.” Kalimat ini menjadi batas produk awal. Jika Anda belum dapat menyebut tindakan selesai dengan jelas, ruang lingkupnya masih terlalu lebar.

Kemudian tulis empat titik dalam alur: masuk, isi atau pilih, konfirmasi, dan hasil. Tambahkan satu kondisi gangguan yang realistis, misalnya pembayaran gagal, pengemudi belum ditemukan, atau jadwal antrean tidak tersedia. Baru setelah itu tentukan komponen mobile seperti bilah navigasi, kartu pilihan, tombol utama, input nominal, dan notifikasi status.

Jangan memulai dari moodboard. Warna dan gaya visual memang memengaruhi rasa percaya, tetapi tidak akan memperbaiki alur yang meminta pengguna kembali ke layar sebelumnya untuk melihat informasi penting. Untuk tiap layar, beri satu tujuan utama dan satu tindakan utama. Bila ada dua tindakan yang sama pentingnya, pecah tugasnya atau gunakan langkah konfirmasi.

Setelah struktur jadi, gunakan data contoh yang terasa lokal: format Rupiah pada pembayaran, kata QRIS saat memindai kode, serta status antrean dan kepesertaan pada layanan publik. Data ini membuat keputusan tata letak lebih nyata daripada teks lorem ipsum.

Peta masalah ke layar awal aplikasi mobile

Kesalahan yang sering terjadi

Memulai dari layar beranda yang penuh fitur.

Tentukan satu tugas selesai terlebih dahulu, lalu buat beranda yang mengarahkan pengguna ke tugas tersebut.

Menampilkan nominal pembayaran hanya setelah pengguna menekan bayar.

Tampilkan penerima, nominal Rupiah, dan metode pembayaran pada layar konfirmasi sebelum tindakan final.

Membuat status sebagai teks kecil di bawah ilustrasi.

Jadikan status inti sebagai informasi pertama yang terbaca, terutama saat pencarian pengemudi, pembayaran diproses, atau antrean berubah.

Menyalin antarmuka aplikasi populer secara utuh.

Ambil pola masalahnya, lalu susun ulang layar berdasarkan pengguna, konten, dan prioritas solusi Anda sendiri.

Pertanyaan yang sering diajukan

Apa contoh desain aplikasi untuk pemula?

Contoh desain aplikasi untuk pemula adalah alur pemesanan perjalanan, pembayaran QRIS, atau pengambilan antrean layanan. Pilih satu tugas kecil, misalnya membayar tagihan dalam Rupiah, lalu rancang lima layar: beranda, input data, konfirmasi, proses, dan bukti hasil. Latihan ini mengajarkan urutan UI, keadaan status, dan prioritas tombol.

Bagaimana memilih masalah untuk aplikasi pertama?

Pilih masalah untuk aplikasi pertama yang memiliki pengguna jelas, satu tujuan selesai, dan alur kurang dari sekitar enam layar inti. Tulis masalah sebagai kata kerja, seperti pesan perjalanan, bayar dengan QRIS, atau cek antrean. Hindari ide yang mencakup pasar, chat, pengiriman, dan pembayaran sekaligus karena struktur produknya sulit diuji pada tahap awal.

Apa contoh alur layanan publik Indonesia?

Contoh alur layanan publik Indonesia adalah cek kepesertaan lalu ambil antrean kunjungan, dengan pola yang dapat merujuk pada Mobile JKN. Pengguna membuka status kepesertaan, memilih layanan atau fasilitas, memilih jadwal bila tersedia, mengonfirmasi pilihan, lalu menerima informasi antrean. Rancang juga keadaan jadwal penuh, data belum termuat, dan pembatalan.

Kapan gaya visual sebaiknya ditentukan?

Gaya visual sebaiknya ditentukan setelah alur tugas, informasi utama, dan keadaan status sudah jelas. Mulailah dengan susunan layar sederhana untuk memastikan pengguna dapat pesan, bayar, lacak, atau daftar tanpa kebingungan. Setelah itu, pilih warna, tipografi, dan ikon yang mendukung hierarki informasi serta konteks produk.

Langkah selanjutnya

Pilih masalah dari galeri dan biarkan floow.design menyusun layar awal untuk solusi Anda. Mulai dari satu alur—pesan, bayar, lacak, atau daftar—lalu tinjau struktur layarnya sebelum menentukan gaya visual.

---

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
• •Google Play — Mobile JKN, BPJS Kesehatan
• •Google Play — Gojek
• •Google Play — Grab