바닥부터 시작하는 UX 스터디 02
UX 견습생의 User Inyerface 웹페이지 뜯어보기: 두번째 화면
지난번 포스팅에서는 화면에서 가장 중요한게 메세지의 명확성이라는 이야기를 했다. 사용자들은 사려깊게 웹을 훑어보지 않고 눈에 띄는 요소를 따라서 화면 이곳 저곳을 건너 뛰기 때문에, 자연스럽게 사용자의 시선을 유도할 수 있는 시각적 계층구조가 잘 짜여져 있어야 한다.
하지만 때로는 자연스러움보다 강제성이 필요할 때가 있는 법이다. 모든 사용자들을 자연스럽게 유도할 수 있다면 얼마나 좋을까? 하지만 언제나 예외가 발생한다. 왜냐하면 모든 사용자들이 항상 시키는 대로 하지는 않기 때문이다. 길을 만들어도 굳이 잔디밭을 가로지르는 사람들이 있다. 목적에 따라 사용자에게 반드시 보여주고 싶은 메세지는 어떻게 전달할 수 있을까?
팝업창은 그런 고민이 있을 때 사용할 수 있는 멋진 해결책 중 하나다. 하지만 이 멋진 해결책은 양날의 검이기도 하다. 인터넷 기사를 보러 들어갔더니 닫기도 까다로운 팝업창으로 시야를 방해받았던 기억을 떠올려 보자. 하루에 한 개 이상의 웹사이트와 애플리케이션 및 기타 서비스 기기들을 마주하고 사는 현대인들에게 팝업창은 여름날 밤의 모기만큼 익숙하면서도 짜증스러운 존재이다.
사용자를 고민하게 하지 마라.
팝업창의 사례에서 금방 유추할 수 있겠지만 사용자는 인내심이 많지 않다.(아닌 사용자가 있을 수도 있지만 나를 포함해서 대부분은 그렇다.) 사용자는 마음먹은 과제를 가장 빠르고 효율적으로, 고민 없이 진행하기를 원한다. 그렇기 때문에 과제 수행 도중에 지속적으로 방해받게 된다면 해당 페이지에 대한 부정적인 인상을 가지고 그곳을 떠날 가능성이 높다. 따라서, 화면을 구성할 때는 사용자를 오래 고민하게 하면 안 된다. 고민의 시간이 길어질 수록, 사용자는 점점 사이트에 대한 호감을 잃기 때문이다.
우리가 웹 사이트에 호감 저장고를 가지고 들어간다고 상상하는 방법을 활용하면 좋다. 사이트에서 문제를 마주할 때마다 저장고의 비축량이 줄어든다...(중략)...여기서 핵심은 모든 사람의 저장고가 매우 클 것이라고 기대해서는 안 된다는 점이다.(스티븐 크룩,사용자를 생각하게 하지마!,181-183p)
User Inyerface 웹사이트는 시작 화면에서 사용자에게 "제한 시간 안에 주어진 양식을 채워야 한다"라는 과제를 주고 있다. 이 과제를 보고 다음 화면으로 넘어간 사용자는 주어진 양식을 채운다는 작업을 수행하고자할 것이다.
그렇다면 User Inyerface의 다음 화면은 어떨까? 사용자가 이용하기 편할까?
User Inyerface 두번째 화면첫 화면이 괜찮아 보였던 사람이라도, 누구나 이 화면을 보면 이 웹사이트가 어딘가 잘못되어있음을 바로 깨달을 수 있을 것이다. 불타는 붉은색의 팝업창과(경고문인가?) 영문을 알 수 없는 애니메이션, 그리고 우측 하단에 가증스럽게 튀어나와있는 문의창이 시선을 사로잡는다. 이 요소들은 실제로 사용자가 과제에 집중할 수 없게 만드는 깜찍한 친구들이다. 게다가 이게 전부가 아니다.
User inyerface 두번째 화면 2화면을 배회하며 1분 쯤 시간을 보내다 보면, 갑자기 또 다른 팝업이 튀어나와 인내심을 깎아먹는다. 이와 같이 두번째 화면에서는 시작 화면보다 다양하고 정신없는 요소들을 만날 수 있다. 하지만 크게 보았을 때 이 화면의 구성요소는 아래와 같다.
폼 양식 요소: 사용자가 수행해야하는 과제와 연관됨
팝업창: 웹사이트가 전달하고 싶은 그 외 정보들
양이 제법 많기 때문에, 이번 포스트에서는 이 두 가지 요소 중 갑자기 튀어나와 사용자를 당황하게 하는 팝업창들을 중심으로 이야기하고자 한다. 이 화면에서 팝업창들은 공통적으로 사용자를 고민하게 함으로써, 과제 수행을 적극적으로 방해하고 있다는 문제를 가지고 있으며, 이는 세부적으로 다음과 같은 요소에 의해 이루어진다.
관습을 따르지 않음
부적절한 모달 창 사용(종류 및 등장 시점)
불필요하거나 명확하지 않은 단어 사용 및 정보 제시
팝업의 종류
본격적으로 각 요소를 뜯어보기 전에, 팝업에 대해서 알아보도록 하자. 우리가 팝업(혹은 오버레이, 팝오버라고 부르기도 한다.)이라고 부르는 요소는 크게 두가지 차원으로 나눌 수 있다.
1. 사용자가 팝업 창 외의 화면에 상호작용할 수 있는가?
그렇다 (O) → 모달리스(modeless/non-modal)
그렇지 않다 (X) → 모달(modal)
2. 배경이 흐리게 표시되는가?
그렇다 (O) → 라이트박스(lightbox)
그렇지 않다 (X) → 특별한 명칭 X
(닐슨 노먼 그룹, Popups: 10 Problematic Trends and Alternatives)
이 기준에 따라 User Inyerface의 해당 화면을 살펴보면, 두개의 모달리스 창과 한 개의 모달 창을 가지고 있다는 사실을 알 수 있다.
User Inyerface 두번째 화면의 팝업이 화면에서 ①과 ③은 모달리스 창이고, ②는 모달 라이트박스이다. 그렇다면 이제 본 화면의 팝업들이 갖고 있는 문제점을 알아보자.
관습을 따르지 않음
우선, 본 화면의 팝업들이 가지고 있는 가장 큰 문제는 사용자가 당연히 그럴 것이라고 생각하는 관습을 따르지 않는 데 있다. 이 문제는 시작 화면에서도 발견되었던 문제이기도 하다.(사용자의 기대를 배신하는 액션 설계)
User Inyerface 모달리스 창 상호작용사용자는 과제 수행 중에 방해받기를 원하지 않는다. 따라서 자연스럽게 화면을 산만하게 하는 원인이 되는 팝업창들을 정리하려고 하게 된다. 그럴 때의 사용자의 움직임을 상상해 보자. 화면에는 시각적 노이즈인 모달리스 창이 두 개 떠 있다. 사용자는 우선 ①의 "예" 버튼을 누르고, ②의 "접기" 화살표를 눌러서 각각의 창을 닫기를 시도한다. 그러나 기대와는 달리, ①의 버튼은 작동하지 않고 ②는 아래로 접히기는 커녕 콩나물마냥 자라난다.
User Inyerface 라이트박스 상호작용이러한 문제는 라이트박스에서도 마찬가지이다. 1분이 지나 해당 팝업이 등장했을 때 사용자는 진행하던 과제를 계속 수행하고자 하는 욕구가 있으므로, 바로 우상단을 눌러 창을 닫거나 녹색 버튼을 눌러 메세지를 확인했다는 제스처를 보내려고 할 것이다. 대부분의 화면에서 "닫기" 버튼은 우상단에 있고, 녹색은 확인이나 동의 등 긍정적인 제스처를 나타내기 때문이다. 그러나, User Inyerface는 그렇지 않다. 습관적으로 우상단을 누르면 팝업창이 전체화면을 메우고, 녹색 버튼을 누르면 창이 꿈쩍도 않고 잠겨 버린다. 그제서야 내가 뭘 누른 건지 버튼을 확인하면 각각 화면 확대와 잠금 버튼인 것을 깨닫게 된다.
사용성을 위해서 관습을 따르는 것은 편리하지만 이러한 관습이 절대적인 것은 아니다. 때로는 웹사이트의 개성이나 보다 나은 명확성을 위해서 기존의 관습을 버려야 할 때도 있다. 하지만 다수에게 익숙한 방식은 오랜 시간동안 걸쳐져서 만들어진 일종의 사회적 합의와도 같은 것이다. 단순히 참신함 때문에 남들이 의자라고 부르는 것을 혼자 책상이라고 이름붙인다고 생각해보자. 얻을 수 있는 이익에 비해 감수해야 할 불편함이 너무나 많다.
관습을 따르지 않은 것들User Inyerface에서 새롭게 정의한 규칙은 다음과 같다. 사용자는 이 세가지 팝업을 닫기 위해서 각각 위 이미지의 ①,②,③을 눌러야 한다. ①은 버튼임에도 옆의 버튼과 일관성이 없는 데다 불필요한 단어들을 사용하고 있어 혼란스럽고, ②는 카피라이트표시로 위장하고 있는 데다, ③은 얼핏 보면 평범한 전송 버튼처럼 보이나 사실은 (밑으로)보내기 버튼이다. 그마저도 누르면 환장할정도로 느린 속도로 접힌다.
일반적인 관습에 익숙해 있는 사용자는 이 사실들을 알아내기 위해서 화면에서 오랫동안 고민해야 하고, 결국 과제 수행 시간은 지연되고 만다. 그러다가 또 1분이 지나서 모달 창이 등장하면? 으, 상상도 하기 싫다.
부적절한 모달 창 사용(유형 및 등장 시점)
User Inyerface: 모달 창(해당 모달 창은 라이트박스로 분류된다.)사실 모달 창은 원래 바로 사용자의 작업이 필요한 오류 상황이나 시스템에 관련된 중요한 정보를 알리기 위한 목적으로 사용된다. 그렇기 때문에 주로 화면에서 시선이 모이는 중심에 배치되며, 즉각적으로 사용자의 관심을 끌 수 있다는 장점이 있다. (닐슨 노먼 그룹, Modal & Nonmodal Dialogs: When (& When Not) to Use Them) 글 처음에서도 언급했지만, 이러한 특성으로 인해 팝업은 약간의 강제성을 가지고 사용자에게 효과적으로 원하는 메세지를 전달할 수 있다.
하지만 편리하다고 모달 창을 아무 때나 남용해서는 안 된다. 모달 창은 사용자가 배경 컨텐츠를 컨트롤 하지 못하게 막기 때문에 사용자의 작업 흐름을 끊을 수 있기 때문이다. 미국의 UI/UX 컨설팅 회사 닐슨 노먼 그룹의 "모달/모달리스 대화 상자는 언제 사용해야할까?" 라는 글에서도 사용자의 현재 작업과 관계 없는 정보로 모달 창을 사용하지 말라고 지적하고 있다.
모달 창은 사용자가 원래 진행하던 작업에서 벗어나게 합니다. 모달 창으로 인한 간섭은 사용자가 대화 상자를 처리하고 다시 원래 작업으로 돌아가는 데에 추가적인 시간과 노력을 낭비하게 만듭니다.
(닐슨 노먼 그룹,Modal & Nonmodal Dialogs: When (& When Not) to Use Them)
User Inyerface에서 사용하고 있는 모달 창은 화면의 타이머가 1분을 넘길 때마다(!) 등장한다. 시험 시간 5분 전 알람처럼 친절하지만, "가능한 빨리 양식을 채워야 한다"는 과제를 가진 사용자에게 있어서는 한창 화면에서 분주한 와중에 끼어들어 작업 흐름을 방해하는 요소밖에 되지 않는다. 특히 모달의 경우 사용자가 상호작용하기 전까지 다른 컨텐츠에 접근할 수 없게 강제하기 때문에 더욱 나쁘다. 게다가 이미 화면에 바로 확인가능한 타이머가 존재하는데 또 다른 타이머를 모달로 띄우는 것은 비효율적이다. 굳이 별도의 창을 사용하지 않아도 사용자는 화면을 통해 시간의 흐름을 알 수 있다.
불필요하거나 명확하지 않은 정보 제시
뿐만 아니라 단어 사용에 있어서도 User Inyerface의 팝업들은 사용자를 혼란스럽게 하는 지점이 존재한다. 사용자에게 메세지를 명확하게 전달하기 위해서는 시각적인 설계도 중요하지만 명확하고 간결한 언어를 사용하는 것도 중요하다. 물론 아무리 깔끔한 언어를 사용해서 메세지를 전달하더라도 사용자에게 필요한 정보가 아니면 아무런 소용이 없다.
필요하지도 않거나 명확하지도 않은 정보들User Inyerface의 팝업 ①,②는 이 부분에서 문제를 가지고 있다. ①의 쿠키 사용에 관한 팝업부터 살펴보자. 사이트가 쿠키를 사용하는 데에 동의하는지 사용자에게 묻는 부분은 개인정보와 연관되어 있다. 그렇기 때문에 이용목적과 용도를 명확하게 안내해주어야 한다. 그러나 이 쿠키 팝업은 "이 사이트는 쿠키를 사용합니다. 문제 있나요?" 라고만 말하고 있다. 쿠키가 뭔지도 모르는 사용자는 이 내용을 보고 웹페이지가 자신에게 정보를 숨기고 있다는 인상을 받을 것이다.
동의 버튼 옆의 동의하지 않음 표시도 마찬가지이다. "아니다"라고 명확하게 표시하지 않고 부정문을 두개 사용하여 사용자를 혼란스럽게 한다. 아니다인 것인지, 동의하지 않는 것이 아닌지 애매하게 읽힐 여지가 있기 때문이다. 때문에 쿠키나 위치 정보와 같이 민감한 정보를 사용자에게 요청할 때에는 사용자에게 충분히 명확하게 설명할 필요가 있다.
②의 문의 팝업 또한 비슷하다. 문의를 요청하는 창에 "문의(help)" 링크가 중복되어 들어가 있어 무엇을 전달하는 것인지 용도를 바로 유추하기 어렵다. 문의 방법에 대해서 안내하는 것인가 싶어 눌러보면 "현재 몇명이 대기중이니 기다리세요."라는 뜬금없는 메세지가 튀어나온다. 이 메세지는 현재 이 페이지의 사용자와 아무런 관계가 없다. 사용자가 필요한 정보도 아니다. 결국 사용자는 필요도 없는 링크의 용도를 고민하고 눌러보느라 아까운 작업 시간을 소모하게 된다.
HOW TO: 사용자를 고민에 빠뜨리지 않기
그렇다면 이 팝업들은 어떻게 개선할 수 있을까?
1. 화면 설계 시 관습을 따른다.
관습이 만능은 아니지만 사용자는 늘 효율적인 루트를 원한다. 모두가 YES 일때 혼자 NO인 요소가 많으면 많을 수록 사용자의 고민만 늘어나게 된다. 결과적으로 과제 수행이 점점 지연될 테니, 사용자는 짜증내면서 웹사이트를 꺼버릴 것이다. 따라서 엄청나게 획기적으로 사용성을 개선시키는 요소가 아니면 그냥 일반적인 관습을 따르는 편이 낫다.
2. 모달 창 사용 시점과 형식을 적절하게 선택한다.
현재 화면에서는 적절하지 않은 방식으로 모달 창이 사용되고 있다. 모달 창은 사용자의 작업 플로우를 방해할 수 있는 치명적인 실수가 될 수도 있다. 정말로 필요한지 아닌지 판단하여 더 알맞은 형태로 바꾸도록 한다.
3. 사용자가 알아야 하고 필요로 하는 정보를 명확히 제시한다.
현재 User Inyerface 화면에서는 사용자에게 필요하지 않은 정보나 불명확한 정보들이 주어지고 있다. 이를 정리하고 사용자에게 전달되어야 하는 메세지를 깔끔하고 간결하게 제시한다.
User inyerface 팝업창 수정안상단에서 너무 많은 면적을 차지하는 데다가 불타는 빨간색으로 인해 주의를 산만하게 했던 쿠키 팝업창을 하단으로 내렸다. 물론 화면 위쪽에 쿠키 요청 오버레이를 배치하는 사이트도 많이 있다. 그러나 User Inyerface의 경우, 해당 팝업을 상단에 배치하면 사용자의 시선이 폼 양식이 아니라 쿠키 창으로 이동해 작업 수행에 지장을 주는 것처럼 보인다. 따라서 사용자가 화면 중앙에 집중할 수 있도록 위치를 옮기고 크기를 조정해서 양식폼을 가리지 않도록 주의했다.
User Inyerface 쿠키 팝업창 수정안기존에 "이 사이트는 쿠키를 사용합니다, 문제있나요?" 라고 적혀있던 성의없는 문장 대신에 수집한 쿠키를 어떻게 사용할 것인지 명확하게 밝히고 동의 방법에 대해서 안내했다. 또한 어디를 눌러야 할 지 혼란스러웠던 버튼 또한 녹색을 사용하고 "동의함"이라고 이름을 붙여 사용자가 헷갈리지 않도록 했다.
User Inyerface 문의 팝업창 수정안우측의 문의 팝업에 대해서는 접기 버튼과 전송 버튼을 익숙한 형태로 수정했다. Help 링크는 해당 팝업을 이용하는 사용자가 필요로 하는 요소가 전혀 아니기 때문에, 해당 링크는 FAQ 링크로 바꾸었다. 문의 창에서 작업하게 될 사용자가 가장 궁금하고 필요로 하는 것이 무엇일까? 자신이 직면한 문제를 빨리 해결할 수 있는 방법이다. 근처에 자주묻는 질문을 확인할 수 있는 링크가 있다면 일부 문제는 문의 작성 후 전송이라는 번거로운 작업을 거치지 않고도 해결할 수 있을 것이다.
마지막으로 1분 간격으로 등장하는 모달 창의 경우, 이미 화면에서 타이머가 확인 가능한 상황이다. 굳이 알림을 모달로까지 만들어서 정성스럽게 사용자를 엿먹일 필요는 없다. 게다가 '5분 안에 양식을 채우세요' 같이 제한시간이 있는 형태의 과제가 아니기 때문에 일부러 시간이 가고 있다는 경고문을 별도로 표시할 필요성이 높지는 않다.
User Inyerface 타이머 경고안내 제안물론 그래도 재촉 알림을 보내고 싶다면 방법이 아주 없는 것은 아니다. 이런 식으로 일정 시간이 지나면 타이머 밑에 경고 문구를 띄움으로써 사용자에게 시간이 가고 있음을 알릴 수 있다. 뿐만 아니라 타이머 색상의 점진적인 변화나 깜박거림 등의 애니메이션을 사용하면 시간이 많이 지났다는 것을 더 강조할 수도 있다.
Comment from DD Kim(UX Designer)
쓸데없이 경고 느낌 나는 빨강을 탈피한 것은 매우 잘한 일이지만, 여전히 팝업창 두개가 입력해야 하는 폼이랑 비슷한 정도로 눈에 띄는 것 같다. 그러면 과제 항목은 가운데에 있는데 양 옆에 팝업이 있어서 결국 시선이 분산되거든. 게다가 지금 상태라면 화면 사이즈가 바뀌었을 때 입력 폼을 방해할 가능성도 있어. 이를 고려해서 레이아웃 재배치나 색 조정이 더 필요할 듯 해.
그리고 이건 개인적인 의견이지만, 문의 입력창이 처음부터 꼭 열려있어야 할까? '어떻게 도와드릴까요?' 문구만 깔려 있거나, 아이콘의 형태로 존재하다가 사용자가 필요할 때 눌러서 불러와도 될 텐데. 한번 생각해보자.
※ 본 연구 포스트는 Bagaar로부터 웹사이트 내용 게재 허락을 받았습니다.
User Inyerface 웹사이트: http://www.userinyerface.com
※ 화면 팝업 관련 참고문헌
https://www.nngroup.com/articles/modal-nonmodal-dialog/
https://www.nngroup.com/articles/popups/
https://www.nngroup.com/articles/overuse-of-overlays/
