There is No Standard For Case Study Format
Ketika waktu pertama kali aku mencoba untuk menulis sebuah studi kasus, aku tidak tahu bagaimana struktur studi kasus yang benar, proses desain apa saja yang sebaiknya ada dan apa saja yang sebenarnya tidak begitu diperlukan. Ada begitu banyak contoh studi kasus, namun semakin banyak contoh semakin bikin pusing karena setiap studi kasus beda-beda pula proses desainnya. Studi kasus A pakai wireframe dan persona, studi kasus B pakai wireframe dan user journey, sementara studi kasus C tidak pakai wireframe tapi pakai mental model dan user flow.
Sampai aku menyadari memang begitulah adanya. Setiap kasus akan beda pula prosesnya dan hal itu juga akan bergantung pada kondisi, waktu, dan sumber dayanya. Akhirnya, setelah beberapa kali membaca contoh studi kasus dan teori-teori UX serta bertanya dengan orang-orang yang lebih mengerti akan UX dan design process, aku mencoba membuat case study recap versiku sendiri. Aku mencoba membuat daftar apa saja yang sebaiknya ada di dalam studi kasus dan apa saja yang sifatnya optional atau tergantung dengan kondisi.
Karena pada dasarnya mau pakai Design Thinking atau tidak, inti dari proses desain biasanya selalu ada riset, masalah, dan solusi. Ya, hanya tiga hal ini saja. Selebihnya tergantung lagi akan kondisi, waktu, kebutuhan, dan kemampuan si desainernya sendiri.
Riset sebaiknya ada karena disanalah kita bisa memvalidasi sesuatu yang kita anggap masalah. Bisa jadi masalahnya bukan yang seperti kita pikirkan, atau bisa jadi masalahnya lebih besar/kecil dari yang kita perkirakan, atau bahkan yang kita anggap masalah sebenarnya bukan sebuah masalah. Untuk itulah kita perlu memvalidasi apakah orang juga mengalami masalah yang sama dengan kita? Seberapa banyak yang mengalami masalah? Apakah ada masalah lain yang mereka alami? Because the core of a designer’s responsibility is to find the right problem to solve, not to solve a problem.
Mental Model dibutuhkan karena keberadaannya akan membantu desainer dalam menentukan solusi desain yang tepat dan sesuai dengan masalah yang dihadapi pengguna. Karena mental model sendiri mempersentasikan bagaimana orang berinteraksi di dunia nyata yang nantinya kita bisa menemukan masalah yang mereka hadapi ketika mereka melakukan suatu interaksi. Namun, jika menurutmu ini tidak perlu, cukup pakai User Journey Map atau cukup menggunakan data dari hasil riset lalu menjabarkannya dalam bentuk list atau apapun yang kamu mau, ya tentu tidak masalah.
Wireframe dibutuhkan untuk memvalidasi solusi desain sedini mungkin sebelum High-Fidelity dibuat untuk meminimalisir ketidaksesuaian hasil tes dengan yang kita harapkan. Karena tujuannya sendiri untuk mengetahui apakah struktur informasi dan flow yang kita buat mudah dimengerti oleh pengguna atau tidak? Mereka kesulitan gak waktu menggunakan desain kita? Kalau mau langsung ke High-Fidelity karena menurutmu itu gak begitu penting ya gak masalah.
Affinity Mapping bisa digunakan kalau masalah yang ada terlalu kompleks, kalau ternyata masalahnya gak begitu kompleks cukup dibuatkan daftar masalah yang tervalidasi.
Mau pakai User Flow atau Wire Flow bebas karena pada intinya kedua hal ini menjelaskan alur dari produk itu sendiri. Gak mau pakai keduanya juga gak masalah karena nanti juga ketika kita menjelaskan prototype, akan kelihatan juga bagaimana flow dari produk yang kita buat.
Intinya, gak masalah dalam penulisan studi kasus itu kamu mau masukin apa aja selagi kamu bisa menjelaskan hubungan antara elemen-elemen tersebut. Kenapa kamu pakai ini? Kenapa nggak pakai itu? Adalah hal-hal yang harus dipersiapkan sebelum kamu membuat desain suatu produk, karena yang terpenting adalah proses berpikir kamu dalam menemukan masalah sampai menentukan solusi untuk masalah tadi. Studi kasus yang lengkap belum tentu baik kalau tidak ada korelasi antara prosesnya, sebaliknya studi kasus yang terlihat simple dan tidak begitu banyak menggunakan ini dan itu bisa saja menarik kalau maksud dan tujuannya tersampaikan.
