디자인 독학하기 03
UI/UX 디자인 경험을 공유합니다 :)
[Contents]
1_ 양옆 여백(Margin) 정하기
2_ 높이(Heights)와 동작(Action) 정하기
3_ 타이틀(Title) 위치 정하기
4_ 타이틀과 동작의 글씨 크기와 색 정하기
02 내비게이션 바의 인터랙션 디자인
03 내비게이션 바를 활용해 UX 향상시키기 (Ref. 인스타그램)
04 중요 버튼은 내비게이션 바가 아닌 엄지 영역에!
많은 기능과 서비스를 갖추고 있는 슈퍼 앱들 사이에서 단순함을 가장 큰 목표로 하는 '작은 앱'이 사람들에게 어떠한 의미로 다가갈지 연구하는 '작은 앱 프로젝트'를 진행하고 있습니다.
최근 회사에서 사이드 프로젝트로 디자인 시스템을 만들고 있다. 그러면서 애플의 Human interface Guidelines(이하 HIG)과 구글의 머티리얼 디자인(Material Design)을 비교하며 깊이 공부해야겠다는 생각이 들었다.
그동안 애플(아이폰)의 모바일 운영체제인 iOS와 구글의 모바일 운영체제인 안드로이드(Android) 모두를 디자인하고 있었으면서도, 둘의 차이를 거의 신경쓰지 않고 있었다. 통일성을 위해 iOS든 안드로이드든 같은 앱이면 모든 부분에서 같아야 한다고 생각했다. 단지 서로 다른 화면 크기와 비율만 신경썼다.
하지만 놓치고 있는 부분이 있었다. 바로 앱 화면 상단에 있는 '내비게이션 바'다. 내비게이션 바(Navigation Bar)는 상태 바(Status Bar) 바로 아래에 위치한 바다. 상태 바는 모바일 화면 최상단에 위치한 바로 시간이나 네트워크 연결 상태, 배터리 잔량 같은 정보를 보여준다.
문제는 HIG와 머티리얼 디자인에서 제시하고 있는 내비게이션 바의 구조가 다르다는 점이다. 각각의 이름부터가 다른데, iOS(HIG)에서는 내비게이션 바, 안드로이드(머티리얼 디자인)에서는 상단 앱 바(The Top App Bar)라고 한다. 이 글에서는 편의상 '내비게이션 바'로 용어를 통일했다. HIG와 머티리얼 디자인에서는 아래와 같이 내비게이션 바를 설명하고 있다.
・애플 Human Interface Guidelines의 내비게이션 바
A navigation bar appears at the top of an app screen, below the status bar, and enables navigation through a series of hierarchical screens.
앱 화면 상단의 상태 바 아래에 있는 내비게이션 바는 연속된 화면의 계층을 탐색할 수 있도록 합니다.
・구글 Material Design의 상단 앱 바
The top app bar displays information and actions relating to the current screen.
상단 앱 바는 현재 화면과 관련된 정보와 작업을 표시합니다.
It’s used for branding, screen titles, navigation, and actions.
브랜딩과 화면 이름, 탐색, 작업들에 쓰입니다.
It can transform into a contextual action bar.
상황에 따라 다른 동작을 하는 바로 바꿀 수 있습니다.
덧. '상황에 맞는 동작 바(Contextual Action Bar)'는 상단 앱 바와 같은 위치에 있지만 상황(화면)에 따라 알맞게 바뀐 바다. 나는 개념을 단순하게 이해하기 위해 이 또한 '상단 앱 바'라 보기로 했다. 이 글에서는 HIG에서 제안하는 내비게이션 바와 같은 위치에 있는 바는 운영체제와 상관없이 모두 내비게이션 바로 용어를 통일했다.
사실 내비게이션 바를 HIG와 머티리얼 디자인에서 제안하는 가이드대로 iOS와 안드로이드 디자인에 차이를 줄 필요는 없다. 가이드를 따르지 않아도 되는 이유가 명확하다면 굳이 따르지 않아도 된다. 가이드는 가이드일 뿐이다.
하지만 나는 사용자가 익숙한 구조는 익숙하게 디자인하는 게 사용자 경험(UX) 관점에서 아주 중요하다는 결론을 내렸다. 다양한 앱들의 내비게이션 바를 관찰해 보니, 많은 경우에 각 가이드에 따라 내비게이션 바를 디자인한 걸 발견했기 때문이다. 특히 각 운영체제에서 기본적으로 제공하는 앱들은 철저히 가이드를 따르고 있었다. (덧. 운영체제 상관 없이 내비게이션 바를 완전히 똑같이 디자인한 앱도 꽤 많았다.)
iOS만 오랫동안 써온 사용자에게 안드로이드의 내비게이션 바를 제공하거나, 안드로이드를 오랫동안 써온 사용자에게 iOS의 내비게이션 바를 제공하면 사용자가 조금이나마 불편할 수 있다. 치명적인 문제는 아닐지라도, iOS 사용자에게는 iOS 내비게이션 바를 안드로이드 사용자에게는 안드로이드 내비게이션 바를 제공해야 더 좋은 사용자 경험을 줄 수 있지 않을까?
1_ 양옆 여백(Margin) 정하기
UI/UX 디자이너로 첫 출근을 하던 날 맞닥뜨렸던 문제가 있다. 바로 앱 화면의 양옆 여백(마진, Margin)을 몇으로 할 지였다. 당시에는 모든 화면의 양옆 여백을 20으로 통일하고, 콘텐츠를 크게 보여주고 싶은 화면은 양옆 여백을 12로 하기로 정했다.
시간이 지나면서 '20'이라는 양옆 여백이 가뜩이나 좁은 모바일 화면을 낭비한다는 생각이 들었다. 한편으로는 전체 화면의 여백이 통일돼 있지 않다는 왠지 모를 불편함(?)도 있었다. 그래서 이번에 디자인 시스템을 만들면서 양옆 여백을 모든 화면에서 '16'으로 통일하기로 했다. 16은 시각적으로 답답하지 않으면서도 공간을 낭비하지 않는 여백이라고 봤다.
양옆 여백을 정하면서 내비게이션 바의 양옆 여백도 자연스럽게 16으로 정해졌다. 내비게이션 바는 사용자의 시선이 가장 먼저 가는 위쪽에 있기 때문에, 양옆 여백 기준선의 시작점이다.
덧. iOS의 단위는 pt, 안드로이드의 단위는 dp로, 각 운영체제에서 양옆 여백은 각각 16pt, 16dp다.
여백을 정하면서 많은 앱을 참고하다가 재미있는 점을 발견했다. 그동안 양옆 여백을 화면 전체에서 일정하게 유지하는 게 당연하다고 생각했는데, 그렇지 않은 앱도 꽤 있었던 것. 여백을 일정하게 유지하는 앱이 더 많긴 했지만, 여백을 고정하지 않고 자유롭게 쓰는 앱도 있었다.
고정하면 깔끔하고 정돈된 느낌을 주지만, 딱딱한 느낌을 주기도 한다. 여백으로 디자인의 기준을 명확히 잡기 때문에 무난하고 효율적으로 디자인하기에 좋지만, 들어가는 내용이 많아지면 단조로우면서 복잡해지기 쉽다.
자유롭게 여백을 정하면 말 그대로 자유로우며, 시각적으로 흥미를 끈다. 특별히 보이는 특징은 콘텐츠 사이의 여백을 널찍하게 준다는 점이다. 여백이 적다면 구분된 내용별로 양옆 여백이 달라 정돈되지 않은 느낌을 줄 것으로 보인다. VSCO 같은 사진 앱이나 에어비앤비 같은 여행 앱처럼 감성적인 접근이 필요한 앱에서 자유로운 여백을 활용한다는 점이 흥미롭다.
2_ 높이(Heights)와 동작(Action) 정하기
다음으로 정한 건 내비게이션 바의 높이다. 각 가이드에 따르면 iOS는 44pt, 안드로이드는 56dp로 내비게이션 바의 높이를 제시하고 있다. 기존에 우리 앱의 내비게이션 바의 높이는 56이었는데, 공간을 낭비하고 있다는 느낌이 강했다.
최종적으로 정한 내비게이션 바의 높이는 48이다. 이 높이가 시각적으로 적당하다고 봤기 때문이기도 하지만, 결정적인 이유는 내비게이션 바의 양쪽 끝에 있는 동작 버튼의 '터치 영역'의 최소 크기를 48*48로 정해뒀기 때문이다. 터치 영역과 높이를 맞추니 모든 게 깔끔하게 맞아떨어졌다.
내비게이션 바 양쪽 끝에 들어가는 동작 버튼에는 24*24 크기의 아이콘이 많이 쓰인다. 그런데 크기가 24*24라고 실제 앱에서 사용자가 터치할 수 있는 영역을 24*24로 하면 안 된다. 그렇게 하면 터치 영역이 너무 작아 터치가 잘 되지 않는 문제가 생겨 사용성을 해친다. 나는 2달 전쯤 만들었던 UX 원칙 5가지에 따라 아이콘의 최소 터치 영역을 48*48로 지정해 개발자에게 가이드를 주고 있다.
내비게이션 바의 너비 같은 경우는 다양한 디바이스에 따라 동적으로 바뀌도록 했으며, 양옆 여백과 높이는 각각 16과 48로 고정했다.
3_ 타이틀(Title) 위치 정하기
iOS와 안드로이드 내비게이션 바의 시각적인 차이를 만드는 건 바로 타이틀의 위치다. iOS는 가운데에 있으며, 안드로이드는 왼쪽 끝에서부터 72dp만큼 떨어져 있다.
개인적으로 iOS의 타이틀 위치가 좋다고 생각한다. 내비게이션 바의 왼쪽 동작이 '뒤로 가기'일 때, 안드로이드의 타이틀 위치는 타이틀이 뒤로 갔을 때의 화면을 뜻하는지, 현재 화면을 뜻하는지 헷갈릴 수 있기 때문이다. 내비게이션 바의 왼쪽 동작이 뒤로 가기인 경우가 많아서 안드로이드 사용자는 이 점에서 혼란스러울 수 있다.(덧. 실제로 나는 안드로이드 폰을 쓸 때 이 점이 아주 불편하다.)
한편 iOS는 타이틀이 가운데에 있기 때문에 타이틀이 화면을 대표하는 역할을 해서 사용자가 현재 앱의 어떤 위치에 있는지 분명히 알려준다. 또한 내비게이션 바의 왼쪽 동작이 뒤로 가기일 때는 뒤로 가기 아이콘과 함께 뒤로 간 화면의 타이틀을 적도록 해서, 현재 화면과 뒤로 갔을 때의 화면이 헷갈리지 않도록 한다. 이런 이유로 만약 내가 내비게이션 바를 운영체제에 상관없이 통일한다면 iOS의 가이드에 따라 통일할 것 같다.
안드로이드 가이드에서 제시하는 내비게이션 바만의 장점도 있다. 내비게이션 바의 오른쪽 공간을 더 활용할 수 있다는 점이다. 머티리얼 디자인에서는 최대 3개의 아이콘까지만 넣도록 제안하고 있다. 다만 아이콘이 많아질수록 복잡해진다는 점도 고려해야 한다.
4_ 타이틀과 동작의 글씨 크기와 색 정하기
마지막으로 타이틀과 동작 버튼의 색을 정해야 한다. 타이틀은 디자인 시스템 안의 타이포그래피(Typography)와 색(Color) 시스템에 따라 크기는 17, 색은 #0F0F0F로 정했다. 동작의 글씨 크기는 17로 고정했으며, 색은 경우에 따라 아래와 같이 나눴다. 중요하지 않거나 사용자가 가급적 누르지 않았으면 하는 동작은 회색 계열의 색을 이용해 계층을 나눴고, 일반적인 경우는 타이틀과 같은 #0F0F0F, 중요한 동작의 경우에는 우리 앱의 포인트 색인 주황을 썼다. 비활성화 버튼 같은 경우는 회색 계열인 #DBDBDB로 누를 수 없는 상태라는 걸 사용자가 알 수 있도록 했다.
요즘 인터랙션 디자인에 관심이 많다. UX 디자인과는 떼려야 뗄 수 없는 사이여서 자연스럽게 관심이 생겼다. 인터랙션 디자인은 앱 같은 디지털 제품에서 특히 중요하다. 과거의 핸드폰은 물리적인 버튼(숫자 버튼 등)을 누르는 동작으로 사용자가 버튼을 눌렀다는 '느낌'을 받았는데, 앱 같은 디지털 제품은 적절한 인터랙션 없이 그런 물리적인 느낌을 받을 수 없기 때문이다.
그래서 스마트폰 화면과 사용자가 자연스럽게 소통하기 위해 적절한 모션과 애니메이션, 피드백 같은 인터랙션이 반드시 필요해졌다. 자연스럽게 인터랙션 디자인은 활발하게 연구되기 시작했고, 모바일 UI/UX 디자인과는 떼려야 뗄 수 없는 분야가 됐다.
내비게이션 바에는 대표적인 인터랙션 디자인이 있다. 바로 화면을 아래로 내리면 내비게이션 바가 위쪽으로 스르륵 숨겨지고, 위로 올리면 다시 나타나는 모션이다.
아래처럼 스크롤에 따라 타이틀의 크기와 위치가 바뀌는 내비게이션 바의 인터랙션도 많이 쓰인다.
이런 내비게이션 바의 모션은 보통 콘텐츠가 많은 쇼핑 앱에서 주로 쓰인다. 사용자에게 더 많은 콘텐츠를 보여주기 위해서, 혹은 주요 콘텐츠를 더욱 부각하기 위해 불필요한 내비게이션 바를 일시적으로 사라지게 만드는 것이다. 사용자가 아래쪽 콘텐츠를 보기 위해 화면을 아래로 내리면 내비게이션 바를 위쪽으로 숨겨 더 넓은 공간을 쓰게 하고, 위로 올리면 사용자가 내비게이션 바의 기능을 쓸 것으로 보고 내비게이션 바를 다시 보여준다.
내비게이션 바의 이런 인터랙션은 '움직이는 디자인'이다. 콘텐츠를 부각하는 역할을 하는 건 물론, 앱 같은 디지털 프로덕트를 마치 살아움직이는 것처럼 느끼게 해 '사용하는 맛'을 낸다.
모바일 UI/UX 디자인을 하면서 종종 마주치는 문제가 있다. 바로 아래와 같이 키보드를 제공해야 하는 화면에서 사진 같은 콘텐츠의 크기 때문에 버튼이 가려지는 문제다. 버튼이 키보드에 가려지기 때문에 사용자는 버튼을 누르기 위해 키보드를 내리는 과정을 거쳐야 한다.
위 예시 화면은 들어가는 요소가 적기 때문에 아래 화면과 같이 디자인해 해결할 수 있다. 가운데 들어가는 사진은 위쪽 텍스트 필드와 버튼 사이에서 각각 일정한 간격을 유지한 채로 동적으로 크기가 바뀌도록 하고, 버튼은 언제나 키보드 위쪽의 일정한 위치에 고정돼 있도록 디자인한 뒤 개발자에게 이 내용을 잘 전달하면 된다. 키보드의 enter(return) 버튼의 색과 글씨를 맞춤 제작하는 것도 좋은 방법이지만, 개발자가 키보드를 통째로 개발해야 하기 때문에 실무에서 활용하는 건 쉽지 않아 보인다.
이처럼 화면이 단순한 경우에는 위와 같은 방법으로 버튼이 키보드에 가려지는 문제를 해결할 수 있다. 하지만 아래처럼 화면이 복잡한 경우는 이야기가 조금 다르다. 위와 같은 화면은 텍스트 필드와 버튼 사이의 공간을 조절할 수 있었지만, 아래 화면은 그럴 수 없다. 들어가야 할 요소가 많아서 버튼이 가려질 수밖에 없다. 아래는 아이폰 X(S)를 기준으로 한 375*812(1x)의 화면인데 이보다 작은 아이폰 화면에서는 텍스트 필드까지 키보드에 가려질 우려가 있다.
꽤 오랫동안 이 화면에서 버튼의 위치를 어디에 둬야 UX(사용자 경험)가 좋아질지 고민했다. 고민을 거듭하다가 훌륭한 해결책을 발견했는데, 바로 인스타그램의 피드 등록 디자인이었다.
그동안 버튼은 반드시 아래쪽, 즉 엄지 영역에 두려는 강박관념을 갖고 디자인을 했는데, 인스타그램의 피드 등록 과정 디자인을 살펴보니 내비게이션 바의 오른쪽에 진행(다음) 혹은 완료 버튼을 두고 있었다. 즉 엄지 영역에 사용자가 해야할 중요 작업이나 키보드가 있어야 할 때 내비게이션 바 오른쪽에 진행 버튼이 오도록 디자인했다.
나는 진행이나 완료 버튼을 엄지 영역에 두는 게 오히려 UX를 좋지 않게 한다면, 엄지 영역을 포기하고 내비게이션 바의 오른쪽에 버튼을 두는 게 사용자에게 더 좋은 경험을 주기 때문에 이런 디자인이 나왔다고 해석했다. (덧. 사실 이 디자인은 아이폰(iOS) 사용자에게는 익숙한 UX 디자인이다.)
아래는 내 디자인에 위 내용을 적용한 모습이다.
하나 명심해야 할 건 이처럼 사용자가 무언가를 입력해야 하는 화면에서 내비게이션 바의 오른쪽 버튼을 진행이나 완료 버튼으로 쓸 때, 버튼이 활성화돼 있는 경우와 활성화돼 있지 않은 경우를 잘 나눠야 한다는 점이다. 사용자가 아무런 입력도 하지 않고 완료 버튼을 눌렀을 때, 입력해야 한다는 경고 팝업을 띄우면 사용자 경험을 해친다. 사용자가 꼭 입력해야 하는 정보를 입력하지 않았다면 버튼을 비활성화 상태로 둬야 한다. 비활성화 상태로 두는 방법은 연한 회색으로 버튼의 색을 정하면 된다. 난 #DBDBDB를 쓰고 있다.
또, 사용자가 열심히 입력한 뒤 모르고 'X'나 '뒤로 가기' 버튼을 누를 수 있다. 사용자가 입력한 정보가 있을 때 완료 버튼이 아닌, X나 뒤로 가기 버튼을 누른 경우는 입력된 정보가 모두 지워진다는 안내를 아래처럼 보여줘야 사용자의 실수를 막을 수 있다.
하지만 엄지 영역은 중요하다.
만약 키보드 같은 제약 없이 엄지 영역을 활용할 수 있다면 중요 버튼은 내비게이션 바보다는 엄지 영역에 두는 게 좋다. 이는 최근 내가 세운 가설을 검증하면서 더 확신할 수 있게 됐다.
가설: 버튼을 위쪽(내비게이션 바)에서 아래쪽(엄지 영역)으로 옮기면 사용자가 더 많이 누를 것이다.
이 가설은 우리 앱의 한 화면이 iOS와 안드로이드가 다르게 디자인돼 있었고, 그에 따른 결과가 명확하게 다르다는 점을 발견하면서 세우게 됐다. iOS는 '사이즈 비교'라는 버튼이 아래쪽 엄지 영역에 있었고 안드로이드는 위쪽 내비게이션 바 오른쪽에 있었는데, iOS는 신규 사용자의 23.4%가 사이즈 비교 버튼을 누르는 반면 안드로이드는 7.46%만 눌렀다. 3배나 차이가 났다.
사이즈 비교는 우리 앱의 중요 기능 중 하나로 사용자가 많이 사용하게 하고 싶다는 내부 합의가 있었고, 나는 안드로이드의 사이즈 비교 버튼을 아래쪽으로 옮겨 디자인했다. 그 결과는 놀라웠다.
사이즈 비교 버튼을 위쪽 내비게이션 바에서 아래쪽 엄지존으로 옮기자 버튼을 누르는 신규 사용자의 비율이 7.46%에서 22.8%로 올라갔다. 무려 3배나 늘어났다. 작은 변화로 큰 성과를 거둔 프로젝트라 기억에 많이 남는다.
사이드 프로젝트로 디자인 시스템을 만들면서 예상하지 못했던 디자인 시스템의 좋은 점을 발견했다. 나 스스로가 아주 많이 성장한다는 점이다. 디자인 시스템을 만들어 보는 시도만으로도 기본을 심도있게 고민하게 되고, 작은 요소(컴포넌트) 하나라도 더 치밀하고 아름답게 디자인하기 위해 노력하게 된다. 또, 각 요소가 어디에 어떤 방식으로 다시 쓰일 수 있을지 고민하다 보니 큰 그림을 그리며 디자인하는 버릇이 생기기 시작했다. 그동안 나무만 바라보는 디자인을 했다면, 디자인 시스템을 만들면서는 나무와 숲을 동시에 보며 디자인하게 된 것이다.
실무에서도 좋은 성과를 낸다. 아직 완성되지 않았음에도 내비게이션 바 같은 디자인 시스템 속 컴포넌트를 어도비 XD에 정리해 디자인에 활용하고, 제플린 스타일가이드에 등록해 개발에 활용하기 시작했더니 디자인과 개발 모두 눈에 띄게 효율적으로 바뀌고 있다.
이번 글을 시작으로 'UI/UX 디자인 가이드'를 하나씩 정리할 계획이다. 실무 디자인을 하면서 나오는 주제를 바탕으로 할 예정이고, 최종적으로는 책으로 묶어 디자이너를 꿈꾸는 많은 사람이 참고할 수 있는 UI/UX 디자인 교과서를 만드는 게 목표다.
(덧)
지난 7월 20일 토요일 코엑스에서 열렸던 스펙트럼콘 2019(SpectrumCon 2019)에 다녀왔습니다. 1000명이 넘는 디자이너 속에 앉아 한 명의 디자이너로서 이런 큰 디자인 콘퍼런스에 참여할 수 있다는 것에 정말 감사했습니다. 몇 달 전만 하더라도 상상하기 힘들었던 일이었습니다.
이런 생각도 들었습니다. 나는 당당하게 디자이너라고 말할 수 있는 디자이너인가? 아직 디자이너라고 하기에는 여러 면에서 부족하다는 생각이 듭니다. 당당하게 디자이너라고 나를 소개할 수 있을 때까지 노력하고, 성장하고, 제 시행착오를 많은 사람과 공유하고 싶습니다(끝).
많은 기능과 서비스를 갖추고 있는 슈퍼 앱들 사이에서 단순함을 가장 큰 목표로 하는 '작은 앱'이 사람들에게 어떠한 의미로 다가갈지 연구하는 '작은 앱 프로젝트'를 진행하고 있습니다.
1. 애플 Human Interface Guidelines(HIG)
2. 구글 Material Design(머티리얼 디자인)
3. 애플 HIG 'Navigation Bars'
4. 구글 Material Design 'App bars: top'
5. 구글 Material Design 'Status bar & Android Navigation Bar'
6. 플러스엑스의 브런치 글 '모바일 디자인할 때 그리드 시스템 꼭 사용해야 할까?'
양옆 마진에 대한 깊이있는 고민을 엿볼 수 있습니다.