CHI UX Indonesia Meetup di kantor Beritagar.id, Jakarta

#TanyaJawab Lean UX — Meetup CHI UX Indonesia (26 Oct 2016)

Lanjutan jawaban dari pertanyaan yang belum terjawab saat meetup

Kamis lalu (26 Oct 2016) saya berkesempatan untuk berbagi tentang Lean UX di acara meetup CHI UX Indonesia yang diadakan di kantor Beritagar.id (Terima kasih banyak Ibu Eunice, Pak Yohanes dan Pak Erwin yang sudah mengundang saya).

Banyak pertanyaan yang masuk melalui sli.do yang belum sempat terjawab malam itu, banyak juga yang tidak sempat diskusi setelah acaranya selesai, jadi saya pikir kenapa tidak saya jawab disini supaya lebih gampang dilihat sekaligus berbagi dengan yang lain yang mungkin tidak sempat datang.

PS: beberapa pertanyaan yang serupa sudah saya gabungkan jawabannya.


1) Mana yang lebih efisien antara Lean UX dengan Product Design Sprint?
Pada intinya, Lean UX adalah sebuah mindset cara kerja yang mengutamakan kolaborasi antar tim untuk mencapai pembelajaran yang sering dengan melibatkan user/customer sedini mungkin. Sedangkan Design Sprint adalah salah satu metode cepat dan efisien untuk menyelesaikan suatu masalah dan memvalidasi ide/solusi. Jadi, sebetulnya keduanya saling melengkapi untuk diterapkan bersamaan, dan bukan untuk dibandingkan.

2) Jika harus menyelesaikan sebuah produk dalam permintaan waktu yang limited dan harus segera di develop, bagaimana UX research team mencari solusi nya?
Ada 2 cara: prioritas & belajar dari best practice, tergantung seberapa terbatas waktu yang tersedia.

  • Tentang Prioritas: Ada 3 hal dalam product management, *time-cost-quality*, tapi kita hanya boleh memilih 2 hal dan tentunya kita tidak mau berkompromi dengan kualitas kan? Lalu bagaimana kita menentukan prioritas? Kembali ke tujuan bisnis dan pertimbangkan siapa yang akan menjadi early adopters yang menunjang tujuan bisnis tersebut lalu optimalkan produk untuk memenuhi kebutuhan mereka. Ini yang sering juga disebut sebagai MVP.
  • Tentang best practice: Belajar best practices dari bisnis yang sudah sukses maupun dari kompetitor langsung juga penting, tapi jangan jadi sekedar meniru tanpa memahami alasan dibalik solusinya. Pahami alasannya, baru kemudian adaptasi prinsipnya untuk menjadi pondasi sementara.

3) Bagaimana bisa merubah mindset bisnis tradisional untuk melek UX?
Beberapa hal penting:
- Berbicara dengan bahasa mereka (mungkin istilah-istilah UX masa kini terlalu asing bagi mereka)
- Pada dasarnya semua bisnis menginginkan profit (dan rencana UX harus selalu melibatkan keberlangsungan dan pertumbuhan bisnis)
- Tunjukkan bukti bukan sekedar janji

Perlu diingat, bahwa istilah user tidak selalu hanya end-customer, tetapi stakeholders/pemilik bisnis pun bisa termasuk user, hanya saja persona-nya berbeda sehingga mewakili kebutuhan dan pain points yang berbeda pula.

4) Pernah menghadapi developer yang keras kepala? Tidak mau mengikuti flow dan design yg dibuat. Bagaimana caranya meyakinkan mereka?
Biasanya situasi ini terjadi saat masing-masing tim bekerja sendiri-sendiri (silo) dalam fase yang terpisah, sehingga setiap pekerjaan yang datang seperti sebuah kejutan buat tim yang akan melanjutkannya. Prinsip kerja lean bertujuan untuk meminimalisir dan bahkan menghilangkan situasi-situasi seperti ini dengan berkolaborasi antar tim sedini mungkin dan saling berbagi pemahaman di sepanjang project.

Shared understanding. Not shared documentation.

Jika situasinya sudah terlanjur terjadi, segera hentikan proses yang ada sekarang dan coba kumpulkan semua orang-orang inti yang terlibat dan mulai berdiskusi bersama. Pada intinya setiap orang yang berkontribusi dalam suatu project yang sama perlu memiliki pemahaman yang sama atas apa yang akan dikerjakan dan dicapai. Semua orang pasti punya keprihatinan tersendiri baik itu dari sisi tech, desain, maupun bisnis, tapi justru itulah pentingnya bekerja bersama supaya kita bisa menemukan solusi yang terbaik.

5) Product harus evolve, bagaimana jika user tidak suka dengan perubahan?
Inilah alasan kenapa harus memvalidasi ide / solusi perbaikan sedini mungkin dan terus memvalidasi sepanjang project itu berjalan, bahkan setelah launch dan seterusnya. Feedback dari user akan menentukan seberapa jauh kita harus memperbaiki atau merubah, tapi dengan melibatkan user sedini mungkin kita bisa mengidentifikasi tanda-tanda ide yang jelek lebih awal. Dan jika memang data-data sudah membuktikan idenya tidak akan berhasil, then let’s pivot.

6) Dalam mendevelop aplikasi, khususnya mengenai ui/ux dalam aplikasi tersebut selalu butuh user research atau kita membuat prototype/testing dulu?
Keduanya sama-sama penting, tergantung sedang dalam fase apa karena research tidak selalu butuh prototype. User research biasanya dilakukan setelah kita menentukan target audience, kemudian research dilakukan untuk memahami user lebih dalam tentang kebutuhan dan pain pointsnya sehingga kita bisa menentukan fitur apa yang paling penting serta bagaimana user akan berinteraksi dengan fitur-fitur tersebut. Prototype kita gunakan untuk memvalidasi kembali ke user tentang fitur-fitur yang sudah dikembangkan.

7) Ada nggak challengenya lean ux?
Challenge terbesar ada di mindset, karena ini adalah pemahaman mendasar tentang cara kita bekerja sehari-hari.

Proses kerja di perusahaan/organisasi kebanyakan adalah warisan dari cara kerja manufacture/pabrik, dimana setiap orang dibatasi role dan jobdesc tertentu dan untuk menyelesaikan suatu pekerjaan harus melalui beberapa proses yang linear (atau mirip dengan konsep waterfall). Dalam prinsip ‘lean’ setiap orang tidak terbatas hanya pada role/jobdesc, justru setiap orang didukung untuk berkontribusi dalam kolaborasi semaksimal mungkin sesuai kemampuan masing-masing.

Fleksibilitas masing-masing tim untuk merubah cara kerja dan cara berpikir akan berbeda, sebagian mungkin lebih sulit ketimbang yang lainnya, tapi bukan berarti tidak mungkin, hanya saja membutuhkan waktu dan usaha ekstra. Pada intinya, penerapan lean ux adalah sebuah proses pembelajaran dan pendewasaan bagi seluruh anggota tim yang terlibat.


We as design community have not share about the way we work and collaborate extensive enough. There are so many different team sizes out there with many different situations and challenges, and sharing will only makes us better. So please leave a comment or question, I’d love to hear your valuable thoughts and experience.

Thanks!