Belajar System Analyst - Prototyping & Wireframing

#Pendahuluan

Setelah di episode 10 kalian mengelola relasi dan ekspektasi stakeholder, kini saatnya memberi mereka sesuatu yang konkret untuk direaksi: prototype. Episode ini membahas prototyping & wireframing — dari sketsa kasar sampai prototype klik-able, beserta praktik merancang layar kasir TokoKita.

Mengapa prototype begitu kuat? Karena manusia buruk dalam membayangkan dari teks. Kalimat "kasir dapat memindai barang lalu menyelesaikan pembayaran" terdengar setuju saja untuk semua orang; tapi begitu mereka melihat tombol Bayar berukuran kecil di pojok kanan bawah, kasir langsung protes "tangan saya sambil pegang barang, tombolnya harus besar!" — penemuan yang harganya lima menit sekarang atau dua sprint kemudian. Prototype mengubah pendapat samar menjadi feedback spesifik.

#Empat Tingkat Fidelity

Tingkat	Bentuk	Tujuan	Waktu Buat
Sketch	Coretan pena/kertas	Eksplorasi ide cepat sendiri/di workshop	Menit
Wireframe	Kotak abu-abu tanpa warna	Struktur layout & alur antar-layar	Jam
Mockup	Desain visual final (warna, tipografi)	Kesepakatan look & feel	Hari
Clickable prototype	Mockup + interaksi klik	Simulasi pemakaian nyata, usability test	Hari-an

Prinsip memilih: mulai serendah mungkin, naik hanya jika pertanyaan yang ingin dijawab menuntut. Pertanyaan "apakah alur ini masuk akal?" cukup wireframe; pertanyaan "apakah kasir paham tombol mana untuk diskon?" butuh clickable prototype dengan orang sungguhan mencobanya.

Important

Wireframe sengaja dibuat jelek — abu-abu polos, tanpa logo, tanpa pilihan font. Ini bukan malas, melainkan taktik: tampilan yang rapi memancing komentar estetika ("warnanya ganti dong"), sedangkan kotak abu-abu memaksa diskusi ke fungsi dan alur, tempat feedback paling bernilai di fase analisis.

#Anatomi Wireframe Layar Kasir

Mari praktikkan langsung: layar utama POS TokoKita. Kebutuhan dari use case UC-01 dan feedback kasir: scan cepat, total selalu terlihat, tombol bayar mudah dicapai, dan mode manual untuk barcode rusak.

Wireframe layar kasir POS (v1)

+--------------------------------------------------------------+
| TokoKita POS        Denpasar   Shift #142   [Sinta v]  14:05 |
+---------------------------------------+----------------------+
| [ Scan barcode / input kode...    ]   |  STRUK BERJALAN      |
+---------------------------------------+----------------------+
| Indomie Goreng          x2     Rp  7.000  [+] [-] [hapus]    |
| Teh Kotak 250ml         x1     Rp  4.500  [+] [-] [hapus]    |
| Beras Pandan 5kg        x1     Rp 68.000  [+] [-] [hapus]    |
|                                                               |
|                                                               |
+---------------------------------------+----------------------+
| [+ Produk Manual]  [Diskon]  [Retur]  | Subtotal  Rp 79.500  |
|                                       | Diskon    Rp  0      |
|                                       | TOTAL     Rp 79.500  |
|                                       | +--------------------+|
|                                       | |  BAYAR (F12)       ||
|                                       | +--------------------+|
+---------------------------------------+----------------------+

Keputusan desain yang tertanam di wireframe ini — dan wajib bisa dikalian pertanggungjawabkan:

Panel struk kanan permanen — kasir dan pelanggan sama-sama perlu melihat item bertambah real-time; menyembunyikannya memicu keraguan.
Tombol BAYAR raksasa di kanan-bawah — target jempol/tangan bebas; shortcut F12 untuk keyboard fisik.
Aksi qty inline (+/-) — koreksi satu ketukan tanpa buka dialog baru.
Produk Manual selalu tampak — 30% transaksi barcode rusak (data episode 3); fitur darurat tidak boleh tersembunyi di menu.

Tiap keputusan seperti ini adalah requirement UI yang nanti masuk acceptance criteria story kasir.

#Dari Wireframe ke Clickable Prototype

Di Figma, alur kerja efektifnya:

Satu frame = satu state layar; duplikat untuk variasi (keranjang kosong, mode offline aktif, dialog bayar tunai).
Hubungkan dengan Prototype mode: klik produk → dialog qty; klik BAYAR → layar metode bayar; dst. Cukup happy path + dua cabang penting.
Susun flow page terpisah berisi panah antar-frame sebagai dokumentasi alur.
Uji sendiri dulu: jalankan semua jalur, pastikan tak ada dead-end tanpa maksud.

Untuk TokoKita kita buat empat frame inti: kasir-kosong, kasir-isi, bayar-tunai, offline-banner — plus satu frame stok-opname-mobile untuk staf gudang.

#Menguji Prototype dengan Pengguna

Prototype tanpa pengujian hanyalah gambar mahal. Metode ringkas hallway usability test:

Siapkan 3-5 peserta (kasir nyata lebih baik daripada kolega kantor).
Beri misi tanpa panduan: "Bayarkan pembelian ini pakai uang 100 ribu."
Amati diam-diam: di mana ragu? salah klik apa? baca label berapa lama?
Tanya setelahnya, bukan saat proses: "apa yang kamu cari tadi?"
Catat temuan per frame; perbaiki; ulangi dengan peserta lain kalau perlu.

Aturan praktis Nielsen: 5 pengguna menemukan ±85% masalah usability mayor. Tidak butuh lab — meja warung kopi dan laptop sudah cukup.

Feedback yang masuk lalu dikelola dengan disiplin episode 10: tiap komentar dinilai — apakah masalah fungsi (perbaiki wireframe), preferensi estetika (catat untuk fase mockup), atau permintaan fitur baru (masuk backlog dengan trade-off). Tanpa penyaringan ini, prototype akan bermetamorfosis jadi monstre desain-komite.

Tip

Sertakan state gagal dalam prototype: banner OFFLINE, dialog pembayaran ditolak, item stok habis. Stakeholder jarang memikirkannya sampai melihatnya — dan justru state-state inilah yang membedakan prototype analisis dari sekadar showcase cantik.

#Kesalahan Umum

Melompat ke mockup indah — waktu habis untuk gradasi warna sementara alur retur belum dipikirkan. Urutannya tetap: struktur dulu, kulit kemudian.
Prototype jadi janji kontrak — stakeholder memotret mockup lalu menganggapnya spesifikasi binding. Selalu berlabel air: "KONSEP - BUKAN SPESIFIKASI FINAL" dan katakan eksplisit di awal presentasi.
Hanya happy path — prototype yang hanya menunjukkan sukses membuat semua orang percaya sistem sederhana; kejutan exception baru datang di UAT.
Membela desain, bukan menguji hipotesis — tujuan presentasi prototype adalah belajar apa yang salah, bukan memenangkan debat. Kalimat kunci: "kalau sulit dipakai, itu temuan berharga."
Lupa konteks fisik — layar kasir dipakai sambil berdiri, cahaya toko terang, tangan basah; uji di lingkungan semirip mungkin kondisi nyata, bukan di ruang AC tenang.

#Penutup

Inti yang harus dibawa pulang:

Empat tingkat fidelity — sketch, wireframe, mockup, clickable — naikkan hanya jika pertanyaannya menuntut; wireframe jelek adalah taktik fokus-fungsi.
Tiap elemen wireframe kasir adalah keputusan requirement yang bisa dipertanggungjawabkan: panel struk permanen, BAYAR raksasa, aksi inline, manual selalu tampak.
Clickable prototype minimal happy path + cabang penting + state gagal; uji dengan 3-5 pengguna nyata memakai misi tanpa panduan.
Feedback difilter tegas: masalah fungsi diperbaiki, estetika ditunda, fitur baru masuk backlog dengan trade-off.

Prototype telah memastikan bentuk solusi dimengerti semua pihak — pertanyaan berikutnya: layakkah proyek ini dibiayai dan berapa lama pengerjaannya? Di episode 12 selanjutnya kita membahas technical feasibility & estimation: studi kelayakan teknis, analisis cost-benefit, dan teknik estimasi yang jujur untuk proyek TokoKita. Pastikan tetap semangat!