brunch

매거진 디자인 뉴스레터 디독

라이킷 35 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김자유 Jul 05. 2019

앱 알림(노티) 디자인 모델

해외 디자인 아티클 번역 뉴스레터 '디독' 구독링크: http://bit.ly/2FNQNpv

디독

page.stibee.com

기능 분석 시리즈를 이어가면서, 오늘은 그 다섯번째로 어플리케이션의 알림 모델에 대하여 이야기해보려 한다. 오늘날 알림은 다루기 복잡한 기능일 수 있다. 이번 아티클은 이에 대하여 모든 전반적인 것들을 다루지는 않지만, 당신의 어플리케이션에 적합한 알림 모델을 선택하는 데 있어, 약간의 명확성과 방향을 제공하는데 충분하길 바란다.

알림 모델을 논하기 전에, 알림은 무엇이고 무엇으로 구성되어 있는지 간단히 요약해보자. 알림은 사용자를 대상으로 하는 어플리케이션에서 비롯되는 정보 중 일부로, 여기에 몇 가지 중요한 알림의 구성요소가 있다.

알림 모델 - 스키마(요약)

출처 : 이 부분은 어플리케이션의 알림이 나타나는 부분이다. 어플리케이션의 아키텍처(정보구성)는 정보가 분류되는 몇 개의 버킷을 가질 수 있는데, 이 버킷들은 알림의 출처가 된다.

정보 : 알림을 통해 사용자에게 전달해야하는 메세지라 할 수 있다. 몇 가지 예시로 “Daenerys Targaryen이 당신에게 친구요청을 했다"거나 “Lord Varys가 당신을 팔로잉하기 시작했다" 가 있다.

형태/유형 : 알림은 주로 정보 제공과 실행 가능한 두 가지 유형으로 이루어지는데, 두 가지 유형 모두 어플리케이션의 맥락에 따라 하위 유형이 추가될 수 있다.

알림 배지 : 이것은 사용자에게 알림을 통해 안내하는 시각적 지표로, 점과 같이 간단할 수도 혹은 읽지 않은 알림 수를 표시하는 카운트일 수도 있다.

앵커 : 앵커는 앱에서 알림을 인터페이스에 나타내는 시각적 구성요소이다. 간단히 말해서, 사용자가 알림 지표/배지를 볼 수 있는 구성요소로, 앵커는 반드시 알림의 출처가 아니고 알림 표면에 구성요소 임을 잊지말자. 앵커는 여러 개의 출처나 하나의 출처로부터 알림을 받아들일 수 있다. 이렇게 생각해보자. 출처는 아키텍처/정보의 레벨에 더 가깝지만, 앵커는 알림 배지를 볼 수 있는 시각적 구성요소이다.

알림은 어플리케이션이 사용자와 소통해 어플리케이션으로 다시 보낼 수 있는 매체 중 하나로, 어플리케이션에서 매우 중요한 부분이다. 이제 몇 가지 현존하는 가장 인기있는 알림 모델과 다른 모델을 사용하는 것이 더 합리적인 경우에 대해 소개하려한다.

1. 알림 센터

이 모델에는 당신의 모든 알림이 모여지는 일종에 정의된 장소가 있다. 알림 센터는 실제로 이용 가능한 지점(estate)에 따라 전용 화면이 되거나 플라이아웃될 수 있다. 이 모델에서, 모든 알림은 출처와 상관없이 알림 센터에 고정되기 때문에 당신은 이 알림 센터를 통해 알림의 출처로 이동할 수 있다. 미디엄도 알림을 위해 이 모델을 사용하고 있다. 당신의 모든 알림의 노출 지점인 종 모양 아이콘에 뱃지가 나타난다. 읽음과 읽지 않은 알림이 시각적으로 다르기 때문에 사용자가 이를 구분할 수 있게 하는 것이 중요하다.

미디엄 - 알림 센터

이 모델의 가장 큰 이점은 바로 유연하다는 것으로, 기존의 알림이나 새로운 알림과 같은 모든 알림을 모을 수 있는 유일한 지점이다.

가이드라인

모든 다른 유형의 알림은 동일한 디자인 스키마를 고려하는 동시에 따라야 한다. 확장성을 우리의 주된 목표료 생각하는 것이 중요하다.

만약 당신이 너무 많은 알림의 출처를 가지고 있다면, 이 모델은 너무 많은 양의 알림이 있을 때 약간 어수선해 보일 수 있다. 만약 유사한 유형의 알림이 있다면, 예를 들어 “Sansa Stark 외 3명의 사람들이 당신에게 친구 요청을 보냈습니다"와 같이 이를 그룹화함으로써 반복을 줄일 수 있다.

알림 센터가 쉽게 발견 및 접근될 수 있는지 확인하자.

알림 센터를 사용하는 경우

당신의 제품에 기존의 네비게이션 옵션에 고정시킬 수 없는 알림이 필요한 경우이다. 알림이 기존 제품의 개체와 일치하지 않거나, 정보 아키텍처에 어떤 정의된 출처로부터 비롯되지 않기 때문에 발생한다.

앱이 랜딩 화면에서 수용할 있는 것보다 더 많은 알림 출처가 있다. 당신에게 주어진 시간이 얼마 없는데, 알림에 대한 가능한 모든 경우를 생각하고 각각의 앵커를 찾기 전에 당신이 기능에 도달해야 하는 경우가 있다. 이러한 경우, 알림 센터는 본질적으로 매우 유연하기 때문에 쉽게 벗어날 수 있다.

2. 출처 고정 알림

이 모델은 모든 알림은 가장 해당 알림의 출처일 것 같은 네비게이션 옵션에 고정되며, 모든 당신의 알림이 모이는 단일 허브나 센터는 없다. 이해를 돕기 위해 와츠앱을 살펴보면, 두 가지 플랫폼(안드로이드와 iOS)에서 채팅이나 통화로부터 나타나는 알림들은 각각의 네비게이션 메뉴에 고정된다. 이 모델의 이점은 바로 더 다양한 컨텐츠의 발견으로 이어진다는 것이다. 이제 사용자는 출처에 도달하기까지 추가된 중간 단계의 불편함 없이 알림에 의해 전달된 정보에 곧바로 접근할 수 있다. 하지만 반대로 이 모델이 알림 센터만큼이나 유연하거나 확장 가능하지 않은 점이 존재한다.

와츠앱 - 출처 고정 알림

이 모델은 앱의 정보 구성에 크게 좌지우지 된다. 네비게이션은 모든 다른 유형의 알림을 수용할 수 있어야 하고, 이전 모델과 동일하게 읽음과 읽지 않은 알림이 시각적으로 다르다는 것이 중요한 과제이다.

가이드라인

모든 알림이 랜딩 화면의 네비게이션 옵션 중 하나에 고정될 수 있는지 확인하자. 당신의 어플리케이션이 복잡해질수록, 알림의 출처 또한 증가한다. 이런 경우에 당신은 알림 센터를 활용하거나 혼합 모델(고정 모델과 알림 센터의 조합)을 고려해볼 수 있다. 이 혼합모델에 대해서는 다음 섹션에서 좀 더 알아보기로 하자.

모든 앵커는 보관할 컨텐츠에 대한 디자인 스키마를 가지고 있어야 하는데, 알림이 앵커의 스키마에 적합한지 확인하자. 이것이 이해하기 어렵다면, 와츠앱을 예로 들어보자. 앵커 ‘채팅'은 어떻게 채팅이 보여아하는지 정의한 디자인 스키마를 가지고 있는데, 이는 채팅에 대한 어떤 알림도 이 스키마를 따라야 한다는 것을 의미하며 이는 ‘통화'에도 마찬가지로 적용된다.

앵커가 쉽게 발견되고 접근할 수 있는지 확인하고 중첩되는 앵커는 피하자.

소스 고정 알림을 사용하는 경우

모든 가능한 출처의 알림은 랜딩 화면에서 수용되어져야하는 경우

알림의 모든 경우를 숙지하고 모든 알림을 기존 디자인 스키마에 적용시킬 수 있을 때를 말하며, 여기서 아람이 해당 출처의 스키마를 따르는 것이 중요한 부분이다.

3. 혼합 모델

이 모델은 두 가지 모델의 조합형으로, 가장 많이 사용되는 모델이다. 인기 앱서비스인 페이스북, 링크드인, 트위터 그리고 인스타그램에서도 이 혼합 모델을 사용하고 있다. 여기서 알림 센터는 네비게이션 메뉴에 옵션 중 하나로 자리잡게 되는데, 이 옵션은 랜딩 화면과는 별개의 출처를 나타내는 앵커로 사용된다. 예를 들어, 페이스북은 ‘친구들' 탭에 새로운 친구 요청을 나타내지만, 페이지와 같은 초대장은 알림 센터에 노출된다.

페이스북 - 혼합 모델

이 모델은 두 가지 모델의 장점을 갖고 있으면서도 대부분의 사례에 쉽게 적용할 수 있다. 당신은 이제 알림 센터에 알림을 고정시킬 수 있지만, 여전히 모든 경우의 수를 고민하고 출처 고정 알림에 적용시킬 수 있는 알림의 우선 순위를 매기는 것은 필요하다.

출처 고정 알림 모델과 마찬가지로, 이 모델 또한 네비게이션 메뉴에 따라 크게 달라질 뿐만 아니라, 메뉴에서 현재 옵션으로의 알림 센터가 존재한다.

가이드라인

제품의 정보 구성 체계에서 가장 중요한 버킷을 찾아내고 순위를 매긴다. 순위를 정하면 어떤 알림이 출처에 고정되어야 하는지와 어떤 알림이 알림 센터에 우선적으로 나타나야 할지 결정할 수 있다. 이 모델은 네비게이션에 따라 달라지기 때문에, 가능한 지점에 따라 알림의 배치가 바뀔 수 있다.

주요 앵커와 알림 센터가 랜딩 화면의 네비게이션 중에 하나로 쉽게 발견되는지 확인하자.