Preferensi notifikasi yang tidak membuat pengguna kesal: toggle dan jam tenang

Kenapa pengguna akhirnya benci notifikasi

Kebanyakan orang tidak membenci notifikasi. Mereka membenci terganggu tanpa alasan yang jelas. Saat alert datang terlalu sering, berulang, atau muncul pada momen yang salah, pengguna berhenti membaca dan mulai menggeser.

Masalah inti biasanya bukan volume. Itu ketidakcocokan. Apa yang mendesak untuk sistem Anda bisa jadi tidak relevan bagi seseorang. Seorang sales mungkin perlu mendapat penugasan lead segera, tapi tidak perlu ping “tips mingguan” pada jam 21:07. Ketika semuanya tampak sama pentingnya, tidak ada yang terasa penting.

Orang mematikan notifikasi karena alasan yang bisa diprediksi: terlalu sering, tidak relevan untuk peran mereka, waktu yang buruk (tidur, rapat, perjalanan), tidak jelas harus melakukan apa, atau membingungkan asalnya.

Alert yang membantu mengurangi usaha. Kebisingan menambah usaha. Notifikasi yang baik menjawab tiga pertanyaan dengan cepat: Apa yang terjadi? Apakah ini penting bagi saya? Apa yang harus saya lakukan selanjutnya?

Ada juga biaya tersembunyi saat pengguna marah-marah mematikan semuanya: mereka bisa melewatkan satu pesan yang benar-benar penting. Akun terkunci, kegagalan pembayaran, atau peringatan keamanan diabaikan karena pengguna opt-out setelah minggu-minggu pings bernilai rendah. Begitulah “mengganggu” berubah jadi “tiket support.”

Preferensi notifikasi yang baik melakukan satu tugas: memberi orang kontrol dengan pilihan yang jelas, dan membuat perilaku dapat diprediksi. Jika pengguna mematikan satu jenis alert, itu harus tetap mati. Jika mereka mengatur jam tenang, aplikasi harus menghormatinya setiap kali, di semua channel.

Aturan sederhana untuk pengaturan notifikasi yang baik

Preferensi notifikasi yang baik dimulai dengan satu pertanyaan: apa yang pengguna coba ikuti, dan apa yang bisa menunggu.

Jika seseorang mengaktifkan alert untuk “pesanan baru,” mereka biasanya bermaksud “beri tahu saya segera supaya saya bisa bertindak.” Jika mereka mau “tips mingguan produk,” artinya “saya akan membaca ini saat ada waktu.” Bangun pengaturan di sekitar niat itu, bukan daftar event internal Anda.

Jaga jumlah event tetap kecil dan berbeda. Jika Anda punya lima varian “status berubah,” kebanyakan orang akan mematikan semuanya atau membiarkan semuanya menyala lalu menyesalinya. Gabungkan event serupa menjadi satu opsi jelas, dan hanya pisahkan ketika tindakan berikutnya benar-benar berbeda.

Default lebih penting daripada yang dipikirkan banyak tim. Untuk hal non-kritis, mulai diam secara default, lalu biarkan orang memilih. Pengguna baru seharusnya bisa tidak melakukan apa-apa dan tetap merasa dihormati.

Gunakan bahasa yang sederhana. Hindari istilah seperti “workflow,” “ticket lifecycle,” atau “webhook failure” kecuali pengguna Anda benar-benar memakai kata-kata itu. Tulis label sebagaimana seseorang akan menjelaskannya ke rekan kerja.

Ketika seseorang mengetuk toggle, mereka harus memahami tiga hal:

• Seberapa sering hal itu mungkin terjadi (segera, harian, mingguan)
• Di mana itu akan tiba (push, email, SMS)
• Apa isinya (detail lengkap atau ringkasan singkat)

Pilih event yang tepat sebelum menambahkan toggle

Sebelum Anda membuat daftar panjang preferensi notifikasi, putuskan event mana yang layak punya pengaturan. Kebanyakan layar pengaturan terasa mengganggu karena menawarkan pilihan untuk event bising dan bernilai rendah, sementara sedikit yang benar-benar penting terkubur.

Mulailah dengan mengelompokkan event berdasarkan tujuan agar orang dapat memprediksi apa yang akan mereka dapatkan:

• Security (login baru, ganti kata sandi)
• Billing (pembayaran gagal, invoice siap)
• Account (perubahan paket, admin ditambahkan)
• Pembaruan workflow (tugas ditugaskan, butuh persetujuan)
• Marketing (tips, promosi)

Dalam setiap grup, pisahkan event menjadi kritis, informasional, dan promosi. Kritis berarti perlu tindakan atau risikonya tinggi. Informasional berarti “bagus untuk diketahui.” Promosi berarti “bagus untuk dimiliki.” Untuk setiap event, tentukan urgensi dan delay yang dapat diterima. Kegagalan pembayaran mungkin perlu dikirimkan seketika. Laporan mingguan bisa menunggu untuk dimasukkan ke digest.

Berhati-hatilah dengan event yang Anda “tidak pernah izinkan dimatikan.” Jika sesuatu harus tetap menyala, buat daftar itu sangat singkat dan jelaskan kenapa (biasanya keamanan dan beberapa alert billing). Segala hal lain sebaiknya dikendalikan pengguna.

Aturan praktis: tulis satu kalimat per event yang mengatakan apa yang terjadi dan mengapa itu penting. Contoh: “Perangkat baru masuk ke akun Anda, sehingga Anda bisa mendeteksi akses mencurigakan.” Jika Anda tidak bisa menulis kalimat itu tanpa terdengar samar, event itu mungkin tidak pantas punya toggle sendiri.

Toggle per-event yang terasa adil dan mudah dimengerti

Toggle per-event bekerja ketika mereka sesuai dengan momen yang benar-benar penting bagi pengguna. Jika event bisa merugikan uang, waktu, atau kepercayaan mereka, itu pantas punya switch sendiri. Jika itu sebatas “FYI,” pertimbangkan menggabungkannya ke digest daripada menambah toggle.

Beri nama toggle seperti event nyata, bukan area fitur. “Pembayaran gagal” lebih jelas daripada “Pembaharuan billing.” Ini adalah perbedaan antara preferensi yang terasa menghormati dan yang terasa seperti labirin pengaturan.

Di bawah setiap toggle, tampilkan contoh satu baris mengenai seperti apa pesan itu. Itu menetapkan ekspektasi dan memudahkan keputusan.

• Komentar baru pada tiket Anda: “Alex membalas: ‘Bisakah Anda kirim screenshot?’”
• Build selesai: “Build web app Anda berhasil dalam 2m 14s.”
• Pembayaran gagal: “Kartu berakhir 4821 ditolak. Perbarui agar layanan tidak terganggu.”

Toggle kategori hanya membantu ketika kategori itu jelas dan stabil. “Security,” “Billing,” dan “Account access” biasanya jelas. “Product updates” atau “Activity” sering menyembunyikan terlalu banyak.

Hindari dependensi tersembunyi. Jika mematikan “Komentar” juga menonaktifkan “Mention,” katakan itu di situ. Lebih baik lagi, pisahkan keduanya. Kejutan adalah yang membuat orang tidak percaya pada seluruh layar.

Tambahkan jeda global yang tidak menghapus pilihan. “Jeda semua notifikasi selama 1 jam / 1 hari / sampai saya menyalakannya kembali” adalah katup pengaman untuk hari sibuk, sambil menjaga pengaturan per-event tetap utuh.

Jam tenang yang menghormati zona waktu dan pengecualian

Jam tenang harus berarti satu hal: tidak ada pesan non-urgensi selama waktu yang pengguna katakan mereka tidak mau diganggu.

Zona waktu yang benar membuat jam tenang terasa “benar” atau rusak. Beberapa orang bepergian dan ingin jam tenang mengikuti lokasi mereka saat ini. Lainnya ingin jadwal “rumah” tetap sama saat perjalanan. Tawarkan kedua opsi dengan label sederhana seperti “Gunakan zona waktu saya saat ini” dan “Gunakan zona waktu rumah saya.”

Jam tenang juga perlu pengecualian yang jelas. Pengguna menerima bypass ketika itu jarang dan mudah dimengerti. Jaga daftar bypass pendek dan berbasis risiko, bukan pemasaran:

• Peringatan keamanan akun (login baru, ganti kata sandi)
• Kegagalan pembayaran yang menghentikan layanan
• Persetujuan yang sensitif waktu dengan tenggat
• Mention atau balasan langsung (opsional)

Kasus tepi penting. Daylight saving bisa menggeser jadwal satu jam, jadi tampilkan kapan “quiet dimulai” dan “quiet berakhir” berikutnya di UI.

Untuk akhir pekan, hindari membuat pengguna membuat dua jadwal dari awal. Sediakan “Hanya Hari Kerja” sederhana, atau biarkan mereka memilih hari dengan satu ketukan.

Preset membantu orang menyelesaikan pengaturan lebih cepat: “Malam (22:00–08:00)” plus “Kustom.” Buat preset bisa diedit setelah dipilih agar tidak terasa seperti jebakan.

Mode ringkasan tanpa membuat pengguna melewatkan update penting

Ringkasan adalah janji: “Kami akan membuat Anda tetap tahu, hanya tidak mengganggu.” Ini paling efektif untuk update berisik dan berprioritas rendah seperti reaksi, aktivitas rutin, atau statistik harian. Ini buruk untuk apa pun yang menghalangi pekerjaan, butuh balasan cepat, atau punya tenggat.

Opsi ringkasan harus mulai dengan memisahkan event ke dua ember. Pertahankan event berurgensi tinggi secara real-time (peringatan keamanan, pembayaran, persetujuan, gangguan). Pindahkan event bervolume tinggi ke ringkasan (thread komentar yang ramai, aktivitas pengikut, ringkasan rutin).

Pertahankan pilihan frekuensi yang familier:

• Harian
• Mingguan
• Hanya saat ada aktivitas
• Tidak pernah (matikan)

Biarkan pengguna memilih waktu pengiriman ringkasan, dan konfirmasi zona waktunya. Ringkasan yang tiba jam 03:00 terasa rusak, meski itu “tepat.”

Kejelasan mengalahkan kontrol canggih. Tandai setiap event sebagai “Real-time” atau “Ringkasan” sehingga pengguna tidak perlu menebak. Jika mengubah event memindahkannya ke ringkasan, katakan itu di sebelah kontrol.

Pratinjau mengurangi kecemasan. Tampilkan contoh kecil apa isi ringkasan: beberapa judul, jumlah, dan item terpenting. Contoh: “3 komentar baru, 2 perubahan status, 1 mention,” dengan potongan singkat.

Pelacakan pengiriman nyata (bukan hanya “terkirim”)

“Dikirim” hanya berarti aplikasi Anda menyerahkan pesan ke provider. Pengguna peduli apa yang terjadi selanjutnya. Untuk alert kritis, “kami mencoba” tidak sama dengan “Anda menerimanya.”

Model sederhana terlihat seperti ini:

• Sent: aplikasi Anda mengantri pesan dan menyerahkannya ke layanan email/SMS/push.
• Delivered: provider melaporkan pesan sampai ke perangkat atau mailbox (jika sinyal itu tersedia).
• Opened/Read: pengguna melihatnya (tersedia untuk beberapa channel, dan tidak selalu andal).

Saat sesuatu gagal, lacak alasannya bila memungkinkan. “Gagal” terlalu samar untuk ditindaklanjuti. Contoh yang lebih baik: diblokir (filter operator), bounce (mailbox menolak), alamat/nomor tidak valid, atau token kedaluwarsa (token push tidak lagi valid). Bahkan jika Anda tidak selalu mendapat detail sempurna dari setiap provider, simpan apa yang Anda tahu.

Kegagalan sementara butuh aturan retry. Default yang baik adalah retry terbatas dengan backoff sehingga Anda tidak meng-spam provider atau menguras baterai. Contoh: retry setelah 1 menit, lalu 5, lalu 30, lalu berhenti dan tandai gagal. Error permanen seperti “nomor tidak valid” tidak boleh di-retry.

Untuk pesan kritis, tunjukkan status sederhana ke pengguna. Jika seseorang berkata, “Saya tidak menerima kode reset kata sandi,” baris yang terlihat seperti “SMS gagal: nomor tidak valid” mencegah frustrasi dan membantu mereka memperbaiki masalah nyata.

Simpan jejak audit untuk support dan kepatuhan. Simpan siapa penerima pesan itu, channel yang dipilih, cap waktu untuk setiap status, dan error terakhir yang diketahui.

Cara mengimplementasikan preferensi notifikasi langkah demi langkah

Anggap preferensi notifikasi sebagai logika produk, bukan tumpukan toggle. Jika Anda membangun aturannya dulu, UI dan sistem pengiriman tetap konsisten saat menambah event.

Bangun aturan sebelum membuat layar

Mulailah dengan inventaris apa yang mungkin Anda beri notifikasi. Untuk setiap event, putuskan seberapa mendesak dan channel mana yang masuk akal (push, email, SMS). Lalu pilih default sehingga kebanyakan orang tidak perlu menyentuh pengaturan.

Cek praktis: jika Anda tidak bisa menjelaskan sebuah toggle dalam satu kalimat pendek, kemungkinan toggle itu menggabungkan beberapa event dan harus dipisah.

Simpan, evaluasi, jadwalkan, lalu ukur

Pastikan setiap pengiriman melewati titik keputusan yang sama. Di situlah Anda menerapkan pilihan pengguna, jam tenang, dan logika ringkasan sebelum apa pun keluar dari sistem.

Simpan preferensi dalam struktur yang cocok dengan cara orang berpikir: berdasarkan event, channel, dan waktu. Tambahkan penjadwalan untuk jam tenang dan jendela ringkasan, termasuk penanganan zona waktu dan pengecualian untuk alert kritis. Log rantai penuh: upaya kirim, respons provider (delivered, bounced, failed), dan tindakan pengguna (opt-out, perubahan).

Contoh: pengguna mematikan email “tips mingguan” tetapi mempertahankan email “peringatan keamanan”, dengan jam tenang 22:00–07:00. Aturan Anda tetap harus mengizinkan email reset kata sandi mendesak jam 02:00, sambil menahan pesan prioritas rendah untuk ringkasan pagi.

Kesalahan umum yang membuat layar pengaturan bikin marah

Kebanyakan orang tidak keberatan menerima pembaruan. Mereka keberatan merasa terjebak, bingung, atau diabaikan. Beberapa kesalahan desain bisa membuat layar preferensi notifikasi dikunjungi sekali, membuat pengguna kesal, lalu tak pernah disentuh lagi.

Pola umum:

• Terlalu banyak toggle dengan nama samar seperti “Updates” atau “Activity,” sehingga pengguna tidak bisa memprediksi apa yang akan mereka dapat.
• Satu saklar utama yang mencampur event dan channel (misalnya, “Beri tahu saya tentang komentar” yang diam-diam mencakup email, push, dan SMS).
• Jam tenang yang mengabaikan perubahan zona waktu atau daylight saving.
• “Ringkasan” yang masih mengirim alert real-time untuk event yang sama, sehingga pengguna melihat keduanya dan mengira produk rusak.

Dua perbaikan mencegah sebagian besar ini. Pertama, buat setiap kontrol menjawab satu pertanyaan: event mana, di channel mana, pada waktu apa. Gunakan nama konkret, seperti “Invoice baru dibayar” alih-alih “Billing.” Kedua, anggap pengiriman lebih dari sekadar “terkirim,” atau Anda akan mengklaim sukses padahal email bounce atau push tidak sampai.

Pemeriksaan cepat sebelum rilis

Sebelum merilis preferensi notifikasi, lakukan pengecekan cepat seperti pengguna nyata. Berpura-puralah lelah, sibuk, dan hanya ingin menghentikan kebisingan tanpa melewatkan sesuatu yang penting.

Mulai dengan event paling berisik. Jika seseorang tidak bisa mematikan satu trigger bising tanpa juga kehilangan alert kritis, pengaturan akan terasa tidak adil.

Lalu periksa waktu. Pengguna tidak boleh menebak apakah pesan tiba sekarang, nanti dalam ringkasan, atau tidak sama sekali. UI harus mengatakan itu dengan jelas, dan teks pratinjau harus sesuai dengan apa yang benar-benar terjadi.

Daftar periksa sebelum kirim:

• Bisakah saya mematikan satu event bising tanpa mematikan alert kritis?
• Apakah jelas apakah tiap event real-time, ringkasan, atau dinonaktifkan?
• Apakah jam tenang mudah diatur, dan apakah menunjukkan zona waktu yang benar?
• Untuk alert penting, bisakah saya melihat status pengiriman (delivered, failed, bounced), bukan hanya “sent”?

Jam tenang adalah tempat kebingungan menyelinap. Kontrol harus menampilkan jendela sederhana seperti “22:00 hingga 07:00,” dan menjelaskan apa yang terjadi pada notifikasi yang diblokir (dibisu, ditunda, atau dipindah ke ringkasan berikutnya). Jika Anda mengizinkan pengecualian, beri label dengan kata-kata sederhana seperti “Selalu izinkan peringatan keamanan.”

Terakhir, uji loop dari aksi ke bukti. Jika pengguna melaporkan “Saya tidak menerimanya,” sistem Anda harus bisa menjawab: apakah itu sudah diantri, diserahkan ke provider, sampai ke perangkat, atau ditolak?

Contoh: pengaturan realistis untuk pengguna sibuk

Maya memimpin tim support 12 orang. Dia ingin tahu apa pun yang bisa membahayakan data pelanggan, tapi tidak ingin ponselnya berdengung untuk setiap komentar, emoji, atau pembaruan rutin. Dia juga sering rapat, jadi butuh pengaturan yang diam secara default dan berisik hanya saat perlu.

Preferensinya seperti ini:

• Peringatan keamanan: Push + SMS (selalu aktif)
• Reset kata sandi dan peringatan login: Push + Email
• Tiket baru ditugaskan ke saya: Push
• Komentar pada tiket yang saya ikuti: Ringkasan harian (email)
• Mention (@saya): Push

Dia memakai ringkasan untuk kebisingan latar seperti aktivitas tiket, perubahan status, dan komentar non-urgensi. Jika sesuatu menjadi mendesak, itu menjadi alert, bukan bagian dari ringkasan.

Jam tenang diatur weekdays 21:00–07:00 di zona waktu lokalnya, dengan satu pengecualian: peringatan keamanan melewati jam tenang. Jika ada login mencurigakan jam 02:00, dia tetap menerima info itu.

Pelacakan pengiriman membuat pengaturan terasa bukan sekadar tebakan. Ketika Maya minta reset kata sandi, dia bisa melihat itu terkirim ke provider email-nya, bukan hanya diberi tanda “sent” oleh aplikasi. Di sisi lain, email invoice bulanan untuk pelanggan menunjukkan bounce, sehingga tim tahu itu tidak sampai inbox.

Saat seseorang bilang, “Saya tidak menerimanya,” support punya jalur jelas:

• Cek log event (apa yang memicu pesan, dan kapan)
• Cek hasil channel (delivered, deferred, bounced, atau failed)
• Konfirmasi pengaturan pengguna (toggle, ringkasan, jam tenang pada waktu itu)
• Kirim ulang atau ganti channel (mis. email ke SMS) dan catat hasilnya

Langkah selanjutnya: kirim pengalaman notifikasi yang lebih tenang

Mulailah dengan daftar event tertulis. Untuk tiap event, putuskan apakah itu kritis (keamanan, billing, akses akun) atau opsional (komentar, like, tips). Jika Anda tidak bisa menjelaskan kenapa event itu ada dalam satu kalimat, kemungkinan besar tidak perlu ada di rilis pertama Anda.

Tulis label yang ditujukan ke pengguna seperti Anda sedang bicara pada orang sibuk. Buat spesifik (“Login baru dari perangkat baru”) dan tambahkan pratinjau satu baris (“Kami akan memberi tahu Anda segera demi keamanan akun”).

Sebelum rilis, tambahkan logging pengiriman agar support bisa menjawab pertanyaan nyata: “Apakah sampai ke saya?” Lacak jalur dari dibuat ke diantri ke penyerahan provider ke delivered atau failed, plus opened bila tersedia.

Jika Anda membangun pusat preferensi di platform no-code seperti AppMaster, membantu untuk memperlakukan notifikasi sebagai fitur produk kelas satu: definisikan event, simpan pengaturan per-user di PostgreSQL, dan jaga satu langkah keputusan bersama dalam logika bisnis. AppMaster (appmaster.io) dirancang untuk logika aplikasi semacam ini, di mana aturan backend dan pengaturan UI perlu tetap selaras saat produk tumbuh.

Roll out ke persentase kecil lebih dulu, lalu pantau tingkat opt-out, penggunaan “jeda semua”, tiket support tentang missing alert, dan tema keluhan. Jika satu event memicu sebagian besar opt-out, perbaiki event itu sebelum menambah lebih banyak.