Sehari dalam Kehidupan Desainer Produk (Realita B2B SaaS, Bukan Versi LinkedIn)

Deskripsi pekerjaan menyebut "kelola desain produk end-to-end." Kalender Selasa berkata tiga rapat, sembilan puluh menit waktu Figma yang sesungguhnya, dan pesan Slack dari eksekutif yang masuk pukul 16.47 menanyakan mengapa produk Anda belum terlihat seperti Linear.

Kesenjangan itulah yang merupakan pekerjaan. Bukan bugnya. Pekerjaannya.

Jika Anda membaca Template Job Description Desainer Produk dan membayangkan hari penuh pekerjaan craft yang fokus, artikel ini adalah kalibrasi yang Anda butuhkan. Sebuah Selasa nyata untuk desainer IC level menengah di perusahaan B2B SaaS berukuran 60 orang, lengkap dengan kalender, thread Slack, dan pertarungan kecil yang menguras lebih banyak energi daripada yang pernah diceritakan siapa pun kepada Anda saat wawancara kerja.

Mengapa Ini Penting Sekarang

Desainer sering berhenti dalam enam bulan pertama. Bukan karena mereka tidak bisa mendesain. Tapi karena mereka datang dengan ekspektasi 70% craft dan mendapatkan sekitar 30% craft, 40% penyelarasan, dan 30% pengendalian kerusakan.

Tidak ada yang memberi tahu Anda ini saat wawancara karena manajer perekrut tidak mau menakut-nakuti Anda, dan desainer tim tidak mau mengakui seberapa banyak waktu mereka dihabiskan dalam rapat. Jadi Anda bergabung, menghabiskan tiga minggu melihat desainer senior menghabiskan sebagian besar waktu mereka di Slack dan Linear, dan mulai bertanya-tanya apakah Anda mengambil pekerjaan yang salah.

Tidak. Pembagian ini memang seperti itu. Memberi namanya membuat semuanya bisa dihadapi.

Jadi inilah hari yang nyata. Bukan highlight reel. Jam-jam yang sesungguhnya.

Hari yang Nyata

08.00, Meninjau Rekaman Panggilan Pelanggan

Kopi, headphone, tab Gong terbuka. Panggilan onboarding kemarin dengan logo baru dari sektor layanan rumah tangga berlangsung 47 menit. Anda hanya perlu 22 menitnya, bagian di mana admin mencoba bulk-edit 80 deal dan menyerah.

Anda memutar dengan kecepatan 1,5x. Tandai empat momen gesekan di Notion dengan tag "bulk-edit pain." Satu kutipan membuat Anda berhenti: "Saya mengekspor ke spreadsheet lalu mengimportnya kembali karena itu lebih cepat." Satu kalimat itu menghancurkan asumsi di balik spesifikasi sprint berikutnya, yang masih mencantumkan bulk-edit sebagai "nice to have." Ini bukan nice to have. Ini alasan pelanggan ini akan churn di bulan keempat jika tidak ada yang menyentuhnya.

Anda memasukkan tautan Gong dengan timestamp plus kutipan tersebut ke dalam dokumen discovery. Dua belas menit total. Dua belas menit terbaik yang akan Anda habiskan hari ini.

09.30, Pekerjaan Discovery dan Sketsa

Hasil Maze dari uji tak termoderasi hari Jumat masuk ke kotak masuk Anda. 14 dari 20 penguji tidak bisa menemukan tindakan sekunder pada kartu deal. Heatmap-nya sangat jelas memperlihatkan masalah. Semua orang mengarahkan kursor ke tombol yang salah.

Anda membuka Figma, file baru, dan membuat sketsa tiga arah untuk alur bulk-edit. Tidak ada piksel. Tidak ada tipografi. Hanya kotak abu-abu dan panah. Arah A adalah pola checkbox-dan-toolbar (familiar, membosankan, aman). Arah B adalah panel samping yang terbuka saat dipilih (lebih banyak ruang layar, lebih banyak klik). Arah C adalah pengeditan inline pada tabel itu sendiri (lebih sedikit klik, lebih sulit dibangun, engineer akan mengeluh).

Sembilan puluh menit. Tiga sketsa. Nol piksel. Anda belum mendesain apa pun yang akan disebut "desain" oleh kebanyakan orang, dan itu tidak masalah. Sketsanya adalah desainnya. Piksel datang kemudian, dan hanya untuk satu arah yang bertahan melewati empat jam ke depan.

11.30, Async dengan PM dan Engineer soal Trade-off

Thread Linear pada spesifikasi. Lead engineer menulis: "Arah C berarti kami memperbarui tiga komponen di Storybook dan kemungkinan menyentuh lapisan virtualisasi tabel. Itu dua sprint, bukan satu." PM membalas: "Bisakah kita rilis Arah A sprint ini dan meninjau C kuartal depan?"

Ini adalah momen di mana Anda bisa menyerah atau memberikan argumen balik. Anda memberikan argumen balik. Anda memasukkan tautan Gong dari pukul 08.00 ke dalam thread beserta kutipan dan satu kalimat: "Arah A tidak memperbaiki perilaku ekspor-dan-reimport. Kita akan terus kehilangan profil pelanggan ini jika kita merilis A dan menyebutnya selesai."

Anda tidak mendapat persetujuan. Anda mendapat "Mari diskusikan dalam critique pukul 13.30." Itu hasil yang tepat. Anda membeli percakapan. Itulah kemenangan.

Sementara itu, Anda membalas dua komentar Linear lainnya, menandai satu tiket "needs spec," dan menulis komentar empat baris pada mockup kondisi kosong rekan yang mengatakan tampilannya indah tapi salinannya terlalu berat. Anda mendapat emoji jempol. Async pada kondisi terbaiknya.

13.30, Kritik Desain

Empat puluh lima menit bersama dua desainer lainnya. Anda menyematkan tiga arah, membahas kutipan pelanggan terlebih dahulu (selalu awali dengan pelanggan, bukan dengan desain), kemudian menunjukkan sketsa.

Arah A dipuji karena bisa dirilis. Arah C dipuji karena benar-benar memecahkan masalah. Arah B dihantam habis, yang memang adil karena Anda sudah tahu itu yang paling lemah sejak awal. Kemudian seorang desainer senior bertanya: "Seperti apa kondisi kosong di C? Ketika pengguna tidak memilih deal apa pun, affordance pengeditan inline akan terlihat rusak."

Anda tidak punya jawabannya. Anda punya sketsa kondisi terisi dan gerakan tangan yang samar untuk kondisi kosong. Itulah celahnya. Kritik tidak membunuh arah Anda. Kritik menemukan lubang yang akan Anda jatuh ke dalamnya minggu depan, dan sekarang Anda bisa menambalnya sebelum menghabiskan tiga hari pada desain beresolusi tinggi.

Anda keluar dengan Arah C hidup, Arah A mati, dan penugasan yang jelas: selesaikan kondisi kosong sebelum Anda membangun apa pun pada keluaran produksi.

15.00, Figma Resolusi Tinggi dan Pemeriksaan Storybook

Sembilan puluh menit Figma yang sesungguhnya. Jendela antara kritik dan gangguan tak terhindarkan menjelang akhir hari. Anda membawa Arah C ke resolusi produksi untuk dua layar: kondisi terisi dengan tiga deal dipilih, dan kondisi kosong yang baru Anda sadari hilang.

Anda mengaudit menggunakan token design system. Dua warna tidak ada dalam daftar token. Satu nilai jarak meleset 4px. Anda memperbaiki keduanya. Anda membuka Storybook, memeriksa komponen table-row yang ada, dan mengkonfirmasi bahwa pola pengeditan inline membutuhkan varian baru. Anda mengajukan tiket Storybook di Linear, menandai pemelihara design system, dan menautkannya kembali ke spesifikasi.

Inilah bagian hari yang terasa seperti pekerjaan dari wawancara. Ini juga rentang terpendek. Perhatikan bahwa ini sembilan puluh menit, bukan enam jam.

16.47, Gangguan dari Eksekutif

DM Slack masuk. "Lihat [kompetitor] baru saja merilis dashboard baru mereka. Terlihat sangat bersih. Bisa kita lihat ini untuk aplikasi kita? Pelanggan terus memintanya."

Jebakannya adalah (a) berkata iya dan panik, atau (b) berkata tidak dan terlihat defensif. Keduanya salah.

Anda menulis tiga kalimat:

Saya lampirkan dokumen discovery. Bulk-edit adalah titik gesekan utama kuartal ini, dan kita akan merilis perbaikannya dalam dua sprint. Saya siap melakukan tinjauan desain singkat tentang dashboard secara terpisah jika Anda mau, tapi saya sarankan untuk tetap mempertahankan pekerjaan dashboard dalam rencana Q3 karena kita memiliki data pelanggan yang mendukung sprint saat ini. Mau saya atur 15 menit besok untuk memandu Anda melalui riset bulk-edit?

Anda melampirkan dokumen discovery Notion dengan kutipan pelanggan dan empat momen Gong dengan timestamp. Anda mengirim.

Eksekutif membacanya. Tiga menit kemudian: "Mengerti, masuk akal. Ayo 15 menit besok."

Anda berhasil mempertahankan tenggat waktu. Anda melakukannya tanpa berkata tidak. Anda melakukannya dengan menunjukkan pekerjaan Anda, yang sejujurnya, adalah satu-satunya langkah yang pernah berhasil dengan eksekutif. Pendapat melawan pendapat adalah lempar koin. Bukti melawan pendapat hampir selalu menang, karena eksekutif sebenarnya tidak mau salah, mereka hanya mau merasa didengar.

17.30, Serah Terima Akhir Hari

Pembaruan Linear. Empat baris. Ini adalah template yang saya gunakan setiap hari:

What shipped today: Direction C high-fi for bulk-edit (populated + empty)
What's blocked: Storybook variant for inline-edit table row (filed, awaiting design system review)
What's next: Edge cases for >100 selected, error states, keyboard nav
What to test tomorrow: Discovery call with [Customer Name], does Direction C match their export-import workaround?

Tag lead engineer pada frame Figma. Letakkan tautan spesifikasi di channel tim. Tambahkan ID uji Maze untuk putaran Jumat depan. Tutup laptop.

Total waktu Figma hari ini: sekitar 110 menit dari 8 jam kerja. Itu sekitar 23% waktu Anda untuk apa yang dianggap sebagian orang non-desainer sebagai seluruh pekerjaan.

77% sisanya adalah bukti pelanggan, penyelarasan, pembelaan, dan serah terima. Itulah pekerjaannya. 23% hanya mendapat kredit di Dribbble.

Pemeriksaan Realita

Realita PM yang Mendorong Tenggat Waktu

PM mendorong tenggat waktu karena itulah pekerjaan mereka. Mereka bukan musuh. Tapi jika Anda menyerah setiap kali PM ingin merilis versi yang lebih kecil, Anda menjadi "desainer yang selalu setuju dengan PM," yang terdengar seperti pujian selama sekitar enam bulan, lalu Anda menyadari Anda sudah berhenti melakukan desain dan mulai melakukan dekorasi.

Gerakannya bukan melawan setiap pertempuran. Gerakannya adalah memilih pertempuran di mana Anda memiliki bukti pelanggan dan berjuang keras untuk itu, serta mengalah untuk yang tidak Anda miliki. Bulk-edit hari ini adalah pertempuran bukti-pelanggan. Layak diperjuangkan. Salinan kondisi kosong yang akan Anda perdebatkan di hari lain? Mungkin tidak. Pilih pertempuran Anda.

Gangguan Desain Ulang Kompetitor

Eksekutif melihat kompetitor merilis sesuatu yang menarik dan panik. Selalu. Jawabannya hampir tidak pernah "ya, mari desain ulang." Jawabannya adalah pola tiga kalimat dari pukul 16.47:

Akui dengan bukti: "Ini yang sedang kami kerjakan dan data pelanggan di baliknya."
Tawarkan komitmen yang lebih kecil: "Saya siap melakukan tinjauan 15 menit secara terpisah."
Reframe timing: "Mari kita masukkan ini dalam percakapan Q3, bukan sprint ini."

Balasan ini berhasil karena memberi eksekutif sesuatu (rapat, pengakuan) tanpa memberi mereka apa yang mereka minta (desain ulang). Mereka hampir selalu mengambil hadiah hiburan, karena yang sebenarnya mereka inginkan adalah merasa memperhatikan.

Diagnosis "Saya Hanya Mendekorasi Figma"

Inilah evaluasi diri, jalankan setiap Jumat:

Kapan terakhir kali saya berbicara dengan pelanggan? Menonton panggilan nyata? Membaca tiket dukungan?

Jika jawabannya lebih dari 10 hari, Anda adalah dekorator, bukan desainer. Anda memindahkan piksel tanpa kebenaran dasar, artinya keputusan desain Anda berasal dari preferensi estetika Anda dan tangkapan layar Dribbble terakhir yang Anda lihat. Itu baik-baik saja untuk pekerjaan hobi dan sangat buruk untuk merilis perangkat lunak yang dibayar orang.

Perbaikannya: pesan satu panggilan pelanggan minggu ini. Bukan panggilan riset dengan skrip PM. Panggilan nyata. Tonton di Gong jika Anda tidak bisa masuk ke kalender. Dua puluh dua menit sudah cukup untuk mereset selera Anda.

Stack (Disebutkan, Beserta Fungsi Nyatanya)

Alat yang digunakan setiap desainer IC di perusahaan B2B SaaS pada tahun 2026, dan apa yang masing-masing sebenarnya lakukan dalam alur harian:

Figma: Eksplorasi, penyematan kritik, serah terima produksi. Seluruh perjalanan dari sketsa hingga rilis ada di sini. Jangan bayar plugin sampai Anda menggunakan multi-edit native dan auto-layout selama enam bulan.
Maze (atau UserTesting): Uji tak termoderasi dengan jadwal mingguan. 20 penguji, 4 pertanyaan, penyelesaian 48 jam. Loop umpan balik murah dan cepat yang menangkap masalah 14-dari-20 sebelum masuk ke dev.
Notion: Dokumen discovery, perpustakaan kutipan pelanggan, prinsip desain. Diberi tag berdasarkan area fitur, bukan berdasarkan tanggal. Perpustakaan kutipan adalah tempat kutipan pukul 08.00 tentang mengekspor ke spreadsheet kini tersimpan, siap untuk pertarungan berikutnya.
Storybook: Sumber kebenaran design system. Komponen baru masuk di sini, bukan di file Figma Anda. Jika tim Anda memperlakukan Figma sebagai sumber kebenaran, design system Anda rusak; sumber kebenaran harus menjadi hal yang benar-benar dirilis oleh engineer.
Linear: Spesifikasi, tiket, serah terima engineer, status. Setiap spesifikasi menautkan frame Figma, dokumen Notion, dan kutipan pelanggan. Jika tiket Linear tidak memiliki ketiga hal itu, belum siap untuk dibangun.

Kombinasinya lebih penting dari alat individual mana pun. Figma tanpa Notion adalah dekorasi. Notion tanpa Linear adalah sandiwara. Linear tanpa Maze adalah tebak-tebakan. Seluruh stack adalah satu loop tertutup dari sinyal pelanggan hingga fitur yang dirilis, dan pekerjaan desainer adalah menjaga loop itu tetap ketat.

Template dan Alat

Serah Terima Akhir Hari Empat Baris

What shipped today:
What's blocked:
What's next:
What to test tomorrow:

Letakkan di Linear pukul 17.30 setiap hari. Engineer tahu apa yang akan mereka terima di pagi hari. PM tahu apa yang berisiko. Anda berhenti mendapat Slack "kita di mana untuk ini?" pukul 09.00.

Skrip Balasan Gangguan Eksekutif

Tiga kalimat. Selalu dalam urutan ini: akui dengan bukti, tawarkan komitmen yang lebih kecil, reframe timing. Sesuaikan kata-katanya, jangan pernah strukturnya. Struktur itulah yang meredakan kepanikan.

Evaluasi Mingguan "Apakah Saya Seorang Dekorator?"

Setiap Jumat, dua pertanyaan:

Kapan terakhir kali saya menonton panggilan pelanggan nyata atau membaca tiket dukungan nyata?
Keputusan minggu ini mana yang berasal dari bukti pelanggan versus selera saya?

Jika pertanyaan 1 lebih dari 10 hari, perbaiki Senin depan. Jika pertanyaan 2 lebih banyak selera daripada bukti, Anda sedang menyimpang.

Skema Penandaan Kutipan Pelanggan di Notion

Setiap kutipan yang Anda simpan membutuhkan tiga tag: area fitur (bulk-edit, onboarding, dashboard), jenis masalah (workaround, dropoff, confusion, delight), dan segmen pelanggan (smb, mid-market, enterprise). Ketika Anda membutuhkan kutipan untuk gangguan eksekutif pukul 16.47, Anda bisa menariknya dalam lima belas detik. Tanpa tag, Anda akan menggulir tanpa henti.

Mengukur Hari yang Baik

Tidak setiap hari merilis piksel. Jadi bagaimana Anda tahu apakah itu hari yang baik? Empat sinyal:

Satu sinyal pelanggan nyata yang dicatat. Sebuah kutipan, timestamp Gong, tiket dukungan yang diperhatikan. Satu. Per hari. Itu saja.
Satu trade-off yang dibela dengan bukti, bukan pendapat. Bahkan jika Anda kalah argumen, pembelaan itu sendiri adalah kemenangan, karena itu membuktikan kepada engineer dan PM bahwa desain bukan preferensi estetika, melainkan disiplin.
Satu frame Figma lebih dekat ke rilis dari kemarin. Tidak perlu selesai. Harus lebih selesai.
Nol pesan Slack yang Anda sesali dikirim ke eksekutif. Ini terdengar seperti lelucon. Bukan.

Jika Anda mencapai keempatnya, hari ini adalah hari yang baik, bahkan jika versi LinkedIn dari pekerjaan Anda menyebutnya "membosankan." LinkedIn tidak membayar Anda. Pelanggan Anda yang membayar.

Panduan Praktis Product Designer