스타트업에서 앱에서의 알림 UI/UX 디자인하기
Notifications in an App - UX Case Study
실무를 시작하기 전 배우는 입장이었을 때는 한 서비스 내에서의 특정 부분의 프로세스를 깊이 고려해 볼 기회가 없었다. 근래에는 스타트업에서 실무를 시작하게 되면서, 매주 앱 내에서의 특정 플로우 기획과 문제 해결을 반복하면서 많은 케이스를 고려해 디벨롭하고 사용성을 좀더 디테일하게 생각할 수 있어 재밌는 나날을 보내고 있다. 이번에 주어진 과제는 우리 앱 내에서의 '알림'을 디자인하는 것이었다. 곧 출시를 앞둔 서비스이므로, 구체적인 서비스의 상세한 언급은 지양하고 UX 케이스 스터디 방식으로 문제 해결 프로세스를 중점적으로 공유하고자 한다.
Background.
출시를 앞둔 서비스이므로, 구체적인 사업 내용에 대해서는 공개할 순 없지만, 하나의 커뮤니티 앱이라고 언급할 수 있겠다. 예를 들면 페이스북, 인스타그램, 블로그처럼 어떠한 분야 내의 커뮤니티이다. 아직 어느 특정 부분을 구상할 때 이미 발생한 사례들로 생각을 할 수 없기 때문에, 브레인 스토밍과 선 사례 분석, 다양한 아티클 정보들이 특히 중요한 역할을 했다. 그리고 해당 서비스 유저들의 퍼소나를 잡되, 거기에 매몰되지 않고 일반적으로 통용될 수 있는 시나리오로 구상하는 것이 중요했다.
Challenge.
알림을 디자인 하기 위한 논의 및 해결점은 다음과 같다.
1. 앱에서 알림은 왜 필요할까?
2. 어떤 알림들이 발생할 수 있을까?
3. 어떤 알림 모델을 사용해야 할까?
4. 알림(or 푸시 알림)의 생성과 만료의 기준은 무엇일까?
5. 알림 클릭 시 화면을 어떻게 보여줄까?
6. 알림을 어떻게 효율적으로 보여줄까?
7. 알림 설정은 어떻게 기획하면 좋을까?
우리는 몇 가지 '알림'에 대한 유용한 아티클을 참고하거나 기존 앱들을 분석하면서 알림을 디자인해 볼 수 있었다.
Solution.
Q1.
앱에서 알림은
왜 필요할까?
A. 사용자에게 앱을 사용하면서 적절한 시기와 맥락에 부합하는 알림을 제공함으로써, 앱 외부에 있는 사용자들을 내부로 불러들여(by 푸시알림) 우리 앱의 활용도와 사용자의 편의를 높이기 위해 알림이 필요하다.
위 아티클에 따르면, 좋은 알림에 대해서는 두 가지 속성이 있다.
1. 맥락에 부합한다. (Contextual) - "내가 왜 이 알림을 받았는가?"
2. 적시에 도착한다. (Time-sensitive) - "내가 왜 이 알림을 지금 받았는가?"
좋은 알림의 두 가지 속성이 맥락성과 적시성이라면, 우리는 사용자에게 맥락성과 적시성을 지키며 사용자 경험을 증진시킬 수 있는 알림을 제공할 필요가 있었다. 우리가 구상해야 하는 알림의 '필요성'에 대해 논리적인 시작점을 상호 공유하고 그 다음으로 단계로 나가보았다.
Q2.
어떤 알림들이
발생할 수 있을까?
A. 우선, 우리 앱 내에서 발생할 수 있는 모든 알림들을 나열해서 브레인 스토밍 해보자.
알림 메세지의 브레인 스토밍가장 처음에는, 우리 앱 화면을 섹션별로 보고 즉각적으로 떠오르는 알림 사항이 무엇이 있을지 생각했고, 이후에는 스프레드시트에서 디테일한 구분을 시도했다. 브레인 스토밍 결과, 발생할 수 있는 알림의 개수는 약 40개 정도가 나왔고, 이를 대분류(네비게이션 기준)와 소분류, 세부 항목으로 묶어서 전체적인 카테고리 유형을 나눠 보았다. 알림을 나열해본 이유는, 앱에서 어떤 알림이 발생하고 거기에서 공통적인 카테고리를 공유하는 것을 그룹핑하여, 카테고리별로 알림을 어떻게 전달할지, UI구성은 어떻게 할 수 있을 지 감을 잡아보기 위함이었다.
알림 메세지의 특성 유형화알림 메세지를 나열한 뒤에는 이들의 특성을 좀더 디테일하게 정의해 본다. 각 알림들이 받는 대상, 피드가 생성되는지, 푸시알림 여부, 알림 후 동작 여부, 알림을 클릭했을 때 이동되는 화면 등을 분류한다. 이 과정은 추후 알림 설정을 구상할 때 특히 유용했는데, 설정 사항들을 그룹핑해서 정의하는 데에 도움이 됐다.
Q3.
어떤 알림 모델을
사용해야 할까?
A. 알림센터와 소스에 정착한 앵커 표시를 결합한, '혼합 모델'을 채택하기로 했다.
위 아티클에 따르면, 알림 모델에는 3가지 모델이 있다.
1. 알림 센터(Notification Center) - 알림이 모아져 있는 섹션, 하나의 풀페이지나 모달 드로어 형태로 나타남
2. 소스에 정착한 알림(Source Anchored Notification) - 네비게이션에 각 항목에 배지 표시
3. 혼합모델(Mixed Model)
여기서 혼합모델은 1, 2의 두 모델을 섞은 것이며 페이스북, 링크드인 등의 SNS관련 앱에서 자주 채택하는 방식이다. 이 모델은 알림의 유형에 따라 일부는 알림 센터로, 일부는 소스에 기반하여 배지 형태로 제공하여 두 모델의 장점을 취하며 다양한 변수에 대응할 수 있다.
초반에는 '소스'의 개념을 제대로 짚고 넘어가지 않아서, 우리 앱에 어떠한 모델이 적절한 것인지 명확한 판단이 서진 않았다. 이후 다시 되짚으며, 여기서 말하는 '소스(Source)'는 알림이 어디서부터 오는지를 알려주는 것임을 알게 되었는데, 이는 즉 우리가 고민하고 있었던 알림의 카테고리를 의미하는 것이었다. 카테고리 = 소스로 이해하면 되고, 이 소스는 네비게이션 내 항목 기반이거나 또다른 어떠한 항목일 수 있다.
페이스북 스터디
페이스북의 혼합모델(Mixed Model)이다.페이스북의 경우는 혼합모델을 채택하고 있다. 혼합모델 사용 가이드에 따르면, 혼합모델은 모든 알림이 나올 수 있는 상황을 생각한 뒤 알림의 특성에 따라 어떤 알림은 네비게이션에 정착(=소스에 정착, 배지 형태의 알림)하고, 어떤 알림들은 그러기 힘들 때 알림센터에서 해결할 수 있도록 유도하는 것이다.
예를 들면, 페이스북에서 네비게이션 내의 항목인 비디오나 친구신청 같은 경우에는, 해당 섹션에 새로운 사항이 업데이트 됐을 경우 배지로 개수를 나타내어 알림을 제공할 수 있다. 이는 즉 소스에 정착한 알림으로 사용자들에게 즉각적인 변화를 인식시킨다. 다만, 내가 가입한 그룹의 새글 알림이나 이벤트가 추가된 것 등에 대한 알림은 네비게이션 내의 항목(소스)가 아니기 때문에, 배지 형태로 나타내기 힘들고 따로 알림센터에 소스화하여(아이콘을 통해) 알림 메세지와 함께 나타난다.
적용하기
우리 앱의 혼합 모델우리 앱 내에는 하단 네비게이션이 있다. 알림 메세지를 브레인 스토밍 할 때 이 네비게이션 항목 기준으로 발생할 알림들을 나열했고, 이 때 네비게이션 항목 내의 콘텐츠에 기반한 '새 게시물 알림'같은 경우는 소스에 정착한 배지로 처리할 수 있음을 알 수 있었다. 하지만 이 외에 프로모션 알림이나 시스템 알림 등은 네비게이션 내에서 해결하기는 힘들기 때문에 알림센터로 보내서 모아볼 수 있도록 했고, 알림센터는 상단 앱바 우측에 위치하여 모달 드로어 형태로 나타난다.
Q4.
알림의 생성과 만료의
기준은 무엇일까?
A. 근본적으로는 사용자의 알림 설정에 따라 알림의 생성 여부가 결정될 것이다. (푸시 알림 수신 여부, 서비스별 알림 설정 등) 알림의 만료의 경우는 우선, 타 서비스를 분석해보며 서비스의 목적이나 알림의 방식에 따른 다양한 기준이 있음을 스터디해 보았다.
알림의 생성과 푸시 알림의 필요성
알림은 기본적으로 어떨 때 생성될 수 있을까? 서두에서 살펴 보았듯, 알림은 맥락성과 적시성에 의해 발생한다. 이를 좀더 아래와 같이 구체화 해 보았다.
내가 한 행위에 대한 결과나 상태 변경이 발생 했을 때 (맥락성) - ① 답변 or 피드백형
내가 한 행위의 완료, 더블체크성 알림 (맥락성) - ② 더블체크형
현재 시기에 서비스에 대한 알림이 필요할 때 (적시성) - ③ 시스템알림형, 프로모션형
내가 원하는 서비스의 새 콘텐츠가 게시 되었을 때 (적시성) - ④ 새글알림형
사용자가 푸시 알림 설정을 허용했다고 가정한다면, 이 때 위의 모든 알림에 대해 푸시 알림이 필요할까? 알림의 케이스를 나열한 뒤에, 어떤 알림은 푸시 알림이 필요하고 어떤 알림은 필요하지 않다는 것을 알게 되었다. ①, ③, ④의 경우는 사용자가 앱의 외부에 있을 때 앱의 내부로 불러들여 어떠한 행위를 할 수 있도록 유도한다는 측면에서 푸시 알림이 필요하다고 판단했고, ②의 경우는 사용자가 앱의 내부에 있을 때 더블체크성으로 알림센터에 기록을 남기는 방식으로, 푸시 알림이 필요하지 않다고 판단했다. 이렇듯 알림 메세지를 유형화하면 푸시 알림의 여부를 고려하기에 유용하다.
푸시 알림 디자인에 참고하면 좋을 아티클 : 모바일 푸시 알림 디자인 때 하기 쉬운 5가지 실수
알림의 만료
각 앱들의 만료의 기준 생각해보기알림센터 내에서 알림이 언제까지 보이는지 만료의 기준을 알아보기 위해 대표적인 서비스들을 분석해 보았다. 각 서비스의 알림센터 가장 하단으로 가서 몇 주 전의 알림이 보이는지 확인해보았는데, 천차만별이었다. 위 서비스 외에도 다양한 서비스들은 대략적으로 한 달에서 두 달 정도 전의 알림을 볼 수 있었고, 네이버 블로그 같은 경우는 2주 정도 전의 알림만을 볼 수 있기도 했다.
겉으로만 보아서는 알림이 만료하는 기준을 잡기가 쉽진 않은데, 대략적인 기준을 고려해 봤을 때 페이스북과 인스타그램은 '그룹핑된 알림'이 위주로 좀더 긴 기간의 알림을 확인할 수 있다고 생각했다. 예를 들면, 좋아요를 받은 것이나 새글 알림이 빈번할 경우 이를 하나로 묶어서 한번에 알림을 해주는 것들이다. 반면에 유튜브는 '그룹핑되지 않는 단일 콘텐츠에 대한 알림' 위주로, 기간이 한 달 정도 였다.
알림의 만료 기준은 사실 위와 같이 알림의 그룹핑에 있다거나, 몇 가지 사례로 결론을 내리는 것은 속단이라 생각한다. 특정한 기간을 미리 정하기 보다는 각 서비스에서 알림이 발생하는 빈도 수나 앱 내에서의 알림의 중요성의 비중에 따라 어느 정도 기간의 알림을 보여줄지 설정하는 것이 좋겠다. 이에 우리 앱도 출시 이후 사례를 통해 좀더 디테일하게 고려해보자는 판단이다.
Q5.
알림 클릭 시
화면을 어떻게 보여줄까?
A. 알림센터 내의 각 메세지를 클릭하면 관련된 페이지로 이동 시킨다. 이때 페이지 뎁스를 줄 것인지, 바로 콘텐츠로 이동하는 것이 좋을지 고민이 되어 타 앱들을 스터디해 보았다.
스타벅스 스터디
스타벅스의 알림센터 플로우우리 앱이 지향하는 알림센터의 형태와 유사한 앱 중에서 스타벅스가 있었다. 스타벅스에서는 알림센터 아이콘 클릭 시, 모달 드로어 형태로 알림센터가 등장한다. 각 알림 메세지 중 사용자에게 관련 페이지로 이동을 유도할 경우 '화살표(>)' 형태가 있고, 이를 터치 시 관련된 페이지로 이동하며, 뎁스가 한 번 들어간다. 이는 알림센터 이후 관련 페이지가 덮이는 방식으로 자연스러운 느낌을 준다. 이 때 Back 버튼을 클릭하면, 알림센터의 모달 드로어가 오픈된 상태가 아닌, 홈 화면으로 돌아온다. 이는 알림센터가 하나의 페이지가 아니라 일시적으로 홈 화면을 사이드 일부를 덮은 상태기 때문에, 이 상태로 멈춰 있는 것이 아닌 톡 건드리면 다시 들어가는 형태로 간주했기 때문이라고 생각한다. 이를 참고하여 우리 앱도 알림 항목 클릭 시 하나의 뎁스로 들어가 관련 페이지를 보여주고, Back 클릭 시 원래 본인이 있던 페이지(알림센터는 들어감)로 나오는 플로우로 구상할 수 있었다.
Q6.
알림을 어떻게
효율적으로 보여줄까?
A. 알림의 출처, 즉 소스를 아이콘으로 시각화하여 구분하고, 소스별로 필터링하여 볼 수 있도록 필터 칩과 알림에 대해 바로 설정할 수 있는 어포던스를 제공한다.
알림센터 내의 알림들을 더욱 효율적으로 보여주기 위한 몇 가지 장치들을 고려해 보았다.
알림 설정
우선 상단의 설정 아이콘을 통해 알림 설정을 위한 어포던스를 제공한다. 이 때 설정은 '알림 설정'만 해당하는 것이 아니라, 앱 내의 '일반 설정'으로 향한다. 일반 설정 내에는 알림 설정이 포함되어 있고, 이러한 설정 아이콘은 햄버거 메뉴 내의 설정과 중복되어 나타나는데, 이유는 알림센터 내에서 사용자에게 '설정'에 대한 어포던스(어포던스 디자인=행동유도성 디자인)를 한번 더 제공하여 알림 내에서도 설정이 가능하다는 유도를 위함이다. 이 방식은 스타벅스 앱에서 햄버거 버튼 내 설정과 알림센터 내 설정을 확인해보면 바로 이해할 수 있을 것이다.
필터 칩
알림센터 내에는 여러가지 소스에 대한 알림이 혼재되어 있다. 사용자가 원하는 소스에 대한 필터링을 위해 소스에 기반한 필터 칩을 삽입했다. 이에 대한 아이디어는 GoodUI 14번에서 얻을 수 있는데, 옵션에 대해서 드롭 다운 메뉴로 숨겨서 보여주지 않고, 사용자가 두 번 학습하지 않고 바로 옵션을 선택할 수 있도록 쉽게 보여주기 위함이다.
소스에 아이콘
다양한 앱들의 알림센터를 분석하다 보면, 대부분의 알림 메세지 좌측에 아이콘 또는 컬러로 알림의 유형을 구분해 놓은 것을 볼 수 있다. 이는 단순히 심미적인 이유라기 보다는, 줄글 형태만 있을 때 보다 사용자가 알림의 소스와 메세지를 보다 시각적으로 구분할 수 있다.
Q7.
알림 설정은
어떻게 기획하면 좋을까?
A. 알림 설정은 일반 설정 내의 일부로 포함되어 있으며, 알림의 유형과 각 서비스에 따라 푸시 알림을 설정할 수 있다.
네이버 카페 스터디
네이버 카페의 알림 설정무수한 앱들 중에서 네이버 카페의 설정 구조가 우리의 앱과 비슷한 점이 있어 참고해 보았다. 알림 설정을 일반적으로 푸시 알림에 대한 설정이며, 이 때 푸시 알림을 전체 on/off 할 수 있는 토글 버튼이 있고 하위 항목은 알림 메세지의 유형이다. 이를 쉽게 구분할 수 있는 기준은, 앞에서 알림 메세지들을 브레인 스토밍하고 유형화할 때의 알림의 유형을 이용하면 된다.
알림 메세지의 특성 유형화다시 한번 살펴보면, 알림들 중에서 '푸시 알림'이 해당되는 '알림 유형'을 알림 설정에 넣으면 된다. 예를 들면, 새글 알림형 / 답변 or 피드백 알림형 / 프로모션형의 알림에 푸시 알림이 작용한다면 알림 설정의 항목에 이를 제어할 수 있도록 하는 것이다. 이 과정을 통해 초반의 알림의 종류를 스프레드시트에 정리한 것이 도움이 많이 된다는 걸 실감했다.
적용하기
우리 앱에서의 알림 설정푸시 알림에 대한 설정을 알림의 카테고리별로 할 수 있으며, 카테고리 클릭 시 카테고리 내에서의 해당 서비스들의 푸시 알림도 개별 제어할 수 있다.
What we've learnt.
알림의 필요성에서 부터 출발하여 알림의 유형과 모델, 설정 방식까지 총체적인 플로우를 고려해보면서 우리가 편하게 사용했던 앱에서의 한 부분은 실제로 깊은 베이스를 토대로 만들어진 것이란 걸 절실히 깨달을 수 있었다. 이미 나온 데이터를 기반으로 기획을 하는 것이 아닌, 가상의 시나리오를 토대로 구상한다는 것이 쉽진 않았지만 함께 배워가며 스스로의 폭을 넓힐 수 있는 과정이었다. 아직 알림의 플로우가 완성된 것이 아니라, 또 빈틈을 채우고 디벨롭 해야 하겠지만, 전체적으로 짚어보았다는 것에 의의를 두고자 한다. 이번 과정을 토대로, 앞으로의 다른 부분에서도 좀더 논리적인 기획과 디자인을 할 수 있길 기대해 본다.
* 이 글은 미디엄에서 영문으로도 확인하실 수 있습니다. :)
