[UX] 구글 머티리얼 디자인 – 3.4.머티리얼 기초(Material foundation) – 내비게이션(Navigation): 내비게이션의 이해(Understanding navigation)

내비게이션(Navigation)은 앱 전반에 걸쳐 사용자가 이동, 탐색하는 것을 의미합니다. 여기서 앱 전반을 구분하는 기준은 앱을 구성하고 있는 화면(Screen)을 의미하며, 이 화면에 대한 사용자의 이동을 내비게이션(Navigation)으로 간주합니다.

출처: 원문보기

0. 내비게이션에서 화면(Screen)이란?

내비게이션을 설명하기에 앞서 앱 내에서 화면(Screen)이 의미하는 단위를 무엇으로 볼지에 대한 정의는 매우 중요합니다. 여기서 화면은 단순히 UX 담당자가 문서 내에 화면으로 구성하는 것을 해당 단위로 보면 안 됩니다.

내비게이션에 말하는 화면(Screen)이란 안드로이드(Android)의 액티비티(Activity), 플러터(Flutter)의 라우트(Route), iOS의 뷰컨트롤러(ViewController)의 개념으로 정의되어야 합니다. GUI 디자인 시 포토샵이나 일러스트레이터의 캔버스(Canvas)의 개념과 유사할 수 있으나 엄밀히 말하면 이 개념은 내비게이션에서 이야기 하는 화면(Screen)의 개념과 다르며, 혼용하여 사용하지 않아야 합니다.

그럼 여기서 화면(Screen)은 무엇으로 간주해야 할까요? 위에서 설명한 각 플랫폼(Android, Flutter, iOS)에서의 액티비티, 라우트, 뷰컨트롤러는 코드상 클래스(Class)의 개념으로 정의됩니다. 이 기준에 따라서 화면을 정의하고 앱 내 내비게이션을 정의하면 개발자와 커뮤니케이션의 이점도 있고, 플랫폼에서 지원하는 내비게이션 방식에 대한 설명을 별도로 기술하지 않아도 되어 작업 생산성을 높일 수 있습니다.

클래스의 개념은 개발자를 위한 개념이기 때문에 해당 콘텐츠에서 자세히 설명하진 않을 예정이며, 해당 내용에 대한 이해가 필요하면 플러터(Flutter)의 라우트(Route) 개념을 설명한 포스팅을 참고해 주십시오.

일단 화면(Screen)으로 정의되는 것은 앱의 시작 순서로 보았을 때, 앱이 로딩되는 동안 출력되는 스플래쉬 화면(Splash screen), 로딩 후에 가장 먼저 출력되는 메인 화면(Main screen 또는 Home screen)이 있을 수 있습니다. 메인 화면에서 이동하는 화면은 서브 화면(Sub screen)으로 보면 되겠습니다.

화면 정의에서 가장 착각을 많이 하는 것들이 경고 메시지 등을 출력하는 대화상자(Dialog)나 사용자 입력을 받는 Navigation bottom sheet, Radio button list, Date picker 등과 같이 별도의 창(Windows) 형태를 띄는 구성 요소(Component)를 화면으로 간주하는 것입니다. 이는 코드 상으로 특정 화면에 출력되는 레이어의 개념으로 보며, 화면 단위로 보지 않습니다. (위에서 언급한 클래스의 개념이 아니라는 의미입니다.)

실제 동작에 있어서의 차이도 있는데, 대화상자(Dialog), Navigation bottom sheet, Radio button list, Date picker 등은 출력된 레이어가 닫기 동작(Close)으로 구현되며, 화면 간의 이동은 앞으로 이동(Move forward), 뒤로 이동(Move backward) 동작으로 로 구현됩니다.

이 개념을 착각하는 가장 큰 이유는 Android navigation bar의 뒤로가기 버튼이 레이어의 닫기(Close) 동작과 화면의 뒤로 이동(Move backward)의 동작을 모두 처리하기 때문입니다. 이에 따라 작업자는 두 가지가 동일한 동작을 하는 것처럼 오해를 할 수 있고, 이에 따라 코드 상으로도 별도의 화면으로 구현된다고 착각하기 쉽습니다.

또한 화면으로 착각하기 쉬운 요소 중 하나는 자주 사용되는 사례는 아니지만 특정 프로세스(Process)를 나타내는 Stepper의 각 단계를 하나의 화면으로 생각하기 쉽습니다. 하지만 프로세스의 각 단계별 화면은 Stepper에서 정의하는 레이어로써 정의되는 것이지 코드 상에서 개별 화면 단위로 구성되지 않습니다. 다시 말해, Stepper에서 출력하는 각 프로세스 화면 역시 레이어 형태로 간주하며, Stepper 역시 개념을 잘 보면 특정 화면을 구성하는 하나의 구성 요소(Component)로 정의된다는 것을 알 수 있습니다.

예를 들어, 갤러리(Gallery) 서비스 화면에서 사진 목록(List component)은 해당 화면을 구성하는 하나의 구성 요소로 볼 수 있는 것처럼 말입니다.

사실 이 개념을 프로그래밍에 대한 지식 없이 이해한다는 것이 쉬운 일은 아닙니다. 화면을 구분하는 가장 쉬운 방법은 해당 화면에 화면 타이틀 텍스트가 존재할 수 있고, 뒤로 가기 버튼이 존재할 수 있는지를 기준으로 검토하는 방법이 가장 쉬운 방법일 수 있겠습니다.

예외적으로 뒤로가기 버튼이 없는 스플래쉬 화면이나 메인화면을 제외한 나머지 화면은 위로 가기 버튼(Up arrow)과 화면의 타이틀 텍스트가 앱 바(App bar) 내에 표시가 되어야 할 것입니다.

참고로 대화상자 중에는 Full screen dialog 유형이 있는데, 이는 위로 가기 버튼을 포함하지 않으며, 위로 가기 버튼 대신 닫기 버튼을 포함하는 것으로 실제 구성 요소 상으로 대화상자(Dialog)로 보는 것이 타당하며, 화면으로 정의하지 않습니다. 또한 Navigation drawer 역시 화면(Screen) 단위로 보지 않으며, 메인 화면 상에 출력되는 레이어(Layer)의 개념으로 보는 것이 타당합니다.

내용을 정리하면 화면(Screen)을 정의하는 것이 내비게이션에서 중요하다고 한 이유는 실제 코드 상으로 구성되는 화면(Screen) 단위는 레이어로 구성되는 논리적 개념의 화면과는 달리 플랫폼에서 지원하는 내비게이션 동작이 상이할 수 있으며, 이에 따라 각 화면에서 전달하는 전달 인자(Parameter) 등의 차이로 인하여 내비게이션 관련 버그가 발생하기 쉽기 때문입니다.

예를 들어, 실제 코드상 화면(Screen)으로 구현된 상황에서 닫기(Close) 동작으로 처리를 한다던지, 레이어 단위로 보아야 하는 Full screen dialog 등을 이용해서 화면을 구성을 하고 뒤로 이동(Move backward) 동작을 정의해 놓는다던지 하는 것은 테스트 단계에서 내비게이션 동작과 관련한 다양한 문제를 야기시킬 수 있기 때문에 이를 UI 담당자가 이해하고 기준을 잡는 것이 매우 중요합니다.

아무쪼록 UI 담당자의 역할이 단순히 화면을 그려내고, 담당부서와의 잘못된 커뮤니케이션으로 앱에 잠재적 문제를 더 유발시키는 사람이 아니라는 것은 분명합니다. 아는 만큼 보인다는 말이 있듯이 이 개념을 잘 이해하고 내비게이션 동작과 관련된 설계를 할 수 있길 바랍니다.

1. 내비게이션 유형 (Types of navigation)

내비게이션(Navigation)은 사용자가 과업을 수행하기 위해 앱 내에서 화면 간 이동하는 행위를 의미합니다. 내비게이션은 몇가지 방법을 통해서 가능합니다. 전용 내비게이션 구성 요소(Dedicated navigation components), 콘텐츠 내에 귀속된 내비게이션(Embedding navigation into contents), 플랫폼 자체적으로 지원하는 방식(Platform affordances) 등은 이러한 방법들에 속합니다.

1.1. 내비게이션의 방향성 (Navigation directions)

내비게이션의 방향성은 앱의 정보 구조(Information architecture)에 기초한 것으로 3가지 방향성을 가지며, 사용자는 이러한 내비게이션 방향 중 한 가지 방향을 따라 화면을 이동할 수 있습니다.

다시 말해, 내비게이션을 정의하는 유형을 3가지로 보고, 정보 흐름의 방향에 따라 사용자가 이동하는 내비게이션 방향이 정해진다는 의미입니다. 자세한 설명은 아래 내용에서 다시 다루겠습니다.

가로 내비게이션(Lateral navigation)은 정보 구조 상에서 동일한 레벨에 대한 화면으로의 이동을 의미합니다. 앱에서 가장 상위 단위의 내비게이션 구성 요소는 그것의 계층구조 내 모든 최상위 단위로의 접근을 제공해야 합니다. 설명이 다소 어렵지만 위 그림과 같은 메뉴 트리(Menu tree)가 있다고 했을 때, 최상위 계층인 Library, Recently Played, Search 메뉴는 서로 변경하면서 이동할 수 있다는 의미입니다.

전방향 내비게이션(Forward navigation)은 정보 구조 상에서 계층의 연속적 레벨의 화면 간 이동을 의미합니다. 역시 말이 어렵지만 위 그림을 통해서 살펴보면 Library가 1차 메뉴이고, Album이 2차 메뉴, Song이 3차 메뉴가 되는데, Library에서 Song으로 하나의 트리를 타고 내려가는 내비게이션이 여기에 해당됩니다. 이러한 내비게이션 방법은 카드(Cards), 리스트(Lists), 이미지(Images), 버튼(Buttons), 링크(Links), 검색(Search) 등과 같은 컨테이너들의 동작과 연동됩니다. 당연한 이야기겠지만 위에서 언급한 컨테이너 타입들은 대부분 해당 요소 선택과 함께 다음 단계의 화면으로 전환이 일어나게 되며, 이러한 유형의 컨테이너들은 이 외에도 다양할 수 있습니다.

역방향 내비게이션(Reverse navigation)은 전방향 내비게이션과 반대되는 개념으로 위 그림에서 3차 메뉴(Song)에서 2차 메뉴(Album)로 2차 메뉴에서 1차 메뉴(Library)로 이동하는 내비게이션을 의미합니다. 화면이 출력되는 시간 순서 상 최근에 출력된 화면에서 이전에 출력된 화면으로 이동하거나 하위 계층에서 상위 계층으로의 화면 이동을 의미합니다. 역방향 내비게이션의 특징은 플랫폼(Android, Flutter, iOS)이 내비게이션에 대한 화면 이동 및 처리방식을 결정하게 됩니다.

참고로 머티리얼 디자인에서 플랫폼의 의미는 Android, iOS, Flutter, Web과 같은 프로그래밍 개발 환경을 의미합니다.

역방향 내비게이션(Reverse navigation)이 플랫폼에서 자동으로 처리됨에 따라 화면 간 이동에 대한 동작 설계는 매우 정교하게 정의되어야 합니다. 화면 간 이동과 화면 위에 레이어로 별도로 출력되는 동작은 다시 한번 말하지만 명확하게 구분되어야 합니다. 이를 지키지 않으면 화면 이동 동작에 대한 버그 및 화면 간 데이터 전달과 관련하여 다양한 버그를 보게 될 것입니다. 기본 동작은 내비게이션에서 화면 이동은 Move foward와 Move backward 동작으로 처리되며, 화면 위에 레이어로 출력되는 화면은 Open과 Close 동작으로 처리되어야 합니다.

추가로 역방향 내비게이션 중에서 시간 순서 상 최근에 출력된 화면에서 이전에 출력된 화면으로 이동하는 규칙(위 그림의 2번 점선 화살표)과 관련해 설명해 보겠습니다.

예를 들어, 검색결과 화면에서 원하는 음악(Song)을 선택(Play)하지 않고, 검색어를 변경하여 다시 검색을 하고, 또 다시 검색어를 변경하여 다시 검색을 한 후 원하는 음악(Song)을 선택하였다고 가정해 보겠습니다.

이 상태에서 역방향 내비게이션은 시간의 역순 화면으로 이동하게 되는데, 원하는 음악(Song)에서 원하는 음악(Song)의 검색결과 화면, 그 이전에 검색어로 검색한 검색결과 화면, 그 이전에 검색어로 검색한 검색결과 화면으로 최초 검색어로 검색한 검색결과 화면이 될때까지 화면 이동이 일어납니다.

역방향 내비게이션은 별거 아닌 듯 보이지만 이 동작과 관련하여 자체적으로 기능을 구현하다보면 내비게이션과 관련된 다양한 문제가 발생하기 때문에 역방향 내비게이션과 관련된 기능을 별도로 구현할 경우 반드시 내비게이션에 대한 구조 설계를 철저히 하고 기능 구현을 해야 합니다. 그럼 아래에서 각각의 내비게이션 유형을 조금 더 자세히 사례를 통해 살펴보겠습니다.

2. 가로 내비게이션 (Lateral navigation)

가로 내비게이션(Lateral navigation)은 정보 계층 구조(Hierarchy)에서 동일 레벨 트리의 화면 간 이동을 의미합니다. 가로 내비게이션은 다른 앱이나 기능으로의 이동을 가능하게 하며, 하나의 콘텐츠 세트(Content set)에서 연관된 아이템으로의 전환을 가능하게 합니다.

2.1. 목적지와 계층 구조 (Destinations and hierarchy)

앱의 최상위 내비게이션 구성 요소(Component)는 그것의 계층 구조 상 최상위 트리의 모든 목적지로의 이동이 가능해야 합니다. 2개 이상의 최상위 트리의 목적지를 가진 앱은 Menu drawer, bottom navigation bar, tabs 등을 이용해 가로 내비게이션을 지원해야 합니다. (Menu drawer, bottom navigation bar, tabs 등의 구성 요소는 이후에 다시 설명하겠습니다.)

용어들이 다소 생소하지만 목적지(Destination)가 의미하는 바는 해당 메뉴를 선택했을 때, 이동하는 화면이라고 이해하면 됩니다. 1.1. 내비게이션의 방향성 (Navigation directions)에서 설명한 것을 예로 들면, 최상위 메뉴 및 해당 화면은 Library, Recently Played, Search가 되며, 각각은 서로 다른 메뉴에서 목적지가 됩니다. 즉, 해당 사례에서 가로 내비게이션을 위한 목적지는 총 3개가 되는 것입니다.

Component	Use for	# destinations	Devices
Navigation drawer	Top-level destinations	5+	Mobile, Tablet, Desktop
Bottom navigation bar	Top-level destinations	3-5	Mobile
Tabs	Any level of hierarchy	2+	Mobile, Tablet, Desktop

Destinations and hierarchy for lateral navigation

위 표에서 Navigation drawer와 Bottom navigation bar는 정보 구조(Information architecture) 상 최상위 계층의 가로 내비게비션을 위해 사용된다는 것을 나타냅니다.

Navigation drawer는 최상위 계층의 항목이 5개 이상이 되더라도 사용할 수 있으며, 모바일(Mobile), 태블릿(Tablet), 데스크탑(Desktop) 등의 다양한 환경에서 사용할 수 있습니다.

Bottom navigation은 최상위 계층의 항목이 3개에서 5개 사이로 제한되며, 모바일(Mobile) 환경에서만 사용됩니다.

Tabs는 최상위 계층 외에 다양한 계층에서의 가로 내비게션에 사용할 수 있으며, 계층의 항목이 최소 2개 이상인 경우에 사용할 수 있습니다. Tabs는 모바일(Mobile), 태블릿(Tablet), 데스크탑(Desktop) 환경에서 사용할 수 있습니다.

실무를 진행하다보면 이런 각 구성 요소(Component) 특징에 대한 이해없이 내비게이션 구성 요소(Component)를 아무거나 사용하는 경우를 많이 볼 수 있습니다.

정말 이런 문제는 매우 흔하게 찾아볼 수 있는데, 반드시 각 구성 요소들이 갖고 있는 특징을 확인하여 UI 디자인에 적절히 활용할 수 있도록 해야 합니다.

Lateral navigation by navigation drawers

위 그림에서 Navigation drawers는 최상위 계층 항목으로 5개 이상을 갖고 있는 것을 보여줍니다. (Inbox, Outbox, Trash, Spam, Updates) 또한 Navigation drawer는 다양한 디바이스의 화면 사이즈에서 일관된 내비게이션 사용 경험을 제공합니다. (가장 기본이 되고 호환성이 좋은 구조의 내비게이션 구성 요소(Component)라는 것을 강조하는 것입니다.)

Lateral navigation by bottom navigation bars

위 그림에서 Bottom navigation bars는 3개에서 5개 사이의 최상위 계층 항목을 모바일 환경에서만 제공합니다. Bottom navigation bars의 장점은 내비게이션을 위한 효과적인 위치(Location), 가시성(Visibility), 지속성(Persistence)을 제공하여 각 목적지로의 이동을 빠르게 할 수 있도록 합니다.

당연한 이야기겠지만 Bottom navigation bars는 Menu drawer를 출력한 상태에서 항목을 선택하지 않아도 되기 때문에 내비게이션 동작 단계가 1단계가 줄어드는 구조를 갖는 구성 요소(Component)입니다. 이에 따라 Bottom navigation bars는 빠른 내비게이션이 가능한 게 장점이 될 수 있습니다. 또한 근래 디바이스 디스플레이의 세로 사이즈가 길어지는 상황에서 Bottom navigation bars는 Menu drawer보다 한손 조작이 더 쉽다는 장점도 추가적으로 갖고 있는 구성 요소입니다.

위 그림에서 Tabs는 계층에 상관없이 2차든 3차든 가로 내비게이션을 위한 구성 요소(Component)로 사용됩니다. 2개 이상의 항목을 출력하는데, 사용되며 디바이스의 화면 사이즈에 유연하게 대응할 수 있는 구성 요소입니다. Tabs는 기본적으로 가로 스크롤이 지원되기 때문에 항목이 늘어나도 디사이스의 화면 사이즈가 줄어들어도 각 목적지로의 이동이 가능한 특징을 갖습니다.

Additional lateral navigation by navigation drawer and tab

위 그림은 최상위 계층의 가로 내비게이션을 위한 Menu drawer와 그 하위 계층의 가로 내비게이션을 위한 Tabs를 복합적으로 적용한 예시입니다.

2.2. 복잡한 정보 구조와 가로 내비게이션

해당 내용은 머티리얼 디자인에서 설명하고 있지 않지만 경우에 따라서 계층 구조 상에서 1차 메뉴가 여러 목적지를 갖고 있고, 2차 메뉴가 다시 여러 목적지를 갖고 있고, 3차 메뉴가 다시 여러 목적지를 갖는 경우를 볼 수 있습니다.

이러한 경우가 발생하는 경우는 주로 앱의 설정 메뉴 등에서 나타날 수 있습니다. 이 경우 각 정보 구조의 하위 계층은 Menu drawer와 Tabs 등으로 조합하지 않으며, Menu drawer 내에서 화면 이동이 일어나는 방식으로 구조가 설계되거나 1차 메뉴로 이동을 하여 해당 화면에서의 리스트(List)를 구성요소로 하여 하위 항목으로 이동하는 구조가 필요할 수 있습니다. (List의 항목을 선택하면 또 다른 List가 출력되는 구조)

이런 사례는 구글의 다양한 레퍼런스 서비스(예: 구글 드라이브, 지메일, 구글맵)에서 확인할 수 있으니 참고하시기 바랍니다.

3. 전방향 내비게이션 (Forward navigation)

3.1. 전방향 내비게이션 방법 (Methods of forward navigation)

전방향 내비게이션은 과업 수행을 위해 화면 간 이동과 관련한 3가지 유형으로 정의될 수 있습니다.

하향이동형(Downward)은 앱 내 계층 구조에서 더 세부적인 콘텐츠에 대한 접근을 위한 내비게이션 유형입니다. 부모 화면(더 상위 계층의 화면)에서 자식 화면(더 낮은 계층의 화면)으로의 이동이 여기에 해당됩니다. 여기서 상위 계층은 위에서 설명했던 1차 메뉴를 출력하는 화면이며, 하위 계층은 2차 메뉴, 3차 메뉴를 출력하는 화면으로 볼 수 있습니다.
순차이동형(Sequentially)은 특정 흐름(프로세스) 상에서 화면의 순서에 따라 내비게이션이 이뤄지는 유형입니다. 예를 들어, 쇼핑몰에서 결재를 하는 단계에 따라서 화면이 순서대로 이동하는 것이 여기에 해당될 수 있습니다.
직접이동형(Directly)은 앱 내에서 하나의 화면에서 다른 화면으로의 직접적으로 이동하는 유형입니다. 예를 들어, 앱의 홈 화면에서 앱의 특정 계층의 위치로 바로 이동하는 것 등을 의미합니다. 예를 들어, 특정 화면에서 설정화면으로 이동하는 것이라던지, 검색을 통한 화면 이동 등이 여기에 해당됩니다.

3.2. 전방향 내비게이션의 적용 (Implementing forward navigation)

가로 내비게이션(Lateral navigation)이 전용 UI 구성 요소(Component)를 사용해 구현되는 것과 달리, 전방향 내비게이션(Forward navigation)은 다양한 구성 요소(Component)를 통해 화면의 콘텐츠 내에 구현됩니다.

즉, 특정 구성 요소(예: Navigation drawer, Bottom navigation bars, Tabs)로서 해당 내비게이션 동작이 이뤄지는게 아니라 화면의 링크(Link) 관계에 따라서 내비게이션이 이뤄진다는 것입니다.

전방향 내비게이션은 다음과 같은 구성 요소들을 통해 적용될 수 있습니다.

카드(Cards), 리스트(Lists), 이미지 리스트(Image lists)와 같은 콘텐츠 컨테이너(Content containers)
다른 화면으로 이동하기 위한 버튼
앱 내에서 하나 또는 여러 화면을 검색하는 검색 기능
콘텐츠 내에서의 링크(Links)

Implementing forward navigation by cards

위 그림은 부모 화면인 홈 화면이 카드(Cards)를 통해 각 노트의 세부 콘텐츠를 미리보기 형태로 보여주고 있습니다. 사용자가 특정 카드를 선택하면 자식 화면(노트의 전체 내용을 출력하는 화면으로 이동(내비게이션) 될 수 있습니다.

Implementing forward navigation by buttons and search

위의 왼쪽 그림은 Stepper를 나타내는 것으로 Next 버튼을 선택하여 다음 화면으로 이동하는 동작을 나타내고 잇습니다. 이는 순차이동형 내비게이션을 나타냅니다. 하지만 위에서도 간단히 언급했지만 원칙적으로 Stepper의 각 단계를 나타내는 화면은 화면(Screen) 단위로 정의되지 않으며, 설명 편의상 예로 든 것임을 이해하고 있어야 합니다.

실제로 이를 증명할 수 있는 방법은 위의 왼쪽 그림에서처럼 Stepper에 속한 4번째 화면에서 Android navigation bars의 뒤로 가기 버튼을 선택하면 Stepper에 속한 3번째로 이동하는 것이 아니라 “Lamb Dolmas” 화면을 호출한 이전 화면으로 이동하는 것을 확인할 수 있을 것입니다.

위의 오른쪽 그림은 검색 기능이 앱 내 정보 구조상에서 어떤 화면으로도 빠르게 이동하는 것이 가능하다는 것을 보여주는 것입니다.

쉽게 말해, 전방향 내비게이션(Forward navigation)은 하위 계층 화면, 순서가 있는 화면, 특정 화면으로 점프하기 위한 방향성을 가진 내비게이션이라고 이해하면 되겠습니다.

4. 역방향 내비게이션 (Reverse navigation)

역방향 내비게이션(Reverse navigation)은 화면 간 이동에서 이전 화면으로 이동하는 것을 나타냅니다. 사용자가 최근에 출력한 화면에서 시간 역순으로 이동하거나 앱의 정보 구조에서 상위 계층 방향으로 이동하는 것이 역방향 내비게이션에 해당합니다.

3.1. 시간 역순 내비게이션 (Reverse chronological navigation)

시간 역순 내비게이션(Reverse chronological navigation)은 사용자가 최근에 살펴본 화면의 히스토리를 역순으로 이동하는 내비게이션을 말합니다. 시간 역순 내비게이션은 앱 내 또는 여러 앱에 걸쳐 사용자의 이동을 가능하게 합니다. 예를 들어, 웹 브라우저에서 뒤로 가기 버튼은 시간 역순 내비게이션 형식 중 하나입니다.

시간 역순 내비게이션은 OS(Operating System)이나 플랫폼(Platform)에 의해서 기본적으로 제공됩니다. 개별 플랫폼은 내비게이션이 어떻게 동작하는지, 사용자가 해당 기능에 어떻게 접근할 수 있는지 등을 직접 정의합니다.

결론적으로 시간 역순 내비게이션은 시스템에서 정의된 동작으로 동작하며, 담당자가 해당 동작을 임의로 정의하지 않도록 해야 한다는 의미입니다. 화면 단위를 정의하고, 정해진 내비게이션 동작 외에 임의로 화면 간 이동과 관련해 내비게이션 동작을 설정하면 여러가지 문제를 야기시킬 수 있음에 유의해야 합니다.

뒤로 가기 버튼은 사용자가 최근에 살펴본 화면에서 시간 역순으로 내비게이션을 할 수 있도록 합니다. 위 그림에서 항목 A는 안드로이드 내비게이션 바(Android navigation bar)의 뒤로 가기 버튼을 의미합니다. 항목 B는 웹 브라우저에서 뒤로 가기 버튼을 의미합니다.

3.2. 상위 계층 방향 내비게이션 (Upward navigation)

상위 계층 방향 내비게이션은 사용자가 단일 앱의 정보 구조에서 앱의 홈화면 또는 최상위 레벨의 화면에 도달할 때까지 한 단계씩 상위 계층으로의 내비게이션이 가능하도록 합니다. 예를 들어, 아래 그림 항목1의 A는 상단 앱 바에서 위로 가기 화살표(Up arrow)로써 상위 계층 방향 내비게이션을 구현하기 위한 유형에 속합니다.

상위 계층 방향 내비게이션은 하나의 앱 내에 모든 자식 화면에서 구현되어야 하며, 플랫폼에서 제시하는 가이드라인을 따라야 합니다. 안드로이드와 웹 앱(Web apps)은 머티리얼 위로 가기(Up arrow) 화살표를 사용합니다. (아래 그림 항목 1의 A) 반면에 iOS 앱은 iOS 내비게이션 바(Navigation bar)의 뒤로 가기 버튼(Back button)을 사용해야 합니다. (아래 그림 항목 2의 B)

위 그림에서 1번은 안드로이드와 웹 앱에서 위로 가기 동작(Up arrow)을 통해 상위 계층 방향 내비게이션이 가능한 것을 나타냅니다. 위 그림에서 2번은 iOS에서 뒤로 가기 버튼을 통해 상위 계층 방향 내비게이션이 가능한 것을 나타냅니다.

위 설명에서 위로 가기 화살표(Up arrow)에 대한 것은 버튼 아이콘 사용에 대한 것을 나타내며, 실제로는 상위 계층 방향 내비게이션이나 시간 역순 내비게이션이나 안드로이드 내비게이션 바(Android navigation bar)를 통해 동작될 수 있습니다.

위 예시는 위로 가기 화살표(Up arrow)를 사용하지 않고, 개별 앱들이 임의로 내비게이션에 사용하는 아이콘을 마음대로 디자인하는 사례가 늘어남에 따라 해당 디자인을 통일하라는 의미에서 해당 아이콘 사용을 강조하는 있는 것이라고 이해하면 되겠습니다.

3.3. 검토사항 (Consideration)

개발하고자 하는 앱의 디자인과 기능성은 앱이 타깃으로 하는 플랫폼의 역방향 내비게이션(Reverse navigation)의 두 가지 유형을 모두 설명할 수 있어야 합니다. 역방향 내비게이션에서 사용자의 경험을 최적화하기 위해서는 다음과 같은 사항을 검토해야 합니다.

사용자의 이전 화면의 위치와 상태로 돌아갈 수 있어야 합니다. 예를 들어, 상하 스크롤(Vertical scroll)을 한 상태에서 화면 이동이 발생했다면 정보를 탐색하거나 과업 수행을 빠르게 하기 위해 스크롤 화면으로 이동할 시, 해당 스크롤이 있던 위치를 기억하고 해당 위치로 이동할 수 있어야 합니다.
이전 화면의 상태를 더이상 이용할 수 없는 상황이라면 명확한 메시지를 제공해야 합니다. 예를 들어, 양식(Form)에 입력된 정보가 보안을 위해 이전 화면으로 돌아갈 경우, 초기화되는 상황이 있을 수 있습니다. 이 경우 해당 상태를 저장할 수 없다는 것을 별도의 메시지로 사용자에게 피드백할 수 있어야 한다는 것입니다.
정보 구조 상 화면들 사이에 자식 부모 관계는 명확하게 나타내야 합니다. 예를 들어, 앱에서 자식 화면으로 직접 이동을 했다면 자식 화면은 상위 계층 방향으로의 내비게이션을 위한 부모 화면을 확인할 수 있어야 합니다.

위 내용의 마지막 내용을 부연 설명하면 내비게이션은 정보 구조 상에서 자식 방향 화면으로의 이동과 부모 방향 화면으로의 이동이 모두 가능해야 한다는 것을 강조하는 것입니다.

예를 들어, 1차 메뉴 화면에서 5차 메뉴 화면으로 이동을 임의로 전체 팝업 화면을 통해 강제로 직접 이동했다가 닫아버리는 내비게이션 설계를 했다고 가정해보겠습니다.

이 경우 작업자는 화면 이동 단계를 획기적으로 줄여서 사용성을 높였다고 자칫 착각하는 경우가 있습니다. 정보 구조 상의 각 계층 구조를 갖는 화면은 반드시 상위 방향 하위 방향으로의 이동을 명확하게 설명할 수 있어야 한다는 것을 다시 한번 설명하는 것입니다.

즉, 상하 관계를 갖고 있는 화면은 반드시 그 단계를 임의로 건너뛰는 내비게이션을 하지 않도록 하라는 의미이고, 이것이 내비게이션의 효율성을 높이고, 사용성을 높인 것으로 이해하는 것은 개념을 잘못 이해한 내비게이션 설계라고 하고 있는 것입니다.

5. 마무리

생각보다 내비게이션에 대한 이해가 부족한 서비스 및 앱은 많이 찾아볼 수 있습니다. 이에 더하여 화면 이동 과정에서 생기는 버그도 이와 관련된 경우가 매우 많습니다.

화면 이동에 대한 동작을 설계함에 있어 화면 단위와 화면 간의 관계를 정의하는 정보 구조(Information architecture)를 먼저 분석 및 설계하는 것은 단순히 정보 간의 관계를 설명하는 것을 넘어서 실제 화면 이동 동작에 영향을 줄 수 있기 때문에 매우 중요합니다. 더불어 위에서 설명한 플랫폼에서 정의된 내비게이션 가이드라인이 무엇인지 또한 미리 검토하고 설계할 수 있어야 되겠습니다.

다음 내용은 내비게이션의 화면 전환(Navigation transition)과 관련하여 화면 전환 애니메이션 및 모션 등이 어떻게 처리되는지를 살펴보겠습니다. 그럼 다음 시간에 뵙겠습니다.

이 블로그 검색

UNCLESOON'S BLOG