Dear Designer: Jangan Jadi “Yes Man”! — Bagian 2 (Jadilah Petarung)
Daripada cuma buang-buang waktu, energi dan lagi kalo emang stakeholder atau tim kita susah banget buat dikalahin mending jadi “Yes Man!” — Belum babak belur kok udah nyerah sih.
Jika ditulisan sebelumnya, aku lebih membahas tentang bagaimana caranya kita bisa berkolaborasi dengan tim & stakeholder agar tidak menjadi “Yes Man!” sekarang ditulisan kedua ini aku pengen meluruskan hakikat menjadi seorang Designer ideal yang mana kita harus tau kapan berkata “Yes” dan “No”. Ohiya kalo mau baca bagian 1, aku taruh dibawah sini ya.
Tidak menjadi Designer yang “Yes Man” bukan berarti kita harus selalu menjawab “No” apapun perkataan bos dan tim kita. Yee itu mah namanya egois. Maka dari itu designer harus mengasah skill critical thinking. Critical thinking yang dimaksud disini adalah kita harus menganalisa, mengkritisi, memfilter hal apapun yang dikatakan tim kita dan membandingkan hal yang ada di pikiran kita. Mana yang lebih masuk akal? Mana yang lebih possible untuk di aplikasikan? Mana yang impact nya tinggi dan cost nya rendah, dll.
Tapi ketika kita sudah expert untuk berpikir kritis, kita sudah sukses untuk berkolaborasi dengan mereka? Apakah mereka sudah pasti mendengarkan kita sebagai true problem solver for user? Gak sama sekali! Kalo kita berhubungan dengan manusia untuk mencapai satu kesepakatan itu adalah hal yang susah. Kita harus melawan, adu argumen, saling mengalahkan ide satu sama lain dengan berbagai macam pros & cons.
Lalu bagaimana caranya kita bisa memenangkan pertarungan tersebut?
1. Pahami product, konteks yang disampaikan, dari A — Z secara mendalam.
Jika kita gapaham tentang produk/fitur yang akan dikembangkan bagaimana kita bisa berpikir kritis? Ini yang selalu aku tekankan. Terkadang kita sebagai designer terlalu arogan dan enggan belajar tentang sesuatu diluar desain. Seolah-olah kita memakai kaca mata kuda, untuk tidak belajar hal lain. Bahkan memahami background product, bisnis, tech constraint, dll yang sebenarnya sudah disiapkan oleh PM berupa Brief/Requirement kita gak sudi. Padahal itu adalah kunci kolaborasi & komunikasi kita ke divisi lain
“Speak with their language! Designer gak bakal bisa berempati ke PM kalo gak pernah belajar product dan bisnis. Designer juga gak akan bisa berkolaborasi dengan engineer jika dia enggan belajar bagaimana cara technology itu bekerja.”
Bukan berarti kita harus mengambil S3 jurusan bisnis untuk berkolaborasi dengan PM dan belajar coding & advanced programming language untuk komunikasi dengan engineer. Gausah muluk-muluk cukup basicnya aja. Kamu harus hafal diluar kepala tentang bisnis dan product yang kamu kerjain. Kalo masih gangerti, tanya PM dan orang bisnis. Untuk kerja sama bareng engineer, kamu cukup belajar gimana cara desain mu di implementasi, ada blocker atau constraint gak? Kalo misal ada blocker gimana kita dengan mereka bisa nyari benang merahnya.
2. Jadilah pendengar yang baik
Setelah kamu sudah paham tetek bengek tentang product dan sudah bisa berempati dengan tim. Saatnya untuk menjadi pendengar yang baik bagi tim mu. Pahamilah saat sesi ideation, meeting atau dalam konteks saling melempar ide dan adu argumen. Sejatinya, disini tidak ada ide yang salah dan benar. Hanya saja kita perlu 1 kesepakatan untuk ide mana yang possible untuk dipake dan kita rasa lebih baik dibandingkan ide lain.
Ohiya, satu lagi bukan berarti 1 kesepakatan tersebut bisa jadi benang merah pas di sesi meeting itu. Bisa jadi kita harus consider semua ide yang sudah dilemparkan. Misal kita kurang setuju dengan pendapat/ide orang lain:
Hai Bambang, idemu keren banget deh. Input mu aku consider dulu ya, aku gak bisa decide langsung. Karena aku harus ngobrol dengan tim X, Y, Z dan aku bakal validasi ke user apakah ini emang yang mereka butuhkan atau tidak
3. Jadikan “data” sebagai jurusmu!
Ketika kita tidak memiliki data untuk variabel decision-making desain kita. Bisa dibilang kita akan mendesain sesuatu berdasarkan asumsi, insting dan ego kita sendiri. Asumsi & Data-driven adalah hal yang sangat kontradiktif. Dengan data kita bisa mengambil keputusan dan mengukur goals dari product kita. Bukan berarti kita tidak boleh menerka, berasumsi atau memiliki hipotesa. Designer juga harus memiliki ini, poinnya disini adalah bagaimana caranya kita memvalidasi asumsi kita tersebut menjadi data yang valid untuk bahan bakar kita membuat suatu product.
When everyone on the team is empowered to understand data, they can make more informed decisions and measure their own success.
Data disini dibagi menjadi 2, kuantitatif & kualitatif. Output dari data kuantitatif dapat berupa angka, grafik & statistik, sedangkan output dari data kualitatif bisa dibilang cukup abstrak karena datanya berupa insight statement, user needs, problem yang sifatnya lebih mendalam dan spesifik. Kamu bisa mendapatkan data kuantitatif dengan memasang tracker atau analytics di tiap product mu dan berkolaborasi dengan data scientist untuk menganalisa atau melakukan riset skala besar dengan menggunakan survei atau metode lain dengan goals mencari insight berupa angka. Sedangkan untuk mencari data kualitatif, kamu bisa melakukan riset pasar ke user kamu. Kamu bisa melakukan in-depth interview, usability testing, dan metode lain.
4. Belajar mengalah
Jika di poin sebelumnya tadi kita berambisi untuk menang, di poin terakhir ini adalah kita harus belajar mengalah. Memang bukan sebuah jaminan ketika kita sudah menguasai 3 poin diatas semua ide dan decision kita untuk mendesain ideal. Tapi ada kalanya semua argumen sama kuatnya. Akan ada saatnya data yang kita dapat dari riset tidak bisa mengalahkan product knowledge dari stakeholder. Ada waktunya desainmu akan kalah dengan technical possibility dari engineer. Dah ya kita harus belajar berlapang dada akan semua kemungkinan itu.
Jika memang decision dari tim kita memang masuk akal dan tidak ada major problem untuk di implementasi, disitulah kita harus mengalah. Kesempurnaan itu fana, dan bisa dikatakan hampir tidak ada. Kita harus mengambil resiko, kita harus berani untuk launch product kita, kita harus tes itu di skala besar, biarkan user kita merasakan product kita dulu, baru nanti ketika masalah nya muncul kita akan menyelesaikan nya satu persatu.
Tidak semua perang bisa kita menangkan. Tidak semua pendapat & ide kita akan dipakai. Product ownership tidak dimiliki oleh 1 orang. Cobalah untuk mengambil resiko. Karena sejatinya, product tidak akan pernah ada kata selesai & sempurna. Iterasi adalah jawabannya!
Kesimpulan
Tidak ada argumen atau ide yang salah dan benar. Tinggal bagaimana caranya kita mensintesis ide-ide itu jadi sebuah solusi. Ketika kita sebagai designer tidak berusaha untuk menjadi petarung. Mempertahankan & memperjuangkan ide atau solusi brilian kita menjadi kenyataan? Berarti kita siap untuk mengorbankan kualitas dari product kita dan hanya menjawab “YES!” atau setuju di setiap argumen atau permintaan dari tim kita. Masih pantaskah kita disebut sebagai designer? problem solver? Oh maaf, mungkin lebih cocok disebut dengan “Babu Stakeholder”.
— Fahmy (Yang pernah jadi babu stakeholder)
Let’s keep in touch
- Email: fahmyhaa@gmail.com
- LinkedIn : Fahmy Habibullah
- Dribbble : fahmyha
- Facebook : Fahmy Habibullah
