Hari dalam Kehidupan UX Designer (B2B SaaS, Edisi IC)

Deskripsi pekerjaan bilang Anda akan "mendesain pengalaman yang indah dan membentuk masa depan produk kami." Yang sebenarnya Anda lakukan kemarin adalah menghabiskan 90 menit berdebat dengan seorang engineer tentang apakah modal konfirmasi perlu tombol batal sekunder, lalu 40 menit menjelaskan kepada sales rep mengapa "buat terlihat lebih menarik" bukan sebuah brief desain. Selamat datang di UX B2B SaaS.

Dunia imajinasi dan kenyataan adalah pekerjaan yang berbeda. Dunia imajinasi adalah foto Dribbble, moodboard, dan tepuk tangan pemangku kepentingan. Kenyataannya adalah catatan riset, perdebatan spesifikasi, dan file Figma dengan 47 frame bernama "Frame 142," "Frame 143," "Frame 144." Keduanya nyata. Hanya satu yang milik Anda.

Inilah seperti apa hari kerja normal bagi UX designer dengan pengalaman satu hingga lima tahun. Tanpa glamor. Tanpa foto portfolio yang memukau. Hanya ritme kerja yang sesungguhnya, jebakan waktu yang tidak ada yang memperingatkan Anda, dan disiplin kecil yang menentukan apakah Anda pulang dengan perasaan lelah-tapi-baik atau lelah-dan-kesal.

08.02, Triase Figma dan Slack

Anda membuka Figma pertama. Tiga file memiliki komentar yang masuk semalam. Dua dari engineer di zona waktu lain, satu dari PM yang bekerja malam.

Anda membuka Slack kedua. Dua belas pesan belum dibaca di DM dan channel #design-team. Satu dari sales rep dengan screenshot dashboard dan kata-kata "bisa kita buat ini terlihat lebih modern." Satu dari customer success yang menandai Anda dalam thread tentang pelanggan yang tidak bisa menemukan tombol ekspor. Sisanya adalah kebisingan.

Triase membutuhkan sepuluh menit jika dilakukan dengan benar. Tiga kategori:

Memblokir engineering. Seorang engineer terhenti karena sebuah state tidak ditentukan di file Figma Anda. Ini adalah interupsi paling mahal untuk ditunda. Jika Anda menunggu tiga jam, mereka beralih ke hal lain dan komponen Anda terlambat satu minggu. Jawab di komentar Figma sekarang. Jawaban dua kalimat, screenshot frame spesifikasi, tautan ke komponen Storybook jika ada. Lanjut.

Permintaan "buat lebih menarik". Sales rep ingin dashboard "lebih eye-catching." Ini permintaan nyata dari orang nyata, dan layak mendapat jawaban nyata, tapi tidak layak mendapat perhatian pagi Anda. Balas di Slack: "Akan ditambahkan ke backlog polesan visual. Pertanyaan singkat dulu: apakah ada deal tertentu yang ingin Anda tutup di mana tampilan menjadi hambatan, atau ini sekadar perasaan umum?" Sembilan dari sepuluh kali, jawabannya adalah "perasaan umum" dan permintaan perlahan menghilang. Pada kasus ke sepuluh, ini adalah eskalasi pelanggan nyata dan Anda meneruskannya ke design lead.

Pertanyaan spesifikasi. "Seperti apa tampilan state ini ketika pengguna memiliki 0 hasil?" Ini nyata dan layak mendapat waktu Anda, tapi tidak perlu jawaban sinkron. Tandai untuk blok async pukul 10.

Triase pagi tidak glamor. Tapi ini juga satu-satunya 15 menit dengan leverage tertinggi dalam hari Anda. Designer yang melewatinya menghabiskan sisa hari secara reaktif. Designer yang melakukannya dengan baik membentuk seperti apa hari mereka.

10.00, Blok Spesifikasi Async

Ini bagian pekerjaan yang tidak diajarkan di sekolah: sebagian besar waktu "desain" Anda adalah menulis.

Anda membuka Notion. Ada tiga pertanyaan spesifikasi terbuka dari triase pagi. Masing-masing perlu jawaban tertulis yang menutup loop, bukan yang membuka kembali loop.

Jawaban buruk: "Sepertinya harus notifikasi toast, tapi coba beri tahu pendapat Anda." Ini mengundang thread enam pesan, karena Anda telah mengalihkan keputusan kembali ke engineer.

Jawaban baik: "Notifikasi toast, kanan atas, auto-dismiss 4 detik. Menggunakan kembali komponen <Toast variant='success'> yang sudah ada di Storybook. Frame 47 di file menunjukkan spesifikasinya. Jika API membutuhkan lebih dari 8 detik, ganti ke banner inline persisten alih-alih toast (frame 48 menunjukkan varian itu). Tiket Linear terlampir di bawah."

Jawaban baik membutuhkan enam menit untuk ditulis. Jawaban buruk membutuhkan 30 detik dan menghabiskan satu jam tim selama dua hari berikutnya. Anda belajar ini dengan cara yang sulit.

Disiplinnya adalah: setiap jawaban spesifikasi diakhiri dengan tiga hal. Keputusan, referensi komponen (tautan Storybook atau nomor frame Figma), dan tautan balik tiket di Linear atau Jira. Tanpa pengecualian. Jejak bukti adalah inti dari semuanya. Enam bulan dari sekarang ketika seseorang bertanya "mengapa kita membangunnya seperti ini," jejaknya yang menyelamatkan Anda dari membuka ulang perdebatan.

Blok async Anda berlangsung dari pukul 10 hingga 11.30. Anda menjawab empat thread spesifikasi, menulis satu dokumen Notion singkat tentang keputusan pola, dan menutup dua komentar Figma yang sebenarnya tidak perlu dijawab karena engineer sudah menemukan jawabannya sendiri dengan membaca file. Kategori terakhir itu adalah kemenangan diam-diam. Artinya file Anda cukup jelas untuk dibaca.

12.00, Uji Kegunaan Moderasi

Makan siang dulu. Anda makan sandwich di meja karena uji dimulai pukul 12.30 dan Anda perlu membaca ulang rencana uji. Ya, Anda seharusnya istirahat makan siang yang benar. Tidak, Anda tidak akan melakukannya, bukan pada hari uji.

Uji tersebut berdurasi 30 menit, moderasi langsung, dijalankan melalui Maze dengan pelanggan nyata: seorang billing manager di perusahaan logistik 200 orang. Anda menguji alur ekspor faktur baru. Hipotesis Anda adalah alur baru mempersingkat waktu-ke-ekspor dari 90 detik menjadi di bawah 30. Hipotesis null Anda adalah alur baru membingungkan pengguna dengan cara yang tidak dilakukan alur lama.

Inilah yang sering salah dilakukan designer baru. Anda tidak mengamati apa yang dikatakan pengguna. Anda mengamati apa yang mereka lakukan. Umpan balik verbal sebagian besar adalah kebisingan. Pengguna ingin membantu. Mereka akan berkata "ini bagus, sangat intuitif" sementara kursor mereka melayang di atas tombol yang salah selama sembilan detik. Hovering itu adalah datanya. Komentar "sangat intuitif" adalah sopan santun.

Yang sebenarnya Anda amati:

• Ragu-ragu. Kursor berhenti. Mata beralih ke bagian lain layar. Pengguna membaca ulang sebuah label. Apa pun yang melayang lebih dari dua detik tanpa klik adalah tanda bahaya.
• Klik yang salah. Mereka mengklik hal yang salah, lalu mundur, lalu mengklik yang benar. Klik yang salah adalah sinyal bahwa hierarki visual Anda berbohong tentang apa yang primer.
• Membaca ulang. Mereka membaca label, menggulir melewati, lalu menggulir kembali untuk membacanya lagi. Label itu tidak jelas. Tugas Anda bukan menambahkan tooltip. Tugas Anda adalah menulis ulang labelnya.

Anda mencatat dalam dokumen Notion tiga kolom: timestamp, observasi, hipotesis. Tanpa komentar, tanpa "saya pikir ini berarti." Hanya apa yang Anda lihat dan apa yang mungkin disarankan. Anda akan mensintesisnya nanti.

Sistem pencatatan Anda harus bertahan untuk sesi berturut-turut. Triknya adalah menggunakan template satu halaman per studi dengan kolom yang sudah diisi sebelumnya dan screenshot ditambahkan setelah sesi, bukan selama. Jika Anda mencoba mengambil screenshot selama sesi, Anda melewatkan perilaku berikutnya. Sesi adalah prioritasnya. Artefak datang setelahnya.

Billing manager menyelesaikan tugas ekspor dalam 47 detik. Lebih baik dari alur lama, lebih lambat dari hipotesis Anda. Ia ragu dua kali: sekali di pemilih rentang tanggal (8 detik), sekali di pemilih format file (5 detik). Ia bilang pengalamannya "jauh lebih baik dari yang kami miliki sekarang," yang nyata tapi bukan datanya. Dua keraguan itu adalah datanya.

14.00, Kritik Desain

Empat puluh lima menit dengan dua designer lain dan design lead Anda. Tiga flow dalam agenda, masing-masing lima belas menit. Anda mempresentasikan salah satunya.

Sebagian besar kritik gagal dengan cara yang sama: berubah menjadi desain komite. Seseorang bilang "bagaimana jika kita coba ungu alih-alih biru," orang lain bilang "bagaimana jika modal muncul dari kanan," dan 20 menit kemudian ruangan telah mendesain ulang flow yang sudah 80% selesai menjadi flow yang kini 40% selesai. Ini adalah kegagalan yang sudah dikenal. Ada namanya dalam kepala Anda: spiral kelompok fokus.

Begini cara menghindarinya. Ketika Anda mempresentasikan flow, Anda menyampaikan tiga hal di awal:

1. Masalah pengguna. Bukan "kami mendesain ulang alur ekspor." Sebaliknya: "Billing manager di pelanggan mid-market menghabiskan rata-rata 90 detik mengekspor faktur dan memberi tahu kami dalam tiket dukungan bahwa prosesnya membingungkan."
2. Kendalanya. "Kami tidak bisa mengubah kontrak API mendasar selama dua kuartal lagi."
3. Umpan balik spesifik yang Anda inginkan. "Saya tidak meminta tentang polesan visual hari ini. Saya bertanya apakah flow ini menangani kasus edge multi-mata-uang untuk pelanggan Eropa kami."

Jika Anda memberikan ketiganya, kritik menjadi berguna. Orang memberi Anda umpan balik tentang hal yang Anda tanyakan, bukan tentang hal yang mereka perhatikan dalam 30 detik pertama.

Dua jenis umpan balik kritik yang benar-benar Anda inginkan terdengar seperti ini. "Saya tidak setuju dengan pola ini" adalah pendapat, sopan diakui, boleh diabaikan. "Ini tidak akan berhasil untuk pengguna admin enterprise karena mereka memiliki 200 ekspor tersimpan dan dropdown Anda hanya menampilkan 10" adalah kritik nyata. Jenis kedua adalah emas. Jenis pertama hanya pembuka. Perlakukan keduanya secara berbeda.

Anda meninggalkan kritik dengan tiga perubahan konkret yang perlu dilakukan pada flow sebelum serah terima. Tidak ada satupun yang berkaitan dengan warna.

16.00, Interupsi

PM menghubungi Anda via Slack. "Hei, pimpinan ingin desain ulang cepat dashboard sebelum Jumat. Bisa dikerjakan besok?" Ini hari Rabu pukul 16.07.

Momen ini menentukan apakah Anda menjadi pelayan piksel tim atau tetap menjadi seorang designer.

Respons yang salah adalah "oke, akan langsung dikerjakan." Respons yang salah terasa baik sesaat karena Anda terlihat membantu. Itu respons yang salah karena pada hari Jumat Anda akan memiliki mockup dashboard yang setengah jadi, dua sesi kegunaan yang dilewatkan, dan dokumen serah terima yang tidak ditulis untuk pekerjaan yang sebenarnya sudah Anda komitkan minggu lalu.

Respons yang benar adalah pertanyaan, bukan persetujuan. "Dengan senang hati akan saya lihat. Bisakah Anda ceritakan apa yang berubah di roadmap sehingga ini menjadi item Jumat, dan apa yang dimaksud 'desain ulang' di sini: penyegaran visual tata letak yang ada, atau restrukturisasi arsitektur informasi? Keduanya adalah pekerjaan yang sangat berbeda." Kirimkan dalam 90 detik. Kembali ke persiapan serah terima Anda.

Separuh waktu, pertanyaan itu mengungkapkan bahwa "desain ulang" berarti "ubah warna grafik," dan orang lain di tim bisa melakukan itu. Seperempat waktu, mengungkapkan bahwa permintaannya nyata tapi tenggat waktunya tidak. Seperempat waktu lainnya, ini adalah keadaan darurat nyata, dan Anda memindahkan sesuatu dari jadwal minggu ini untuk menanganinya. PM lebih menghargai Anda karena pertanyaan itu daripada karena persetujuan refleksif.

17.00, Persiapan Serah Terima

30 menit terakhir. Ini bagian hari di mana sebagian besar designer memotong sudut dan sebagian besar engineer mengirim Slack keesokan paginya untuk menanyakan "apa maksudnya ini?"

Disiplin serah terima adalah 20 menit pekerjaan yang mencegah 90 menit ping esok hari. Ini adalah asuransi termurah yang pernah Anda beli.

Anda membersihkan file Figma. Frame diberi nama dengan niat: "Alur ekspor / langkah 2 / varian multi-mata-uang." Layer dikelompokkan. Frame tersembunyi dihapus. Komponen ditautkan, bukan dilepas.

Anda menulis spesifikasi Notion satu halaman. Lima bagian, tidak lebih. Masalah (satu kalimat). Solusi (tiga kalimat). State dan kasus edge (daftar). Referensi komponen (tautan Storybook, nomor frame Figma). Pertanyaan terbuka (hal-hal yang masih perlu Anda dan engineer putuskan).

Anda melampirkan dokumen Notion ke tiket Linear. Anda meletakkan tautan Storybook di komentar tiket. Anda menandai engineer.

Anda menutup laptop pukul 17.32.

Apa yang Tidak Diceritakan Deskripsi Pekerjaan

Separuh pekerjaan ini adalah riset dan menulis. Mungkin lebih dari separuh. Bagian Figma (bagian yang dideskripsikan JD sebagai "mendesain pengalaman yang indah") sebenarnya adalah irisan terkecil dari minggu Anda. Kebanyakan minggu ada di antara 25% dan 35% dari waktu Anda. Sisanya adalah berbicara dengan pengguna, berbicara dengan engineer, menulis spesifikasi, duduk dalam kritik, dan mengelola interupsi.

Designer yang kelelahan di B2B SaaS datang dengan harapan seperti Dribbble. Mereka ingin membuat layar. Mereka mendapat pekerjaan yang sebagian besar berupa percakapan dan menulis tentang layar. Ketidaksesuaian itulah yang menghabisi mereka.

Designer yang berkembang memperlakukan Figma sebagai alat berpikir, bukan portfolio. File mereka berantakan di tengah dan rapi di akhir. Notion mereka penuh dokumen spesifikasi satu halaman yang tidak dibaca orang lain tapi menyelamatkan mereka setiap kali ada yang bertanya "mengapa kita mengirimkan ini seperti ini." Mereka menulis lebih banyak daripada mendesain, dan mereka baik-baik saja dengan itu karena tulisanlah yang membuat desain berhasil diterapkan.

Interupsi "buat lebih menarik," spiral kelompok fokus, jebakan pelayan piksel, semuanya punya nama karena memang berulang, bukan karena nasib buruk. Begitu Anda menamainya, Anda bisa mengenalinya dalam lima menit pertama. Itulah keterampilan yang tidak diajarkan di sekolah dan tidak ada di JD.

Anda bukan di pekerjaan ini untuk membuat layar. Anda di sini untuk membuat keputusan tentang layar, mempertahankannya dalam tulisan, dan mengirimkannya dengan cara yang bertahan melewati perubahan roadmap kuartal berikutnya. Layar adalah artefaknya. Keputusan adalah pekerjaannya.

Besok terlihat hampir sama seperti hari ini. Triase, blok async, sesi pengguna, kritik, interupsi, serah terima. File berbeda, bentuk yang sama. Bentuk itu adalah pekerjaannya.

Pelajari Lebih Lanjut

• Template Job Description Product Designer, JD pendamping yang dipasangkan dengan panduan ini
• 30/60/90 Hari Pertama sebagai UX Designer Baru
• Riset Pengguna yang Menggerakkan Roadmap
• Wireframing dan Prototyping yang Bertahan Melewati Engineering
• Kesalahan Umum UX Designer