Belajar Product Designer - Collaboration dengan PM & Eng

#Pendahuluan

Setelah di episode 12 kita membuktikan keputusan desain lewat eksperimen, pada episode ini kita menghadapi realitas paling menentukan: produk tidak dibangun oleh desainer sendirian. Product designer bekerja di tengah tim lintas fungsi — dan kualitas kolaborasi dengan PM dan Engineer sering kali lebih menentukan keberhasilan produk daripada kualitas desainnya sendiri.

Desain terbaik tidak berguna jika tidak bisa dibangun. Desain yang jelas menghemat puluhan jam diskusi. Dan PM yang percaya pada kalian akan membela desain di depan stakeholder. Kolaborasi adalah keterampilan yang bisa dilatih — dimulai dari working agreements, memahami PRD, dan handoff yang profesional.

#Working Agreements: Aturan Main Tim

Working agreements adalah kesepakatan sederhana tentang cara tim bekerja — bukan aturan birokrasi, melainkan hal-hal yang menghilangkan gesekan harian. Contoh yang umum untuk tim desain-PM-eng:

Working agreement terbaik disusun bersama, bukan diumumkan. Luangkan 30 menit di awal sprint untuk menuliskannya di halaman Notion/Google Docs bersama tim — lalu review tiap bulan.

#Memahami dan Menyumbang PRD

PRD (Product Requirements Document) adalah dokumen PM yang menjelaskan masalah, target user, requirement, dan metrik sukses. Product designer bukan pembaca pasif — kalian menyumbang bagian-bagian yang kalian kuasai.

Struktur PRD standar yang perlu kalian kenali:

1. Problem statement & konteks
2. Target user & persona
3. Goal & success metrics
4. Requirements (fungsional & non-fungsional)
5. Scope (in scope / out of scope)
6. Open questions & risks

Kontribusi desainer di tiap bagian: problem statement dikoreksi dengan temuan riset, user persona diisi hasil interview, success metrics diuji apakah measurable, requirements disorot untuk area yang ambigu secara desain, dan open questions ditandai mana yang butuh riset sebelum design.

#Latihan: Analisis PRD Sehati

Buat PRD singkat 1 halaman untuk fitur booking dokter, lalu jawab:

1. Apakah problem statement menyebut perilaku, bukan sekadar keluhan?
2. Apakah success metrics bisa diukur dan dibedakan dari vanity metrics?
3. Bagian mana yang masih ambigu untuk didesain?

#Design-Engineering Handoff

Handoff adalah momen desain berpindah ke kode. Handoff yang buruk menghasilkan implementasi menyimpang dan pertanyaan berulang. Handoff yang baik membuat engineer tahu apa yang harus dibangun dan mengapa. Isi handoff yang lengkap:

• File Figma terorganisir: halaman dan frame dinamai jelas (episode 7).
• Flow prototype: tautan prototype interaktif untuk konteks alur.
• Spesifikasi interaksi: state, animasi, dan perilaku tepi (loading/error/empty dari episode 9).
• Design tokens: nama token dipakai, bukan nilai mentah (episode 8).
• Responsive & breakpoint: perilaku di ukuran layar berbeda.
• Aksesibilitas: kontras, target, label (episode 10).
• Event tracking: daftar event yang harus dikirim (episode 11).

Komponen   : button.primary size.lg
States     : default / pressed / disabled / loading
Loading    : spinner 16px di kiri label, label tetap "Booking"
Disabled   : saat slot tidak tersedia, opacity 50%
A11y       : kontras 4.6:1, target 48px, aria-label "Booking dokter"
Event      : booking_clicked {source: hasil_triase, doctor_id}

Mengapa spesifikasi serinci ini penting? Karena hal-hal kecil yang tidak dispesifikasikan akan diisi oleh tebakan engineer — dan tebakan di 50 titik kecil menghasilkan produk yang melenceng 20% dari desain.

#Alur Kolaborasi yang Sehat

Kunci dari alur ini: review terjadi sebelum handoff, bukan sesudah. Dan QA/demo bukan titik akhir — temuan di sana menjadi input iterasi berikutnya, bukan ajang menyalahkan.

#Penutup

Inti yang harus dibawa pulang:

• Working agreements menghilangkan gesekan harian dan disusun bersama tim.
• PRD bukan dokumen PM; desainer menyumbang riset, persona, metrik, dan requirement.
• Handoff lengkap mencakup file rapi, flow, spesifikasi interaksi, tokens, a11y, dan event tracking.
• Hal kecil yang tidak dispesifikasikan akan diisi tebakan engineer — spesifikasikan.
• Review sebelum handoff lebih murah daripada perbaikan setelah rilis.

Di episode 14 selanjutnya kita akan membahas service design & ecosystem — meluaskan pandangan dari layar aplikasi ke keseluruhan layanan Sehati: blueprint, touchpoints, dan pengalaman end-to-end yang melibatkan banyak pihak. Sampai jumpa di episode 14!