brunch

You can make anything
by writing

C.S.Lewis

by BUNDI Jun 24. 2019

앱에서 ‘알림’을 디자인하는 법

각기 다른 알림 모델들, 언제 그리고 어디에 사용해야 할까요?



"띠링", "카톡", "땡"...

핸드폰이 울린다는 건, 새로운 알림이 있다는 걸 의미합니다.

거의 모든 서비스에서 바로 이 알림 기능을 사용 중이죠.


알림 기능은 사용자에게 정보를 제공하면서도,

서비스에 들어오게끔 만드는 중요한 기능입니다.

오늘은 알림 기능을 디자인하는 방법, 세 가지를 소개합니다.





*다음은 아래 글에 대한 번역입니다.

https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96






앱에서 ‘알림’을 디자인하는 법

각기 다른 알림 모델들, 언제 그리고 어디에 사용해야 할까요?




여러분 안녕하세요.

Breakdown 시리즈를 계속하고 있는데 벌써 5번째 시리즈, 알림(Notification) 편입니다.

알림은 꽤나 복잡할 수 있는 기능입니다.

이 글에서는 모든 디테일을 다루지는 않습니다만, 읽으시는 여러분이 여러분들의 서비스에 적합한 알림 모델을 명확하게 고를 방향성을 제시하길 희망합니다.


알림 모델에 대해 이야기하기 전에, 도대체 알림이 무엇이며 무엇으로 이루어져 있는지 알아봅시다.

알림은 앱 사용자들을 향하고 있는 정보로 구성되어있습니다. 여기 알림의 중요한 요소들을 소개합니다.



알림 모델 스키마



소스 Source


이 알림이 어디서 왔는지를 알려줍니다. 앱의 구조에 따라 정보가 분류되는 카테고리가 여러 개로 나뉠 수 있습니다. 그리고 그런 카테고리가 알림의 소스가 됩니다.



정보 Information


알림에 담기는 정보이며, 사용자에게 전달되어야 할 내용입니다. 자주 쓰이는 예시로 ‘John이 친구 요청을 보냈습니다’, ‘Peter가 당신을 팔로우합니다’ 등이 있습니다.




종류 Type


알림은 주로 정보성 Informational 혹은 실용성 Actional으로 분류됩니다. 두 종류 모두 앱의 맥락에 따라 추가 설명이 붙을 수 있습니다.




알림 배지 Notification Badge


알림 배지는 사용자에게 알림이 있음을 지시하는 시각적 지표입니다. 알림 배지는 동그라미로 표현될 수 있고, 그 위에 번호를 표기해서 확인하지 않은 알림의 수를 알릴 수 있습니다.




앵커 Anchor


앵커는 인터페이스상에서 알림이 위치하는 시각적 영역입니다. 간단히 말해서, 사용자가 알림을 확인하는 공간을 의미합니다. 앵커는 알림의 필수적 요소는 아니고 알림이 나타나는 곳에 사용될 수 있는 요소입니다. 앵커는 하나 혹은 여러 개의 소스에서 오는 알림을 담아낼 수 있습니다. 이렇게 생각하세요. 소스는 좀 더 구조적/정보적 차원의 개념이고, 앵커는 알림 배지를 어디서 볼지를 정하는 시각적 차원의 개념입니다.





알림은 사용자가 서비스와 소통하는 수단이자, 사용자가 다시 서비스로 돌아오게 하는 수단입니다. 때문에 서비스에서 정말 중요한 기능을 담당하고 있습니다. 지금부터는 몇 가지 자주 쓰이는 알림 모델을 소개하고, 언제 어떤 모델이 적합한지를 소개하고자 합니다.







알림 센터 Notification Center


이 모델에는 모든 알림 내용이 모입니다. 알림 센터는 지정된 어떤 화면일 수도, 아니면 현재 있는 화면에 따라 플라이 아웃 화면일 수도 있습니다. 이 모델에서는 소스에 상관없이 알림 센터에 알림들이 고정됩니다. 사용자는 알림 센터에서 알림들의 소스를 확인할 수 있습니다. 대표적으로 Medium이 알림 센터를 사용 중입니다. 종 아이콘에 배지가 알림을 알려주며, 모든 알림이 이 곳에 있습니다. 이 모델에서 중요한 점은, 읽은 알림과 읽지 않은 새로운 알림을 시각적으로 구분해서 사용자에게 제공하는 것입니다. 이 모델의 가장 큰 장점은 유연함입니다. 이미 존재하는 소스부터 새로운 소스까지, 모든 알림을 하나의 공간에서 쉽게 관리할 수 있습니다.


알림 센터 모델 예시 - Medium



가이드라인


각기 다른 종류의 모든 알림들이 고려되어야 하며, 동일한 디자인 스키마를 따라야 합니다. 스키마를 디자인할 때는 항상 확장성을 생각해야 합니다.

만약 너무 많은 소스의 알림이 존재한다면, 알림 창이 다소 난잡해 보일 수 있습니다. 비슷한 종류의 알림이 있다면, 함께 묶어 중복을 피할 수 있습니다. 예를 들어 ’Sarah 외 3명이 친구 요청을 보냈습니다’와 같은 알림을 사용할 수 있습니다.

명심하세요. 알림 센터는 쉽게 찾을 수 있고 쉽게 접근할 수 있어야 합니다.



이럴 때 사용하세요


알림 영역이 현재 존재하는 내비게이션 옵션 중에 그 어떤 옵션에도 귀속되기 힘든 상태일 때. 이와 같은 경우는 서비스에 존재하는 어떤 요소가 지속적으로 알림과 연관되어 알림을 만들어 내지 않거나, 서비스 구조상 어떤 요소에 딱 지정되어 알림이 만들어지지 않을 경우를 생각할 수 있습니다.

새로운 알림을 만들어낼 새로운 소스가 등장할 가능성이 있을 때.

시간이 많이 없을 때. 모든 알림에 적합한 앵커를 고려하고 가능성을 생각할 시간이 부족할 때 사용하세요. 알림 센터의 유연함 덕분에 쉬운 해결책이 될 수 있습니다.







소스에 정착한 알림 Source Anchored Notification


이 모델은, 모든 알림이 내비게이션 옵션들에 맞게 들어가 있습니다. 모든 알림이 모이는 단일화된 공간은 없습니다. Whatsapp 같은 채팅 서비스를 생각하면 이해하기가 쉽습니다. 안드로이드와 iOS 두 플랫폼 모두에서, 채팅과 전화 알림은 해당되는 내비게이션 메뉴에 귀속되어있습니다. 이 모델의 장점은, 콘텐츠를 탐색하기 쉽다는 데 있습니다. 사용자는 중간중간 다른 내용을 같이 살펴볼 필요 없이, 알림이 담고 있는 정보에 곧바로 접근할 수 있습니다. 하지만 이 모델은 알림 모델보다는 유연하지 못하며, 확장성도 제한됩니다. 그리고 이 모델은 서비스의 구조에 큰 영향을 받습니다. 내비게이션은 각기 다른 모든 알림을 모두 감당해낼 수 있어야 합니다. 또한 알림 센터 모델과 마찬가지로, 읽은 알림과 읽지 않은 알림을 시각적으로도 구별해내야 합니다.



소스에 정착한 알림 모델 예시 - Whatsapp



가이드라인


모든 알림이 하나의 내비게이션 옵션에 귀속될 수 있도록 해야 합니다. 서비스가 복잡해질수록, 알림이 오는 소스들도 다양 해질 것입니다. 이러한 경우, 아예 알림 센터 모델을 사용하거나, 두 모델을 섞어놓은 혼합형 모델을 고려할 수 있습니다. 혼합 모델에 대해서든 다음 순서로 알아보겠습니다.

각 앵커는 그것이 담고 있는 내용에 따라 디자인 스키마를 정해야 합니다. 그리고 알림 또한 앵커가 취하고 있는 디자인 스키마를 따라야 합니다. 이를 이해하기 위해 Whatsapp을 살펴봅시다. ‘채팅’ 앵커에 쓰인 디자인 스키마는 어떤 정보가 ‘채팅’에 어떻게 보여줄지를 알려줍니다. 그리고 알림 또한 이 스키마와 동일하게 보이고 있습니다. 물론 ‘통화’와 같은 다른 앵커도 마찬가지입니다.

앵커는 쉽게 찾을 수 있으며 접근하기도 쉬워야 합니다. 여러 개로 복잡하게 구성된 앵커는 자제하는 게 좋습니다.





이럴 때 사용하세요


모든 알림을 내비게이션 메뉴들에서 소화할 수 있을 때.

지금 구축된 디자인 스키마 안에서, 모든 알림에 대한 가능성을 생각해 놓고 해결할 수 있을 때. 각 알림은 알림들이 속한 앵커가 따르고 있는 스키마를 그대로 따라갈 수 있어야 합니다.







혼합 모델 Mixed Model


이 모델은 앞서 본 두 모델을 섞어놓은 모델입니다. 그리고 가장 자주 쓰이는 모델이기도 합니다. Facebook, Linkedin, Twitter, Instagram과 같은 유명한 앱이 이 모델을 사용 중입니다. 이 모델에서 알림 센터는, 내비게이션에 보이긴 애매한 알림 들을 담아내는 공간이 됩니다. 예를 들어, Facebook은 새로운 친구 요청을 ‘친구’ 탭에서 해결합니다. 하지만 페이지 초대와 같은 알림 들은 모두 알림 센터로 가게 됩니다. 이 모델은 두 모델의 장점을 모두 지니고 있으며, 다양한 변수에 대응할 수 있습니다. 물론 알림 센터를 두고 모든 알림을 거기서 해결할 수 있겠지만, 알림이 발생한 소스에 기반하여 가장 최적화된 방식으로 알림을 보여주기 위해 고민하는 과정은 꼭 필요합니다. 소스에 정착한 알림 모델처럼, 이 모델 역시 내비게이션 모델에 의존적이긴 하지만, 알림 센터라는 다른 옵션을 지니고 있습니다.



혼합 모델 예시 - Facebook



가이드라인


서비스 구조상 가장 중요하고, 우선순위 위에 위치한 정보를 찾아 순위를 매겨보세요. 그렇게 순위를 정해 보면 어떤 중요한 알림을 해당 소스에 정착시켜줄지, 어떤 덜 중요한 알림을 알림 센터로 보내줄지 정할 수 있게 될 겁니다. 이 모델은 내비게이션에 의존적인 만큼, 현재 내비게이션에서 제공하는 정보에 따라 알림 배치를 생각하면 좋습니다.

내비게이션 중앙에 위치한 앵커일수록 주목성이 강하고 찾기 쉽다는 점을 명심하세요.




이럴 때 사용하세요


먼저 모든 알림이 나올 수 있는 상황을 생각해 보세요. 어떤 알림 들은 내비게이션에 정착시켜 해결할 수 있으나, 어떤 알림 들은 그러기 힘들 때 사용하세요.

복잡한 소스를 지닌 메뉴가 내비게이션에 있을 때 사용하세요. 예를 들어, Facebook의 햄버거 메뉴 아이콘을 생각할 수 있습니다. 이 햄버거 메뉴에 있는 메뉴들(그룹, 추억, 저장됨, 쇼핑 등등)에서 나오는 알림들이 바로 알림 센터로 이동하게 됩니다.







결론


소개한 3개의 모델들은 적절한 상황에 사용되면 모두 유용한 모델들입니다. 어떤 모델을 사용할지는 서비스의 정보 구조와, 어떤 알림을 중점적으로 제공하고 싶은지에 따라 결정하면 됩니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari