Communitygithub.com

bbulman/findability

사용자가 무언가를 찾지 못할 때, 사이트 검색이 결과를 반환하지 않거나 잘못된 결과를 반환할 때, 검색 로그 분석이 필요할 때, 베스트 베트(best bets)나 동의어 설정이 필요할 때, 결과 없음 페이지를 디자인해야 할 때, 또는 '아무것도 찾을 수 없어서' 챗봇이 제안될 때 사용합니다. 전체 페이지 트리를 다시 그리거나, 메뉴 이름만 단독으로 변경하거나, 트리 테스트를 실행하는 용도는 아닙니다.

findability란 무엇인가요?

이 스킬은 '사람들이 찾을 수 없다'는 문제의 네 가지 일반적인 원인을 진단하고, 가장 저렴한 해결책을 선택하며, 성공 여부를 측정할 지표를 설정하는 체계적인 방법을 제공합니다. AI 어시스턴트가 검색 로그, 분석 데이터, 사용자 피드백을 분석하여 문제가 콘텐츠 자체의 부재, 잘못된 레이블, 깊은 경로, 또는 검색 엔진 실패 중 어떤 것인지 진단하도록 돕습니다. 진단 결과에 따라 베스트 베트, 동의어, 내비게이션 개선, 결과 없음 페이지 디자인 등 구체적인 수정 사항을 제안하고, 측정 가능한 지표를 설정하여 개선 효과를 추적할 수 있도록 합니다. 챗봇이 '아무것도 찾을 수 없는' 문제의 해결책으로 제안될 때, 그것이 적절한지 먼저 테스트하고 더 나은 대안을 제시하는 기능도 포함합니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/bbulman/information-architecture-skill/tree/HEAD/skills/findability

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

파인더빌리티 (Findability)

"사람들이 찾을 수 없습니다"라는 증상에는 일반적으로 네 가지 원인이 있으며, 각각 다른 해결 방법이 필요합니다. 이 스킬은 무엇을 먼저 변경할지 결정하는 데 도움을 줍니다. 즉, 불만 사항에서 원인을 분리하고, 이를 해결하는 가장 저렴한 수정 방안을 선택하며, 효과가 있었는지 보여주는 측정 지표를 설정합니다.

시작하기 전에

필요한 것없을 경우
사람들이 무엇을 찾을 수 없는지, 그들이 누구인지, 그리고 어디서 찾았는지질문하십시오. 모호하다면, 후보들을 나열하고 가설로 취급하십시오.
사이트, 앱, 또는 적어도 그 내비게이션질문하십시오. 이것 없이는 진단 계획만 작성할 수 있습니다.
검색 로그 (CSV 형식): query,count,results, 가능한 경우 clicks무엇을 내보내야 하는지, 어떤 기간 동안인지 말씀해 주십시오. 진단 계획, 측정 지표, 빈 테이블을 제공하십시오. 로그가 무엇을 말했을지 추정하지 마십시오.
분석 데이터, 지원 문의, 인벤토리어떤 결론을 바꿀지 말하고, 해당 결론을 '미확인'으로 표시하십시오.

방법

  1. 실패를 작업으로 작성하십시오. "[누가] [목표]를 위해 [어디]에서 [무엇]을 찾으려고 했는데, [어떤 일이] 발생했습니다." 불만 사항당 한 줄씩, 그들의 말 그대로 작성하십시오.

  2. 로그를 읽고 그 숫자를 사용하십시오.

    node "${CLAUDE_SKILL_DIR}/scripts/search-log.mjs" searches.csv
    

    로그가 순위를 매기기에는 너무 작다고 말하면, 사람들이 입력한 단어 목록으로 사용하고 비율은 명시하지 마십시오. 내보내기 기간을 말하십시오; 스크립트는 알 수 없습니다.

  3. 처방하기 전에 진단하십시오. 다음 순서대로 원인을 분석하십시오. 각 원인은 이전 원인에 기반하기 때문입니다. 여러 원인이 동시에 적용될 수 있습니다. 각 결론을 '확인됨' 또는 '추론됨'으로 표시하십시오.

    원인확인 방법일반적인 수정스킬
    누락: 존재하지 않음사람들이 사용하는 모든 이름으로 찾아보십시오. 일치하는 콘텐츠가 전혀 없는 결과 0건 쿼리생성하거나, 제공되지 않음을 명확히 말하십시오content-inventory
    잘못된 레이블: 다른 이름으로 존재함그들의 단어가 결과 0건이거나 클릭이 없지만 콘텐츠는 다른 이름으로 존재함; pogo-sticking 발생이름 변경, 동의어 추가labeling
    깊이 숨겨짐: 이름은 좋지만, 접근 경로가 없음홈과 허브로부터의 단계를 세어보십시오; 고립된 페이지, 막다른 길, 유일한 경로인 깊은 페이지 매김, 해당 콘텐츠를 제공해야 할 섹션 페이지에서 시작된 검색을 찾으십시오사람들이 이미 찾는 곳에 링크를 추가하거나 이동하십시오navigation, sitemaps
    검색 실패: 존재하고, 쿼리와 일치하지만, 결과가 잘못됨상위 쿼리를 직접 실행하고 결과를 읽으십시오; 클릭이 없는 결과, 재구문, 결과 페이지 이탈베스트 베트, 동의어, 인덱스 범위, 랭킹Step 5

    많은 파인더빌리티 문제는 검색 엔진보다 레이블과 그룹화를 수정하는 것이 더 저렴하므로, 엔진부터 시작하지 마십시오. 깊이 자체가 결함은 아닙니다: 세 번 클릭 규칙은 신화이며, 각 단계가 목표와 명확하게 관련되어 있다고 느껴질 때 사람들은 더 많이 클릭합니다.

  4. 어떤 경로가 작동해야 하는지 결정하십시오. 탐색과 검색을 모두 지원하십시오. 사람들은 둘 사이를 전환하기 때문입니다. 상위 쿼리는 홈에서 한 두 단계 안에 도달할 수 있어야 합니다.

    사람 유형강화할 경로
    정확한 이름을 아는 경우검색, 또는 A to Z 목록
    필요는 알지만 이름을 모르는 경우명확한 레이블로 탐색, 그 다음 패싯
    탐색 중이거나 비교 중인 경우탐색, 필터, 관련 링크
    이전에 보던 것으로 돌아오는 경우최근 항목, 저장된 보기, 바로가기
    작업 중간인 경우작업 중인 곳의 컨텍스트 링크 또는 신호
  5. 원인이 검색일 때 검색을 수정하십시오. 상위 쿼리에 대해 큐레이팅된 베스트 베트를 결과 상단에 배치하십시오. 스크립트의 변형 그룹에서 동의어 세트를 구축하되, SYNONYM WOULD ANSWER로 표시된 것부터 시작한 다음, 사람만이 발견할 수 있는 약어나 전문 용어 등을 추가하십시오. 결과 없음 페이지가 막다른 길이 되지 않도록 하십시오. references/search-tuning.md에서 세 가지 모두와 내보내야 할 사항을 다룹니다.

  6. 결정이 이루어지는 곳에 신호를 배치하십시오. 좋은 신호는 사람이 이미 가지고 있는 질문에, 선택을 하는 순간에, 이미 보고 있는 곳에서, 조용하고 저렴하게 답변합니다. 자동차 연료 게이지 옆에 연료 주입구 방향을 보여주는 화살표가 그 모델입니다. 신호나 개인화된 진입점을 추가하기 전에 references/routes-and-cues.md를 읽으십시오.

  7. 누군가 AI 채팅을 해결책으로 제안한다면, 먼저 테스트하십시오. 버튼과 메뉴를 통해 사람들은 행동할 수 있고 시스템이 무엇을 할 수 있는지 보여줍니다. 열린 채팅 상자는 첫 번째 작업을 느리게 하고 두 번째 작업은 전혀 하지 않습니다.

    상황더 나은 답변
    제한적이고 알 수 있는 옵션 집합버튼, 메뉴 또는 필터
    사람들이 시스템이 무엇을 할 수 있는지 모름눈에 보이는 구조; 빈 상자는 아무것도 가르쳐주지 않음
    알려진 단계가 있는 반복 작업직접 경로
    콘텐츠 누락 또는 잘못된 레이블먼저 수정하십시오; 채팅은 없는 것을 검색할 수 없음
    진정으로 개방형이며 매번 다르게 표현됨채팅이 그 자리를 차지할 수 있으며, 그 주변에 구조가 있어야 함
  8. 실제로 수집할 수 있는 측정 지표를 설정하십시오. 변경하기 전에 기준선을 확보하고, 문제당 하나의 측정 지표를 설정하십시오. 기준선이 없으면 그렇게 말하십시오.

    측정 지표출처목표
    간단한 항목을 찾는 시간사람들을 대상으로 한 시간 제한 작업 테스트30초 미만
    작업 성공률작업 테스트 또는 트리 테스트최소 70%, 상위 작업의 경우 80%
    검색 결과 0건 비율검색 로그자체 기준선 미만
    검색 이탈, 재구문분석 (결과 페이지가 추적되는 경우)자체 기준선 미만
    이 주제에 대한 지원 문의량헬프 데스크 (태깅된 경우)자체 기준선 미만

    references/measures.md에서 각 지표가 무엇을 보여줄 수 있고 보여줄 수 없는지 설명합니다.

결과물

사용자가 다른 파일 이름을 지정하지 않는 한 findability-diagnosis.md 파일을 다음 순서로 작성하십시오: 권장 사항 (두세 문장); 실패 내용 (작업 형태); 증거 (출처, 기간, 스크립트 숫자); 진단 (항목, 원인, 증거, 확인됨 또는 추론됨); 옵션 (두세 가지, 각각의 비용과 해결되지 않는 부분 포함); 수정 목록 (순서대로, 각각을 담당할 스킬 포함); 베스트 베트 및 동의어 (query, action, target); 결과 없음 페이지 (해당되는 경우); 측정 지표 (이름, 기준선, 목표, 출처, 재확인 날짜); 가정 및 사용할 수 없었던 것.

작업반환할 내용
아무도 찾을 수 없는 한 가지실패, 원인, 증거, 수정 및 하나의 측정 지표를 답변에 포함
읽을 검색 로그증거, 베스트 베트 및 동의어, 결과 0건 발생 간격
"사이트 전반적으로 파인더빌리티가 나쁘다"전체 문서

긴 테이블은 마지막에 배치하십시오. 문서가 길다고 더 철저한 것은 아닙니다.

확인 사항

  • 모든 숫자는 스크립트 실행 또는 사용자가 제공한 출처에서 비롯됩니다. 로그가 변경된 경우 스크립트를 다시 실행하십시오.
  • 모든 수정 사항은 해결하는 원인을 명시하고, 모든 원인에는 증거가 있거나 '추론됨'으로 표시되어 있습니다.
  • 접근 권한이 있다면 상위 쿼리를 직접 실행해 보았습니다. 로그만으로는 결과가 좋았는지 알 수 없기 때문입니다.
  • 제안된 각 동의어가 동일한 의미인지 확인했습니다. 스크립트는 철자별로 그룹화하므로 의미가 다른 단어를 짝지을 수 있습니다.
  • 검색 로그에는 검색 상자에 입력된 이름과 이메일이 포함될 수 있습니다. 스크립트는 이메일 주소를 숨깁니다. 다른 개인 정보는 보고서에 복사하지 마십시오.

여기서 Claude가 할 수 없는 일

실제 사용자가 검색하는 것을 지켜보거나, 시간을 측정하거나, 조직의 전략을 알지 않는 한 알 수 없습니다. 사용량 숫자, 검색량, 성공률, 인용문을 절대 만들어내지 마십시오. 데이터가 없는 측정 지표는 아직 수집되지 않은 것으로 표시하십시오. 대안을 장단점과 함께 제안하고, 하나를 추천하고 그 이유를 말하십시오; 결정권자는 사람에게 있습니다. 검색 제품이 할 수 있는 일(동의어, 고정 결과, 쿼리 로깅)은 다양하므로, 기대하는 바를 말하고 사용자에게 확인을 요청하십시오.

다음 단계로 넘어가는 곳

다음 필요 사항스킬
무엇이 존재하는지 알아내기content-inventory
이름이 잘못됨labeling
용어와 필터 작업 필요taxonomies
그룹이 사람들의 사고 방식과 일치하지 않음card-sort
접근 경로 누락navigation, sitemaps
변경된 계층 구조 테스트tree-tests
패싯 또는 미리보기에 필요한 필드content-models
페이지 이동url-structure, redirect-maps
전체 사이트 재구조화 또는 시작 위치 불확실information-architecture

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

bbulman/information-architecture

Use when someone wants to organize, restructure or review how a site, app, docs set, knowledge base or content library is grouped and found, and the job spans several pieces or it isn't yet clear which piece is needed, even if they never say "information architecture" or "IA". Not for a job that is clearly one piece, such as only a tree test or only a redirect map, and not for visual design.

bbulman/labeling

Use when someone needs to name or rename a section, menu item, tab, category, feature or link, when labels feel vague or read like internal jargon, or when they ask "what should we call this", "is this label clear", "nobody knows what Resources means" or "people don't understand this menu". Not for deciding the structure behind the labels, building a tag vocabulary, or writing body copy and microcopy.

bbulman/navigation

Use when someone wants a navigation or menu designed, audited or cut down, including a main menu, nav bar, sidebar, app switcher, mega-menu, footer, breadcrumbs, tab bar or mobile menu, or says "there are too many items in the menu", "rethink the sidebar", "our nav is a mess" or "where should settings go". Not for deciding which pages exist, for wording a single label, for fixing site search, or for running a tree test.

bbulman/sitemaps

Use when someone needs the structure of a website, app or docs set decided, asking for a sitemap, site tree, page hierarchy or list of sections, or saying "what pages do we need", "how should we organise the site", "where should this page live" or "the site is too deep". This is where the structure gets decided. Not for writing the linked sitemap file that later design stages read once the structure is settled (design-os:create-sitemap), for generating sitemap.xml, or for designing the menus.

관련 스킬