다양한 알림 모델과 및 알람을 언제 발송해야 하는지 알아보기
(출처 : 이 기사는 [Designing notifications for apps]를 번역 및 가공한 콘텐츠입니다.)
이제 알림은 처리하기가 복잡한 기능이 되었습니다.
이 기사에서는 모든 세부 사항을 다루지는 않지만, 애플리케이션의 특징별로 어떤 알림 모델을 사용하는 게 적합한지 쉽게 선택할 수 있도록 3가지 알림 모델을 설명해보겠습니다.
알림 모델에 대해 얘기하기 전에 알림의 구성에 대해 간략히 설명하겠습니다.
알림은 사용자를 대상으로 앱에서 생성된 정보들이며, 다음은 알림의 중요한 구성 요소입니다.
출처 : 애플리케이션에서 알림이 시작된 곳입니다. 애플리케이션에는 정보가 분류되는 여러 메뉴들이나 정보 덩어리들이 있을 수 있으며 이러한 것들은 알림의 출처가 됩니다.
정보 : 알림을 통해 사용자에게 전달되어야 하는 메시지입니다. 예를 들면 "Daenerys Targaryen이 친구 요청을 보냈습니다"또는 "Load Varys님이 회원님을 팔로우하기 시작했습니다."같은 것들입니다.
정보 유형 : 알림은 주로 정보성이거나 액션을 유도(혹은 액션이 가능한)하는 두 가지 유형 중 하나 일 수 있습니다. 이 두 가지 유형 모두 앱의 콘텍스트에 따라 추가적인 하위 유형을 가질 수 있습니다.
배지 : 사용자에게 알림을 알려주는 시각적 표시입니다. 배지는 점 모양같이 평범하고, 그 안에 숫자를 넣어해서 읽지 않은 알림 수를 표시할 수 있습니다.
앵커 : 앵커는 알림이 인터페이스에 표시되는 앱의 시각적 컴포넌트입니다. 간단히 말해 사용자가 알림 표시+ 배지를 볼 수 있는 곳이며, 알림의 출처가 아니라 알림이 나타나는 컴포넌트 일뿐입니다. 앵커는 여러 출처에서 오는 알림 또는 하나의 출처에서 오는 알림을 수용할 수 있습니다.
알림은 애플리케이션이 유저와 커뮤니케이션하고 유저의 행동을 다시 애플리케이션으로 가져올 수 있는 매체 중 하나이기 때문에 앱에서 정말 중요한 부분입니다.
이제 널리 사용되는 알림 모델을 살펴보도록 하겠습니다.
이 모델에는 모든 알림이 도착하는 지정된 장소가 있습니다.
알림 센터는 전용 페이지가 따로 있거나 플라이 아웃 형태의 디자인을 가지고 있을 수도 있습니다.
이 모델에서 모든 알림은 출처와 상관없이 알림 센터에 날아와 모이게 되며, 알림 센터에서 알림의 출처 페이지로 이동할 수 있습니다.
대다수의 애플리케이션에서는 이 모델을 알림에 사용하며, 시각적으로는 벨 아이콘에 배지가 함께 표시됩니다.
알림 센터는 모든 알림이 시작되는 곳입니다.
또한 읽은 알림 및 읽지 않은 알림은 시각적으로 다르게 디자인할 수 있어서 유저가 이를 구분할 수 있습니다.
이 모델의 가장 큰 장점은 유연성입니다.
기존 알림 또는 새로운 알림 등 모든 알림을 한 곳에서 수용할 수 있습니다.
다양한 유형의 알림을 모두 고려해야 하며 이 다양한 유형의 알림은 모두 동일한 디자인 스타일을 따라야 합니다. 그렇기 때문에 알림의 디자인 스타일을 설계할 때 확장 성을 기본 목표로 생각하는 것이 중요합니다.
알림의 출처가 너무 다양하면 알림이 많을 때 이 모델이 약간 복잡해 보일 수 있습니다. 비슷한 유형의 알림이 있으면 그룹화하여 반복을 줄이는 게 알림의 인지에 도움이 됩니다. ( ex) "Sansa Stark 및 기타 3 명이 친구 요청을 보냈습니다.")
알림 센터를 쉽게 찾고 접근할 수 있는지 확인해 보아야 합니다.
알림이 프로덕트가 정의하고 있는 정보 구조에서 발생하지 않았거나, 알림의 출처가 되는 곳이 제대로 정보 설계가 안되어 있다면 기존 내비게이션 바에 표시할 수 없는 알림이 발생할 것입니다. 이 경우 알림 센터가 필요할 수 있습니다.
알림의 발생이 너무 많아 랜딩 화면에서 수용할 수 있는 것보다 더 많은 알림의 발생하는 경우에도 알림 센터가 사용됩니다.
알림에 대해 모든 시나리오를 생각하고 각각에 대한 노출방식을 찾기 전에 알림 기능을 제공해야 하는 경우가 있습니다. 이렇게 시간이 부족한 경우, 알림 센터는 매우 유연하기 때문에 쉽게 만들 수 있습니다.
이 모델에서는 모든 알림이 출처를 따라서 발생한 부분의 내비게이션 바에 고정됩니다.
모든 알림을 포함하는 하나의 허브 혹은 알림 센터는 없습니다. 더 나은 '출처별로 고정된 알림'을 만들고 싶다면 Whatsapp을 참고해보세요.
Android 및 iOS에서 채팅 또는 전화 알림은 각 탐색 메뉴에 고정됩니다.
이 모델의 장점은 알림이 묻히지 않아서 많은 콘텐츠를 확인할 수 있다는 것입니다. 유저는 알림 센터 같이 중간단계를 거치지 않고 직접 정보에 도달할 수 있습니다.
그러나 이 모델은 알림 센터만큼 유연하거나 확장 가능하지 않습니다.
이 모델은 애플리케이션의 정보 아키텍처에 따라 크게 영향을 받습니다.
내비게이션은 모든 다른 유형의 알림을 수용할 수 있어야 하고 알림 센터 모델과 마찬가지로 읽기 및 읽지 않은 알림의 시각적 차이가 중요합니다.
모든 알림을 내비게이션에 고정할 수 있는지 확인해야 합니다. 애플리케이션의 복잡성이 증가함에 따라 알림의 출처도 늘어날 수 있습니다. 이 경우 알림 센터로 이동하거나 혼합형 알림 모델 (예 : 고정된 알림과 알림 센터의 조합)을 고려할 수 있습니다. 다음 섹션에서 혼합 모델을 살펴보겠습니다.
모든 앵커에는 콘텐츠에 대한 디자인 스타일이 있어야 하고 알림이 앵커의 스타일에 맞는지 확인해봐야 합니다. 이를 이해하기 위해 WhatsApp의 예를 들어 보겠습니다. 여기서 "chats"앵커에는 채팅 개체의 모양을 정의하는 디자인 스타일이 있습니다. 즉, chats에 고정된 알림은 이 스타일을 따라야 합니다. “calls”도 마찬가지입니다.
앵커를 쉽게 찾고 접근할 수 있는지 확인해봐야 하고, 서로 중첩되는 앵커를 사용하면 안 됩니다.
랜딩 화면에서 모든 알림을 수용할 수 있을 때
모든 알림 시나리오를 고려했으며, 기존 디자인 스타일을 사용하여 모든 알림을 수용할 수 있을 때. 이러한 알림은 고정된 알림 스타일을 따르는 것이 중요합니다.
이 모델은 두 모델의 조합으로 가장 일반적으로 사용되는 모델입니다.
Facebook, LinkedIn, Twitter 및 Instagram은 혼합형 알림 모델을 사용하는 인기 있는 앱들입니다.
여기서 알림 센터는 내비게이션의 옵션 중 하나가 되며 메뉴에 없는 곳에서 알림이 발생했을 때 앵커로 사용될 수 있습니다. 예를 들어 Facebook은 새 친구 요청을 "친구"탭에 고정하지만 페이지를 좋아하는 초대는 알림 센터에 고정합니다.
이 모델은 두 모델의 장점이 있으며 대부분의 경우를 쉽게 수용할 수 있습니다.
모든 알림을 알림 센터에서 수용할 수도 있고, 우선순위와 시나리오를 정해서 알림의 출처별로 고정된 알림도 수용할 수 있습니다.
출처별로 고정된 알림과 마찬가지로 이 모델도 내비게이션 메뉴에 크게 의존하며, 여기에는 알림 센터도 옵션으로 제공됩니다.
프로덕트의 정보구조에서 가장 중요한 정보 덩어리를 걸러내고 순위를 매깁니다.
순위를 매기면 어떤 알림을 출처에 고정하고 어떤 알림을 알림 센터에 배치해야 하는지 우선순위를 지정할 수 있습니다. 이 모델은 내비게이션에 따라 다르므로 사용 가능한 페이지의 공간에 따라 알림 구성이 변경될 수 있습니다.
내비게이션의 일부 요소로 앵커 및 알림 센터를 배치할 경우, 쉽게 찾을 수 있는지 확인해 보아야 합니다.
알림 시나리오와 정보 우선순위가 충분히 고려되었을 경우. 각각의 알림 출처에 고정할 수 있는 알림이 있지만 정보 구조상 출처에 고정할 수 없는 알림도 있기 때문에 어떤 알림을 출처에 고정하고 어떤 알림을 알림 센터로 보낼지 정해져 있어야 합니다.
내비게이션에 알림 출처가 중첩되어 있을 때에도 활용할 수 있습니다. 예를 들어 Facebook 앱의 햄버거 메뉴 아이콘은 Groups, Watch, Memories, Saved, Marketplace 등 그 여러 정보 덩어리에서 오는 알림을 위한 앵커입니다.
위에서 언급 한 모든 모델은 올바른 상황에서 올바르게 사용되었을 때 유용합니다.
앱에 어떤 모델을 선택할지 결정하는 것은 정보 아키텍처와 제공하려는 알림 유형에 따라 다릅니다.
감사합니다.