Capek-capek membuat sebuah fitur, akhirnya tidak ada user yang memakai

Huftttttttt………..

Dulu saya pernah membuat sebuah fitur dengan harapan bisa membantu user, tapi setelah fitur itu dirilis, ternyata tidak ada user yang memakainya.

Hufffttttt…….

Menghabiskan banyak waktu dan resource untuk membuat, tapi pada akhirnya tidak ada yang memakainya.

Apakah sia-sia? Tentu tidak. Dari hal yang kita anggap sia-sia, Sebenarnya ada satu hal berharga yang kita peroleh, yaitu adalah pelajaran (lesson learned).


Lesson Learned

Kesalahan saya waktu itu adalah terlalu percaya diri untuk merancang sebuah fitur (untuk website online shop) tanpa melakukan validasi.

Waktu itu saya berasumsi, user membutuhkan sebuah pengaturan (settings). Dimana mereka bisa memilih apa saja peraturan (terkait proses pembelian) yang akan ditampilkan di halaman profil toko mereka. Agar bisa dilihat oleh calon pembeli.

Saking percaya dirinya, saya langsung merancang fitur tersebut, lalu melanjutkan ke proses development bareng dengan programmer.

Hasilnya? Ternyata user memilih cara lain yang lebih efektif menurut mereka, yaitu dengan mengisi di bagian “Profil”.

User tidak mengisi di bagian Peraturan Pembelian

Kenapa user tidak mengisi di bagian Peraturan Pembelian?
Simple, karena tidak sesuai dengan kebutuhan mereka.

Contohnya: User hanya menerima sistem pembayaran berupa COD, tapi di bagian pengaturan tidak ada opsi tersebut. Sehingga mereka memilih mengisikan semua peraturan mereka di bagian “Profil”. Karena di bagian profil, mereka bisa mengetikkan apa saja yang mereka mau.


Pelajaran Pertama: Validasi masalah sebelum membuat solusi

Ini adalah hal yang cukup penting untuk dilakukan. Jangan sampai kita membuat sebuah solusi dari sebuah masalah yang masih asumsi. Karena nanti pada akhirnya solusi kita tidak akan terpakai.

Sebaiknya kita fokus dulu terhadap masalahnya. Dengan mengerti masalah yang sebenarnya, akan membantu kita untuk membuat solusi yang lebih efektif.

Beberapa contoh pertanyaan untuk memvalidasi masalah (kita ambil contoh tentang peraturan pembelian):
Apakah user butuh untuk menampilkan info terkait hal hal yang berhubungan dengan proses pembelian?
Jika iya, Apa saja info yang perlu untuk ditampilkan?
Apakah keperluan info yang ditampilkan untuk setiap user itu sama?, atau berbeda?.

Pelajaran Kedua: Uji coba solusi sebelum dilanjutkan ke proses development

Ketika solusi telah dibuat atau dirancang, hal yang perlu dilakukan adalah mengujinya. Bisa dengan menggunakan user testing. Hal ini penting dilakukan untuk memvalidasi, apakah solusi yang dibuat sudah sesuai kebutuhan user atau belum

Pada contoh diatas, saya hanya memberi opsi pembayaran dengan Transfer atau Kartu Kredit. Tapi ternyata user hanya menerima pembayaran lewat COD atau bayar saat ketemu. Sehingga solusi yang saya buat tidak memenuhi kebutuhan user.

Selalu bertanyalah. Bahkan bertanya pada diri sendiri. “Apakah kita sudah membuat sebuah solusi yang tepat untuk user?”

PS: Apakah artikel ini cukup membantu?, jika artikel ini belum cukup membantu, silahkan menulis di kolom komentar hal apa saja yang bisa ditambahkan agar artikel ini lebih baik lagi :)

Terima Kasih :D