Belajar Product Designer - Data-Driven Design

#Pendahuluan

Setelah di episode 10 kita memastikan Sehati accessible by default, pada episode ini kita menambahkan lensa terakhir sebelum masuk fase pengujian: data. Desain produk yang baik di era modern tidak bisa hidup dari selera saja — ia harus bisa menjawab "bagaimana kita tahu ini bekerja?"

Data-driven design berarti keputusan desain didasarkan pada bukti kuantitatif (analytics) dan kualitatif (riset), bukan hanya intuisi. Namun ada jebakan besar: data bisa menyesatkan jika metriknya salah. Di episode ini kita belajar memilih metrik yang benar, menyiapkan event tracking Sehati, dan mengubah insight menjadi aksi desain.

#Metrik: Pilih yang Benar, Bukan yang Mudah

Ada perbedaan antara metrik vanity (membuat senang, tapi tidak menuntun keputusan) dan metrik actionable. Contoh: jumlah download aplikasi itu vanity — ia tidak memberi tahu apa yang harus diperbaiki. Konversi "dari cek gejala → booking" itu actionable — naik/turunnya langsung menunjukkan di mana desain perlu diperbaiki.

Kerangka untuk memilih metrik produk:

Acquisition — berapa orang datang? (install, kunjungan)
Activation — berapa yang mengalami nilai inti? (selesai cek gejala pertama)
Retention — berapa yang kembali? (konsultasi kedua dalam 30 hari)
Revenue — berapa yang menghasilkan uang? (konversi ke subscription)
Referral — berapa yang mengajak orang lain?

Pilar strategi Sehati di episode 5 bisa langsung dipetakan ke metrik: triase tepercaya → % user yang menyelesaikan cek gejala dan kepuasan hasil triase; akses cepat → waktu dari booking ke konsultasi; kontinuitas → retensi 30 hari.

#Menyiapkan Event Tracking

Data tidak muncul sendiri — harus direncanakan. Identifikasi event dan property di tahap desain, bukan setelah rilis. Untuk fitur cek gejala:

Event	Property penting
`cek_gejala_started`	entry_point, user_id
`cek_gejala_answered`	question_number, answer
`cek_gejala_completed`	result (hijau/kuning/merah)
`booking_clicked`	source (hasil triase/home), doctor_type
`booking_completed`	total_harga, metode_pembayaran

Rencana event tracking sederhana

Event   : cek_gejala_completed
Trigger : user menyelesaikan pertanyaan terakhir
Property: result = hijau|kuning|merah
          duration_s = 35
          answers = [batuk, demam, pilek]

Saat menyusun design spec (episode 16), sertakan daftar event ini — engineer butuh tahu kapan dan apa yang harus dikirim ke Amplitude/Mixpanel.

#Membaca Data: Funnel dan Cohort

#Funnel Analysis

Funnel menunjukkan di mana user berhenti di tiap langkah:

Funnel cek gejala → booking

1. Buka Sehati            100%
2. Mulai cek gejala        68%
3. Selesai cek gejala      41%   ← drop besar (27pt)
4. Lihat rekomendasi       38%
5. Booking dokter          12%

Funnel ini langsung menunjukkan masalah: 41% user tidak selesai cek gejala. Pertanyaan desain berikutnya jelas: apa yang terjadi di langkah 2-3? Apakah pertanyaan terlalu banyak? Apakah ada bagian yang membingungkan? Inilah awal investigasi desain yang didukung data.

#Cohort Analysis

Cohort mengelompokkan user berdasarkan waktu aktivasi untuk melihat retensi, bukan agregat yang menyesatkan. Contoh: pasien yang pertama kali memakai fitur cek gejala di minggu pertama vs minggu kedua — apakah fitur baru meningkatkan retensi bulan berikutnya? Jawabannya jauh lebih jujur daripada sekadar "total user naik".

Warning

Waspadai survivorship bias dan sample yang tidak representatif: data yang diambil dari 3 hari pertama peluncuran fitur bisa menyesatkan. Dan "average" bisa menyembunyikan cerita — selalu lihat distribusi (misal persentil waktu konsultasi, bukan rata-rata yang dirusak outlier).

#Dari Insight ke Keputusan Desain

Data memberi tahu di mana masalahnya; riset kualitatif memberi tahu mengapa. Keduanya saling melengkapi. Contoh alur kerja data-driven di Sehati:

Funnel menunjukkan drop di langkah 2-3 cek gejala (kuantitatif).
Session recording (Hotjar/Maze) menunjukkan user ragu saat melihat pertanyaan tentang alergi (kualitatif).
Hipotesis: pertanyaan alergi membuat user merasa tidak tahu dan berhenti.
Desain: buat pertanyaan alergi opsional + label "bisa dikosongkan".
Validasi di episode 12: A/B test apakah perubahan ini menaikkan completion rate.

#Praktik: Tetapkan Baseline Sehati

Pilih 3 metrik actionable dari pilar strategi Sehati.
Buat daftar 5 event yang harus ditrack untuk metrik tersebut (ikuti format tabel di atas).
Gambar funnel ideal cek gejala → booking dengan target angka (misal completion ≥ 60%, booking konversi ≥ 15%).
Tulis satu hipotesis desain yang bisa diuji dari baseline tersebut.

#Penutup

Inti yang harus dibawa pulang:

Bedakan metrik vanity dan actionable; yang actionable menuntun keputusan desain.
Pilih metrik per pilar strategi (acquisition, activation, retention, revenue, referral).
Rencanakan event tracking di tahap desain, lengkap dengan property.
Funnel menunjukkan di mana masalah; riset menunjukkan mengapa.
Waspadai data yang menyesatkan: sample kecil, rata-rata, dan bias.

Di episode 12 selanjutnya kita akan membahas experimentation & validation — A/B testing, usability testing, dan iterative validation untuk membuktikan hipotesis desain Sehati sebelum fitur dirilis besar-besaran. Sampai jumpa di episode 12!