잘못 사용하고 있는 유행 UX 패턴
[번역] 많이 쓰이는 만큼 잘못 쓰이고 있는 대표적인 UX패턴
이 문서는 Medium에서 Zoltan Kollin이 작성한 "Misused mobile UX patterns"을 번역한 글입니다. 아마추어 번역가입니다.
당신이 경험 디자이너라면 다른 이들에게 영감을 받는 것이 UI 디자인을 그대로 카피하는 것이 아니라는 것에 동의할 것이다. 대신 모범 리서치 사례를 보는 것이다. 디자인 패턴을 이용하는 것이다. 또한 가이드라인을 따르는 것이다. 사용성 높은 인터페이스를 만들기 위해 유저가 익숙한 패턴을 이용하는 것이다.
어떤 사람들은 가이드라인과 다른 사람을 따르는 것이 창의력을 죽인다고 믿는다. 결국 모든 앱이 똑같아지기 때문이다. 하지만 UX 관점으로 보자면 나는 다른 문제를 발견한다. 가장 “모범 사례”을 쓰는 것에 익숙해지다 보면 Google / Facebook / Instragram/ [당신이 좋아하는앱] 이 항상 맞다고 생각할뿐더러, 당신의 디자인 목표가 그들의 목표가 같다고 착각하고, 그것에 대해 비판적으로 생각해볼 기회를 빼앗기기 때문이다. 그래서 나는 모범사례라고 여겨져 왔지만, 그래서 더욱더 신중해야 할 몇 가지 UX 패턴들에 대해 이야기해보겠다
1. 숨겨진 내비게이션
햄버거 메뉴에 관한 글들은 수없이 많다. 대부분은 디자이너들이 햄버거메뉴를 반대하는 글 이리라 생각된다. 처음 듣는 얘기라고? 이 글(첫 번째)과 이 글(두 번째)을 읽어보면 알 수 있다. 요약을 해보자면 아이콘 자체에 대한 거라기보다는 내비게이션을 아이콘 뒤에 숨기는 것이 문제라고 말할 수 있다.
이런 방법은 디자이너들을 꾀나 잘 유혹한다: 제한된 스크린에 대한 걱정을 덜어주고, 전체 내비게이션을 스크롤 가능한 오버레이로 만들어 숨긴 상태를 디펄트(default)로 만들기 때문이다.
하지만 많은 실험 결과가 메뉴 옵션을 노출시켜주는 것이 연대성을 높여주고 유저 만족도, 그에 따른 이익까지도 높여준다고 한다. 이 때문에 많은 앱의 대가(big players)들은 '햄버거메뉴'로부터 연관성 있는 메뉴로 구성된 항상 눈에 보이는 '내비게이션 옵션'으로 옮겨가고 있다.
YouTube navigation change annotated by Luke Wroblewski2. 넘쳐나는 아이콘들…
제한적인 스크린 공간 때문에 텍스트를 아이콘으로 대체하기도 한다. 픽토그램은 더 적은 양의 공간을 차지하고, 번역될 필요도 없을뿐더러, 사람들이 익숙하기까지 하니... 얼마나 좋은 옵션인가? 게다가 남들도 그렇게 한다.
하지만 이런 추측은 유저들이 아이콘 뒤로 숨겨진 '기능'을 발견할 수 없게도 만든다. 당신이라면 밑의 이 아이콘을 누르면 바로 메세지 보내기 기능이 있다고 쉽게 짐작할 수 있을 것인가?
Instagram아니면, 만약 당신이 “Google Translate”을 한번도 사용하지 않았을 때 아래의 픽토그램을 본다면 어떤 기능인줄 정확히 알 수 있을 것 같은가?
우리는 유저가 추상적이고 애매모호한 픽토그램에 익숙해져 있거나, 이것이 무엇인지를 발견하고 배우기 위해 추가적인 시간을 쓸 의향이 있다고 착각하는 오류를 범하곤 한다.
Mysterious tab bar on Bloom.fm만약 아이콘이 적당한 텍스트 라벨이 있어야 사용하기 편리하다면, 이는 잘못된 사용인 것이다. 당신이 아무리 Forsquare 같이 유명한 앱이라 해도 당신의 유저는 ‘배워야’ 하기 때문이다.
Icon hint in Swarm app아이콘을 아예 쓰지 말라는 것이 아니다. 유저가 이미 잘 알고 있는 아이콘들은 엄청 많다 – 보통 공통적으로 쓰이는 ‘검색, 비디오 플레이, 이메일, 설정’ 등과 같은 기본적인 것들 말이다.(하지만 여전히 유저는 ‘하트’ 아이콘을 누르면 어떤 일이 벌어질지 확실히 알지 못한다)
어떤 아이콘들은 대부분의 유저들이 쉽게 알아볼 수 있고 '보편적'으로 여겨진다복잡하고 추상적인 기능은 항상 적당한 텍스트 라벨과 함께 보여야 한다. 그런 경우에는 아이콘이 메뉴 아이템을 쉽게 발견하게 해줄뿐더러, 꽤나 잘 된 마무리를 해주고 당신의 앱에 개성을 더해줄 것이다.
Pixelmator navigation기본적인 기능들은 아이콘을 통해 효과적으로 전달될 수 있지만 복잡한 기능들은 텍스트 라벨이 있어야 한다. 또한 아이콘 사용시에는 반드시 Usability Test를 거쳐야 한다
3. '제스처' 내비게이션
2007년 애플이 아이폰을 선보였을 때 멀티터치 기술은 각광을 받았고, 유저는 포인트와 탭뿐만 아니라 줌인(zoom-in)하고 핀치(pinch)하고 스와이프(swipe) 할 수 있다는 사실도 깨달았다. 제스처는 단연 디자이너들 사이에서 유명해졌고, 많은 앱들이 제스처 컨트롤을 가지고 여러가지를 실험하기 시작했다.
Gesture navigation in Clear app내비게이션과 아이콘을 텍스트 라벨로 대체하여 숨기는 것처럼 제스처 역시 제한된 스크린에 많은 기능을 구현해야 하는 디자이너를 솔깃하게 하곤 한다. (예를 들어... “Delete 버튼이 없어야 해, 사람들은 왼쪽으로 스와이프 할 거야. 아니면 오른쪽으로라도. 일단 해보고 결정하자”)
제스처에 대해 주의해야 할 점은 '숨겨져' 있다는 것이다. 사람들은 항상 기억해내야 한다. 햄버거메뉴의 케이스처럼 말이다: 옵션을 숨긴다면, 사용하는 사용자도 줄어들 것이다. 또한 제스처는 아이콘과 같은 문제를 가지고 있다: tapping, zooming, scrolling 같은 일반적으로 유저들이 이해하는 제스처가 따로 있고, 이가 아니면 유저가 스스로 발견하고 배워야 한다는 점이다. 불행히도 대부분의 많은 앱들에서 쓰이는 제스처는 정해진 일반적인 규범이나 일관성이 없다 – 여전히 인터페이스 디자인에서 새로운 분야이기 때문이다. 이메일에 쓰이는 Swiping 같은 간단한 제스처라도 메일 앱마다 다 다르게 쓰일 수 있다.
애플 메일 / 오른쪽으로 스와이핑 = "읽지않음 표시(Mark as Unpread)"
메일박스 / 오른쪽으로 스와이핑 = "보관하기"디바이스를 흔드는 식의 제스처 역시도 iOS의 “취소하기 (Undo)”와 Google Maps의 “피드백 보내기” 기능을 둘 다 가지고 있다. 같은 제스처라도 다르게 사용된다는 것을 기억하라.
제스처는 항상 숨겨진 작동기능이고, 유저 입장에서 이를 기억하는 것은 엄청난 노력이라는 것을 잊지 말아야 한다. 만약 Tinder 앱이라면, 오른쪽으로 스와이프 하는 것이 어떤 기능을 하는지 전 세계한테 가르쳐줄 수도 있을 테지만, 이는 Tinder특성상 스와이프 기능이 앱의 ‘콘셉트’이기 때문에 효과적으로 쓰인 것이다.
4. 튜터 오버레이 타입의 온보딩 (Tutor overlays as Onboarding)
최근 핫한 UX토픽인 온보딩(onboarding)은 유저와 앱의 첫만남에 대한 것이다. 많은 경우에 단순히 오버레이 튜터리얼을 통해 사용자에게 앱의 인터페이스에 대하여 소개해주는 것을 뜻한다:
Discovery 앱의 코치마크왜 이게 나쁜 걸까? 유저는 보통 도입 부분으로 스킵해버리기 때문이다. 그들은 바로 앱을 사용해보길 바란다. 또 튜터리얼을 보더라도, 오버레이를 닫자마자 '뭐였지?'하고 잊어버릴 확률이 다분하다. (특히 스크린이 정보로 꽉 찼을 때). 그리고 마지막으로 중요한 점은 인터페이스에 코치 마크(coach marks)를 추가한다고 해서 더 이해하기 쉬워지지는 않는다. 이것을 기억하라:
유저 인터페이스는 '농담'과 비슷하다. 굳이 설명이 필요하다면, 그다지 재밌는 농담이 아니다
온보딩 플로우를 유저가 더 유용하게 사용할 수 있도록 만들 여러 가지 디자인 방법들은 많다. 예를 들어 Slack 은 첫 스크린을 전체 앱의 콘텍스트의 이해를 돕는 데 사용한다. 스크린이나 기능을 설명하는 대신 간단히 자신을 소개하고 유저들이 받을 수 있는 ‘혜택’에 대해 말한다.
더 인터렉티브하게 첫 유저의 참여시키기 위해서는 더 진보적인 온보딩(Progressive Onboarding)을 사용할 수 있다. Duolingo는 앱이 어떻게 사용되는지 설명하지 않는다: 유저가 직접 해보고 선택한 언어를 계정 등록하지 않고도 빠르게 테스트해볼 수 있게 한다. 사람들은 ‘하면서 배우기 때문이다.’ 게다가 이는 진정한 앱의 ‘가치’를 보여주는 한층 더 매력적인 방법이다.
위에서 언급한 스와이프 제스처가 Mailbox에서 Apple mail과 어떻게 달랐는지 기억하는가? Mailbox는 이를 인지하고 진보적 온보딩(Progressive Onboarding)을 이렇게 사용하였다: 유저는 시작하기 전 ‘리허설’과 같이 특정한 제스처를 직접 시도하고 이해할 기회를 갖게 될 수 있는 것이다.
반 투명의 코치 마크(coach marks)를 디자인하기 전에, 잠시 멈춰 유저의 첫 사용자 경험이 어때야 할지 잘 생각해보아라. 문맥(context)에 맞는지에 초점을 맞춰야 한다. 대부분의 경우 유저를 반길 수 있는 더 나은 방법들이 있을 것이다.
5. 창의적이지만 직관적이지 않은 ‘Empty states’
경험이 부족한 디자이너들들은 empty states를 쉽게 무시하지만, empty states는 전체적인 앱의 사용성에 막대한 영향을 끼치는 요소이다. 또 어떤 디자이너들은 에러 메세지나 Empty States를 빈 캔버스로 여겨 창의적인 예술활동을 할 기회로 보기도 한다.
밑에 이 구글 사진(Google Photos)에서의 empty state를 살펴보자. 처음 봤을 땐 뭔가 대단해 보이지 않는가? 가이드라인에 따라 잘 짜인 레이아웃에, 멋진 그래픽까지 있다.
하지만 두 번째로 봤을 때는 이상한 점을 발견한다:
1. 왜 컬렉션이 없는데 찾기(search) 버튼이 눈에 띄는 걸까? 아무것도 없는데 무엇을 찾으라는 건가?
2. 눈에 띄는 이미지는 탭이 불가능하다. (왠지 많은 사람들이 시도해볼 것 같은데도 말이다)
3. 텍스트에 ‘+’ 플러스 사인을 눌러 앨범, 스토리를 추가해보라고 적혀있는데, 이는 굉장히 어색하다. 왜 텍스트 내에서 ‘+’ 플러스 사인 버튼을 바로 누를 수 있게 하지 않았는가? 이는 마치 “계속하기 위해서는 계속하기 버튼을 눌러라”와 비슷하다. (그냥 계속하기 를 버튼을 합치거나 옆에다 배치한다면 간단한 것 아닌가?)
간단히 말하면, 사실상 위의 empty state는 유저가 문맥을 이해할 수 있도록 돕지 않았다:
1. 컬렉션은 무엇인가? 유용한가?
2. 왜 나는 컬렉션이 없나?
3. 어떻게 해야 만들 수 있을까? (만들어야 한다면 말이다)
창의성만큼은 적은 게 많은 것일 수도 있다. 밑의 empty state 예시는 사용성에 있어서 굉장히 잘 되어있다. (텍스트에 ‘이제 밑의 버튼을 탭 하세요' / Now tap the button below’라는 말이 없다면 더 좋았겠다만...)
Lootsy 의 Empty stateEmpty states (웹상에서의 404페이지와 비슷한)는 심미적인 요소나 브랜드 개성에 대한 것만은 아니다. '사용성'에 영향을 미치는 중요한 역할을 하고 있다.
직관적으로 디자인하라.
마지막으로... 모든 것에 대해 의문을 가져라
오해는 없길 바란다 - 디자인 패턴과 모범사례들은 여전히 우리의 친구이다. 하지만 사용자들 뿐만 아니라 각각의 앱들마저도 다른 성격과 목적을 가졌다는 것을 잊지 말아야 한다. 한 가지의 성공사례는 어떤 앱에서는 성공적일 수 있지만 당신의 앱에는 실패 요소가 될 수 있는 것이다. 한 가지가 모든 것에 다 맞춰질 수 있는 것이 아니다. 게다가 당신은 그 앱이 왜 그렇게 디자인되었는지 잘 모르지 않는가?
당신만의 생각, 당신만의 디자인, 그리고 당신만의 시험을 해보아라.
재어보고, 테스트해보고, 입증하고 – 타당하다고 생각되면 가이드라인을‘따르지 않는 것’, “unfollow”하는 것을 두려워하지 말아야 한다.
<<이 포스트는 Mobile Weekend Budapest에서 발표한 내용과 같다. 슬라이드.>>
