ZEN of UX. 13 - 닫기 버튼이 왼쪽으로 가는 까닭은

앱 디자인이 태동하던 10여 년 전¹ 만 해도, 앱이 수행하는 기능은 웹사이트와 크게 다르지 않았어. 하지만 요즘의 앱은 웹과 비교도 안될 정도로 넓은 영역을 포괄하는 것 같아. to-do앱처럼 가벼운 앱도 여전히 많지만, 대부분의 상업적인 앱은 휴대성과 다양한 장치(카메라, NFC, 마이크 등의 장치와 GPS, 조도, 모션 감지 등의 센서 등)를 활용하여 보다 복합적인 기능을 수행하기 때문에, 앱 자체도 무거워지고 활용도도 높아졌지. 물론, 앱이 무거워지는 가장 큰 이유는 사용자를 뺏기지 않겠다는 욕심이 가장 큰 이유일 테고. ^^

이제 앱이 복잡해지는 속도는 두 OS의 가이드 업데이트 속도를 앞서기에 이르렀어. 이제는 애플과 안드로이드의 가이드만으로는 각 서비스의 필요를 커버할 수 없게 되었지. 5년 전까지만 해도 애플과 안드로이드 가이드를 맹신하는 분위기였다면, 요즘은 참고 정도로만 사용되고 있고, 각 서비스 회사들은 개성 있는 독특한 UI를 사용하는 데 주저함이 없어졌어. 바야흐로 춘추전국의 UI시대야. 두 OS 가이드의 업데이트가 요즘 뜸해진 것도 그 때문이라고 생각해. 

전통적인 형태의 Hierarchy

웹사이트 시절부터 관습적으로 그려지던 이런 UI, IA는 이제 별로 의미가 없어진 것 같아. 이전엔 A에서 B로 갈 때 5번의 클릭(탭)을 통해서 진입할 수밖에 없었지만, 모듈화된 기능을 중심으로 flow를 구성하는 요즘에는 hierarchy 자체가 갖는 의미가 많이 약화되었지.

IA가 유기물의 형태로 진화하는 건 꽤 자연스런 일인 것 같아 - @ vippng

 

IA보다 flow chart의 역할이 강조되고, 기능에 빠르게 접근하는 게 전체 구조를 짜는 것보다 중요해진 요즘 - 가장 많은 변형이 일어나는 화면은 다름아닌 이중 모달일 거야. (아래 이미지)

Emile Bergeron on Stackoverflow.com

직관적으로 느껴지겠지만, 이중 모달은 오랫동안 금기 사항이었어. 보기에도 좋지 않고, 기능적으로도 매끈하지 못한데다, 데이터도 이중, 삼중으로 물고 있어야 하고, 하나의 태스크를 완료하지 않은 상태에서 새로운 태스크를 띄우는 꼴이라서 유저 입장에서도 불안한 형태거든.

그런데, 요즘은 이런 화면을 어떻게든 구현해야 하는 상황이 되었어.

처음에 만들어진 기능 모듈들은 아주 제한적인 기능만 가지고 있어서, 한 화면에 구현하는 게 어렵지 않았어. 그런데 거기에 기능이 붙고, 링크가 붙고... 오랫동안 고도화해 온 결과, 현재의 기능 모듈은 대개 한 페이지에서 끝나는 게 불가능해졌지. 더욱이 앞뒤로 비슷한 기능 모듈이 붙게 되면, 이중 모달로도 해결되지 않는 복잡한 형태가 되곤 해. 당연히 UI 구조를 잘 짜면 많은 문제를 해결할 수 있겠지만, 부서가 많이 나누어진 대기업의 경우라던지, 하나의 기능도 버릴 수 없는 경우는, 어쩔 수 없이 조금 변칙적인 UI를 구성할 수밖에 없겠지. 

 

@ Apple

 

애플 유저는 이런 화면이 익숙할 거야. 애플에서는 이 화면을 Sharing and Actions² 라고 부르는데, 앱에서 가능할 법한 사사로운 기능을 묶어 놓은 모달이야. (통상 Extension이라고 부르기도 하고.) 그런데, 이 모달에 대한 주의사항을 읽어보면, 애플도 이걸 사용하는 데에 아주 조심스럽다는 걸 알 수 있어. 

Enable a single, focused task. An extension isn’t a mini-app. It performs a narrowly scoped task related to the current context.

단일 작업 실행 가능 : 익스텐션은 미니 앱이 아닙니다. 현재 컨텍스트와 관련된 좁은 영역의 기능만을 수행합니다.

Avoid placing modal views above your extension. Extensions are displayed within a modal view by default. While an alert might make sense above an extension, avoid layering additional modal views.

익스텐션 위에 모달 뷰를 사용하지 마십시오 : 익스텐션은 모달 뷰로 표현되기 때문에, 알러트를 그 위에 표기할 순 있어도, 추가 모달을 그 위에 얹지 마십시오. (애플 스스로도 어기고 있는 룰)

© Apple

이걸 보면, Save to Files 기능은 최소 한 개 이상의 추가 페이지가 필요해. AirDrop처럼 하나의 기능을 띄우는 것만으로도 애플 스스로의 규정을 어기는 거지만 어쨌든 하나의 기능을 수행하니까 그러려니 해도, Save to Files의 경우는 뎁스를 타고 들어가는 액션이나 새 폴더를 만드는 액션까지 추가되었기 때문에 애플 규정을 제대로 어기고 있는 셈이야.

그런데, 자세히 보면 "Cancel"이 좌측으로 이동한 것을 알 수 있어. Done, Save 등 '더 중요한 기능'이 우측을 차지하게 되면서, 자연스럽게 Cancel 버튼이 좌측으로 이동한 것이지. 그런데 이 Cancel... 닫기 버튼이잖아?

@ Apple

그래도 대부분의 경우, 애플은 아직도 고집스럽게 우측에 x 버튼을 두고 있어. Cancel과 x 버튼의 상징성에 미묘한 차이가 있기는 하지만, 최소한 x 버튼이 좌측으로 들어가는 경우는 보지 못한 것 같아. 보통 Cancel/Done 조합은 별도의 타이틀바를 가지는 상태에서 사용되고, x버튼은 약식이거나(맨 왼쪽 이미지) 서브타이틀(두 번째 이미지)과 병렬로 위치하는 게 차이라면 차이지. 텍스트의 진행방향이 좌에서 우로 가기 때문에 우측에 여백이 생길 수밖에 없고, 또한 대부분의 유저들은 오른손잡이이기 때문에 우측 상단이 여러모로 안정적인 위치겠지. 

@ Facebook (share)

하지만 애플을 제외한 다른 유명 앱들에선 왼쪽에 x 버튼을 두는 실험이 활발하게 이뤄지고 있어. 그리고 위에서 얘기한 바와 같이, 나는 이게 기능의 복잡도에 영향을 받았기 때문이라고 추측하고 있어. 애플의 경우는 자기 OS만 통제하면 되기 때문에 문제가 적지만, OS를 넘나들어야 하는 서비스들은 상황이 다르기 때문이지.

페이스북의 share 기능을 보자구. 애플은 화면을 가득 채우는 모달만을 사용하지만, 페이스북은 컨텐츠의 양만큼만 높이를 가지는 형태를 사용하고 있어. 그리고 애플의 경우는 모달이 여러 개 겹치는 경우 하나씩 꺼야만 본래 화면으로 돌아갈 수 있는 반면, 페이스북은 뎁스에 상관없이 모달을 끌어내리거나 모달 밖의 영역을 탭해서 그동안의 과정을 모두 취소할 수 있지. 

트랜지션에서도 차이가 있어. 애플은 풀-모달이니까 언제나 아래에서 위로 화면을 채우는 움직임인데 반해, 페이스북은 모달 내에서 왼쪽으로 스와이프 되기도 하고, 이전 모달이 꺼지면서 새 모달을 띄우기도 하고, 모달에서 새 페이지로 전환되기도 해. 폐쇄적으로 최적화를 추구하는 iOS에 반해, 서비스 사업자는 기능 자체에 집중하는 성향이 있기 때문에 이런 차이가 생기는 것 같아.

여기까지 보면, 왼쪽에 x 버튼을 두는 것의 장점이 조금 명확해지지? 내가 생각하는 장점은 다음과 같아. (주관적인 생각이니 당연히 정답은 아님) 

1. 모듈의 확장성

중요한 버튼이 우측에 배치되는 것은 앞으로도 오랫동안 유지될 거야. 그리고 페이스북이 기능 추가 등 UI 개선을 멈추지는 않을 거야. 이 두 가지 전제를 바탕으로 하면, 각 세부 기능의 메인 버튼을 위해 우측 상단을 비워 두어야 하는 상황은 불을 보듯 뻔하지. (부서가 기능별로 쪼개져 있는 큰 회사의 경우는 더욱더) 즉, 좌측 상단은 메인 플로우의 '닫기'가 위치하고, 우측 상단은 서브 플로우의 기능 버튼 (save, done, add 등)이 위치하는 것은 모듈을 확장하기에 효율적인 장치일 거야.

2. 트랜지션의 유용성

© 티스토리

이 글을 쓰고 있는 티스토리 모바일의 경우도 왼쪽에 x 버튼을 두고 있어. 우측에서 좌측으로 다음 기능이 들어오는 형태인 경우, 왼쪽에 x 버튼을 두는 게 유리해 보여. 우측 상단에는 '완료', '발행' 등의 중요한 버튼을 계속 겹치게 하고, 좌측 상단은 연속으로 탭해서 이전으로 신속하게 돌아갈 수 있게 하는 형태지. 이건 페이스북이나 인스타그램, 심지어 애플에서도 일부 차용하고 있는 형태야. 동일한 영역에 비슷한 기능의 버튼을 두면, 유저는 한 곳만 연속으로 눌러서 손가락의 이동을 최소화할 수 있거든. 

728x90

 

오늘의 얘기는 형태에 대한 개인적인 생각이야. x 버튼이 좌측에 있어야만 한다고 주장하는 것도 아니고, 왼쪽에 위치하는 것이 기능 때문인지 단순히 시각적인 시도인지도 명확하지 않아. 모든 것이 추측이고 나름의 분석일 뿐이야. 개연성이라면 '앱이 복잡할수록 x 버튼이 왼쪽으로 가더라'라는 리서치의 결과뿐이지. 

위에 기재한 것 중에 확실한 건 요정도가 아닐까 해 : 대부분의 큰 서비스들은 OS의 가이드, 심지어 HIG 규정도 가볍게 무시하는 추세이고, 큰 서비스들은 독립적인 가이드를 구축해 나아가는 중이라는 것. 이제 더 이상 OS 가이드가 절대적인 지침은 되지 못한다는 것. 그동안 UX 디자이너들이 저항하고 있던 "맥시멀 펑션"의 댐은 이제 거의 허물어졌다는 것.

---

Update 2021.02.08
Line의 디자인 시스템(링크)에는 x 버튼의 위치에 대해서 이렇게 정의하고 있네. 간단히 말하자면 왼쪽은 "취소"이고, 오른쪽은 "완료/종료"라는 거지. 직관적이긴 하지만, 해당 부분의 하단에는 '버튼이 여러개일 경우 위치를 유연하게 할 수 있다'는 등 아직은 유연한 상태인 것 같아. 

모달의 ‘X’버튼은 과업 취소 혹은 과업 완료, 닫기 두 가지 특성을 가집니다. ‘X’버튼이 전진 과업과 함께 배치되어 취소 역할을 하는 경우 왼쪽에 배치하며, 모달 내에서 작업을 완료하거나 종료 할 목적으로 사용하는 경우 오른쪽 배치가 권장됩니다. 따라서 ‘X’버튼만 제공되는 대부분의 케이스에서 우측 배치가 권장됩니다. 이는 ‘X’버튼이 과업 취소의 개념으로 사용되는 것이 아니고, 모달 과업 완료나 모달 닫기 성격으로 사용되기 때문입니다.

---

¹ 우리나라에서 iOS, aOS를 통한 앱이 만들어지기 시작했던 건 빨라야 2009년이라고 생각해. 물론 이전에도 심비안이나 윈도우 모바일 작업은 제법 있었고, 나 역시도 첫 심비안 제작 경험은 2006년이었으니, 역사를 길게 보자면 2000년대 초반부터라고 할 수 있겠지만, 논의를 iOS, aOS로 한정하고 보면, 한국에서의 앱 제작은 10년 내외라고 보는 것이 좋을 것 같아.

² 꽤 무거운 기능인데, 한 페이지로 설명을 갈음하는 게 어색해. 보다 자세한 정의가 있는 페이지를 발견한 사람은 피드백 부탁해.
https://developer.apple.com/design/human-interface-guidelines/ios/extensions/sharing-and-actions/