Pentingnya Menghapus Elemen yang Tidak Perlu

• Produk yang makin kompleks bisa menjadi lebih baik bukan dengan lebih banyak penjelasan, melainkan dengan menghapus elemen yang tidak perlu; kasus kalkulator harga Pinecone menunjukkan hal ini
• Kalkulator harga awalnya dimaksudkan agar pengguna dapat memperkirakan biaya berbasis penggunaan di muka, tetapi kesalahan input kecil saja dapat membuat estimasi biaya membengkak hingga 1.000 kali dan menghalangi pendaftaran
• Secara internal, masalah ini coba diperbaiki dengan menambahkan penjelasan dan nilai default, tetapi perbaikan itu justru menimbulkan kebingungan lain hingga lebih dari 550 pesan menumpuk di kanal Slack khusus
• Dalam uji A/B yang menghapus kalkulator, pengunjung yang tidak melihatnya memiliki kemungkinan mendaftar 16% lebih tinggi dan kemungkinan menghubungi tim 90% lebih tinggi, tanpa peningkatan tiket dukungan terkait harga
• Elemen yang pernah ditambahkan cenderung tetap ada meskipun nilainya berkurang, sehingga keputusan untuk mengurangi bagian besar dari produk, proyek, dan proses perlu ditinjau secara sadar

---

Kasus penghapusan kalkulator harga Pinecone

• Dalam model harga berbasis penggunaan, Pinecone menempatkan kalkulator biaya di halaman harga karena pengguna sulit mengetahui biaya aktual secara akurat sebelumnya
• Setelah bertemu dan memvalidasi dengan calon pengguna, ditemukan bahwa sebagian pengguna batal mendaftar setelah melihat estimasi biaya yang sangat tinggi dari kalkulator
  • Kasus penggunaan tersebut tergolong relatif kecil menurut standar Pinecone
  • Kalkulator ternyata jauh lebih membingungkan dan sensitif dari perkiraan
  • Kesalahpahaman atau input yang keliru sekecil apa pun dapat melebih-lebihkan estimasi biaya hingga 1.000 kali
• Kalkulator memberi keyakinan yang keliru kepada pengguna, dan pengguna menerima angka kalkulator seolah-olah itu biaya aktual tanpa memeriksa dokumentasi, bertanya kepada tim, atau memverifikasinya lewat penggunaan langsung
• Sebagai respons cepat, penjelasan, disclaimer, detail, dan nilai default ditambahkan, tetapi upaya untuk mengurangi satu kebingungan justru melahirkan kebingungan lain
• Diskusi internal juga membesar hingga lebih dari 550 pesan menumpuk di kanal Slack khusus, dan banyak waktu tersita untuk rapat serta penulisan dokumen
• Seseorang sempat bertanya, “Apakah kalkulator ini benar-benar diperlukan?”, tetapi awalnya pertanyaan itu tenggelam di antara pendapat mayoritas
• Setelah itu, uji A/B dilakukan untuk memastikan apakah nilai produk akan hilang jika kalkulator beserta masalah yang ditimbulkannya dihapus
  • Pengunjung yang tidak melihat kalkulator memiliki kemungkinan mendaftar 16% lebih tinggi dibanding pengunjung yang melihat kalkulator
  • Kemungkinan menghubungi tim 90% lebih tinggi
  • Tidak ada peningkatan tiket dukungan terkait harga
• Dalam survei internal, 7 dari 10 anggota perusahaan memperkirakan versi dengan kalkulator akan lebih baik, tetapi hasil pengujian menunjukkan sebaliknya

Mengapa penghapusan itu sulit

• Banyak organisasi, saat menyelesaikan masalah, lebih dulu memikirkan penambahan daripada pengurangan
  • Meski penghapusan dapat memberi keuntungan besar, sulit menjadikannya pilihan yang intuitif
  • Sebagai riset terkait, artikel ini mengutip People systematically overlook subtractive changes
• Sistem penghargaan juga biasanya lebih selaras dengan menambahkan sesuatu, sementara insentif untuk penghapusan cenderung jarang ada
  • Sebagai contoh bahwa penghapusan juga perlu diberi penghargaan, artikel ini turut menyajikan Negative 2000 Lines Of Code
• Orang yang pernah sangat kuat mendorong penambahan suatu elemen sulit mengakui bahwa elemen tersebut tidak menambah nilai
• Jika seseorang mencoba menghapus elemen yang dulu didorong oleh orang lain, tindakan itu bisa terlihat seperti menyerang penilaian atau pekerjaan orang tersebut, sehingga elemen itu cenderung dibiarkan
• Sesuatu yang sudah ada sering diasumsikan ada karena alasan yang baik, lalu tidak ditinjau ulang
• Setelah terbiasa dengan kondisi saat ini, orang cenderung enggan terhadap perubahan itu sendiri sebelum cukup mempertimbangkan penghapusan
• Penyederhanaan dengan berani memangkas elemen non-esensial dapat meningkatkan tingkat respons pelanggan, menghasilkan sistem yang lebih andal, serta mempercepat pertumbuhan dan pendapatan
• Yang dibutuhkan bukan pemangkasan kecil, melainkan keputusan untuk menghapus bagian besar dari proyek, produk, dan proses; semakin kuat penolakan tim terhadap suatu penghapusan, semakin besar pula potensi keuntungan yang mungkin tersembunyi di dalamnya

[GN⁺]

Pendapat Hacker News

• Saya tidak tahu kalkulator ini bagus atau buruk, tetapi alasannya sekilas tampak cukup tidak masuk akal
  Wajar saja pendaftaran meningkat jika Anda menyembunyikan fakta bahwa biaya produk bisa besar dari pengguna. Apakah mereka benar-benar menjadi lebih baik bergantung pada apakah mereka nanti menerima tagihan yang tidak menyenangkan, dan itu tidak bisa diketahui lewat A/B test singkat di halaman pendaftaran
  Saya juga sering melihat contoh seperti rasio klik naik setelah informasi dihapus dari snippet hasil pencarian. Karena untuk melihat informasi yang tadinya ada di snippet sekarang orang harus mengklik, wajar saja klik meningkat, tetapi mana yang sebenarnya lebih baik jadi terlupakan

  • Masalah kalkulator itu adalah jika pengguna memasukkan data yang sedikit salah atau salah memahami arti suatu metrik, kalkulator menghasilkan estimasi 1000 kali harga sebenarnya
    Dilemanya adalah “bagaimana memperbaiki kasus seperti itu”, dan solusinya adalah “hapus kalkulator yang berantakan itu”. Bukan menyembunyikan biaya 1000 kali lipat, melainkan menghindari kehilangan pengguna akibat estimasi keliru 1000 kali lipat
  • Sayang juga mereka tidak mengakui kemungkinan adanya dark pattern. Banyak perusahaan tahu bahwa jika informasi harga dihapus, calon pelanggan akan masuk lebih jauh ke dalam funnel, dan karena waktu yang sudah mereka habiskan, pada akhirnya mereka membeli meski sebenarnya ingin memilih pesaing
    Contohnya dealer mobil yang mempersulit pengecekan harga online dan mendorong orang mengirim email atau datang langsung. Kalkulator memudahkan belanja pembanding, dan banyak perusahaan tidak menyukainya. Sadar atau tidak, ini adalah motif yang perlu dipertimbangkan
  • Ini hampir merupakan blind spot seluruh industri, dan meluas melampaui industri teknologi ke desain industri dan rekayasa produk secara umum
    Jika transparan kepada pengguna, hasilnya pasti lebih membingungkan. Sebab tolok ukurnya sendiri memperlakukan pengguna seperti ternak bodoh yang bisa digiring ke rumah jagal. Dalam kerangka ini, fitur apa pun yang memperlakukan pengguna sebagai manusia yang berpikir akan menciptakan kebingungan dan merusak conversion rate
  • Ini sepenuhnya benar. Pernah ada penggemar berat A/B test di tim kami yang sangat mengurangi ruang kosong di halaman harga agar tombol daftar naik ke above the fold, lalu menjadikan peningkatan klik tombol daftar sebagai bukti eksperimen berhasil
    Tentu saja halaman harga jadi buruk rupa, tetapi itu tidak lagi penting karena “pendaftaran meningkat”. Dalam kasus ini, kalkulator mungkin terasa membebani bagi orang yang tidak akrab dengan istilahnya, tetapi keputusan intuitif “bagaimana menyederhanakannya?” seharusnya datang lebih dulu. Budaya A/B test yang mengharuskan semuanya dianalisis dan dibuktikan secara statistik itu kurang bagus
  • Bukankah itu bisa dilihat sebagai fungsi dari kalkulator yang terlalu sederhana dan sering salah?
    Jika pengguna sejak awal tidak bertahan, bagaimana Anda bisa menguji apakah mereka puas atau tidak puas nantinya? Jika Anda menutup loop dan meningkatkan engagement, peluang untuk mendidik pelanggan dengan benar dan memuaskan mereka lewat interaksi berikutnya juga meningkat

• Saya meng-upvote karena ingin menyebarkan kebijaksanaan besar dari tulisan ini, tetapi batasnya bisa cepat kabur
  Pola pikir “apakah sesuatu yang bernilai akan hilang jika bagian ini dihapus?” kadang berdampak buruk pada proyek tahap awal. Terutama karena nilai masa depan dari kode dan data sulit diperkirakan
  Suatu kali, di proyek baru, saya membuat skema SQL awal dengan kolom metadata tambahan untuk tag postingan, tetapi minggu berikutnya seorang engineer senior menghapus semuanya dengan alasan prinsip YAGNI. Karena saat itu tidak ada di roadmap, secara teknis ia benar, tetapi pekerjaan awalnya hanya sekitar satu jam dan biaya mempertahankan datanya nyaris nol
  Setahun kemudian, orang yang membuat fitur yang membutuhkan kolom itu ternyata saya sendiri, dan sekarang saya harus mengerjakan hal yang sama lagi, termasuk migrasi DB produksi yang sudah memiliki pengguna. Jadi sebaliknya, kita juga perlu bertanya “apakah sesuatu yang bernilai akan muncul jika bagian ini dihapus?” Dalam tulisan ini jawabannya jelas, tetapi dalam kasus saya tidak demikian

  • Saya paham situasinya, tetapi meskipun belakangan produk memang membutuhkannya, keputusan senior saat itu untuk menghapusnya mungkin tetap benar
    Saya ingat SpaceX punya metrik yang menangkap konsep serupa: persentase fitur yang dihapus lalu ditambahkan kembali untuk kedua kalinya. Jika semua fitur yang dihapus ditambahkan kembali, berarti tingkat residivisme fitur 100%, tandanya terlalu sering memangkas; 70% juga tinggi, 30% pun tinggi
    Namun 0% juga buruk. Jika tidak cukup mencoba menghapus fitur yang tidak perlu, produk akhirnya membengkak. Pada tahap awal produk, rasio ini tampaknya lebih tinggi, dan seiring matang akan lebih baik turun ke rasio rendah yang tidak nol
    Karena saat ini kita tidak tahu set fitur persis yang diperlukan untuk produk terbaik, pendekatan probabilistik untuk memangkas hal yang tidak perlu itu boleh saja. Jika diperlukan, tambahkan lagi, dan selama itu tidak terjadi terlalu sering, tidak ada alasan meragukan keputusan penghapusan awal
    Atau, alih-alih mencoba keduanya di dunia nyata dan melihat hasilnya, kita bisa rapat selama 6 bulan saja membahas proxy metric untuk hipotesis dan keyakinan awal yang tidak terucapkan
  • Masalah utama saat menambahkan sesuatu karena mungkin dibutuhkan di masa depan adalah orang pergi, orang lupa, dan setahun kemudian ada kolom metadata tetapi tidak ada yang tahu lagi dipakai untuk apa
    Jadinya “boleh dipakai? boleh dihapus?” lalu ada yang teringat Knight Capital, yang pernah mengalami bencana besar setelah menggunakan ulang field lama. Karena itu mempertahankan field lama selalu terasa lebih aman, dan akhirnya muncul metadata dan metadata_1. Tahun berikutnya tidak ada yang tahu mengapa ada dua field metadata, sehingga makin membingungkan
  • Dalam kebanyakan kasus, menebak kebutuhan di muka membuat kita membangun sesuatu yang tidak perlu. Bahkan ketika akhirnya benar-benar diperlukan, biasanya bentuk yang dibutuhkan sangat berbeda
    Codebase terburuk yang pernah saya alami dirancang dengan mempertimbangkan penggunaan masa depan yang kompleks. Bahkan dalam contoh ini, codebase baru membutuhkan kolom itu setahun kemudian. Jadi menurut saya preseden yang benar adalah menghapus semua potongan kode yang mengantisipasi kebutuhan masa depan. Bahkan jika pada akhirnya diperlukan lagi
  • Mudah sekali terseret ke arah terlalu banyak atau terlalu sedikit pekerjaan defensif dan spekulatif
    Bagi seseorang itu adalah optimasi prematur, bagi orang lain itu menjadi “saya pernah melihat pola serupa sebelumnya dan akan menambahkan hal yang dulu saya harap sudah ada”. Sepertinya tidak ada cara yang andal untuk membedakan mana yang benar
  • Apakah Anda akan menulis komentar ini jika field itu tidak ditambahkan kembali?
    Situasi yang Anda jelaskan punya tiga hasil utama. Pertama, field itu berguna persis seperti cara implementasi awalnya. Kedua, fiturnya diimplementasikan tetapi dengan field lain atau implementasi lain. Ketiga, fiturnya tidak pernah diimplementasikan
    Bahkan jika probabilitas ketiga pilihan itu dianggap sama, membuatnya sejak awal hanya menjadi kemenangan dalam sepertiga kasus. Jika tidak dihapus, pertimbangkan juga berapa banyak biaya kognitif yang selama ini dikeluarkan untuk memastikan fitur-fitur lain yang diimplementasikan bekerja dengan benar bersama kolom metadata itu
    Dalam kasus ini, penilaian Anda benar dan pemahaman Anda tentang proyek sangat baik, tetapi apakah keputusan itu benar harus dinilai berdasarkan informasi yang tersedia saat itu, bukan setelah mengetahui semua informasi sesudahnya

• Bagian yang mengatakan “dalam pemungutan suara internal perusahaan, 7 dari 10 orang menilai versi dengan kalkulator akan lebih baik” itu menarik dan merupakan dinamika yang klasik
  Secara keseluruhan tulisannya bagus, tetapi poin ini sebenarnya layak lebih ditekankan. Jika 30% pihak terkait memandang kalkulator itu buruk, meskipun mayoritas menganggapnya baik-baik saja, itu sinyal adanya potensi masalah besar
  Di sini politik perlu diwaspadai. Orang biasanya tidak ingin mengkritik tim lain kalau tidak ada keuntungan politis. Jadi ketika perusahaan bertanya, “Apakah hal yang dibuat tim kami ini punya dampak bersih positif?”, jawaban default-nya mudah menjadi “ya” karena orang tidak ingin membuat keributan tanpa alasan
  Dalam situasi seperti itu, jika 30% mengirimkan sinyal kemungkinan penghancuran nilai, itu jauh lebih penting daripada kelihatannya. Perlu ditelusuri cukup dalam mengapa mereka melihatnya begitu. Dalam kasus ini, poin itu memang disadari dan berakhir baik, tetapi hasil pemungutan suara ini sejak awal sudah menjadi bukti adanya masalah serius

  • Secara prinsip saya setuju, tetapi sulit menentukan bagaimana menilai secara kuantitatif seberapa kontroversial sebuah perubahan. Tidak ada fitur yang mendapatkan kesepakatan 100%. Angka 30% memang tidak terlihat bagus, tetapi apakah berbeda secara bermakna dari 20%?
    Jika kepentingan berbagai pihak bercampur, ini makin rumit. Tim sales mungkin ingin mengaktifkan segala macam dark pattern, sementara customer support bisa saja sudah muak memproses refund karena perpanjangan garansi otomatis ditambahkan ke keranjang
    Bagian tulisan yang mengatakan bahwa menghapus kalkulator bisa lebih baik bagi pengguna karena lebih banyak penjualan selesai itu lucu. Mungkin pilihan yang tepat justru pengguna mendapat kejutan harga yang semestinya lalu pergi, tetapi itu diabaikan
  • Masalah lain dari pemungutan suara internal adalah yang masuk bukan sudut pandang orang yang memakai fitur, melainkan sudut pandang orang yang membuat fitur
    Bayangkan kode kalkulatornya berantakan dibandingkan bagian proyek lain, memakai library lama, rusak saat diperbarui, mungkin punya kerentanan keamanan, memakai resource secara tidak wajar, dan merusak build system. Tidak ada yang ingin mengurusnya
    Dalam situasi ini, jika ditanya apakah itu ide bagus, kebanyakan orang akan menjawab “tidak” dan berharap kekacauan itu dihilangkan. Maka 70% adalah angka yang sangat bagus. Sebaliknya, jika fitur itu sesuatu yang disukai orang untuk dikerjakan, 70% menjadi angka yang benar-benar buruk
  • Di tulisan hanya disebut bahwa 30% itu tidak yakin versi dengan kalkulator akan “berkinerja lebih baik”, bukan bahwa mereka menganggapnya “ide buruk”
    Tentu saja mereka mungkin berpikir begitu, tetapi itu lompatan yang cukup besar. Mereka mungkin mengira tidak akan ada banyak perbedaan, atau memperkirakan performanya rendah karena kalkulator kadang memberikan jawaban yang salah

• Pesan umumnya menarik, tetapi bagian ini agak membuat saya berhenti sejenak
  Apakah kalimat “dengan sedikit salah paham atau salah memasukkan input saja, estimasi bisa dilebih-lebihkan hingga 1000 kali” berarti dalam penggunaan nyata pun, jika sedikit salah memahami atau salah menilai metrik, biaya yang harus dibayar bisa 1000 kali dari rencana?
  Dalam sistem penagihan online, itu sangat realistis. Saya pernah salah mengonfigurasi prototipe GCP dan mengira biayanya sekitar 2–3 dolar, tetapi setelah beberapa hari tidak diperhatikan, tagihannya keluar lebih dari 100 dolar
  Melihat harga perkiraan melonjak gila-gilaan hanya karena sedikit mengubah slider, bisa dimengerti kalau pelanggan pergi. Menghapus alatnya mungkin membantu pendaftaran, tetapi tidak membantu pelanggan yang kemudian menghadapi masalah seperti ini

  • Sebenarnya kemungkinan itu kecil. Dua kasus nyata berikut menunjukkan alasannya
    Seorang pengguna mengira query per detik dihitung sebagai jumlah pencarian × top-k dari setiap pencarian. top-k adalah jumlah hasil yang ingin dikembalikan. Jika top-k bernilai 10, ia memasukkan nilai query per detik 10 kali lebih tinggi dari yang sebenarnya dan melihat estimasi sekitar 10 kali lebih tinggi daripada tagihan nyata
    Pengguna lain mengira jumlah vektor dihitung sebagai jumlah embedding × jumlah dimensi embedding. Karena 1.536 adalah jumlah dimensi yang umum, inputnya secara harfiah menjadi 1.536 kali lebih tinggi. Penggunaan nyata dihitung dengan benar oleh Pinecone, jadi tagihannya tidak menjadi setinggi itu
    Jumlah dimensi vektor adalah konsep dasar bagi engineer AI, dan QPS adalah metrik dasar bagi administrator DB, tetapi banyak pengguna Pinecone baru mengenal AI, baru mengenal administrasi DB, atau keduanya

• Penulis seharusnya mengikuti nasihatnya sendiri. Hapus “Psst... Get the next post in your inbox” yang menyelip di tengah tulisan, dan hapus juga tombol bodoh yang mengikuti saat scrolling
  Saya menghitung ada lima cara untuk berlangganan di halaman itu saja. Apakah benar-benar perlu lima? Perlukah disodorkan tepat di depan wajah orang di tengah konten? Apakah mereka pikir mengganggu dan membuat orang kesal akan menambah pelanggan? Apakah pelanggan seperti itu yang mereka inginkan?
  Menghapus sesuatu biasanya cukup jelas. Tinggalkan pola pikir seperti lubang “lebih, lebih, lebih; hasilkan uang; tarik pelanggan”, lalu pikirkan “apa yang benar jika ingin menghormati pengguna, dan bagaimana kita bisa membantu mereka dengan memperlakukan mereka sebagai manusia, bukan objek yang dompetnya diperas”

  • Setuju, tetapi data tidak mengatakan begitu. Elemen-elemen menjengkelkan seperti ini berkontribusi sangat baik pada tujuan bisnis
    Perlu diingat bahwa sebagian besar bisnis ada untuk menghasilkan uang, bukan untuk membuat pembaca HN merasa nyaman
  • Jika pelajaran dari optimasi pencarian blog dipahami dengan benar, saat ingin membangun basis pembaca, memasukkan banyak ajakan bertindak yang merebut perhatian pembaca jelas cukup bernilai sampai-sampai layak menanggung kekesalan pembaca yang kritis
    Apa artinya menghormati pengguna adalah pertanyaan terpisah, meski tidak sepenuhnya tidak terkait

• Fakta bahwa ada channel Slack khusus, terkumpul lebih dari 550 pesan berisi pendapat dari berbagai penjuru perusahaan, dan puluhan jam rapat serta ribuan kata dihabiskan untuk membahas apa lagi yang harus ditambahkan demi memperbaiki kalkulator adalah gejala perekrutan berlebihan
  Jika orang terlalu banyak, inisiatif hilang. Jika mereka lupa apa yang benar-benar penting dan merasa harus mencapai konsensus ala komite, berarti orangnya terlalu banyak

  • Bisa jadi, tetapi itu juga gejala perdebatan gudang sepeda yang bisa muncul bahkan hanya dengan dua orang
  • Saya tidak tahu bagaimana dari satu kalimat itu bisa sampai pada kesimpulan bahwa perusahaan punya terlalu banyak karyawan
  • Setidaknya, kalau diskusi desain dilakukan di channel seluruh perusahaan, hal seperti ini terjadi
    Desain ala komite pun tetap terbatas di dalam komitenya

• Bukankah lebih baik menghapus skema harga itu sendiri yang terlalu rumit sampai pelanggan tidak bisa memodelkannya secara berguna?

  • Menurut tulisan, faktor terbesarnya bukan banyaknya pilihan, melainkan pengguna salah memahami pilihan tersebut
    Artinya, ketika opsi A berharga x dolar dan opsi B berharga 10x dolar, jika sebagian besar pengguna keliru mengira mereka membutuhkan B, kalkulator menjadi alat yang menimbulkan salah paham
    Saya cukup menyukai pendekatan “hubungi kami untuk harga”. Memang menyebalkan bagi pengguna yang ingin cepat mengetahui kisaran harga kasar, tetapi ini membantu mengidentifikasi kasus ketika harga standar atau harga yang sulit dijelaskan secara online bisa dinegosiasikan. Situasi yang tadinya mungkin membuat pengguna lewat begitu saja juga bisa tertangkap. Tentu saja ini tidak cocok untuk kebanyakan e-commerce

• Di perusahaan kami ada sekitar 250 produk, dan 5 di antaranya bertanggung jawab atas 80% pendapatan.
  Tim pengembang untuk 5 produk itu bahkan kewalahan sekadar mengejar perbaikan bug, dan kesulitan menambahkan fitur baru yang penting. Siapa pun yang meminta, memasukkan sesuatu ke roadmap saja sudah seperti pertarungan yang mustahil.
  Perusahaan punya ribuan developer, tetapi sebagian besar ditempatkan pada produk yang hampir tidak berkontribusi pada pendapatan.
  Agar bisa bergerak maju, tampaknya jelas bahwa sebagian besar produk harus dipangkas dan tim disusun ulang untuk mendorong produk-produk utama penghasil pendapatan yang tersisa. Namun hal itu tidak terjadi, dan tidak ada tanda-tanda atau rumor bahwa itu akan terjadi. Politik perusahaan benar-benar keras.

• Saya punya pengalaman serupa. Di sebuah situs web dengan beberapa produk yang tampak cukup mirip, saya khawatir orang-orang sulit memutuskan harus membeli yang mana sehingga akhirnya tidak membeli.
  Jadi kami membuat applet rekomendasi produk: pengguna menjawab beberapa pertanyaan, lalu applet merekomendasikan satu atau dua produk yang paling cocok. Memang ada cukup banyak pekerjaan sampai dibuat dengan benar, tetapi setelah selesai applet itu berjalan baik.
  Ketika dipasang di situs, tingkat konversi anjlok. Setelah A/B testing, jelas applet itu merusak tingkat konversi. Saya masih belum tahu mengapa, tetapi faktanya begitu. Jadi kami memindahkannya dari homepage ke bagian FAQ, dan hampir tidak ada yang memakainya lagi.

  • Itulah nilai dari testing. Hasilnya kadang tidak intuitif.
  • Mungkin applet rekomendasi itu benar-benar membantu orang, sehingga berdasarkan informasi tambahan yang baru diberikan, mereka memutuskan bahwa pilihan terbaik adalah tidak membeli.
    Mungkin orang-orang tadinya bimbang, dan applet itu menghemat usaha mereka untuk mencoba-coba sendiri demi mencari tahu.
    Jika itu layanan, bisa jadi strategi ala Amazon Prime—orang mendaftar dulu karena belum yakin, lalu setelah itu memanfaatkan kekeliruan biaya hangus—sebenarnya bisa berhasil. Atau tanpa applet, mereka mungkin mendaftar dengan harapan versi termurah sudah cukup, tetapi applet langsung mematahkan harapan itu.
    Jika itu produk fisik, applet tersebut mungkin membantu mereka menghindari pembelian yang buruk.
    Saya tidak berharap orang mencarinya di FAQ. Kalau di footer mungkin, tapi bukan FAQ.

• Ini studi kasus yang menarik, tetapi saya skeptis terhadap implikasinya yang lebih luas. Pinecone terkenal mahal dibanding layanan database vektor lainnya. Jika melakukan perbandingan harga secara horizontal, ada beberapa pilihan yang lebih baik di pasar.
  Menghapus kalkulator tidak menyelesaikan masalah inti. Itu hanya membuat biaya menjadi lebih kabur dan membuat pengguna lebih sulit membandingkan opsi sejak awal. Dari sudut pandang saya, ini mungkin mengurangi tahap perbandingan, sehingga lebih banyak pengguna yang kekurangan informasi mengunggah data tanpa benar-benar memahami dampak biayanya.
  Penyederhanaan kadang bernilai, tetapi dalam kasus ini tampaknya lebih menguntungkan perusahaan daripada pengguna. Daripada menghapus kalkulator sepenuhnya, mungkin lebih baik meningkatkan akurasi dan kegunaannya. Terutama untuk layanan B2B yang biayanya bisa naik cepat, transparansi harga itu penting.