Mendesain Sebuah MVP

f a r a h
Traveloka Design
Published in
5 min readOct 21, 2016

Ketika membuat suatu fitur baru, biasanya semangat kita masih segar dan berapi-api. Tim pun berambisi untuk melakukan sesuatu yang luar biasa. Terkadang kita bisa menjadi terlalu bersemangat sampai-sampai menambahkan banyak hal ke dalam proyek yang sedang kita kerjakan. Kalian yang berkecimpung di dunia pengembangan produk, mungkin tidak asing lagi mendengar kisah percakapan semacam ini:

(Saat meeting)

“Gimana kalo kita tambahin fitur X biar bisa jadi competitive advantage untuk mobile app kita?”

“Oh, sekalian bikin Y aja.”

“Kayaknya bagus kalo nambah Z juga.”

.

.

.

(30 menit kemudian)

Mari kita buat teknologi artificial intelligence.” — — *yha! 😔

(Dan produknya pun tidak pernah selesai, apalagi rilis.)

Tamat.

Sedih, kan? 😢

Kitabnya anak startup

Supaya hal seperti itu bisa dicegah, penting bagi kita untuk menetapkan batasan secanggih apa fitur yang akan kita buat. Salah satu referensi yang umum digunakan adalah teori dari Eric Ries dalam bukunya, The Lean Startup.

Dari buku tersebut dijelaskan bahwa prinsip dari Lean Startup adalah memperpendek waktu siklus build -> measure -> learn sehingga kita bisa segera mengeluarkan produk kita dengan cepat meskipun produk tersebut belum sempurna. Kemudian dari sana kita belajar dari kesalahan yang ditemukan ketika produk sudah ada di pasar. Istilah kerennya MVP (Minimum Viable Product). Namun, MVP yang belum sempurna bukan berarti bisa dibuat asal-asalan dan rilis tanpa validasi masalah yang ingin diselesaikan.

Berbekal ilmu dari buku The Lean Startup dan juga masukan dari designer lainnya, saya mencoba menerapkannya dalam pekerjaan saya sebagai Interaction Designer (IxD) untuk produk Hotel.

Begini kira-kira ceritanya:

Pada suatu Senin, Product Manager mengajak tim untuk berdiskusi tentang ide produk baru yang rencananya akan diluncurkan di mobile app dalam waktu beberapa bulan ke depan. Ini adalah momen diskusi yang krusial karena merupakan waktu yang tepat untuk menggali sebanyak mungkin informasi terkait ide produk serta memilah mana yang sebenarnya baru asumsi dan mana yang berasal dari data.

Dari hasil diskusi tersebut, banyak sekali asumsi tentang user yang berhubungan dengan pengalaman reservasi hotel. Setelah semua asumsi terkumpul, kami menyepakati cara menjawab asumsi-asumsi tersebut.

Langkah-langkah yang dilakukan selama proses pengembangan fitur kurang lebih seperti berikut:

  1. Verifikasi data kualitatif dan kuantitatif
  2. User research
  3. Kolaborasi dengan berbagai macam tim
  4. Tes prototype
  5. Rilis produk

1. Verifikasi Data Kualitatif dan Kuantitatif

Langkah pertama adalah memverifikasi asumsi secara kualitatif dan kuantitatif. Hal ini kami lakukan dengan berkolaborasi bersama tim Customer Service dan tim Data.

Dari hasil kolaborasi ini, kami mengidentifikasi kesulitan user dan keluhan yang mereka alami, lalu membuat prioritas masalah berdasarkan besar kecilnya dampak dari temuan tersebut. Kami juga mendefinisikan siapa user kami secara lebih konkret berdasarkan data yang ada.

2. User Research

Hal selanjutnya yang kami lakukan adalah mencari tahu kebutuhan user. Pertanyaan yang diajukan adalah seputar:

Apa informasi yang dapat membantu user untuk mengambil keputusan dengan cepat?

Apa fasilitas yang user butuhkan?

Apakah user membutuhkan fitur ini?”

Dan lain-lain.

Untuk menjawab pertanyaan-pertanyaan tersebut, kami melakukan user research. Supaya bisa berempati dengan user, kami mengundang mereka ke kantor untuk diajak berdiskusi. Diskusi ya, bukan interview satu arah.

Agenda diskusi bersama pelanggan/user ini bisa bervariasi. Salah satu cara yang pernah saya lakukan adalah dengan mengajak masing-masing dari mereka untuk menceritakan pengalamannya dalam bentuk storyboard.

Contoh Storyboard dari Johnny Holland

Storyboard ini membantu mereka mengingat urutan perjalanan mereka ketika melakukan reservasi hotel. Dengan cara tersebut, kami berusaha melihat dan memahami cerita mereka hingga detail yang mungkin tampak sepele. Tujuannya adalah agar kami dapat memberikan service memadai hingga kesulitan terkecil pun bisa kami bantu.

Banyak hal baru yang kami dapatkan terkait pengalaman mereka. Pengalaman baik meyakinkan kami tentang apa yang harus kami pertahankan. Pengalaman buruk meyakinkan kami tentang apa yang bisa kami tawarkan kepada mereka sebagai bantuan dan apa yang kami dapat perbaiki.

Hasil validasi asumsi ini membuat kami mengerti masalah apa yang dihadapi oleh pelanggan. Selain itu, kami juga jadi paham bagaimana cara pelanggan memilih hotel dan apa kekhawatiran mereka. Dari situ kami bisa menentukan hal-hal apa yang paling membantu mereka dalam melakukan reservasi hotel.

3. Kolaborasi dengan Berbagai Macam Tim

Setelah berdiskusi mengenai produk dengan pelanggan, kami mengadakan pertemuan dengan tim dan para stakeholders untuk membicarakan hasil riset yang telah kami lakukan dan bagaimana mereka dapat turut membantu dalam pengembangan produk.

Dengan komunikasi yang baik, seluruh anggota tim dapat mengetahui produk seperti apa yang akan kami kembangkan dan untuk siapa.

Kami melakukan iterasi brainstorming solusi selama dua minggu, sampai akhirnya user flow yang dibuat bisa dianggap sudah efisien dan telah mencakup berbagai skenario yang mungkin terjadi. Proses brainstorming ini dilakukan bersama Product Manager, para Designer, dan para Engineer.

4. Tes Prototype

Setelah user flow hasil brainstorming sudah cukup solid, User Interface Designer menuangkan ide flow ke dalam bentuk mockup dan Product Copywriter menentukan kata-kata yang sesuai dan jelas untuk user. Setelah mockup dan copywriting disinkronisasi, kami tes apakah perjalanan user sudah cukup jelas.

Testing ini dilakukan tidak cukup hanya sekali saja. Kami melakukan validasi konsep dengan mengetesnya bersama dengan customers. Sementara validasi usability bisa dilakukan dengan bantuan karyawan internal. Karyawan internal dari tim non produk hotel tentunya, supaya tidak bias.

Revisi, tes, revisi, tes, sampai akhirnya versi high-fidelity (lengkap dengan warna dan piksel) selesai. Setelah itu kami menuju tahap selanjutnya.

5. Rilis Produk

Setelah hasil tes dirasa cukup, barulah prototype diteruskan ke tim Engineer untuk dikembangkan. Kemudian lahirlah MVP yang ditunggu-tunggu.

Setelah produk rilis, bukan berarti tim Design sudah lepas tangan dari proses pengembangan produk. Kami memahami bahwa banyak hal yang bisa diperbaiki. Evaluasi pelanggan dan hasil data analytics akan menjadi inspirasi untuk perbaikan fitur di iterasi selanjutnya.

Kira-kira begitulah proses yang saya coba kerjakan untuk mempraktekkan teori Lean Startup dalam membuat MVP.

Kami dari Traveloka sangat berterima kasih kepada para pelanggan yang telah turut membantu pengembangan fitur Traveloka. Semoga ke depannya makin banyak pelanggan yang bersedia untuk berkolaborasi dengan kami demi menciptakan produk terbaik untuk pelanggan/user.

--

--