Belajar UI/UX Design - Design Handoff ke Developer

#Pendahuluan

Setelah di episode 21 KasirKita bergerak, pada episode ini kita menjembatani dunia desain dan kode: design handoff. Momen ini menentukan seberapa setia implementasi developer terhadap desain — dan seberapa mulus kolaborasi ke depannya.

Mengapa penting? Handoff yang buruk adalah biaya tersembunyi terbesar: developer menebak-nebak spacing (padahal ada token), mengimplementasi komponen "yang mirip" (padahal ada varian benar), dan mengajukan pertanyaan yang seharusnya sudah dijawab desain. Handoff yang baik membuat implementasi cepat, konsisten, dan mengurangi design debt.

#Figma Dev Mode

Dev Mode adalah mode Figma untuk developer: satu klik untuk melihat spec, salin CSS/Android/iOS, dan navigasi file tanpa mengubah desain.

Developer memakai Dev Mode untuk membaca:

Spacing & dimensions — jarak antar elemen, ukuran komponen.
Typography — font, size, line-height, letter-spacing.
Color — nilai hex/token, bukan "biru bu Sari".
Variants — nama komponen & propertinya (state, size).

Agar Dev Mode efektif, file harus terorganisasi — beri nama layer yang masuk akal (btn-pay/primary), bukan Frame 182 — dan terhubung ke tokens.

Tip

Developer bukan pembaca pikiran: beri mereka konteks. Tandai frame yang siap implement (status Ready for dev), beri flow line yang jelas, dan sambungkan tiap layar ke komponen design system-nya. File yang rapi menghemat puluhan pertanyaan di Slack.

#Spec dan Annotation

Spec (spesifikasi) & annotation (anotasi) menjelaskan perilaku yang tidak terlihat dari visual statis. Sejak episode 7 kita sudah terbiasa menulis anotasi; saat handoff, lengkapi dengan:

Anotasi layar Konfirmasi (handoff)

- [ ] Tombol Konfirmasi: state loading 1s, lalu toast sukses
- [ ] Total: teks selalu bold, warna token color.text.primary
- [ ] Daftar item: scrollable, max-height 60vh
- [ ] Offline: simpan transaksi lokal, badge "tersimpan offline"
- [ ] Error: tampilkan inline, bukan toast (konteks form)
- [ ] A11y: modal pakai role=dialog + focus trap + Esc menutup

Setiap anotasi menjawab "apa yang terjadi di sini, pada kondisi apa?". Tandai juga perilaku khusus (breakpoints episode 14, reduced-motion episode 21) supaya tidak hilang di kode.

#Token Export (DTCG)

Token dari episode 12 diekspor dari Figma ke format yang bisa dipakai langsung oleh developer:

Ekspor token Figma → JSON (gaya DTCG)

# Figma: buka panel Variables → pilih Collection
# → ikon "..." → "Export variables" → pilih format JSON
# hasilnya file seperti tokens.json, contoh isi:

tokens.json — hasil ekspor variabel Figma

{
  "color/text/primary": {
    "$type": "color",
    "$value": "#1A1A1A"
  },
  "spacing/md": {
    "$type": "dimension",
    "$value": "16"
  }
}

Format DTCG memungkinkan token dipakai di tool apa pun (Style Dictionary, Tailwind config, CSS variables). Workflow produksi: ekspor → pipeline build → generate CSS variables / Tailwind theme, sehingga desain dan kode berbagi sumber nilai yang sama.

#Kolaborasi Desain-Developer: Design Review

Design review adalah sesi rutin di mana desainer & developer meninjau implementasi vs desain, bukan perang posisi. Aturan mainnya:

Bahas perbedaan, bukan salah-siapa — setiap gap adalah keputusan bersama (mungkin trade-off teknis yang sah).
Prioritaskan temuan: blokir (fungsi salah), mayor (penyimpangan mencolok), minor (detail kecil).
Adakan rutin (per sprint / per fitur), jangan menumpuk hingga rilis.
Catat keputusan — termasuk kompromi, supaya tidak diulang diskusinya.

Contoh hasil review yang sehat: "gap spacing 2px pada daftar item karena komponen yang dipakai salah varian" (fix cepat) vs "animasi panel diganti fade karena performa di perangkat entry-level" (kompromi sah, dicatat).

Warning

Waspada handoff sekali jalan. Desain hampir selalu berubah selama implementasi — karena temuan teknis, data nyata, atau feedback stakeholder. Bangun alur iterasi: desainer merespons pertanyaan developer dalam 24 jam, developer memberi update saat ada perubahan scope. Handoff adalah proses, bukan event.

#Praktik: Siapkan Handoff Package

Siapkan frame Handoff di file KasirKita:

Rapikan layer: beri nama bermakna pada semua layer utama.
Sambungkan ke komponen & tokens: pastikan tidak ada hardcode value.
Tulis anotasi untuk layar Konfirmasi & Pembayaran (perilaku, error, offline, a11y).
Ekspor tokens (JSON DTCG) dan tempelkan di file.
Buat status "Ready for dev" pada frame yang sudah final.
Jadwalkan design review pertama dengan daftar temuan yang akan dicek.

#Common Pitfalls

File tanpa organisasi — layer Frame 182; developer kesulitan membaca.
Spesifikasi tak tertulis — perilaku hanya "di kepala desainer".
Hardcode value di desain — token tidak terpakai; implementasi tidak konsisten.
Satu arah komunikasi — desainer memberi, developer menerima; tidak ada umpan balik.
Handoff saat semua sudah "selesai" — realita: iterasi selama implementasi itu normal.

#Penutup

Pada episode 22 ini, kalian telah menyiapkan handoff package KasirKita yang profesional.

Inti yang harus dibawa pulang:

Dev Mode memungkinkan developer membaca spec langsung; file yang rapi adalah fondasinya.
Spec & annotation menjelaskan perilaku & kondisi yang tidak terlihat dari visual statis.
Token export DTCG membuat desain & kode berbagi nilai yang sama — satu sumber kebenaran.
Design review rutin membahas gap implementasi sebagai keputusan bersama, bukan mencari salah.
Handoff adalah proses iteratif, bukan event sekali jalan.

Di episode 23 selanjutnya kita akan melihat bagaimana AI mengubah cara desainer bekerja: desain dengan AI: Figma Make & MCP — prompt-to-design, variasi, audit aksesibilitas, dan design-to-code lewat MCP. Sampai jumpa di episode 23!