Kenapa Aplikasi Menambah Fitur yang Kita Nggak Butuh?

Pernah melihat fitur baru di aplikasi dan berpikir, "Ini buat siapa?"

Reaksi itu wajar. Kita membuka aplikasi untuk satu keperluan, lalu menemukan tombol, menu, atau notifikasi yang tidak ada hubungannya dengan keperluan itu. Kesannya, tim di balik aplikasi itu tidak paham apa yang dibutuhkan penggunanya.

Kadang kesan itu benar. Tapi sering kali ada penjelasan lain: fitur itu memang bukan untukmu.

Artikel ini memakai aplikasi daftar belanja bersama yang sama dengan di product manager itu sebenarnya mengerjakan apa. Aplikasinya fiktif, kedua penggunanya simulasi, dan aku tidak menebak alasan perusahaan aplikasi tertentu di balik fitur-fiturnya.

Fitur yang tidak kamu pakai, mungkin dipakai orang lain

Bayangkan dua pengguna aplikasi daftar belanja yang sama:

	Pengguna A	Pengguna B
Tinggal dengan	Sendiri	Tiga anggota keluarga lain
Cara memakai aplikasi	Menulis daftar, lalu belanja sendiri	Berbagi satu daftar, belanja bergantian
Masalah yang sering muncul	Lupa membawa daftar	Barang yang sama dibeli dua kali

Sekarang aplikasi itu menambah fitur baru: penanda "sudah dibeli" yang langsung muncul di ponsel anggota lain, lengkap dengan nama yang mencentangnya.

Bagi pengguna A, fitur ini tidak berguna. Dia belanja sendiri, jadi tidak ada yang perlu diberi tahu. Bisa jadi dia malah terganggu oleh tampilan nama yang tidak pernah berubah.

Bagi pengguna B, fitur ini menyelesaikan masalah yang paling sering ia alami. Kalau suaminya sudah membeli telur di minimarket dekat kantor, ia tahu sebelum membelinya lagi di pasar.

Fiturnya sama. Nilainya berbeda total, karena situasi kedua pengguna berbeda.

Satu fitur, beda arti untuk tiap orang

Ada kerangka yang sudah lama dipakai untuk menjelaskan hal ini. Noriaki Kano dan rekan-rekannya memperkenalkannya pada 1984 dalam makalah berjudul Attractive Quality and Must-be Quality. Kerangka yang kemudian dikenal sebagai model Kano ini mengelompokkan fitur berdasarkan pengaruhnya pada kepuasan pengguna. Empat kelompok yang paling sering dipakai:

Kelompok	Artinya	Contoh di aplikasi daftar belanja
Wajib ada	Tidak membuat puas kalau ada, tapi membuat kecewa kalau tidak ada	Daftar tersimpan dan tidak hilang
Makin baik makin puas	Kepuasan naik seiring kualitasnya	Daftar tersinkron makin cepat ke ponsel lain
Menyenangkan	Tidak diharapkan, tapi membuat senang kalau ada	Daftar otomatis dikelompokkan per lorong toko
Tidak berpengaruh	Ada atau tidak, pengguna tidak peduli	Pilihan tema warna daftar

Yang membuat kerangka ini berguna untuk pertanyaan kita: satu fitur bisa masuk kelompok yang berbeda untuk pengguna yang berbeda. Penanda "sudah dibeli" masuk kelompok "tidak berpengaruh" bagi pengguna A, dan mungkin "wajib ada" bagi pengguna B.

Jadi ketika kamu melihat fitur yang terasa tidak berguna, pertanyaan yang lebih tepat bukan "kenapa mereka membuat ini?", tapi "pengguna seperti apa yang membutuhkan ini?"

Jadi semua fitur pasti ada alasannya?

Tidak juga. Fitur yang dibuat untuk orang lain adalah satu penjelasan. Fitur yang meleset adalah penjelasan lain, dan itu juga sering terjadi.

Pendo, perusahaan perangkat lunak analitik produk, menerbitkan Feature Adoption Report pada 2019 berdasarkan data pemakaian dari 615 langganan pelanggannya. Temuan mereka: rata-rata 12% fitur menghasilkan 80% volume pemakaian harian, sementara 80% fitur jarang atau tidak pernah dipakai. Karena datanya berasal dari pelanggan Pendo sendiri dan Pendo menjual alat untuk mengukur pemakaian fitur, angka ini sebaiknya dibaca sebagai gambaran, bukan ukuran pasti untuk semua aplikasi.

Kalau sebagian besar fitur jarang dipakai, sebagian di antaranya mungkin memang dibuat untuk kelompok kecil yang membutuhkannya. Tapi sebagian lagi mungkin dibuat berdasarkan dugaan yang tidak pernah diuji. Beberapa kemungkinan yang umum:

• Kebutuhan ditebak, bukan dicari tahu. Tim membayangkan pengguna menginginkan sesuatu tanpa memeriksa apakah masalahnya nyata.
• Satu permintaan dianggap mewakili banyak orang. Satu keluhan yang keras terdengar seperti keluhan semua pengguna.
• Fitur dibuat, tapi tidak pernah diukur. Tidak ada yang memeriksa apakah fitur itu benar-benar dipakai setelah dirilis.

Ini persis risiko yang dalam kerangka Marty Cagan disebut risiko value: apakah pengguna benar-benar mau memakainya. Penjelasannya ada di artikel tentang pekerjaan product manager. Dan pola "dugaan diperlakukan sebagai kepastian" itu sama dengan yang dibahas di saran ini terdengar bagus, apa yang perlu dicek.

Dari sisi tim produk: fitur ini untuk siapa?

Kalau kamu yang harus memutuskan, misalnya sebagai PM aplikasi daftar belanja tadi, pertanyaannya bukan "fitur ini bagus atau tidak", tapi:

1. Kelompok pengguna mana yang mengalami masalahnya? Pengguna yang berbagi daftar, bukan semua pengguna.
2. Seberapa sering masalah itu terjadi bagi mereka? Sekali sebulan atau setiap minggu?
3. Seberapa besar kelompok itu? Kalau cuma sedikit pengguna yang berbagi daftar, mungkin masalah lain lebih layak dikerjakan dulu.
4. Bagaimana supaya fitur ini tidak mengganggu kelompok lain? Misalnya penanda nama hanya muncul kalau daftar sudah dibagikan ke orang lain. Pengguna A tidak pernah melihatnya.
5. Bagaimana kita tahu fitur ini berhasil? Misalnya dengan memeriksa apakah keluhan barang dobel berkurang setelah fitur dirilis.

Pertanyaan ketiga adalah soal memilih prioritas, dan cara menimbang manfaat terhadap usaha ada di kalau semuanya ingin dikerjakan, mulai dari mana. Pertanyaan keempat sering terlupakan, padahal itu yang membedakan fitur yang membantu satu kelompok dari fitur yang merepotkan kelompok lain.

Apa yang bisa kamu lakukan sebagai pengguna?

Kalau ada fitur yang mengganggumu, ada dua hal yang biasanya lebih berguna daripada sekadar kesal:

Cek pengaturan. Banyak aplikasi membolehkan fitur tertentu dimatikan atau disembunyikan, terutama notifikasi.

Beri masukan yang konkret. Masukan "fitur ini nggak berguna" sulit ditindaklanjuti. Masukan yang menyebut situasimu jauh lebih membantu: "Aku belanja sendiri, jadi penanda nama ini cuma menambah tampilan. Bisa disembunyikan kalau daftarnya tidak dibagikan?" Susunannya sama dengan usulan yang mudah ditanggapi di cara menyampaikan ide supaya orang paham: konteks, usulan, dan alasan.

Pelajaran di luar aplikasi

Pola yang sama muncul di luar aplikasi. Aturan baru di kantor yang terasa merepotkan, kebiasaan di rumah yang terasa tidak perlu, atau fasilitas di lingkungan tempat tinggal yang tidak pernah kamu pakai, mungkin dibuat untuk orang yang situasinya berbeda denganmu.

Itu tidak berarti semuanya pasti tepat. Sebagian memang keliru, sama seperti sebagian fitur aplikasi. Tapi sebelum menyimpulkan, pertanyaan "ini untuk siapa, dan masalah apa yang mau diselesaikan?" biasanya membuka lebih banyak pemahaman daripada "kenapa ini ada?"

Ringkasan

Fitur yang tidak kamu butuhkan belum tentu tidak dibutuhkan siapa pun.

1. Satu fitur bisa punya nilai berbeda untuk pengguna yang berbeda. Model Kano menjelaskan bahwa fitur yang sama bisa wajib bagi satu orang dan tidak berpengaruh bagi orang lain.
2. Tapi banyak fitur memang meleset. Data Pendo menunjukkan 80% fitur jarang atau tidak pernah dipakai, sering karena kebutuhannya ditebak tanpa diuji.
3. Pertanyaan yang berguna adalah "untuk siapa?" Bagi tim produk, untuk memutuskan fitur. Bagi pengguna, untuk memahami dan memberi masukan yang konkret.

Sumber: Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, 14(2). Pendo (2019). The 2019 Feature Adoption Report. pendo.io