알림함 UX: 읽음·처리 완료·구독 해제 구분하기

알림함에서는 “내용을 확인했다”와 “내가 할 일을 처리했다”를 구분해야 합니다. 디자인 검토 스레드를 열었다고 해서 댓글에 담긴 문제가 해결되는 것은 아닙니다. 읽지 않은 알림 배지를 없애도 앞으로의 알림이 중단되지는 않습니다. 서로 다른 동작을 하나의 버튼에 합치면 사용자는 어디까지 처리했는지 놓치거나, 계속 지켜봐야 할 작업의 알림을 실수로 끌 수 있습니다.

팀의 디자인 검토 알림함을 예로 들어 읽음 상태, 개인별 알림 정리, 구독을 함께 설계해 보겠습니다. 목표는 배지 숫자를 잠깐 0으로 만드는 것이 아니라, 사용자가 자리를 비웠다가 돌아와도 자신의 작업을 안심하고 이어 갈 수 있는 목록을 만드는 것입니다.

읽음, 처리 완료, 팔로우는 서로 다른 질문에 답합니다

각 행의 동작을 디자인하기 전에 상태별 의미부터 정하세요. 읽음 상태는 이 사용자가 해당 업데이트를 확인했는지를 나타냅니다. 개인별 정리 상태는 그 항목을 자신의 처리할 알림 목록에 계속 둘지를 나타냅니다. 팔로우 여부는 앞으로의 업데이트를 받을지를 나타냅니다. 알림의 대상인 검토나 작업에는 팀이 함께 사용하는 별도의 상태가 있을 수 있습니다.

이 네 가지는 하나만 선택할 수 있는 상태가 아니라 서로 별개의 기준입니다. 하나의 검토가 읽은 상태이면서 처리할 목록에 남아 있고, 저장되어 있으며, 팔로우 중일 수도 있습니다. 모든 상태를 배지로 표시할 필요는 없지만, 동작을 설계할 때는 각각의 의미를 구분해야 합니다.

GitHub의 알림 안내 문서(영문)에는 읽음, 완료, 저장, 구독 해제가 각각 다른 이름의 동작으로 제시되어 있습니다. 다만 일부 결과는 연결되어 있습니다. 구독을 해제하면 현재 알림도 제거됩니다. 이후 직접 멘션되거나, 팀이 멘션되거나, 검토 요청을 받으면 다시 알림이 올 수 있습니다. 자체 알림함 정책을 정할 때 이런 구체적인 결과를 참고하세요. 버튼이 따로 있다는 이유만으로 각 동작의 효과도 서로 독립적이라고 가정해서는 안 됩니다.

알림함의 한 행이 무엇을 나타내는지 정하세요

이 검토 사례에서는 한 행이 “결제 오류 메시지”라는 하나의 대화 스레드를 나타냅니다. 같은 대화에 새 댓글이 세 개 달려도 동일한 행이 갱신됩니다. 이 행에는 최근 활동과 함께 “회원님이 멘션되었습니다” 또는 “이 검토를 팔로우하고 있습니다”처럼 이 사용자에게 알림이 온 이유를 표시합니다.

이렇게 묶으면 댓글이 많은 대화 하나가 알림함 전체를 차지하는 일을 막을 수 있지만, 배지가 무엇을 세는지 정해야 합니다. 숫자 “3”은 읽지 않은 스레드 세 개일 수도, 읽지 않은 이벤트 세 건일 수도, 조치가 필요한 항목 세 개일 수도 있습니다. 하나의 단위를 정하고 명확히 설명하세요. 이 사례의 배지는 처리할 알림 목록에 있는 읽지 않은 스레드만 세며, 처리 완료된 스레드는 제외합니다. 읽지 않은 스레드를 처리 완료로 옮기면 읽음 상태를 바꾸지 않아도 배지의 집계 대상에서 빠집니다. 처리할 목록에 있는 같은 대화를 아직 읽지 않았다면, 댓글이 세 개 달려도 스레드 한 개로 세지 세 개로 세지 않습니다.

관련된 숫자도 뜻이 분명해야 합니다. “처리할 알림 12개 · 읽지 않음 3개”라고 표시하면 대화 세 개를 읽어도 처리할 목록이 비지 않는다는 점을 알 수 있습니다. 단순 안내나 답변이 필요 없는 대화가 함께 포함된 숫자에 “작업”이라는 이름을 붙이지 마세요.

제품에서 이벤트 하나를 한 행으로 표시한다면, 같은 대상에 다시 변경이 생겼을 때 이전 이벤트를 어떻게 다룰지도 정해야 합니다. 무엇을 묶어서 보여 줄지는 디자인상의 선택이지만, 설명 없이 스레드 단위와 이벤트 단위를 오가면 혼란이 생깁니다.

다음 행동을 고를 수 있도록 각 행에 맥락을 담으세요

좋은 알림 행은 모든 항목을 열어 보지 않아도 네 가지를 알 수 있게 합니다. 무엇이 바뀌었는지, 어디에서 일어났는지, 필요한 경우 누가 변경했는지, 그리고 왜 나에게 알림이 왔는지입니다. 결제 관련 대화라면 스레드 제목, 프로젝트 이름, “마야가 회원님을 멘션했습니다”라는 안내, 짧은 댓글 발췌문을 표시할 수 있습니다.

발췌문에는 제목을 반복하기보다 판단에 도움이 되는 내용을 담으세요. “어떤 카드 정보를 확인해야 하는지 안내할 수 있을까요?”라는 문장은 디자이너가 지금 검토를 열어 볼지 결정하는 데 도움이 됩니다. 반면 “결제 오류 메시지에 새 댓글이 있습니다”는 다른 필드에 이미 나온 정보에서 크게 벗어나지 않습니다.

읽지 않은 상태를 미세한 색상 차이만으로 구분하지 마세요. 읽을 수 있는 상태 문구, 접근성을 위한 설명이 있는 점 표시, 글꼴 굵기 등의 표현을 함께 사용할 수 있습니다. 읽음으로 바뀐 뒤에도 제목과 중요한 맥락은 잘 보여야 합니다. 강조를 줄이는 것이 대비를 떨어뜨리는 결과로 이어져서는 안 됩니다.

상대적인 시간 표시는 목록을 훑어보는 데 도움이 되지만, “어제”만으로 사건의 순서를 파악하게 해서는 안 됩니다. 필요할 때는 사용자의 현지 시간을 정확히 제공하고, 보는 사람의 시간대가 다르다는 이유만으로 이벤트 자체의 의미를 바꾸지는 마세요.

어느 시점에 읽음으로 바뀌는지 정의하세요

행을 선택하는 즉시 읽음으로 바꿀까요? 상세 패널이 로드된 뒤에 바꿀까요? 아니면 사용자가 별도로 읽음 처리를 해야 할까요? 이 규칙은 인터페이스가 실제로 확인할 수 있는 사실과 맞아야 합니다. 키보드 포커스가 행을 지나갔다는 것만으로 내용을 읽었다고 볼 수는 없습니다.

이 사례에서는 행을 선택하면 상세 패널에 대화를 불러옵니다. 현재 업데이트의 내용이 정상적으로 표시된 뒤에 해당 업데이트를 읽음으로 처리합니다. 불러오기에 실패하면 읽지 않은 상태를 유지하고 다시 시도할 방법을 보여 주세요. 네트워크 요청이 시작됐다는 이유만으로 배지를 지우지 마세요.

사용자가 읽는 도중에도 새 댓글이 도착할 수 있습니다. 패널을 열 때 참·거짓 값 하나만 바꾸는 대신, 어느 업데이트까지 표시했는지 추적해야 합니다. 패널에 이벤트 18까지의 댓글을 보여 준 뒤 이벤트 19가 도착했다면, 이전 내용에 대한 읽음 확인이 새 이벤트까지 읽은 것으로 처리해서는 안 됩니다. 새 댓글을 바로 표시할 수도 있고, 추가 업데이트가 있다고 안내할 수도 있습니다. 어느 방식을 선택하든 일관된 읽음 처리 규칙이 필요합니다.

사용자가 나중에 다시 확인할 표시로 활용할 수 있도록 “읽지 않음으로 표시”를 제공하세요. 이 동작은 개인에게만 영향을 주며 결과를 예측할 수 있어야 합니다. 팀 검토에서 스레드를 읽지 않음으로 바꿨다고 작성자에게 자신의 의견이 거절되었다는 알림을 보내거나, 다른 사람의 읽음 상태를 되돌려서는 안 됩니다.

‘내 알림 처리 완료’를 되돌릴 수 있게 하세요

결제 관련 질문에 답한 디자이너가 알림을 처리 완료로 표시합니다. 이 알림함에서는 해당 스레드가 자신의 처리할 목록에서 빠지고 개인의 ‘처리 완료’ 화면으로 이동합니다. 팀 전체의 대화를 해결된 것으로 바꾸거나, 화면 디자인을 승인하거나, 댓글을 삭제하는 동작은 아닙니다.

주변 맥락에서 개인에게만 적용되는 동작임이 분명하다면 버튼 이름을 “처리 완료”로 줄여도 됩니다. 같은 인터페이스에 팀 전체에 적용되는 “대화 해결” 동작도 있다면 문구와 위치를 구분하세요. 결과가 다른 두 동작에 같은 체크 표시를 쓰면 쉽게 혼동할 수 있습니다.

즉시 실행 취소할 수 있게 하고, 나중에도 ‘처리 완료’ 화면을 통해 다시 찾을 수 있게 하세요. 행이 사라지면 키보드 포커스를 적절한 인접 항목이나 빈 목록의 제목으로 옮깁니다. 더 이상 존재하지 않는 컨트롤에 포커스를 남겨 두어서는 안 됩니다.

새로운 관련 이벤트가 생기면 처리 완료된 항목을 다시 활성화할지도 정하세요. 이 사례에서는 새 멘션이 오면 대화가 읽지 않은 상태로 돌아오지만, 관련 없는 백그라운드 업데이트로는 돌아오지 않습니다. 이는 이 알림함에 명시적으로 정한 정책이지 모든 제품에 적용되는 원칙은 아닙니다. 왜 다시 나타났는지 알려 주어야 사용자가 ‘처리 완료’를 믿을 수 없는 동작으로 여기지 않습니다.

구독 해제는 앞으로 받을 알림에 관해 설명해야 합니다

“팔로우 중단”은 앞으로 전달받을 알림을 바꿉니다. 이 디자인 검토 알림함에서는 일반 업데이트만 중단하고, 현재 스레드는 기존의 ‘처리할 알림’ 또는 ‘처리 완료’ 화면에 그대로 둡니다. 처리 완료로 표시하는 동작은 별개입니다. 사용자가 오늘의 알림 목록을 비우는 동작으로 오해하지 않도록 컨트롤 가까이에 이 결과를 설명하세요.

이 사례에서는 일반 업데이트 수신을 중단한 뒤에도 직접 멘션되면 스레드가 처리할 알림 목록에 읽지 않은 상태로 나타납니다. 확인 문구는 “일반 업데이트 알림을 중단할까요? 누군가 회원님을 멘션하면 계속 알림을 받습니다.”처럼 쓸 수 있습니다. 다른 제품에서는 팀 멘션이나 담당자로 지정된 검토도 예외일 수 있지만, 해당 제품이 실제로 지원하는 규칙만 설명해야 합니다.

제품 정책상 끌 수 없는 업데이트에 일반적인 구독 해제 버튼을 사용하지 마세요. 대신 사용자가 실제로 조정할 수 있는 설정을 설명하세요. 또한 구독 설정이 비공개 스레드를 볼 권한까지 부여하지는 않습니다. 알림 전달과 접근 권한은 별개의 문제입니다.

하나의 검토가 알림함에서 이동하는 과정을 살펴보세요

다음 순서는 앞에서 정한 정책이 어떻게 작동하는지 보여 줍니다. 디자인 검토용 알림함에 제안하는 동작이며, Pixso 자체 알림 시스템을 설명하는 내용은 아닙니다.

이 결과는 목록, 상세 패널, 이메일 링크 어디에서든 일관되어야 합니다. 이메일에서 돌아온 사용자는 관련 대화나 업데이트에 도착해야 합니다. 항목이 처리 완료로 옮겨졌다는 이유로 설명 없이 빈 알림함을 보여 주어서는 안 됩니다.

동작이 실패하거나 권한이 바뀌어도 사용자의 위치를 보존하세요

인터페이스에서 성공을 예상해 항목을 먼저 제거했지만, 실제 행 동작은 실패할 수 있습니다. 처리 완료가 확인되지 않으면 명확한 메시지와 함께 행을 복원하거나, 미완료된 동작을 표시하면서 해당 항목에 계속 접근할 수 있게 하세요. 서버가 거부한 상황에서 행이 사라졌다는 이유만으로 처리가 확실히 완료된 것처럼 보여 주어서는 안 됩니다.

대상 항목이 더 이상 존재하지 않으면 이용할 수 없음을 알리고 알림을 닫을 수 있게 하세요. 접근 권한이 제거되었다면 캐시에 남아 있는 비공개 발췌문을 계속 노출하지 마세요. 복구 경로도 현재 권한을 따라야 합니다. 알림 링크가 접근 제한을 우회하는 수단이 되어서는 안 됩니다.

‘읽지 않음’ 필터에서는 행을 읽는 순간 목록에서 사라질 수 있습니다. 사용자가 다 읽기도 전에 상세 패널까지 없어지지 않도록 하세요. 목록을 갱신하는 동안 열린 대화를 유지하고, 현재 선택된 항목을 명확히 표시할 수 있습니다. ‘전체’로 돌아갔을 때도 관련 없는 항목으로 갑자기 이동하지 말고 사용자가 이어서 볼 수 있는 위치를 유지하세요.

Pixso에서 알림함의 동작 모델을 검토하세요

Pixso에서 실제로 있을 법한 검토 스레드 몇 개를 담은 목록·상세 화면을 만드세요. 아직 읽지 않은 멘션, 읽었지만 처리할 목록에 남은 대화, 새 멘션을 받아 다시 나타난 처리 완료 항목, 실패한 동작을 각각 포함합니다. 개인 알림 목록의 상태와 팀이 공유하는 대화의 상태는 주석을 나누어 기록하세요.

검토자에게 자신의 목록에서 지우지 않고 마야의 질문을 읽은 다음, 필요한 일을 처리하고 일반 업데이트 알림을 중단해 달라고 요청하세요. 각 동작이 무엇을 바꿀 것으로 기대하는지 들어 보세요. “처리 완료”를 디자인 승인으로 이해한다면 아이콘을 다듬기 전에 문구를 고치거나 팀 전체에 적용되는 동작과 분리해야 합니다.

주요 화면 상태를 연결해 검토하고, 구현이 필요한 동작을 주석으로 남기세요. 업데이트 버전을 구분하는 읽음 확인, 항목 제거 후의 포커스 이동, 구독의 예외 규칙, 접근 권한 변경 등이 여기에 해당합니다. 클릭 가능한 프로토타입은 의도한 순서를 전달할 수 있지만, 내부 규칙이 실제로 구현되었음을 증명하지는 않습니다.

Pixso에서 더 명확한 알림함을 디자인해 보세요 →

사용자가 믿고 사용할 수 있는 알림 목록을 만드세요

읽지 않은 알림 수는 확인할 내용을 보여 주고, 개인의 처리 완료 상태는 할 일을 정리하며, 구독은 앞으로의 알림 전달을 제어합니다. 각각의 약속을 구분하고, 상태 변경을 되돌릴 수 있게 하며, 항목이 다시 나타난 이유를 설명하세요. 배지를 지울 수 있을 때가 아니라 자신의 작업이 어디에 있을지 예상할 수 있을 때 알림함은 비로소 유용해집니다.