Design process adalah urutan langkah dari sebuah masalah sampai halaman yang jadi, lalu diulang lagi. Bayangin renovasi dapur. Kamu tanya dulu keluarga apa masalahnya ("dapurnya gelap, rak terlalu tinggi"), gambar denahnya pakai pensil, baru pilih keramik dan cat. Sebelum tukang mulai, kamu jalan-jalan di ruangannya pakai tanda lakban di lantai. Tukang dapat ukuran yang pasti. Setelah dipakai sebulan, ada yang dibetulkan lagi. Halaman web dibuat dengan cara yang sama: riset, wireframe, visual design, prototype dan tes, handoff, iterasi.
🧪 Tebakan cepat: Tim Bu Sri cuma sempat mengetes prototype halaman pesan dengan satu orang. Ada gunanya, atau lebih baik tunggu sampai bisa tes dengan 20 orang? Jawabannya ada di bagian "4. Prototype dan tes".
Kita jalankan prosesnya di halaman pesan Homestay Kabut, dari nol.
1. Research: pahami masalahnya dulu
Sebelum menggambar apa pun, cari tahu siapa penggunanya dan apa masalahnya. Bu Sri membaca ulang 40 chat tamu terakhir di WhatsApp, lalu menghitung pertanyaannya:
| Pertanyaan tamu | Jumlah |
|---|---|
| "Tanggal segini kosong?" | 14 |
| "Totalnya berapa?" | 11 |
| "Bisa batal gak?" | 8 |
| "Bayarnya gimana?" | 7 |
Dari angka itu lahir problem statement, satu kalimat masalahnya: "Tamu gak bisa tahu tanggal kosong, total harga, aturan batal, dan cara bayar tanpa bertanya, jadi Bu Sri menjawab pertanyaan yang sama berulang-ulang." Cara riset lain: wawancara pengguna, survei, dan competitive analysis (melihat cara app booking lain menampilkan total).
2. Wireframe (lo-fi)
Wireframe adalah sketsa kasar layout: kotak abu-abu, tanpa warna, tanpa gambar asli, cuma struktur. Lo-fi artinya low fidelity, belum mirip hasil akhir. Tujuannya memutuskan apa saja yang ada di halaman dan urutannya, dan mengubah sketsa jauh lebih cepat daripada mengubah kode.
[ gambar kamar ]
[ nama kamar · tamu · lokasi ]
[ harga per malam ]
[ check-in, check-out (ketik tanggal) ] <- "Tanggal segini kosong?"
[ tombol pesan ]
[ total harga ] <- "Totalnya berapa?"
[ aturan batal dan cara bayar ] <- "Bisa batal gak?", "Bayarnya gimana?"
Tiap pertanyaan dari riset dapat satu kotak. Alatnya bebas: kertas dan pensil, Figma, atau Balsamiq.
3. Visual design (hi-fi)
Setelah wireframe disetujui, baru masuk visual design (hi-fi, high fidelity): typography (font, ukuran, tebal), color (palet, kontras), spacing (margin, padding, grid), dan imagery (foto, ikon). Hasilnya halaman Homestay Kabut yang hijau dan rapi. Kelihatan siap, tapi belum dicoba siapa pun. Tiap bagian ini punya pelajarannya sendiri di jalur ini.
4. Prototype dan tes
Prototype adalah versi yang bisa diklik, dibuat untuk dicoba sebelum kode ditulis. Tim Bu Sri memberi Pak Hadi (58 tahun) satu tugas: "Pesan Kamar Teras untuk 2 malam, mulai 12 Des." Lalu mereka cuma mengamati, tanpa membantu.
| Yang terjadi pada Pak Hadi | Yang diubah |
|---|---|
| Mengetik "12-12" di kolom check-in, muncul "Format tanggal salah". Butuh 3 kali coba. | Tanggal check-in dipilih, jumlah malam tinggal ditekan (1, 2, 3 malam). |
| Gak menemukan total: dia berhenti di tombol dan gak menggulir ke bawah. | Total pindah ke atas tombol. |
| Bertanya: "Submit ini langsung bayar?" | Tombol jadi "Pesan kamar, bayar di tempat". |
Jadi jawaban tebakannya: ada gunanya. Satu orang sudah menemukan tiga masalah, semuanya sebelum satu baris kode ditulis. Ini cocok dengan model Jakob Nielsen dan Tom Landauer (1993): rata-rata satu penguji menemukan sekitar 31% masalah usability, dan tiap penguji berikutnya makin banyak mengulang temuan yang sama. Tes kecil yang sering lebih berguna daripada tes besar yang gak pernah sempat.
5. Developer handoff
Developer handoff adalah saat designer menyerahkan desainnya ke developer, dengan:
- Spesifikasi: ukuran, warna, dan jarak dalam angka yang pasti.
- Assets: gambar kamar dan ikon yang sudah diekspor.
- Interaction notes: hover, loading, error, dan keadaan lain.
Contoh spesifikasi tombol pesan yang diterjemahkan developer ke CSS:
.book {
min-height: 44px; /* cukup besar untuk jari */
font-size: 16px;
font-weight: 700;
color: #fff;
background: #15803d; /* satu-satunya warna aksen */
border-radius: 10px;
}
.book:disabled {
background: #94a3b8; /* waktu loading atau kamar penuh */
}
min-height: 44pxdanfont-size: 16pxdatang dari spesifikasi, bukan tebakan developer..book:disabledada karena desainnya juga menggambar keadaan loading dan kamar penuh, gak cuma keadaan normal.
6. Iterate
Desain gak pernah benar-benar "selesai". Sebulan setelah halaman baru rilis, Bu Sri menghitung lagi dengan cara yang sama seperti riset: pertanyaan tamu turun dari 40 jadi 9. Tapi muncul pertanyaan baru, "Boleh bawa hewan?", 4 kali. Itu bahan riset putaran berikutnya. Selain menghitung chat, iterasi bisa memakai analytics, heatmap, dan feedback pengguna.
Developer dalam proses ini
Idealnya developer ikut sejak wireframe, bukan cuma waktu coding. Developer bisa memberi masukan soal:
- Feasibility: bisa dibangun gak? Misalnya, apakah tanggal penuh bisa diambil dari data pesanan yang sudah ada.
- Kompleksitas: kira-kira berapa lama tiap bagian. Teks total cuma sejam, kalender ketersediaan bisa berhari-hari.
- Edge cases: keadaan yang sering lupa digambar designer, seperti loading, error (internet putus waktu tombol ditekan), dan empty state (semua tanggal penuh).
⚠️ Jebakan yang sering ketemu
- Langsung visual design tanpa wireframe. Kamu sibuk memilih warna sebelum urutan isinya benar, lalu harus merombak semuanya.
- Riset cuma pakai "menurut saya". Hitung sesuatu yang nyata: chat, tiket keluhan, data pemakaian.
- Menuntun penguji. "Klik yang hijau ya, Pak" membuat tesnya gak menemukan apa-apa. Kasih tugasnya, lalu diam dan catat.
- Handoff tanpa keadaan selain normal. Developer jadi menebak sendiri tampilan loading, error, dan kamar penuh.
TL;DR: Design process: research (pahami masalahnya, misalnya hitung 40 chat tamu), wireframe atau lo-fi (sketsa kasar tanpa warna, cuma struktur), visual design atau hi-fi (tambah typography, color, spacing, imagery), prototype dan tes (satu penguji sudah berguna: Pak Hadi menemukan 3 masalah sebelum ada kode), developer handoff (spesifikasi, assets, interaction notes), lalu iterate (ukur lagi, 40 pertanyaan jadi 9). Developer sebaiknya ikut sejak wireframe untuk memberi masukan soal feasibility, kompleksitas, dan edge cases.
