알림 설정 화면은 토글을 누르기 전에 무엇이 발생하고, 어느 채널로, 언제 전달되는지 답해야 합니다. ‘알림 켜기’ 하나로는 긴급한 리뷰 요청, 댓글 멘션, 주간 요약의 차이를 설명할 수 없습니다. 사용자가 저장 결과를 예측할 수 있어야 합니다.
이 글은 가상의 디자인 리뷰 서비스를 예로 미래의 알림을 설계합니다. 이미 도착한 알림을 정리하는 작업은 알림 받은편지함 UX 가이드와 다릅니다. 실제 상태를 테스트하려면 화면을 Pixso 프로토타입으로 연결하고, 설명 없이 한 가지 변경을 수행하게 하세요.

채널보다 이벤트에서 시작하기
이메일, 푸시, 인앱은 전달 위치이지 알림을 보내는 이유가 아닙니다. 먼저 서비스가 실제로 만드는 이벤트를 적습니다. 예시는 댓글의 직접 멘션, 담당자로 지정된 리뷰, 팔로우한 파일의 일반 업데이트입니다. 세 이벤트에 같은 긴급도를 적용하지 않는 것이 핵심입니다.
| 이벤트 | 관심을 가질 이유 | 검증할 기본값 | 설명할 내용 |
|---|---|---|---|
| 직접 멘션 | 응답이 필요한 호출일 수 있음 | 인앱과 선택 가능한 즉시 채널 | 이메일을 꺼도 인앱에는 남는다는 점 |
| 리뷰 할당 | 업무가 사용자에게 넘어옴 | 인앱과 허용된 즉시 채널 | 채널을 바꾸거나 해제하는 방법 |
| 팔로우한 파일 활동 | 유용하지만 매번 긴급하지 않음 | 인앱 또는 다이제스트 | 전달은 늦어져도 파일 변경은 늦어지지 않음 |
표의 기본값은 예시일 뿐 Pixso의 알림 정책을 의미하지 않습니다. 적용하기 전에 실제 사용자에게 확인하세요. 끌 수 없는 보안 알림이 있다면 ‘모든 알림’ 스위치에 섞지 말고 해당 행에서 이유를 밝혀야 합니다.
각 행이 결과를 설명하게 하기
이벤트마다 한 행을 만들고 짧은 설명과 채널 선택을 둡니다. “직접 멘션 — 댓글에서 이름이 언급될 때”처럼 쓰면 벨이나 봉투 아이콘이 설명을 대신하지 않습니다. 번역이나 보조 기술에서도 이벤트와 채널의 관계가 읽혀야 합니다.
사용할 수 없는 채널은 원인을 보여 주세요. 푸시가 비활성화된 이유가 운영체제 권한 거부일 수 있고, 이메일이 비활성화된 이유가 주소 미확인일 수 있습니다. 다음 행동이 다르므로 “알림 켜기”만으로는 부족합니다. Apple과 Android가 관리하는 시스템 설정을 제품 토글이 덮어쓸 수 있는 것처럼 보이게 하지 마세요.
권한·선호·전달 상태 분리하기
푸시가 오지 않는 이유는 앱에서 끈 경우, 기기가 거부한 경우, 이벤트가 규칙을 만족하지 못한 경우로 나뉩니다. “푸시 선택됨 · 시스템 설정에서 차단됨”처럼 표시하면 사용자의 선택을 임의로 바꾸지 않고 상태를 설명할 수 있습니다.
저장 확인도 정직해야 합니다. 서버가 규칙을 저장했다면 “선호 설정을 저장했습니다”라고 할 수 있지만, 기기 권한이 없는데 “이제 푸시를 받습니다”라고 약속해서는 안 됩니다. 운영체제에서 바뀌는 소리와 중요도 역시 제품 설정과 별도의 경계로 안내하세요.
다이제스트와 방해 금지 시간의 범위 정하기
“덜 보내기”는 모호합니다. 빈도, 채널, 묶이는 이벤트, 시간대를 함께 표시하세요. 예를 들어 “팔로우한 파일의 일반 업데이트를 현지 시간 평일 09:00에 이메일 한 통으로 전송”이라고 씁니다. 직접 멘션이 다이제스트를 우회한다면 저장 버튼 아래 각주가 아니라 멘션 행에 적습니다.
방해 금지 시간은 일정 시간 동안 어떤 방해를 미룰지 정하는 기능이지, 인앱 기록을 삭제하는 기능이 아닙니다. 22:00–08:00을 선택했다면 일반 업데이트는 아침까지 기다리고 직접 멘션은 선택한 예외 규칙을 따른다고 보여 주세요. 시간대가 바뀌면 새 현지 시간이 어떻게 적용되는지도 알려야 합니다.
버튼을 그리기 전에 저장 방식을 결정하기
여러 토글을 각각 저장하면 일부 요청만 실패해 서버가 승인하지 않은 조합이 화면에 남을 수 있습니다. 다이제스트, 일반 푸시, 방해 금지 시간을 함께 바꾸는 폼이라면 하나의 저장으로 전체 선호를 전송하고 “저장 중” 상태와 결과 요약을 보여 주는 편이 안전합니다.
요청이 실패해도 입력값을 지우지 말고 재시도를 제공합니다. 다른 기기에서 바뀌었다면 현재 저장값과 충돌을 보여 준 뒤 덮어쓰게 하세요. 버튼을 눌렀다는 이유만으로 성공 토스트를 보여 주거나 설명 없이 이전 값으로 되돌리지 않습니다.
한 사용자의 흐름 따라가기
모바일 결제 디자인을 리뷰하고 컴포넌트 라이브러리를 팔로우하는 Maya를 생각해 봅시다. 목표는 멘션은 즉시 받고, 라이브러리의 모든 변경에 대한 개별 이메일은 멈추는 것입니다.
- 현재 멘션과 파일 활동 설정을 확인합니다.
- 파일 활동만 평일 09:00 이메일 다이제스트로 바꿉니다.
- 22:00–08:00을 설정하고 미뤄지는 알림과 인앱에 남는 알림을 확인합니다.
- 저장 후 다이제스트와 멘션 예외를 요약으로 확인합니다.
- 다음 날에도 같은 선택을 다시 볼 수 있습니다.
이 시나리오는 설계 연습이며 Pixso가 이 알림을 실제로 보낸다는 주장이 아닙니다. 중요한 약속은 한 이벤트의 소음을 줄여도 다른 이벤트를 우연히 차단하지 않는 것입니다.

성공 경로만이 아니라 예외 상태 테스트하기
저장됨, 변경 중, 저장 실패, 저장 완료 상태를 그립니다. 푸시가 있으면 시스템 권한과의 불일치도 추가합니다. 작은 화면에서는 이벤트 이름과 채널 라벨을 함께 읽게 하고, 가로로 스크롤하는 체크박스 표를 피하세요. 키보드 사용자는 이벤트와 채널이 포함된 접근 가능한 이름을 필요로 하며, 저장 결과는 지각 가능한 상태 메시지여야 합니다.
화면을 Pixso에 배치하고 저장·재시도·돌아가기 경로를 연결합니다. 동료에게 “멘션은 남기고 파일 활동 개별 이메일은 끄세요”라고 요청한 뒤 오늘 밤과 내일 아침에 무엇이 올지 물어보세요. 인터페이스에서 답하지 못한다면 문구나 그룹을 다시 설계합니다. 프로토타입은 의도를 보여 주지만 구현에서는 권한, 시간대, 전달 규칙을 별도로 보장해야 합니다.
신뢰할 수 있는 알림 설정은 각 컨트롤의 범위가 예측 가능합니다. 이벤트, 채널, 시간을 보이게 하고 시스템이 실제로 전달할 수 있는 것만 약속하세요.