bbulman/navigation

내비게이션 (Navigation)

내비게이션은 구조의 어떤 부분이 화면에 고정적으로 배치되고 어떤 부분이 다른 방식으로 도달되는지를 결정합니다. 슬롯은 한정되어 있으며, 각 표면(Surface)은 무엇이 그 슬롯을 차지할 자격이 있는지에 대한 고유한 규칙을 가집니다.

먼저 필요한 것

입력	출처	누락된 경우
현재의 모든 표면	코드베이스에서 먼저 라우트와 내비게이션 컴포넌트(헤더, 푸터, 앱 전환기, 사이드 레일, 탭 바)를 읽으세요. 절대 홈페이지만으로 재설계하지 마십시오.	각 표면의 스크린샷이나 항목 목록(타이핑된)을 요청하세요.
그 뒤의 트리	사이트맵 또는 라우트	직접 현재 트리를 매핑하고 그 사실을 명시하세요. 구조 자체가 잘못되었다면 중단하고 sitemaps를 사용하세요.
최상위 작업(Top Tasks), 사람들이 실패하는 작업, 사용 현황	사용자, 분석, 검색 로그, 반복되는 지원 문의	질문하거나 상단에 가정을 명시하세요. 사용량을 추정하지 마세요. 데이터가 있다면 어떤 결정이 바뀔지 말하세요.

이 중 아무것도 얻을 수 없다면, 무엇이 필요한지 말하고 references/spec-template.md에서 진입 규칙(Entry Rule)을 채워 넣은 빈 명세를 생성하세요.

방법

1. 모든 표면을 매핑하세요. 표면, 항목, 대상, 개수. 같은 대상을 두 이름으로 표시한 것, 아무데도 연결되지 않는 항목, 우연히 하나의 표면에만 존재하는 항목을 표시하세요.

2. 전역(Global)과 지역(Local)을 분리하세요.

   	전역(Global)	지역(Local)
   역할	이 전체 공간이 제공하는 것	이 페이지 주변의 것
   표시	모든 페이지에서 동일	해당 섹션 내에서만
   표면	Primary, Utility, Footer	사이드 레일, 페이지 내 목차, 브레드크럼, 관련 링크
   잘못될 때	한 섹션의 하위 항목을 나열할 때	전역 항목을 반복할 때

   3단계 이상의 내비게이션이 필요한 섹션은 일반적으로 자체 사이드 레일이나 자체 홈 페이지가 필요합니다.

3. 각 표면에 진입 규칙(Entry Rule)을 부여하고 모든 항목에 적용하세요.

   표면	속하는 것	속하지 않는 것	진입 규칙
   Primary	사용자와 비즈니스에 가장 중요한 3~6개의 대상	슬롯을 차지할 자격이 없는 모든 것	최상위 작업(Top Task) 또는 명시된 비즈니스 목표를 제공하고, 신규 사용자에게 이해가 되며, 이미 있는 가장 약한 항목보다 나은 것
   Utility	로그인, 계정, 검색, 언어, 설정	마케팅 순위가 매겨진 항목	사람의 세션이나 도구에 관한 것이지 콘텐츠에 관한 것이 아님
   Footer	더 완전한 사이트맵, 법적 고지, 연락처, 보조 콜투액션	잡동사니 서랍(사람과 크롤러가 여전히 읽습니다)	어떤 페이지에서든 누군가 필요로 하거나 법적으로 요구됨. 명명된 그룹에 맞는 것
   Contextual	사이드 레일, 페이지 내 목차, 브레드크럼, 관련 링크	전역적인 모든 것	여기서만 의미가 있으며, 서면 규칙에 따라 배치됨
   앱 탭 바	최대 5개의 탭; 6번째는 'More'가 되거나 제거됨	거의 사용되지 않는 대상	제품 내에서 반복되는 최상위 작업

4. 할당하세요(Allocate). 7개 이상의 Primary 항목은 일부가 자리를 차지할 자격이 없다는 신호로 간주하세요. 통합하거나 푸터로 이동하세요. 거의 동일한 항목을 하나로 병합하세요. 사람들이 실패하는 모든 작업에 하나의 정식 홈(Canonical Home)을 부여하고, 다른 진입점은 그곳으로 연결된다고 명시하세요.

5. 두세 가지 배열을 제시하세요 (작업별, 객체별, 대상별). 각각의 비용과 어려운 점을 함께 제시하세요. 하나를 추천하고 그 이유를 설명하세요.

6. 패턴을 선택하세요.

   상황	사용	참고
   하나의 항목에 자체 하위 항목이 있는 세 개 이상의 하위 그룹이 있는 경우	메가 메뉴(Mega-menu)	키보드 포커스와 모바일 버전은 별도 작업으로 설계
   짧고 평평한 하위 항목 목록	일반 드롭다운 또는 허브 페이지 링크	종종 허브 페이지가 더 나음
   3단계 이상의 깊이	브레드크럼(Breadcrumbs)	모든 크럼은 실제 페이지. 페이지당 하나의 경로. 사용자가 거쳐온 경로가 아닌 정식 홈을 따름
   긴 참조 페이지	페이지 내 목차(In-page contents)	지역 전용
   다른 역할에 다른 시작점이 필요한 경우	개인화된 바로가기(Personalised shortcuts)	바로가기를 개인화하고 지도는 개인화하지 마세요. 모든 사람이 다른 메뉴를 보면 사람들이 길을 알려줄 수 없고, 지원팀이 위치를 설명할 수 없으며, 분석이 의미를 잃음

7. 모바일과 키보드를 지금 설계하세요. 모바일에서 Primary가 어떻게 축소되는지, 무엇이 보이는 상태로 유지되는지, 각 메가 메뉴에 어떤 일이 발생하는지 설명하세요. 키보드에서는 모든 항목이 시각적 순서로 도달 가능해야 하고, 포커스가 보여야 하며, Escape는 Enter가 연 것을 닫고, 호버(hover)만으로 작동하는 것은 없어야 합니다. 세부 사항은 references/mobile-and-keyboard.md에 있습니다. 열리는 메뉴가 있다면 반드시 읽으세요.

8. 결정이 내려지는 곳에 단서(Cues)를 배치하세요. 좋은 단서는 사람이 이미 가지고 있는 질문에, 선택하는 순간에, 이미 보고 있는 곳에서, 조용하고 저렴하게 답을 줍니다. 자동차 연료 게이지 옆에 있는 주유구가 어느 쪽에 있는지 알려주는 화살표가 모범 사례입니다. 현재 위치를 활성 상태(active state)로 표시하세요.

9. 항목이 어떻게 제거되는지 계획하세요. 링크를 제거하는 것은 페이지를 제거하는 것이 아닙니다.

   단계	할 일
   운명 결정	병합, 푸터 또는 유틸리티로 이동, 검색으로만 접근 가능, 또는 제거
   페이지가 사라지는 경우	리디렉션 맵에 추가
   페이지가 유지되는 경우	다른 경로가 여전히 도달하는지 확인
   사람들에게 알림	로그인된 제품에서 한두 릴리스 동안 이전 위치에 포인터를 남기고, 이전 경로를 언급하는 도움말 문서, 둘러보기, 이메일 수정
   단어 유지	이전 레이블을 검색 동의어로 유지한 후 검색과 지원 요청을 모니터링

10. 검증은 tree-tests에 넘기세요. tree-tests가 계획과 작업을 작성합니다. 작업을 촉발한 각 문제, 확신이 없었던 모든 배치, 그리고 제안된 답변을 제공하세요. 목표: 최소 70% 성공률, 최상위 작업의 경우 80%, 경로 비율(path ratio) 최대 1.5.

결과물(Deliverable)

navigation-spec.md, 다음 순서로 작성:

1. 권장 사항(Recommendation): 두세 문장과 주요 이유.
2. 현재 상태(Current state): 각 표면, 개수, 문제점.
3. 옵션(Options): 배열당 한 행, 비용 포함.
4. 명세(The spec): 표면별 레이블과 대상, 각 Primary 항목이 슬롯을 차지하는 이유. 그 다음 브레드크럼 패턴, 모바일, 키보드, 활성 상태.
5. 정식 홈(Canonical homes): 각 문제 작업, 해당 작업의 유일한 홈, 그곳으로 연결되는 진입점.
6. 이전과 이후(Before and after): 모든 현재 항목과 이동 위치(폐기된 항목과 그 방법 포함).
7. 진입 규칙(Entry rule): 새로운 최상위 항목이 통과해야 하는 테스트.
8. 가정과 미해결 질문(Assumptions and open questions).
9. tree-tests로의 인계(Hand-off to tree-tests): 문제 작업, 확신이 없는 배치, 제안된 답변.

규모를 줄이세요. 메뉴 재검토는 진단, 새 트리, 각 문제 작업의 단일 홈, tree-tests로의 인계가 필요합니다. 콘텐츠 모델이나 URL 정책은 필요하지 않습니다. 문서가 길다고 더 철저한 것은 아닙니다. 모든 항목을 배치하라는 요청은 모든 항목에 홈이 있음을 의미합니다.

확인하기(Check it)

스크립트는 없습니다. 이 확인은 짧으며 명세를 읽어야 하므로 직접 수동으로 수행하고 실패한 부분을 수정하세요:

• Primary 항목 수 계산(최대 7개, 3~6개 권장) 및 탭 수 계산(최대 5개).
• 모든 현재 항목이 이전/이후 테이블에 새 위치 또는 명시된 폐기와 함께 나타나는지 확인.
• 모든 대상이 트리 또는 라우트에 존재하고, 모든 브레드크럼 부모가 실제 페이지이며, 사이드 레일, 브레드크럼 및 URL이 동일한 이야기를 전달하는지 확인.
• 각 문제 작업에 정확히 하나의 홈이 있고, 제안된 답변과 함께 tree-tests 인계 항목에 포함되는지 확인.
• 제공되지 않은 사용 현황 주장이 없는지 확인. 빈도 관련 단어는 가정으로 표시.

여기서 Claude가 할 수 없는 것

• 조직의 전략이나 정치를 알지 못함(알려주지 않는 한). 어떤 항목이 슬롯을 차지할지는 부분적으로 비즈니스 결정이므로 초안을 제시하고 누구의 결정인지 명시하세요.
• 트래픽, 사용 현황, 연구를 만들어내거나 실제 사람과 트리 테스트를 실행할 수 없음.
• 프레임워크의 메뉴 컴포넌트가 무엇을 하는지 말할 수 없음. 예상되는 바를 말하고 사용자에게 확인하라고 지시하세요. 플랫폼 지원이 다를 수 있기 때문입니다.

인계(Hand-off) 대상

• information-architecture: 작업이 여러 스킬에 걸쳐 있을 때의 진입 지점.
• sitemaps: 기본 트리를 변경해야 할 때.
• labeling: 항목의 문구를 작성하기 위해. taxonomies: 필터나 패싯이 실제 필요일 때.
• url-structure 및 redirect-maps: 대상 주소가 변경될 때. content-models: 컨텍스트 규칙 뒤에 필드가 필요할 때.
• tree-tests: 연구를 실행하기 위해. findability: 문제가 검색이나 단서(Scent)일 때. content-inventory 및 card-sort: 무엇이 있는지, 사람들이 어떻게 그룹화하는지 아무도 모를 때.