bbulman/information-architecture

정보 아키텍처

정보 아키텍처는 시스템의 콘텐츠와 기능을 사람들이 필요한 것을 찾고 무엇을 할 수 있는지 이해할 수 있도록 그룹화하고, 레이블을 지정하며, 연결하는 방법입니다. 모든 결정은 하나의 테스트를 통과해야 합니다. 즉, 이 구조가 앞에 있는 사람이 빠르게, 설명 없이도 올바른 선택을 할 수 있도록 돕는가?

이는 다른 모든 것의 상위에 있습니다. 잘못된 구조는 콘텐츠가 제자리를 찾지 못하게 하고, 디자인이 불필요한 네비게이션을 추가해야 하며, 검색에서 URL이 계속 변경되고, CMS는 임시방편의 연속이 됩니다.

이 스킬은 작업의 범위를 정하고 전체에 적용되는 규칙을 담고 있습니다. 실제 작업은 아래 스킬들에 포함됩니다.

1. 작업 선택

대부분의 요청은 전체 도구 세트가 아닌 일부만 필요합니다. 무엇을 만들지 명확히 하여 상대방이 무엇을 받을지 알 수 있게 하세요.

작업	순서대로 실행할 항목
기존 콘텐츠 재구성	content-inventory, card-sort 또는 taxonomies, sitemaps, 주소가 변경되는 경우 url-structure, tree-tests, redirect-maps
새 사이트, 앱 영역 또는 섹션	sitemaps, navigation, url-structure, content-models
메뉴, 네비게이션 또는 앱 전환기 재검토	navigation, labeling, tree-tests
태그 및 카테고리	taxonomies
제대로 작동하지 않는 이름	labeling
"사람들이 X를 찾을 수 없음"	findability, 이후 진단이 가리키는 스킬 실행
사이트 이동 또는 재구축	sitemaps, navigation, url-structure, content-models, redirect-maps
구축 전 구조 확인	tree-tests
AI 기능 또는 제품	여기 5절 참조, 이후 findability

사이트맵만으로는 장식에 불과합니다. 사이트 구축의 경우 전체 세트는 사이트맵, URL 규칙, 네비게이션 명세, 콘텐츠 모델, 그리고 재구축 시 리디렉션 맵입니다. 이 네 가지가 없으면 누구도 이를 기반으로 구축할 수 없습니다.

형제 스킬을 사용할 수 없는 경우, 아래 규칙을 사용하여 해당 부분을 여기서 처리하고 그 사실을 명시하세요.

2. 프레임 설정 후 현재 상태 파악

어떤 경로를 선택하기 전에, 이 시스템을 사용하는 사람과 그들이 하려는 작업, 현재 및 2년 후 콘텐츠 양, 비즈니스가 원하는 것, 그리고 성공 측정 방법을 확정하세요. 변경 전에 해당 측정값의 현재 수치를 기록하세요. 그렇지 않으면 이후 비교할 대상이 없습니다.

그런 다음 현재 그림을 구축하세요. 홈페이지만 보고 재설계하지 마세요.

• 코드베이스: 라우트, 네비게이션 컴포넌트, sitemap.xml, CMS 스키마, 카테고리 또는 태그 테이블을 확인하세요. 섹션별 항목 수를 세세요. 비어 있거나 과적된 섹션은 그 자체로 발견 사항입니다.
• 콘텐츠 폴더: 한 번에 하나의 항목이 아닌 전체 코퍼스를 조사하세요. 그것이 무엇이고 누구를 대상으로 하는지 설명하고, 잘못된 해석 위에 구축하기 전에 상대방이 수정할 기회를 주세요.
• 데이터베이스 또는 CMS의 콘텐츠: 먼저 제목, 유형, 태그 및 날짜를 내보내세요.
• 매우 큰 세트: 유형별로 조사하고 각 유형 내에서 샘플링하세요. 샘플링한 내용을 명시하여 샘플을 전체 조사로 오해하지 않도록 하세요.

또한 사람만 알고 있는 정보도 요청하세요. 즉, 대상 사용자와 그들의 주요 작업, 조직의 방향, 분석 데이터, 사이트 검색 로그, 그리고 지원팀이 계속 답변하고 있는 질문들입니다.

3. 전체 작업에 적용되는 규칙

• 조직도를 기준으로 하지 말고 사람들이 하려는 작업을 기준으로 구조화하세요. "회사 소개, 엔지니어링, API"보다 "개발자를 위한 API"가 낫습니다.
• 각 항목에 하나의 정식 위치를 부여하세요. 다른 곳에서 링크될 수는 있지만, 항목은 한 곳에만 존재합니다.
• 클릭 수보다 단서(scent)를 유지하세요. 각 단계가 목표처럼 보이면 사람들은 더 많이 클릭합니다. 세 번 클릭 규칙은 신화입니다. 막다른 길과 모호한 레이블이 실제 비용입니다.
• 10배의 콘텐츠를 대비해 설계하세요. 카테고리가 성장할 경우, 지금부터 설계하세요.
• 여러 가지 진입점을 제공하세요. 탐색, 검색, 필터, 관련 링크, 브레드크럼.
• 결정이 이루어지는 곳에 단서를 배치하세요. 좋은 단서는 사람이 이미 가지고 있는 질문에, 선택하는 순간에, 이미 보고 있는 곳에서, 조용하고 저렴하게 답변합니다.
• 다음으로 큰 맥락을 위해 설계하세요. 페이지는 섹션 안에, 섹션은 사이트 안에, 사이트는 비즈니스 안에 있습니다.

4. IA 작업을 하는 AI로서

잘하는 것: 몇 분 안에 전체 코퍼스를 읽고, 대체 체계를 제안하며, 수천 개의 항목에 일관되게 분류 체계를 적용하고, 유사한 용어를 찾아내며, 어디에도 맞지 않는 항목을 식별합니다.

할 수 없는 것: 실제 사람과 카드 소팅이나 트리 테스트를 실행하거나, 알려주지 않는 한 조직의 전략과 정치를 알 수 없습니다. 따라서:

• 제안하되, 결정하지 마세요. 각각의 장단점이 있는 두세 가지 체계를 제시하고, 하나를 추천하며 그 이유를 설명하세요. 단일 답변은 결정을 숨깁니다.
• 먼저 대상과 방향을 파악하세요. 누구를 위한 것인지, 제품의 방향이 무엇인지 알려주지 않았다면 물어보거나, 상단에 가정을 명시하세요.
• 요청받은 모든 항목을 배치하세요. 맞지 않는 항목은 가장 덜 나쁜 위치에 배치하고 플래그를 표시하며, 이동, 병합 또는 폐기에 대한 사례는 별도의 권장 사항으로 제시하세요.
• 요청된 모든 산출물을 제공하세요. 산출물이 필요 없다고 생각되더라도 일단 제공하고 별도로 그 사유를 제시하세요.
• 연구 데이터를 절대 만들어내지 마세요. 허구의 참가자 수, 성공률, 티켓 볼륨, 인용문 또는 빈도를 사용하지 마세요. "매시간 사용"을 사실로 진술하는 것은 안 됩니다. "아마도"라고 말하고 가정으로 나열하세요.
• 플랫폼 동작을 추측하지 마세요. 호스트나 CMS가 할 수 있는 일은 다양합니다. 기대하는 바를 말하고 확인하도록 안내하세요.
• 콘텐츠를 보호하세요. 콘텐츠, 메타데이터, 라우트 또는 리디렉션을 제자리에서 편집하기 전에 작업이 버전 관리되거나 백업되었는지 확인하세요.

5. AI 제품 및 에이전트 컨텍스트를 위한 IA

제품에 AI를 추가하기 전에 실제로 방해가 되는 것이 무엇인지 살펴보세요. 사람들이 시스템 작동 방식을 알 수 없거나, 카테고리를 구분할 수 없거나, 같은 질문을 계속해야 한다면, 더 명확한 구조, 더 나은 레이블 또는 잘 배치된 단서가 채팅 상자보다 더 저렴하게 문제를 해결할 것입니다. 버튼과 메뉴는 두 가지 역할을 합니다. 사람들이 행동할 수 있게 하고, 시스템이 무엇을 할 수 있는지 보여줍니다. 개방형 채팅은 첫 번째 역할을 느리게 하고 두 번째 역할은 전혀 하지 않습니다. 작업이 실제로 개방형인 경우에만 채팅을 사용하고, 그 외에는 구조화된 인터페이스 뒤에서 AI를 사용하세요.

에이전트를 위한 컨텍스트도 IA 문제입니다. 모델에게 적절한 정보를 적시에 제공하세요. 즉, 더 깊은 파일을 가리키는 짧은 진입 파일, 각 사실에 대한 하나의 정식 위치, 일관된 이름, 그리고 작업에 필요하지 않은 것은 로드하지 않는 것입니다.

6. 작업이 여러 스킬에 걸쳐 있는 경우

달리 요청받지 않는 한, 다음 내용이 포함된 하나의 문서를 반환하세요:

1. 요약: 두세 문장으로 된 권장 사항과 주요 이유.
2. 현재 상태: 현재 트리와 그 안의 문제점(수치 포함).
3. 옵션: 두세 가지 체계, 각 체계가 누구에게 서비스를 제공하는지, 비용 및 부담이 되는 부분.
4. 제안: 권장 트리와 각 노드의 템플릿 유형, 레이블 및 네비게이션 명세, 관련 URL 규칙 및 콘텐츠 모델.
5. 마이그레이션: 이동하는 항목이 있는 경우 이전-새 매핑 및 재태그 지정 참고 사항.
6. 가정 및 미해결 질문: 추측한 모든 것.
7. 검증 방법: 정답과 목표가 포함된 트리 테스트 작업 또는 먼저 실행할 카드 소트.

작업 규모에 맞게 조정하세요. 권장 사항을 먼저 제시하고, 각 섹션을 사용 가능한 수준으로 최대한 짧게 유지하며, 긴 테이블은 끝으로 미루세요. 문서가 길다고 더 철저한 것은 아닙니다.

전달하기 전에 문서가 자체적으로 일관된지 확인하세요. 배치 테이블에 대해 총계를 다시 계산하고, 작성한 테이블에 대해 명시한 모든 규칙을 확인하며, 경로 길이에 대한 모든 주장을 트리에서 추적하고, 제공하는 모든 배송 가능 파일이 계획의 모든 행을 구현하는지 확인하세요.

정보 아키텍처를 검토할 때(자신의 것이든 다른 사람의 것이든) references/rubric.md로 평가하세요.

7. 발견 시 명명할 패턴

• 조직도 네비게이션: 부서 이름을 딴 섹션.
• 두 개의 경쟁 분류 체계: 사이드 레일, 브레드크럼 및 URL이 각각 다른 것을 말함.
• 하나의 우산 아래 모든 것: 모든 섹션이 /services/<thing> 아래에 있으며, URL이 있는 정크 서랍.
• 자리 표시자 섹션: 출시되는 "Coming soon" 페이지. 구축하거나 제외하세요.
• 구조 대신 채팅 상자: 명확한 옵션이 질문에 더 빨리 답하고 시스템 작동 방식을 가르쳐 줄 수 있는 곳에 개방형 AI 인터페이스를 사용.