Thiết kế tùy chọn thông báo với công tắc theo sự kiện, giờ im lặng, bản tóm tắt và theo dõi giao hàng để người dùng được thông báo mà không thấy bị spam.
Hầu hết mọi người không ghét thông báo. Họ ghét bị gián đoạn vô lý. Khi cảnh báo đến quá thường xuyên, lặp lại, hoặc xuất hiện vào lúc sai, người dùng ngừng đọc và bắt đầu vuốt bỏ.
Vấn đề cốt lõi thường không phải là số lượng. Là sự không phù hợp. Những gì hệ thống của bạn coi là khẩn cấp có thể vô nghĩa với một người. Một nhân viên bán hàng có thể cần biết ngay một lead được gán, nhưng không cần một “mẹo hàng tuần” lúc 21:07. Khi mọi thứ đều quan trọng như nhau, thì chẳng có gì là quan trọng.
Mọi người tắt thông báo vì những lý do dễ đoán: quá nhiều, không liên quan đến vai trò của họ, thời điểm tệ (ngủ, họp, đi lại), không rõ phải làm gì tiếp theo, hoặc không biết thông báo đến từ đâu.
Cảnh báo hữu ích giảm nỗ lực. Tiếng ồn tăng nỗ lực. Một thông báo tốt trả lời nhanh ba câu hỏi: Chuyện gì đã xảy ra? Có quan trọng với tôi không? Tôi phải làm gì tiếp theo?
Còn chi phí ẩn khi người dùng nổi giận tắt mọi thứ: họ lỡ mất thông điệp thực sự quan trọng. Tài khoản bị khoá, thanh toán thất bại, hay cảnh báo bảo mật bị bỏ qua vì người dùng đã chọn rút lui sau nhiều tuần nhận tin ít giá trị. Đó là cách “phiền phức” trở thành “vé hỗ trợ”.
Tùy chọn thông báo tốt làm một việc: trao quyền cho người dùng với những lựa chọn rõ ràng và khiến hành vi trở nên dễ đoán. Nếu người dùng tắt một loại cảnh báo, nó nên luôn tắt. Nếu họ đặt giờ im lặng, ứng dụng nên tôn trọng mọi lần, trên mọi kênh.
Cài đặt thông báo tốt bắt đầu với một câu hỏi: người dùng cố gắng theo dõi điều gì, và điều gì có thể chờ.
Nếu ai đó bật cảnh báo cho “đơn hàng mới,” họ thường muốn “báo ngay để tôi có thể hành động.” Nếu họ muốn “mẹo sản phẩm hàng tuần,” họ có ý là “tôi sẽ đọc khi có thời gian.” Xây cài đặt xung quanh ý định đó, chứ không phải danh sách sự kiện nội bộ của bạn.
Giữ số lượng sự kiện ít và rõ ràng. Nếu bạn có năm biến thể của “trạng thái thay đổi,” hầu hết mọi người sẽ hoặc tắt hết hoặc bật hết rồi hối hận. Gộp các sự kiện tương tự thành một lựa chọn rõ ràng, chỉ tách khi hành động tiếp theo thực sự khác.
Mặc định quan trọng hơn nhiều đội nghĩ. Với mọi thứ không quan trọng, bắt đầu ở chế độ im lặng theo mặc định, rồi cho phép người dùng đăng ký. Người dùng mới nên có thể không làm gì mà vẫn cảm thấy được tôn trọng.
Dùng ngôn ngữ đơn giản. Tránh những từ như “workflow,” “ticket lifecycle,” hay “webhook failure” trừ khi người dùng thực sự dùng những từ đó. Viết nhãn theo cách ai đó giải thích cho đồng nghiệp.
Khi ai đó bật công tắc, họ nên hiểu ba điều:
Trước khi bạn xây một danh sách dài các tùy chọn, hãy quyết định sự kiện nào thực sự xứng đáng có cài đặt. Hầu hết màn hình cài đặt gây phiền vì chúng cho lựa chọn cho các sự kiện ồn ào, ít giá trị, trong khi vài thứ quan trọng thật bị chôn.
Bắt đầu bằng cách nhóm sự kiện theo mục đích để người dùng dự đoán được họ sẽ nhận gì:
Trong mỗi nhóm, tách sự kiện thành: khẩn cấp, thông tin, và khuyến mại. Khẩn cấp nghĩa cần hành động hoặc rủi ro cao. Thông tin là “biết thì tốt.” Khuyến mại là “thấy cũng được.” Với mỗi sự kiện, định nghĩa mức khẩn và độ trễ chấp nhận được. Thanh toán thất bại có thể cần gửi ngay. Báo cáo hàng tuần có thể chờ bản tóm tắt.
Cẩn trọng với danh sách “không cho tắt.” Nếu có thứ phải luôn bật, giữ danh sách rất ngắn và giải thích lý do (thường là bảo mật và một vài cảnh báo thanh toán). Mọi thứ khác nên do người dùng kiểm soát.
Quy tắc thực tế: viết một câu cho mỗi sự kiện nói chuyện gì đã xảy ra và tại sao nó quan trọng. Ví dụ: “Một thiết bị mới đã đăng nhập vào tài khoản của bạn, để bạn phát hiện truy cập đáng ngờ.” Nếu bạn không thể viết câu đó mà không mơ hồ, sự kiện có lẽ không xứng đáng có công tắc riêng.
Công tắc theo sự kiện chỉ hiệu quả khi chúng khớp với những khoảnh khắc người dùng thực sự quan tâm. Nếu sự kiện có thể khiến họ mất tiền, thời gian hoặc niềm tin, nó xứng đáng có công tắc riêng. Nếu chủ yếu là “FYI”, cân nhắc gom vào bản tóm tắt thay vì thêm công tắc nữa.
Đặt tên công tắc như các sự kiện thực, không phải khu vực tính năng. “Payment failed” rõ ràng hơn “Billing updates.” Đây là khác biệt giữa cài đặt có vẻ tôn trọng và cài đặt như mê cung.
Dưới mỗi công tắc, hiển thị một ví dụ một dòng về tin nhắn sẽ trông như thế nào. Nó đặt kỳ vọng và giúp quyết định dễ hơn.
Công tắc theo danh mục chỉ hữu ích khi các danh mục rõ ràng và ổn định. “Security,” “Billing,” và “Account access” thường rõ. “Product updates” hay “Activity” thường che giấu quá nhiều.
Tránh phụ thuộc ẩn. Nếu tắt “Comments” cũng vô hiệu hoá “Mentions,” hãy nói ngay bên cạnh. Tốt hơn, tách riêng. Bất ngờ là điều khiến người dùng mất lòng tin vào toàn màn hình.
Thêm một chế độ tạm dừng toàn bộ mà không xóa lựa chọn. “Tạm dừng mọi thông báo trong 1 giờ / 1 ngày / cho đến khi tôi bật lại” là van an toàn cho những ngày bận, trong khi giữ nguyên cài đặt theo sự kiện.
Giờ im lặng nên chỉ có một ý nghĩa: không có tin không khẩn trong thời gian người dùng nói họ không muốn bị làm phiền.
Múi giờ là thứ khiến giờ im lặng cảm thấy đúng hoặc hỏng. Một số người đi lại và muốn giờ im lặng theo vị trí hiện tại. Người khác muốn lịch “tại nhà” cố định ngay cả khi đi công tác. Cung cấp cả hai với nhãn rõ ràng như “Dùng múi giờ hiện tại của tôi” và “Dùng múi giờ nhà.”
Giờ im lặng cũng cần ngoại lệ rõ ràng. Người dùng chấp nhận bỏ qua khi điều đó hiếm và dễ hiểu. Giữ danh sách ngoại lệ ngắn và dựa trên rủi ro, không dựa trên marketing:
Các trường hợp méo (edge cases) quan trọng. Chuyển giờ mùa hè có thể dịch lịch đi một giờ, nên hiển thị “lần im lặng tiếp theo bắt đầu lúc” và “kết thúc lúc” trong UI.
Với cuối tuần, tránh bắt người dùng tự xây hai lịch từ đầu. Cung cấp một nút “Chỉ ngày trong tuần,” hoặc cho phép họ chọn ngày với một lần chạm.
Preset giúp người dùng hoàn tất nhanh: “Đêm (22:00 đến 08:00)” và “Tùy chỉnh.” Cho phép chỉnh sửa preset sau khi chọn để người dùng không cảm thấy bị ép.
Bản tóm tắt là một lời hứa: “Chúng tôi sẽ giữ bạn được biết, nhưng không làm phiền.” Nó phù hợp nhất với các cập nhật ồn, ít khẩn như phản ứng, hoạt động thường xuyên, hoặc số liệu hàng ngày. Nó kém hiệu quả với thứ chặn công việc, cần trả lời nhanh, hoặc có hạn chót.
Tùy chọn tóm tắt nên bắt đầu bằng cách chia sự kiện thành hai nhóm. Giữ sự kiện khẩn ở thời gian thực (cảnh báo bảo mật, thanh toán, phê duyệt, sự cố). Chuyển sự kiện nhiều lượng sang tóm tắt (luồng bình luận đông, hoạt động người theo dõi, tóm tắt định kỳ).
Giữ các lựa chọn tần suất quen thuộc:
Cho người dùng chọn giờ gửi tóm tắt và xác nhận múi giờ. Bản tóm tắt đến lúc 3 giờ sáng sẽ cảm thấy hỏng, dù “đúng” về mặt thời gian.
Rõ ràng luôn thắng điều khiển cầu kỳ. Gắn nhãn mỗi sự kiện là “Thời gian thực” hoặc “Tóm tắt” để người dùng không phải đoán. Nếu thay đổi một sự kiện đẩy nó vào tóm tắt, nói rõ bên cạnh công tắc.
Bản xem trước giảm lo lắng. Hiển thị mẫu nhỏ về nội dung tóm tắt: vài tiêu đề, số lượng, và những mục quan trọng nhất. Ví dụ: “3 bình luận mới, 2 thay đổi trạng thái, 1 đề cập,” kèm đoạn trích ngắn.
“Đã gửi” chỉ nghĩa hệ thống của bạn đã chuyển tin tới nhà cung cấp. Người dùng quan tâm chuyện tiếp theo. Với cảnh báo quan trọng, “chúng tôi đã cố gắng” không bằng “bạn đã nhận.”
Một mô hình đơn giản như sau:
Khi có lỗi, theo dõi lý do khi có thể. “Failed” quá mơ hồ để hành động. Ví dụ tốt hơn là blocked (lọc nhà mạng), bounced (hộp thư từ chối), invalid address/number, hoặc expired token (token push không còn hiệu lực). Dù không lấy được chi tiết hoàn hảo từ mọi nhà cung cấp, hãy lưu những gì bạn biết.
Lỗi tạm thời cần quy tắc thử lại. Mặc định tốt là retry có giới hạn với backoff để không spam nhà cung cấp hay làm cạn pin. Ví dụ: thử lại sau 1 phút, rồi 5, rồi 30, rồi dừng và đánh dấu thất bại. Lỗi vĩnh viễn như “số không hợp lệ” thì không nên thử lại.
Với thông báo quan trọng, cho người dùng thấy trạng thái đơn giản. Nếu ai đó nói “Tôi không nhận được mã đặt lại mật khẩu,” một dòng hiển thị như “SMS thất bại: số không hợp lệ” giúp họ sửa vấn đề thay vì bực tức.
Giữ lịch sử kiểm toán cho hỗ trợ và tuân thủ. Lưu ai là người nhận, kênh nào được chọn, dấu thời gian cho từng trạng thái, và lỗi cuối cùng biết được.
Hãy coi tùy chọn thông báo như logic sản phẩm, không phải một đống công tắc. Nếu bạn xây quy tắc trước, UI và hệ thống gửi sẽ nhất quán khi thêm sự kiện.
Bắt đầu với kiểm kê những gì bạn có thể thông báo. Với mỗi sự kiện, quyết định mức khẩn và kênh phù hợp (push, email, SMS). Rồi chọn mặc định để phần lớn người dùng không cần chạm vào cài đặt.
Một kiểm tra thực tế: nếu bạn không thể giải thích một công tắc bằng một câu ngắn, nó có thể kết hợp nhiều sự kiện và nên tách.
Đảm bảo mọi lần gửi đều qua cùng một điểm quyết định. Đó là nơi bạn áp dụng lựa chọn người dùng, giờ im lặng và logic tóm tắt trước khi bất cứ thứ gì rời khỏi hệ thống.
Lưu cài đặt theo cấu trúc mà người dùng nghĩ: theo sự kiện, theo kênh, và theo thời gian. Thêm lịch cho giờ im lặng và cửa sổ tóm tắt, bao gồm xử lý múi giờ và ngoại lệ cho cảnh báo quan trọng. Ghi lại chuỗi đầy đủ: cố gắng gửi, phản hồi nhà cung cấp (delivered, bounced, failed), và hành động người dùng (opt-out, thay đổi).
Ví dụ: người dùng tắt email “mẹo hàng tuần” nhưng giữ email “cảnh báo bảo mật,” với giờ im lặng 22:00–07:00. Quy tắc của bạn vẫn phải cho phép email đặt lại mật khẩu khẩn cấp lúc 2:00, trong khi giữ các tin ít ưu tiên cho bản tóm tắt buổi sáng.
Hầu hết mọi người không phiền khi nhận cập nhật. Họ phiền khi cảm thấy bị mắc kẹt, bối rối, hoặc bị phớt lờ. Một vài lỗi thiết kế có thể biến màn hình cài đặt thành nơi người dùng vào một lần, khó chịu, rồi không bao giờ động lại.
Mẫu phổ biến:
Hai cách khắc phục phần lớn vấn đề. Thứ nhất, khiến mỗi điều khiển trả lời một câu hỏi: sự kiện nào, kênh nào, thời gian nào. Giữ tên cụ thể như “New invoice paid” thay vì “Billing.” Thứ hai, xử lý giao hàng hơn cả “đã gửi,” hoặc bạn sẽ tuyên bố thành công ngay cả khi email bị bounce hay push không đến được thiết bị.
Trước khi phát hành tùy chọn thông báo, làm một lần chạy thử như người dùng thực. Giả vờ bạn mệt mỏi, bận, và chỉ muốn dừng tiếng ồn mà không bỏ lỡ thứ quan trọng.
Bắt đầu với sự kiện ồn nhất. Nếu người dùng không thể tắt một trình kích hoạt ồn mà không mất cảnh báo quan trọng, cài đặt sẽ cảm thấy bất công.
Rồi kiểm tra thời gian. Người dùng không nên đoán liệu tin sẽ đến ngay, sau trong bản tóm tắt, hay không đến nữa. UI nên nói rõ, và văn bản xem trước nên khớp với thực tế.
Danh sách kiểm trước khi phát hành:
Giờ im lặng là nơi dễ gây nhầm lẫn. Điều khiển nên hiển thị cửa sổ đơn giản như “22:00 đến 07:00,” và giải thích chuyện gì xảy ra với thông báo bị chặn (tắt tiếng, trì hoãn, hay chuyển vào bản tóm tắt tiếp theo). Nếu cho phép ngoại lệ, gắn nhãn bằng từ ngữ rõ ràng như “Luôn cho phép cảnh báo bảo mật.”
Cuối cùng, test vòng từ hành động đến bằng chứng. Nếu người dùng báo “Tôi không nhận được,” hệ thống của bạn phải trả lời: đã được xếp hàng, chuyển cho nhà cung cấp, đã giao tới thiết bị, hay bị từ chối?
Maya dẫn đội hỗ trợ 12 người. Cô muốn biết mọi thứ có thể gây rủi ro dữ liệu khách hàng, nhưng không muốn điện thoại rung cho mỗi bình luận, emoji, hay cập nhật thường lệ. Cô cũng hay họp, nên cần cài đặt im lặng theo mặc định và chỉ ồn khi thật sự cần.
Cài đặt của cô trông như sau:
Cô dùng bản tóm tắt cho tiếng ồn nền như hoạt động ticket, thay đổi trạng thái, và bình luận không khẩn. Nếu điều gì đó trở nên khẩn, nó là cảnh báo, không phải phần của bản tóm tắt.
Giờ im lặng đặt từ 21:00 đến 07:00 ngày trong tuần theo múi giờ địa phương, với một ngoại lệ: cảnh báo bảo mật vượt qua giờ im lặng. Nếu có đăng nhập đáng ngờ lúc 2:00, cô vẫn nhận được.
Theo dõi giao hàng là nơi cài đặt của cô ngừng là suy đoán. Khi Maya yêu cầu đặt lại mật khẩu, cô thấy nó đã được delivered tới nhà cung cấp email, không chỉ hiển thị “sent” trong ứng dụng. Trong khi đó, email hoá đơn hàng tháng cho một khách hàng bị bounce, nên đội biết là không tới hộp thư.
Khi ai đó nói “Tôi không nhận được,” hỗ trợ có đường đi rõ ràng:
Bắt đầu với danh sách sự kiện viết sẵn. Với mỗi sự kiện, quyết định nó là khẩn (bảo mật, thanh toán, truy cập tài khoản) hay tùy chọn (bình luận, lượt thích, mẹo). Nếu bạn không thể giải thích lý do tồn tại của một sự kiện trong một câu, nó có lẽ không nên có trong bản phát hành đầu tiên.
Viết nhãn hướng người dùng như bạn đang nói với người bận rộn. Giữ cụ thể (“New login from a new device”) và thêm một dòng xem trước (“Chúng tôi sẽ cảnh báo bạn ngay lập tức vì lý do an toàn tài khoản”).
Trước khi phát hành, thêm ghi nhận giao hàng để hỗ trợ trả lời câu hỏi thực tế: “Nó có tới tôi không?” Theo dõi đường đi từ tạo -> xếp hàng -> chuyển cho nhà cung cấp -> delivered hoặc failed, cùng với opened khi có.
Nếu bạn xây trung tâm tùy chọn trong nền tảng no-code như AppMaster, tốt hơn là coi thông báo như tính năng sản phẩm hạng nhất: định nghĩa sự kiện, lưu cài đặt theo người dùng trong PostgreSQL, và giữ một bước quyết định chung trong logic nghiệp vụ. AppMaster (appmaster.io) được thiết kế cho loại logic ứng dụng này, nơi quy tắc backend và cài đặt UI cần luôn khớp khi sản phẩm phát triển.
Ra mắt cho một tỉ lệ nhỏ trước, rồi quan sát tỉ lệ opt-out, sử dụng “mute all,” vé hỗ trợ về cảnh báo bị thiếu, và chủ đề phàn nàn. Nếu một sự kiện dẫn đến phần lớn opt-out, sửa sự kiện đó trước khi thêm nhiều thứ khác.
Why do users turn notifications off even when the feature is useful?Vì cảnh báo không khớp với mục đích của người dùng. Mọi người chấp nhận nhiều thông báo khi chúng thực sự giúp họ hành động; họ tắt khi tin nhắn lặp, không liên quan hoặc đến vào lúc không phù hợp.
What should the default notification settings be for a new user?Mặc định nên ở chế độ im lặng cho mọi thứ không quan trọng, rồi để người dùng chủ động bật. Giữ các mục quan trọng như bảo mật và một vài cảnh báo thanh toán mặc định bật, mọi thứ khác dễ điều chỉnh để người mới cảm thấy được tôn trọng ngay cả khi không động đến cài đặt.
How do I know if I have too many notification toggles?Gộp các sự kiện tương tự khi hành động tiếp theo giống nhau, chỉ tách khi quyết định thay đổi. Quy tắc thực tế: nếu bạn không thể giải thích công tắc bằng một câu ngắn ai cũng hiểu — chuyện gì xảy ra và phải làm gì — thì nó có thể quá mơ hồ hoặc quá rộng.
What’s the best way to label notification preferences so they feel understandable?Đặt tên công tắc như các sự kiện thực tế với kết quả rành mạch, không dùng tên khu vực tính năng. “Payment failed” hay “New login from a new device” làm người dùng hiểu ngay, còn “Updates” hay “Activity” khiến họ phải đoán và thường dẫn đến tắt thông báo.
Which notifications should users never be allowed to turn off?Chỉ dùng “không thể tắt” cho những cảnh báo hiếm và rủi ro cao, chủ yếu là bảo mật và một vài lỗi thanh toán có thể khóa tài khoản hoặc ngừng dịch vụ. Nếu phải giữ bật, giải thích lý do bằng ngôn ngữ đơn giản để người dùng thấy bảo vệ chứ không phải cưỡng chế.
How should quiet hours behave to avoid confusing users?Giờ im lặng phải trì hoãn hoặc tắt tiếng các thông báo không khẩn trong cửa sổ do người dùng chọn, đồng thời cho phép một danh sách ngắn ngoại lệ cho các sự kiện rủi ro cao. Nó cũng phải xử lý múi giờ đúng để cài đặt không bị “hỏng” khi người dùng đi công tác hoặc khi chuyển giờ mùa hè.
When should I offer a digest instead of real-time notifications?Dùng bản tóm tắt cho các thông báo nhiều nhưng ít khẩn như hoạt động thường lệ, tương tác hoặc số liệu nền; giữ mọi thứ khẩn cấp ở thời gian thực. Nguyên tắc: người dùng không nên nhận cả tóm tắt lẫn thời gian thực cho cùng một sự kiện trừ khi bạn nói rõ điều đó.
What’s the difference between “sent” and “delivered,” and why does it matter?“Sent” chỉ nghĩa là bạn đã chuyển tin tới nhà cung cấp, không phải người dùng đã nhận. Theo dõi trạng thái sau như delivered, bounced, blocked, hay invalid destination để hỗ trợ trả lời “nó có tới tôi không?” và để người dùng sửa lỗi như email sai hay token đẩy hết hạn.
How should I handle retries when notification delivery fails?Dùng retry giới hạn với backoff cho lỗi tạm thời, rồi dừng và đánh dấu là thất bại kèm lý do có thể hành động. Không retry các lỗi vĩnh viễn như số điện thoại không hợp lệ, và tránh gửi lặp nhanh khiến trông như spam hoặc tiêu tốn pin.
How do I implement notification preferences without creating a messy system?Lưu cài đặt theo người dùng theo sự kiện, kênh và thời gian, rồi đưa mọi thông báo qua một bước quyết định chung áp dụng các quy tắc đó trước khi gửi. Trong AppMaster, điều này thường có nghĩa là mô hình hóa cài đặt trong PostgreSQL và thực thi giờ im lặng, tóm tắt, và ngoại lệ trong một quy trình nghiệp vụ để UI và backend luôn đồng bộ khi mở rộng.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
