기획서(스토리보드) 작성 방법 | 05 - 메뉴트리 (Menu Tree)

연관 글

• [기획] - 기획서(스토리보드) 작성 방법 | 01 - 시작하기
• [기획] - 기획서(스토리보드) 작성 방법 | 02 - 서비스 개요
• [기획] - 기획서(스토리보드) 작성 방법 | 03 - IA (Infromation Architecture)
• [기획] - 기획서(스토리보드) 작성 방법 | 04 - 주요 서비스 프로세스 (Main Process)
• [기획] - 기획서(스토리보드) 작성 방법 | 05 - 메뉴트리 (Menu Tree)
• [기획] - 기획서(스토리보드) 작성 방법 | 06 - 공통 규칙 (Common Rule)

 

 

 

메뉴트리(Menu Tree) 란

• 메뉴트리는 말 그대로 각 사용자가 사용하는 메뉴(menu)의 Tree 구조를 이야기합니다.
• 앞서 작성한 문서를 통해 설계된 항목을 메뉴로 한정하여 실제 UI 상 화면 메뉴를 구성하는 방법으로 접근할 수 있습니다
  
  
  

메뉴트리 작성의 목표

• 메뉴트리를 통해 화면 구성 설계를 목표합니다.
• 사용자의 동선이 끊기지 않는 메뉴구조 설계 등의 부가적인 목적이 있습니다.
• 추가로 메뉴트리를 통해 개발 과정에서의 계층구조 (hierarchy)를 수립하는데 용이하게 동작합니다
  • 자세한 내용은 추 후 다른 주제(개발자와 협업하기 편)에서 다룰 예정입니다
    
    
    

메뉴트리 작성 방법

• 메뉴트리는 작성자의 성향에 따라 Flow chart, 엑셀 등 여러 형태를 가질 수 있습니다.

• 메뉴트리에서는 권한 및 인증에 따라 달라지는 메뉴를 명시적으로 표현하는데에 포인트가 있습니다.

  • 이 과정에서 각 메뉴(기능)의 명확한 카테고라이징이 진행됩니다
  • 과도한 depth를 지양하여 사용자에게 편리한 동선을 제시합니다

다른 글과 마찬가지로 토이프로젝트로 진행하는 스터디 매칭 플랫폼의 예시입니다.

관리자 웹 메뉴트리

 

사용자 앱 메뉴트리

정리

상기 예시를 참고하면 메뉴트리는 아래와 같이 정리할 수 있습니다

메뉴트리의 형태는 정해져있지 않다

• 상기 관리자 웹 메뉴트리의 경우 횡(가로) 형으로 작성되었으며, 사용자 앱 의 경우 종(세로) 형으로 작성되었습니다
• 권장하는 바는 실제 서비스 내에서 보여지는 GNB / LNB / FNB 구조와 비슷하게 푸는 방안이 좋습니다.
  • 다만, 실제 기획서(파워포인트, confluence 등) 작성 환경에 따라 작은 화면안에 풀어내기 어려운 경우 형식에 대한 부분은 상세 기획 화면에서 기술해도 무방합니다.
• 이때, 메뉴트리의 작성 목적을 상기하며 작성하는것이 중요합니다.
  
  
  

권한에 의한 메뉴 노출 기준을 수립한다

• 권한에 연관된 화면 분기에 있어 필수성 또는 필요성이 크지 않다면 동일한 구성요소(component & feature)가 많은 경우 하나의 화면에서 메뉴(기능)의 노출 여부를 결정해주는 방법을 권장드리는 편입니다.
• 본 예시에서는 색상으로 구분해 두었습니다.
• 주의사항은 공통된 메뉴의 하위 구성요소에 차이가 있는경우에 해당 되는 점을 꼭 참고 하셔야합니다.

카테고라이징(Categorizing)을 명확히 한다

• 이 부분은 관리자 웹 메뉴트리를 참고하시면 좋습니다.
• 웹의 경우 통상적으로 각 메뉴의 명칭을 그대로 표현하는 편이며 이 과정에서 사용자(관리자도 사용자로 접근합니다)가 하고자 하는 행위가 어느 메뉴에 있을지를 충분히 예상하고 접근할 수 있도록 유도합니다.
• 앱의 경우 플랫폼 특성 상 적은 화면에 많은 내용을 보여주기 어려움에 따라 아이콘(icon)으로 대체하는 경우가 많음에 따라 개인적으로는 가능한 depth를 줄이는 방향으로 설계합니다
  • 예시로 모집중인 스터디 , 참여중인 스터디, 스터디 만들기(신규등록) 의 경우 스터디 라는 큰 메뉴로 카테고라이징할 수 있습니다
  • 그럼에도 불구하고 나뉘게 된 이유는 아래와 같은 요소가 있을 수 있습니다.
    • 전제 : 인스타그램/페이스 북과같은 하단 탭 구조 설계
      1. 스터디 탭으로 구분 시 하위 depth를 표현하기 위해 별도 서브 메뉴 (상단 탭)이 필요할 수 있다.
      2. 상단 탭이 추가되는 경우 사용자의 인터랙션 동선이 아래에서 위로 계속 움직여야 하는 불편함이 있을 수 있다.
      3. 상단 탭 영역을 하위 depth로 사용하는 경우 추 후 상단 바(뒤로가기 등이 있는 네비게이션 바)의 인터렉션이 겹칠 수 있다.
• 사실 위 내용 중 동선이나 사용성에 대한 내용은 유저의 사용성에 따라 다르게 인식될 수 있는 부분입니다.
• 포인트는 메뉴트리 설계 시 어느정도 화면에 대한 설계가 함께 이루어짐에 따라 추 후 서비스의 확장성을 감안하여 수립하는 것도 방법이 될 수 있습니다.

이어지는 글

• 이어지는 글에서는 공통규칙(Common Rule)에 대해 작성될 예정입니다

본 블로그 글은 작성자의 기준에서 작성된 내용이며 참고용으로만 이용해주세요