프라이버시 UX: 더 나은 알림 및 권한 요청

• 1부: 웹 양식의 개인 정보 보호 문제 및 개인 정보 보호
• 파트 2: 더 나은 쿠키 동의 경험
• 3부: 더 나은 알림 UX 및 권한 요청
• 4부: 개인 정보 인식 설계 프레임워크

정말 늦고 싶지 않은 회의 중 하나에 늦었다고 상상해 보십시오. 당신은 서둘러 신발과 코트를 입고 문 열쇠를 가져오고 문 손잡이를 잡습니다. 계단을 내려오면서 주머니에 손을 넣고 휴대폰을 꺼내 지하철 시간표를 확인하거나 택시를 주문한다.

화면을 잠깐 보면 땀에 흠뻑 젖을 정도로 충분합니다. 밤새 휴대폰 충전을 잊었다는 것을 깨달았습니다. 휴대폰은 남은 2%의 배터리 충전량으로 자랑스럽게 작동하고 있습니다. 희망과 믿음으로 가득 찬 거리를 질주할 때 화면의 밝기를 어둡게 하고 홈 화면에서 올바른 앱 아이콘을 찾습니다. 물론 그 정확한 순간에 수많은 알림이 화면 아래로 내려와 새로운 팔로워, 업데이트, 미리 알림 및 메시지에 대한 집중적인 관심을 요청합니다.

이것이 어떤 느낌인지 너무 잘 알고 있을 가능성이 높습니다. 그 상황에서 알림의 계단식 스택에 대해 조치를 취할 가능성은 얼마나 됩니까? 그리고 몇 분 후 연결을 놓쳤을 때 다른 알림이 도달하면 알림을 완전히 끌 가능성은 얼마나 됩니까? 철저하게 만들어진 사용자 흐름과 세련되고 소중한 픽셀에도 불구하고 알림이 문자 그대로 가능한 가장 파괴적인 방식으로 방해가 되는 상황 중 하나입니다.

수많은 애플리케이션, 서비스, 사람, 기계, 챗봇이 우리의 관심을 끌기 위해 싸우고 있는 상황에서, 집중하는 것은 즐기고 보호해야 하는 사치입니다. 따라서 알림이 요즘 좋은 평판을 누리지 못하는 것은 당연합니다. 뿐만 아니라, 종종 그들은 요점에서 벗어나 조종적이라고 느끼기도 합니다.

"그들은 종종 관련성이 가장 낮은 시간에 나타나며 잘못된 긴급감을 만들어 초점을 흐리게 하고 좌절을 야기합니다."

— Alex Potrivaev, 인터콤

이것은 도구 모음의 읽지 않은 수만큼 홈 화면의 떠 있는 창에 적용됩니다. 이는 알림으로 가려진 마케팅 메시지뿐만 아니라 서비스에 영구적으로 관심을 끌기 위해 많은 작은 메시지로 세분화된 소셜 업데이트에도 해당됩니다.

이러한 모든 알림은 즉각적인 주의를 필요로 하며 매우 공격적인 느낌을 주며 , 소셜 그룹을 놓치지 않고 연결 상태를 유지하려는 우리의 욕구에 따라 작동합니다. 사실, 사용자가 현재 무엇을 하고 있는지에 상관없이 무조건적인 관심을 요구하고 주의를 끌면서 어두운 패턴이 할 수 없는 방식으로 개인 정보 보호를 방해합니다.

그러나 침입감을 느끼는 것은 알림의 잘못이 아닙니다. 우리는 그것들이 종종 방해가 되도록 설계합니다. 사용자는 중요한 알림을 놓치거나 시기적절한 메시지 또는 제한된 판매를 놓치고 싶지 않지만 시끄러운 업데이트의 끝없는 파도에 짜증을 느끼고 싶지도 않습니다. 후자가 너무 자주 발생하면 사용자는 알림을 완전히 끄며 한 사용자가 말한 것처럼 "필사적으로 관심을 구걸"하기 때문에 종종 앱과 브랜드에 대한 쓴맛을 느끼게 됩니다. 한 명의 범인은 다른 모든 사람들을 위해 그것을 망칠 수 있으며, 알림이 다른 것과 같지 않다는 사실에도 불구하고 말입니다.

알림의 다양한 측면

알림은 본질적으로 주의를 산만하게 하는 것입니다. 그들은 사용자가 알지 못하거나 상기시키고 싶은 (잠재적으로) 중요한 사건에 대해 사용자의 주의를 환기시킵니다. 따라서 그들은 도움을 제공하고 일상에 구조와 질서를 가져오는 매우 도움이 되고 관련성이 있을 수 있습니다. 그렇지 않을 때까지.

일반적으로 알림은 정보 제공 (일정 미리 알림, 지연 알림, 선거일 밤 결과)이거나 행동을 장려 (결제 승인, 업데이트 설치, 친구 요청 확인)할 수 있습니다. 다양한 소스에서 스트리밍할 수 있으며 다양한 영향을 미칠 수 있습니다.

• UI 알림 은 사용자가 웹 인터페이스와 상호 작용할 때 UI에서 미묘한 카드로 나타납니다. 따라서 사용자가 웹 인터페이스와 상호 작용할 때 널리 받아들여지고 일부 대응하는 것보다 덜 침습적입니다.
• 브라우저 내 푸시 알림 은 해제하기가 ​​더 어렵고 사용자가 UI에 액세스하지 않는 경우에도 스스로 주의를 끌 수 있습니다.
• 인앱 알림 은 데스크톱 및 모바일 앱 내에 있으며 UI 알림만큼 단순할 수 있지만 홈 화면이나 알림 센터로 푸시되는 메시지와 함께 더 중심적인 역할을 할 수 있습니다.
• 소프트웨어 업데이트 또는 이동통신사 변경과 같은 OS 알림 도 혼합되어 다양한 메모, 캘린더 업데이트 및 그 사이의 모든 것과 함께 표시되는 경우가 많습니다.
• 마지막으로 알림은 챗봇, 추천 시스템 및 실제 사람이 보내는 이메일, SMS 및 소셜 메시징 앱으로 전달될 수 있습니다.

모든 특징과 출처를 감안할 때 알림이 어떤 시점에서 어떻게 압도적일 수 있는지 알 수 있습니다. 하지만 우리가 수신하는 모든 알림에 똑같은 양의 주의를 기울이는 것은 아닙니다. 대다수 사용자의 경우 OS 알림에 따라 소프트웨어 업데이트를 설치하는 데 몇 주가 소요될 수 있지만 일반적으로 새로운 LinkedIn 또는 Facebook 요청을 확인하거나 거부하는 데 몇 시간 이상 걸리지 않습니다.

모든 알림이 같지는 않으며 사용자가 알림에 부여하는 주의 수준은 알림의 특성, 보다 구체적으로 알림이 트리거되는 방법 및 시기에 따라 다릅니다.

Shankar Balasbramanian은 "통지 시스템의 중요 분석"에 대한 기사에서 알림 트리거를 몇 개의 그룹으로 분류하는 놀라운 연구를 수행했습니다.

한 트리거 그룹이 다른 그룹보다 항상 더 효과적이라고 추론할 수는 없지만 모든 그룹의 일부 알림은 다른 그룹보다 주의를 끄는 데 훨씬 더 나은 경향이 있습니다.

• 사람들 은 친한 친구와 친척의 새 메시지, 근무 시간 중 선택한 동료의 알림, 은행 거래 및 중요한 알림, 일정 알림, 예정된 이벤트, 알람, 실행 가능하고 기다리고 있는 확인 또는 릴리스에 더 관심이 있습니다.
• 사람들은 일반적으로 뉴스 업데이트, 소셜 피드 업데이트, 공지 사항, 새로운 기능, 충돌 보고서, 웹 알림, 정보 제공 및 자동화된 메시지에 대해 덜 관심 을 갖습니다.

당연히 사용자는 배터리 부족 알림이나 결제 확인에 즉시 주의를 기울이는 경향이 있습니다. 또한 일정 알림, 진행 상황 업데이트(예: 패키지 배달 ETA) 및 일대일 메시지가 다른 알림보다 더 중요합니다. 사실, 우리가 사용자들과 나눈 모든 대화 에서 다른 사람의 메시지는 자동 알림보다 훨씬 더 가치가 있었습니다 . 물론 사용자가 알림을 참을성 없이 기다리고 있다면 우선 순위가 약간 바뀔 수 있지만 사진의 좋아요 77개를 확인하기 위해 필사적으로 서둘러 모든 것을 뒤로한 사람은 거의 없습니다.

따라서 알림이 다를 수 있으며 알림에 따라 다르게 인식될 수 있습니다. 그러나 더 개인적이고 관련성 있고 시기적절한 알림이 많을수록 더 많은 참여를 기대해야 합니다. 그러나 알림 디자인에 이 모든 것이 의미하는 바는 무엇이며 어떻게 하면 알림을 덜 방해하고 더 효율적으로 만들 수 있을까요?

일반 기본값에 의존하지 마십시오: 알림 모드 설정

일반적으로 고객이 서비스에 등록하는 데에는 충분한 이유가 있습니다. 그날 새 계정을 만들기 위해 아침에 눈을 뜨는 사람은 많지 않습니다. 실제로 그들은 귀하의 서비스가 일상 업무에 도움이 되거나 워크플로를 개선할 수 있다고 느낄 수 있습니다. 서비스 작동 방식을 이해하기 위해 알림이 필요하지 않기를 바랍니다. 하지만 서비스가 제공하는 가치를 이해하기 위해 알림을 수신해야 할 수도 있습니다.

아마도 그들은 잠재적인 고용주로부터 중요한 메시지를 받았거나 볼 가치가 있는 데이트 프로필 일치가 있을 수 있습니다. 그들은 잠시 동안 서비스에 체크인하는 것을 잊었다는 이유로 이러한 메시지를 놓치고 싶지 않을 수 있습니다. 디자이너로서 우리는 고객에게 동기를 부여하는 동시에 적절하고 실행 가능한 포인터만 제공하기 위해 혼합에 알림을 약간만 뿌릴 필요가 있습니다.

불행히도, 대부분의 서비스에서 가입하는 것은 드문 일이 아닙니다. 잠시 후 받은 편지함이 모든 종류의 메시지(대부분 순전히 정보 제공용)로 가득 차 있다는 것을 깨닫고 종종 즉시 전송되며 거의 실행되지 않습니다. 특히 이메일 알림은 기본적으로 켜져 있는 경우가 많으며, 길고 다루기 힘든 이용 약관에 동의하는 사용자의 동의가 있습니다. 원치 않는 메시지가 쏟아지는 것을 좋아하는 사람은 아무도 없으며 스팸 이메일의 경우에도 원치 않는 알림에 대해서도 마찬가지입니다.

기본적으로 모든 고객에 대한 기본 알림 빈도를 설정하는 대신 아주 드물게 선별된 몇 가지 알림만 보낼 수 있습니다. 고객이 인터페이스를 계속 사용함에 따라 선호하는 알림 유형과 빈도를 결정하도록 요청할 수 있습니다. 쿠키 동의 프롬프트도 마찬가지입니다. "진정 모드"(낮은 빈도), "일반 모드"(중간 빈도) 및 "파워 사용자 모드"(높은 빈도)와 함께 미리 정의된 권장 옵션을 제공 할 수 있습니다.

하지만 이보다 더 세분화할 수도 있습니다. 예를 들어 Basecamp는 온보딩 경험의 일부로 "항상 켜짐" 및 "작업 가능 대기" 옵션을 도입하여 신규 고객이 알림이 발생하는 즉시(언제든지) 수신할 것인지 또는 특정 시간을 선택할 것인지 선택할 수 있습니다. 알림을 보낼 수 있는 범위 및 요일. 또는 반대로 사용자에게 방해를 받고 싶지 않을 때 묻고 그 시간에 알림을 일시 중지할 수 있습니다. 모든 고객이 업무 시간 외 또는 주말에 업무 관련 알림을 받기를 원하는 것은 아닙니다. 동료가 지구 반대편에서 토요일 밤에 추가 근무를 하고 있는 경우에도 마찬가지입니다.

시간이 지남에 따라 알림 형식도 조정이 필요할 수 있습니다. 이벤트가 발생할 때 알림을 하나씩 전송하는 대신 사용자는 모든 알림을 매일 또는 매주 특정 시간에 단일 독립형 메시지로 그룹화하여 "요약 모드"를 선택할 수 있습니다.

이는 알림과 관련하여 Slack이 제공하는 설정 중 하나입니다. 실제로 시스템은 시간이 지남에 따라 알림 빈도도 조정합니다. 처음에는 Slack 채널이 매우 조용할 수 있으므로 시스템은 게시된 모든 메시지에 대해 알림을 보냅니다. 활동이 더 빈번해짐에 따라 Slack은 알림 수준을 줄여 사용자가 실제로 언급될 때만 알림을 받도록 권장합니다.

Slack이 제공하는 또 다른 기능은 사용자가 자신이 관심 있는 주제가 언급될 때만 알림을 받도록 선택한 단어를 강조 표시할 수 있도록 하는 것입니다.

이 시점에서 알림 빈도가 너무 많은 관심을 받고 있는 것처럼 들릴 수 있지만 알림의 일반적인 문제점에 대해 질문했을 때 가장 일반적인 문제는 메시지가 관련성이 있거나 실행 가능한 경우에도 단연코 높은 빈도였습니다.

결론은 알림을 천천히 그러나 꾸준히 보내기 시작한다는 것입니다. 알림 모드를 설정하고 트리거 선택 및 알림 형식과 같은 세분화된 옵션을 제공합니다. 너무 많이 보내는 것보다 너무 적게 보내는 것이 좋습니다. 고객이 잘못된 시간에 신경이 쓰이는 수많은 알림을 수신 거부하려는 경우 다시 기회를 얻지 못할 수도 있습니다.

신중하게 타이밍을 선택하십시오

우리는 그것을 인정하고 싶지 않을 수도 있지만, 우리 중 많은 사람들에게 하루는 떠오르는 태양의 평화롭고 마음챙김한 인사로 시작되지 않습니다. 대신, 휴대폰의 빛나는 화면을 지루하고 반사적으로 바라보는 것으로 시작합니다. 더 구체적으로 말하자면, 우리가 매일 아침 가장 먼저 보는 것은 현재 시간도, 사랑하는 사람도 아니라, 우리가 잠자는 동안 지칠 줄 모르고 쌓여가는 알림의 스택입니다.

이러한 마음 상태가 업데이트된 개인 정보 보호 정책, 빛나는 새 기능 또는 마무리해야 할 미지불 비용을 사용자에게 상기시킬 수 있는 가장 좋은 기회는 아닐 수도 있습니다. 새로운 소셜 공유 및 소셜 서클의 반응과 같은 개인 알림은 예정된 약속 및 그날의 할 일과 같이 훨씬 관련성이 높을 수 있습니다.

타이밍이 중요하고 시기적절한 알림도 중요 합니다. 고객이 시차로 인해 멀리 떨어진 곳에 도착하는 한밤중에 고객을 방해하고 싶지는 않을 것입니다. 따라서 시간대 및 현지 시간의 변화를 추적하고 그에 따라 알림 전달을 조정하는 것이 좋습니다. 반면에 고객은 더 이상 관련이 없을 때 표시되는 중요한 알림에 대해 특별히 만족하지 않을 것이므로 중요한 이벤트나 발표를 추적하는 경우 해당 이벤트가 다음 시간에 고객을 방해할 만큼 중요한지 결정해야 합니다. 불편한 시간.

분석은 사용자가 알림에 대해 조치를 취할 가능성이 있는 시점을 알려 주므로 시간을 기반으로 응답을 연구 및 추적하고 해당 시간에 알림 발송을 트리거하는 것이 좋습니다. 예를 들어, 고객이 아침에 메시지를 공유하는 것을 가장 잘 받아들이는 경우 현지 아침 시간의 적절한 순간까지 알림을 미루십시오.

설계로 스트레스 상황을 피하십시오

알림에서 타이밍은 고려해야 할 유일한 중요한 속성이 아닙니다. 이 섹션의 시작 부분에서 연결을 잡기를 바라는 불쌍한 캐릭터를 기억하십니까? 매우 낮은 배터리 수준에서 알림을 표시하는 것은 좋은 생각이 아니며 사용자가 연결에 어려움을 겪거나 자동차 운전과 같은 작업에 집중할 때 비생산적입니다. 배터리 잔량과 연결 품질을 평가할 수 있다면 사용자의 상태가 최적이 아닐 때 알림을 보내지 않는 것이 좋습니다. 물론 알림도 관련성이 있어야 하므로 사용자의 위치도 평가할 수 있다면 전혀 적용되지 않는 위치 종속 알림을 보내지 마십시오 .

사용자의 현재 활동에 중요할 수 있으므로 알림을 보류하기 어려운 경우가 있습니다. 사용자가 내비게이터 앱의 지시에 따라 자동차를 운전하는 경우 도로에서의 사고로 인한 권장 경로 변경에 대해 보다 지속적이고 겸손한 알림을 제공해야 할 수 있습니다. 이 경우 다른 중요한 알림과 마찬가지로 "새 업데이트 사용 가능" 버튼을 표시할 수 있습니다. 새로 고치다." 콘텐츠에 대한 액세스를 차단하는 알림보다 훨씬 덜 침습적이지만 페이지 또는 페이지 상태가 오래되었고 새 정보를 사용할 수 있음을 나타내는 데 효과적입니다.

실제로 특정 기본 시간에 알림을 보내는 대신 사용자의 과거 행동을 기반으로하더라도 동전의 이면을 탐색하고 대신 행복하고 성공적인 순간을 활용할 수 있습니다. 송금 서비스인 TransferWise는 고객이 결제를 받으면 알림을 표시합니다. 앱 스토어에서 앱 리뷰를 요청할 수 있는 절호의 타이밍이 아닐까요? 우리는 중요한 이정표를 추적하고 Luke Wroblewski가 호출한 것처럼 적시 에 고급 기능에 도달하면 사용자에게 알릴 수 있습니다.

알림을 그룹화하여 빈도 줄이기

주어진 날짜에 적절한 양의 알림에 대한 황금률은 없습니다. 모든 알림이 다른 것처럼 모든 고객의 선호도와 동기도 다릅니다. 사용자의 참여를 유지하려면 고객의 도달 범위 또는 선호도에 따라 알림 차단을 점진적으로 해제해야 할 수 있습니다. Intercom의 제품 디자이너인 Alex Potrivaev의 "스마트 알림 디자인" 기사에서 설명한 것처럼 바로 여기에서 점진적인 그룹화 가 시작됩니다.

아이디어는 간단합니다. 고객이 게시물당 평균 5개 미만의 반응을 받는다는 것을 알고 있다면 각각에 대해 고유한 알림을 제공하는 것이 좋습니다. 가까운 친구, 가족 또는 영향력 있는 사람들의 메시지와 같은 중요한 이벤트에서 메시지가 오는 경우 알림을 트리거할 수도 있습니다. 게다가 다른 사람의 행동에 의해 촉발된 알림이 자동화된 알림보다 더 중요하다는 것을 알고 있으므로 해당 특정 고객에 대한 개인 알림에 우선 순위를 지정하고 집중합니다 .

알림의 양이 증가하면 그룹화를 시작하고 적절한 시기에 간결한 요약을 제공할 수 있습니다. 예를 들어, Facebook은 특정 메시지에 대한 반응 ("Stoyan Stefanov 및 48명의 다른 사람들이 귀하의 게시물에 반응했습니다… 반면에 LinkedIn은 거의 모든 이벤트를 하나씩 실행하는 것으로 보입니다 ("Stoyan Stefanov가 귀하의 게시물에 댓글을 남김") . 따라서 알림 스트림을 오염시키고 스캔 및 사용을 어렵게 만듭니다.

물론 사용자의 이력을 기반으로 알림을 그룹화하는 것 이상을 사용자 지정할 수 있습니다. 사용자가 새로운 사진 좋아요에 어떻게 반응하는지, 간단히 살펴보거나 모든 알림에 대해 자세히 알아본다면 다음에 더 나은 알림을 제공할 수 있습니다. Alex는 다음과 같이 결론지었습니다.

"일반적으로 콘텐츠와 상호 작용하는 방식에 따라 더 나은 문구와 구조 선택이 제공될 수 있으며 기본 동작에 따라 다르게 구성된 알림을 볼 수 있습니다."

물론 이를 위해서는 지속적인 피드백 루프도 필요합니다.

사용자가 알림을 일시 중지하거나 일시 중지하도록 허용

고객에 대한 데이터의 가치를 무시하는 회사는 거의 없습니다. 실제로 피드백 루프 를 도입하여 가치 있는 장기적 통찰력을 얻을 수 있습니다. 즉, 고객에게 특정 종류의 알림을 "더 보기" 또는 "더 적게 보기"로 선택할 수 있는 옵션을 지속적으로 제공합니다. 그러나 우리가 장애를 켜짐/꺼짐 상태(당신은 장애가 있든 없든)로 인식하는 경향이 있는 것처럼, 우리는 종종 과거 행동만으로도 사용자의 행동을 정확하게 예측할 수 있다고 생각합니다.

그러나 현실은 거의 흑백입니다. 우리 이용자들은 한 팔에 아기를 안고 있을 때나 최근에 일어난 불의의 사고로 인해 일시적으로 방해를 받을 수 있으며, 자신이 처한 상황도 마찬가지로 변동할 수 있습니다. 수신 알림에 대한 응답으로 다시 알림과 같은 빠른 조치는 일시적이기는 하지만 문제를 완화하는 데 도움이 될 수 있습니다.

사용자의 컨텍스트는 지속적으로 변경됩니다 . 참여율이 비정상적으로 감소하거나 비정상적으로 많은 양의 알림(생일, 결혼 기념일 또는 선거일 밤)이 올 것으로 예상되는 경우 알림 음소거, 일시 중지 또는 일시 중지 옵션을 제공하는 것이 좋습니다. , 아마도 다음 24시간 동안.

이것은 우리의 직관에 매우 어긋날 수 있습니다. 고객이 갑자기 조용해진 경우 다시 참여를 원할 수도 있고 중요한 이벤트가 발생했을 때 고객의 참여를 극대화하기를 원할 수도 있습니다. 그러나 알림 빈도를 계속 누르는 것은 대부분의 경우 너무 위험합니다. 겉보기에 무해해 보이는 알림이 장기적으로 볼 때 잠재적으로 고객을 멀리하게 만드는 지점에 도달하기 쉽습니다. 사용자가 한동안 활동하지 않았거나 활동하고 싶지 않은 데는 타당한 이유가 있을 수 있으며, 대개는 서비스와 전혀 관련이 없습니다.

또 다른 옵션은 알림을 사용하는 데 사용되는 매체 변경을 제안하는 것입니다. 사용자는 서로 다른 긴급성 수준을 서로 다른 커뮤니케이션 채널과 연관시키는 경향이 있습니다. 인앱 알림, 푸시 알림 및 문자 메시지는 좋은 이메일보다 훨씬 더 방해가 되는 것으로 간주되므로 빈도가 특정 임계값을 초과하면 사용자가 푸시 알림에서 일일 이메일 요약으로 전환하도록 유도할 수 있습니다.

임계값 설정 및 알림 의사 결정 트리 구축

하지만 임계값을 적절하게 설정하는 것은 쉽지 않습니다. 중요한 이벤트는 제 시간에 수신되도록 즉각적인 알림을 트리거해야 합니다. 덜 중요한 이벤트는 기다릴 수 있지만 서비스에 대한 고객의 관심을 끄는 데 유용할 수 있습니다. 잠재적으로 관련이 없는 알림은 가차 없이 걸러내어 중요한 알림을 소중하게 여길 수 있는 시간과 공간을 남겨 두어야 합니다.

일반적으로 친구나 동료의 메시지와 같이 짧은 알림은 긴급하지 않은 경우 UI 알림으로, 긴급한 경우 푸시 알림으로 가장 적합합니다. 긴급한 것이든 아니든 긴 알림은 이메일로 보내는 것이 좋습니다 . 이 경험 법칙은 서비스마다 다르므로 긴급성, 길이 및 빈도를 기반으로 특정 종류의 알림에 가장 적합한 매체를 추적하기 위해 알림 결정 트리 를 구축할 수 있습니다. 또한 임계값을 정의하고 임계값에 도달하면 일시 중지 또는 설정 조정에 대한 프롬프트를 트리거할 수 있습니다.

옵트인 및 옵트아웃을 명확히 하십시오

요즘에는 서비스가 극단적으로 진행되어 고객이 전능한 알림에서 선택 해제하는 것이 엄청나게 어려울 것으로 거의 예상됩니다. 인터페이스의 먼 구석에 능숙하게 숨겨진 모호한 문구와 모호한 레이블은 드문 일이 아닙니다. 브랜드에 더 해롭고 피해를 줄 수 있는 다른 디자인 고려 사항은 거의 없습니다. 사용자가 설정을 쉽게 조정할 수 없으면 강력한 포를 적용하여 이메일 알림을 스팸으로 표시하거나 OS 설정 또는 브라우저 설정에서 알림을 차단합니다. 웹사이트나 앱의 경우 다시 구독을 요청하는 것 외에는 쉽게 복구할 수 있는 방법이 없습니다.

훨씬 더 간단한 방법은 내용, 형식, 빈도 및 방해 금지 시간을 포함하여 알림에 대해 매우 세분화된 제어를 제공하는 것입니다. 웹사이트 로그인 또는 앱 로그인을 우회하여 빈도를 변경하기 위해 "더 적은 이메일" 또는 "중지"로 최근 알림에 회신하는 옵션을 제공할 수 있습니다(Notion.so가 그렇게 함). 앱의 경우 OS 기본 설정에 의존하지 않고 앱에 통합 된 알림 기본 설정을 제공합니다. 여기에서 사용자가 모든 종류의 알림에서 무엇을 기대할 수 있는지 설명할 수도 있습니다. 예를 들어 알림이 어떻게 표시되는지도 알 수 있습니다.

실제로 많은 사용자는 정말로 필요한 경우 두 위치 모두에서 알림 설정을 검색 하지만 모호한 설정을 찾는 데 시간이 오래 걸릴수록 인내심이 줄어듭니다. 실제로 대부분의 사용자는 최근 알림으로 인해 실제로 좌절하거나 짜증이 나는 순간에 알림을 끄는 방법을 찾습니다. 그것은 기분 좋은 마음의 상태가 아니며, 서비스로서 당신은 아마도 당신의 유료 고객이 잔소리를 하고 혼란스러워하는 대가로 그러한 마음의 상태를 불필요하게 확장하고 싶지 않을 것입니다.

그러나 동전의 다른 면도 탐험하는 것을 잊지 마십시오. 사용자가 알림을 구독할 가능성이 더 높은 사용자 여정의 일부를 식별합니다. 예를 들어, 온라인 상점에서 주문이 성공적으로 이루어졌거나 항공편 예약이 확인된 경우입니다. 두 경우 모두 알림을 통해 고객이 지연을 추적하거나 제 시간에 탑승권을 검색할 수 있습니다. 또한 실시간 푸시 알림을 제안하기에 좋은 시기이기도 합니다. 즉, 먼저 이러한 알림을 보낼 수 있도록 고객의 허가를 요청해야 합니다. 그리고 그 주제는 별도의 대화가 필요합니다.

허락을 구하는 겸손한 길

일부 웹 사이트는 상당히 개성이 있습니다. 그렇지 않습니까? 방종하고 마음이 무례하고 진정으로 호의적입니다. 얼마나 자주 당신에게 알림을 보내달라고 구걸하는 놀라운 권한 프롬프트로 인사하기 위해 겉보기에 겸손하고 소박한 페이지를 우연히 발견합니까? 아직 한 단어도 읽지 않았지만 이미 장기적인 약속을 요구하는 단어가 있습니다. 솔직히 말해서 상당히 침습적인 것입니다.

사용자 경험의 관점에서, 로드 시 권한 프롬프트를 표시하는 것은 아마도 첫인상을 나쁘게 만드는 가장 좋은 방법일 것입니다. 대부분의 경우 돌이킬 수 없는 실수입니다. 2019년 1월부터 Chrome은 기본 프롬프트가 트리거될 때 표시되는 옵션을 변경했습니다. 사용자는 나중에 응답하기 위해 알림을 해제할 수 있지만 이제는 알림을 "수락"할지 또는 "차단"할지 선택해야 합니다. 후자는 사용자가 결국 액세스 권한을 부여하기 위해 광야의 브라우저 설정을 통해 길을 찾지 않는 한 전체 사이트에 대해 웹 알림이 영구적으로 차단됩니다. 대다수의 사용자가 내용을 전혀 읽지 않고 즉시 이러한 프롬프트를 차단하는 것은 놀라운 일이 아닙니다.

전략적으로 사용자가 실제로 수락할 가능성이 높은 경우에만 권한을 요청하는 것이 좋습니다. 그렇게 하려면 실제로 고객의 허가가 필요한 이유와 그 대가로 고객에게 제공할 수 있는 가치를 고객에게 설명해야 합니다. 실제로 이 전략은 '이중 요청 패턴'의 형태로 구현되는 경우가 많습니다. 즉시 허가를 요청하는 대신, 우리는 먼저 몇 번의 페이지 방문, 몇 번의 상호 작용, 사이트에서 보낸 일정 시간 등 일정 정도의 참여를 먼저 기다립니다 . 결국 우리는 사용자가 알림을 구독할 수 있다는 사실과 알림이 얼마나 중요한지 강조할 수 있습니다. 또는 보다 정확한 위치 인식 검색 결과를 위해 사용자의 허가가 필요하다는 사실을 강조할 수 있습니다. 사용자가 매장 찾기 페이지를 방문할 때 인터페이스에서 지리적 위치를 요청하려는 경우와 같이 페이지의 컨텍스트로 충분할 때도 있습니다.

이 모든 경우에 눈에 잘 띄는 클릭 유도문안 버튼은 사용자가 이에 대해 가장 잘 받아들이는 순간을 기다립니다. 사용자가 버튼을 탭하기로 선택하면 해당 작업을 계속 진행할 가능성이 높다고 가정할 수 있습니다. 따라서 버튼을 클릭하면 실제 기본 권한 요청이 표시됩니다.

기본적으로 권한 프롬프트를 두 가지 요청으로 나눕니다.

1. UI에 내장된 요청,
2. 브라우저 수준의 기본 요청입니다.

Adam Lynch가 언급했듯이 사용자가 기본 브라우저 프롬프트에서 탭을 잘못 누르거나 클릭을 잘못하여 여전히 권한을 취소 하는 경우 브라우저 설정(또는 설명 링크). 분명히 사용자가 이미 권한을 부여한 경우 알림 요청을 표시하는 것은 의미가 없습니다. 권한 API를 사용하여 단일 비동기 인터페이스를 통해 권한 상태를 쿼리하고 그에 따라 UI를 조정할 수 있습니다.

지리적 위치, 카메라, 마이크, 블루투스, MIDI, WebUSB 등에 대한 액세스와 같은 모든 종류의 권한 요청에 동일한 전략을 적용할 수 있습니다. UI 알림 프롬프트의 문구와 모양은 여기에서 매우 중요하므로 각 권한 또는 기능에 대한 참여 및 수락 비율을 추적하고 그에 따라 조치를 취하는 것이 좋습니다 . 그리고 알림에 대한 주요 메트릭을 추적하는 모든 것의 왕으로 우리를 데려옵니다.

알림에 대한 메트릭 추적

일반적으로 알림은 발생하거나 예정된 이벤트에 대해 고객에게 알리는 목적으로 전송되지 않습니다. 좋은 알림은 유용하고 실행 가능하여 고객과 기업 모두의 목표를 달성하는 데 도움이 됩니다. 이를 위해서는 관련 메트릭을 먼저 발견하고 정의해야 합니다.

최소한 우리가 보내는 알림이 처음부터 관련이 있는지 알아야 할 수도 있습니다.

• 알림의 문구, 형식 및 빈도가 우리가 달성하고자 하는 원하는 행동(소셜 공유, 사이트에서 보낸 시간 또는 구매)을 유도합니까?
• 어떤 알림이 다른 알림보다 더 중요합니까?
• 알림이 실제로 사용자를 애플리케이션으로 다시 데려갑니까?
• 알림을 보내고 사용자가 사이트 또는 앱으로 돌아오는 데 시간이 얼마나 걸리나요?
• 클릭률 알림과 사용자가 사이트를 떠나는 사이에 평균적으로 얼마나 많은 시간이 소요됩니까?

초보자, 일반 사용자, 고급 사용자 등 다양한 수준의 사용자 참여에 대해 문구, 길이, 발송 시간, 그룹화 및 알림 빈도를 실험해 보세요. 예를 들어, 사용자는 보다 캐주얼하고 시스템 알림처럼 느껴지지 않는 대화 메시지를 더 잘 수용하는 경향이 있습니다. 알림을 트리거한 실제 사람의 이름을 언급하는 것도 유용할 수 있습니다.

수신 거부 또는 앱 제거 등 잠재적인 부정적인 영향을 추적하기 위해 천천히 알림을 보내는 것은 결코 나쁜 생각이 아닙니다. 먼저 소그룹에 알림 그룹을 보내면 Nick Babich가 "좋은 알림을 만드는 방법"에서 언급한 것처럼 "너무 늦기 전에 유해한 알림 캠페인을 조정하거나 취소"할 수 있는 기회가 있습니다.

이러한 모든 노력은 동일한 목표를 염두에 두고 있습니다. 중요한 중단을 피하고 고객의 알림 피로를 방지 하는 동시에 고객이 알아야 할 정보를 알아야 할 시간에 알려줍니다. 그러나 쿠키 프롬프트가 짜증나고 빈번한 알림이 방해만 된다면 개인 데이터의 보안 및 관리 방식에 관해서는 고객이 훨씬 더 시급한 걱정을 하는 경향이 있습니다.

Android와 iOS에서 알림이 요청, 그룹화 및 표시되는 방식에는 상당한 차이가 있으므로 네이티브 또는 하이브리드 앱을 디자인하는 경우 이를 자세히 검토해야 합니다. 예를 들어 iOS에서 사용자는 앱을 온보딩하거나 나중에 사용할 때까지 앱 알림을 설정하지 않는 반면, Android 사용자는 설치 중에 알림에서 옵트아웃할 수 있으며 기본 동작은 옵트인입니다. PWA에서 보낸 푸시 알림은 각 OS에서 기본 알림처럼 작동합니다.

Admittedly, these issues will not be raised immediately, but as customers keep using an interface and contribute more and more personal data, doubts and concerns start appearing more frequently, especially if more people from their social circles are involved. Some of these issues are easy refinements, but others are substantial and often underestimated blockers.

In the final article of the series, we'll be looking into notifications UX and permission requests, and how we can design the experience around them better, with the user's privacy in mind.

• Part 1: Privacy Concerns And Privacy In Web Forms
• 파트 2: 더 나은 쿠키 동의 경험
• Part 3: Better Notifications UX And Permission Requests
• 4부: 개인 정보 인식 설계 프레임워크

Useful Resources And References

• “Designing Notifications For Apps,” Shashank Sahay
• “Different Types Of Notifications: Websites, Apps And Beyond,” Joanna Martin
• “It's Time For Notifications To Get Smart,” Alex Potrivaev
• “Improving User Experience With Real-Time Features,” Lauren Plews