사이드바 메뉴는 햄버거 메뉴^{Hamburger Menu}라고도 부른다. 요즘 흔히 볼 수 있는 이 햄버거 메뉴는 사실 좋은 점 보다 위험한 점이 더 많다.

알려진 데이터는 다음과 같다.

• 사이드 드로어가 사용자의 사용시간을 반토막 낼 수도 있다^{Side drawer navigation could be costing you half your user engagement}
• 모바일 메뉴 AB 테스트^{Mobile Menu AB Tested}
• 햄버거 vs 메뉴: 마지막 AB 테스트^{Hamburger vs Menu: The Final AB Test}

우선 이것이 관찰하기에 미묘한 이슈라는 점을 기억해둘 필요가 있다. 나는 이 이슈를 관찰하기 위해 사용자 테스트를 거쳤고, 위의 다른 데이터도 비슷한 과정을 거쳤다.

이 글에서 다루는 햄버거 메뉴의 문제점, 해결책, 결과에 대해 인지하고 사이드바 메뉴를 적용하길 권한다.

문제점_{The Problems}

1. 발견가능성 저하
2. 효율성 저하
3. 플랫폼 내비게이션 패턴과의 충돌
4. 한눈에 들어오지 않는 문제

발견가능성 저하_{Lower Discoverability}

눈에 보이지 않으면 잊혀진다.

사이드바 메뉴와 하위 내용은 기본적으로 보이지 않는 상태이다.

사이드바 메뉴를 사용자가 사용하려면 우선 사이드바 메뉴 버튼이 작동하는 것이라는 점을 인식해야 한다. 앱 개발사는 이 메뉴 버튼을 보완하기 위해서 툴팁을 이용하거나 ‘메뉴’라고 이름을 붙이기도 한다. 그렇지만 중요한 내용의 대부분을 메인 화면에서 제공하는 애플리케이션에서는 이렇게까지 하지 않는 경우도 있다.

효율성 저하_{Less Efficient}

사용자가 기능을 잘 이해하고 있다고 하더라도, 햄버거 메뉴 패턴을 사용하면 내비게이션 과정에 불필요한 단계가 생기는 것을 피하기 어렵다. 사용자가 원하는 내용을 보기 위해서 반드시 메뉴를 열어야하기 때문이다.

아래는 반대로 내비게이션 요소를 항상 노출하는 경우의 예이다.

플랫폼 내비게이션 패턴과의 충돌_{Clash with Platform Navigation Patterns}

iOS 같은 플랫폼에서 햄버거 메뉴를 사용하려면 OS가 제공하는 표준 내비게이션 패턴과의 충돌을 피할 수 없다.

좌측의 내비게이션 바 버튼은 메뉴 버튼을 위해 사용해야 하지만, 사용자에게 뒤로 가기 내비게이션도 제공해야 한다. 이런 경우 디자이너는 위의 이미지처럼 과도한 내비게이션 바를 만드는 실수를 범한다. 화면 제목을 넣을 공간도 없다. 또는 아래의 경우처럼 메뉴를 확인하기 위해서 사용자가 수차레의 화면 전환을 거쳐야 하는 경우도 있다.

한눈에 들어오지 않는 문제_{Not Glanceable}

사이드바 메뉴를 사용하는 경우에는 사용자가 앱의 다른 영역으로 이동하려고 할 때만 사이드바를 열기 때문에, 특정 아이템의 정보를 드러내기가 어렵다.

이런 경우의 예를 Jawbone의 UP 애플리케이션에서 찾아볼 수 있다. 사이드바 메뉴 버튼 옆에 알림 아이콘을 배치하는 형태이다.

이런 형태는 많은 아이콘을 만들어야 하기 때문에 확장성면에서 좋지 않다. 결국 디자이너는 아이콘의 의미를 포기하고 더욱 일반적인 형태의 아이콘을 만들게 된다.

반면에 아래에 있는 트위터의 탭바를 보자. 알림의 의미를 사용자가 이해할 수 있고, 알림과 연결된 화면으로 바로 이동할 수 있다.

인지_Cognition

화면에서 컨텐츠를 보여주는 영역을 확보하기 위해서 햄버거 메뉴를 사용해야 한다고 생각할 수도 있다. 그렇지만 이것은 사용자에 대한 오해이다. 사용자가 화면에 보이는 모든 것을 본다고 생각하겠지만, 실제로는 그렇지 않다. 사용자가 집중해서 보는 영역이 있고, 이것은 줄어든 화면에서도 마찬가지이다.

놓친 아이콘의 사례: 모바일 기기에서 발생하는 변화 맹시
^{The Case of the Missed Icon: Change Blindness on Mobile Devices}

위 사례를 참고해 보면 내비게이션에 부정적인 영향을 끼치지 않고도 화면 영역을 확보할 수 있다는 점을 알 수 있다. 그리고 이 방법을 적용하면 피드백 제공, 상태 표시와 같은 HCI의 기본원칙도 지킬 수 있다.

한가지 덧붙이자면, 우리는 HCI에 대한 이해를 새롭게 할 필요가 있다. HCI에 대한 이해는 시각적인 접근을 바탕으로 한 디자인에서 발견할 수 있는 실수를 회피하는 좋은 방법이 된다.

해결책_{The Solution}

문제점에 대해서는 충분히 살펴봤다. 이제 해결책을 찾아보자.

언제 사용할 것인가_{When Should I Use It?}

기본적으로는 사용하지 않는 것이 좋겠지만, 아주 드물게 햄버거 메뉴 패턴이 적절한 경우도 있다. IRCCloud의 경우는 패턴을 적절히 사용한 예이다. 채널과 채널 멤버 사이의 내비게이션을 사이드바로 노출한다. 주 화면에 내비게이션 계층으로 표현해야할 하위 화면이 없기 때문에 사이드바를 사용할 수 있다. 미디어는 레이어로 표시한다.

그렇지만 이런 시나리오이기는 해도, UI가 과도하게 표현되었기 때문에 정보구조를 다시 검토해볼 필요가 있다.

우측에 채널 멤버 버튼이 있기 때문에, 채널과 관련된 동작을 보여줄 액션 버튼을 놓을 곳이 없다. 대신에 디자이너는 채널, 네트워크, 계정과 같은 성격이 다른 메뉴를 하나의 동작으로 담게 됐다.

이런 문제에 대한 해결책을 이어서 살펴보자.

대안은 무엇인가?_{What Should I Use Instead?}

사이드바 메뉴 패턴에는 무엇이든 간단하게 추가할 수 있다. 그러나 이런 간단한 과정은 직접적인 중요성이 결여된 나쁜 정보구조^{Information Architecture}를 만들어낸다.

정보구조를 다시 살펴보는 것이 해결책이다.

위의 사례는 사이드바 메뉴를 제거하는 방법을 잘 보여준다. 색상별 점을 이어보면 서로 다른 두 패턴에서 구성요소가 어떻게 변화했는지 살펴볼 수 있다.

사례분석_Takeaways

1. 상태는 메시지탭에서 바로 확인할 수 있다
2. 아이템을 항상 노출하고 바로 접근할 수 있다
3. 내비게이션 제스쳐가 충돌하지 않는다

이런 이슈를 해결하고도 스크롤 방향에 따라 네비게이션 바를 숨기는 방법으로 수직 영역을 확보할 수 있다. Facebook이나 Safari가 이런 방법을 채택했다. 고정 탭바에서 지금 보고 있는 화면을 명시해주기 때문에 내비게이션 바를 노출할 필요가 없다. 조금 더 간소화하고 싶다면 툴바 정도로 충분할 것이다. 이 때에도 꼭 지켜야 할 점이 있다.

1. 내비게이션을 숨기지 않는다.
2. 직접 접근이 가능해야 한다.
3. 내비게이션 제스쳐가 충돌하지 않아야 한다.
4. 아이콘을 이용해 관련된 피드백을 제공한다.

[업데이트] 앱이 아닌 웹사이트의 경우에는 정보 구조를 다시 검토하는 것이 최선이기는 하지만 iOS의 패턴 대신에 웹사이트 상단에 목록을 표시할 수도 있다. 웹사이트 내비게이션이라는 점만 명확하다면 사용자는 곧 다른 내용을 보기 위해 스크롤을 내리게 될 것이다.

또한 모바일 웹사이트에서 300ms 클릭 지연을 없애는 것도 알아두자. 터치 이벤트를 이용하거나 이 방법을 이용할 수 있다.

어떻게 확장할까?_{How does it scale?}

내가 예제로 제안하는 것은 iOS를 기준으로 한다. iOS의 경우에는 탭바나 툴바를 사용해볼 수 있다. 그렇지만 탭바에 다섯 가지가 넘는 요소를 넣으려면 어떻게 해야할까?

이런 상황은 이상적이지 않고, 애플리케이션의 정보구조에 검토가 필요하다는 것을 의미할 수도 있다. 그렇지만 반드시 다섯 가지가 넘는 탭이 필요하다면, 마지막 탭을 이용해서 다른 메뉴에 접근할 수 있게 만드는 것이다. 안타깝게도 여기서는 사이드바 메뉴와 크게 다른 점이 없다.

Rookie의 경우처럼 스크롤 할 수 있는 툴바를 구현할 수도 있다. 이 방법은 사이드바 메뉴의 이슈를 피할 수 있다. 대신 내비게이션 마찰이 발생할 가능성이 조금 더 높은데, 탭과 스크롤의 구분이 간단하지 않기 때문이다.

이 방법은 내비게이션보다는 동작에 보다 적절하다는 점도 기억해두자.

Rookie의 구현 방법은 불확실한 상태를 잘 다루고 있다. 툴바를 그대로 두고 횡으로 스크롤하면 자르기나 방향전환 같은 기능을 숨겨서 다른 기능을 보여준다. 이런 구현을 통해서 툴바가 사라졌다가 다시 나왔을 때 초기의 상태로 돌아가지 않고, 사용자가 마지막으로 스크롤한 상태로로 노출한다.

결론_Conclusion

사이드바 메뉴 패턴의 문제점과 iOS에서의 해결 방법에 대해 살펴봤다. 이 글이 명확하고 유용했으면 좋겠다. 이 글과 관련된 의견이 있다면 트위터 @lmjabreu로 말을 걸어주길 바란다.

[업데이트] 이 글에 대한 응답이 환상적이다. 많은 독자는 물론이고 중요한 대화가 트위터에서 오갔다. Storify를 이용해서 이 대화를 수집해 놓았다. Android와 웹에서의 내비게이션 패턴에 대해서도 더 다뤄볼 필요가 있을 듯 하다.

이 주제에 관한 다른 글과 트윗 살펴보기_{Other articles and tweets on this topic:}

• Hamburgers & Basements: Why not to use left nav flyouts
• An update on the hamburger menu
• Basement Menus and Breaking the “Rules” of App Design
• Pagebreak Snippet #150: Why and How to avoid Hamburger Menus
• Who Designed the Hamburger Icon?