파인더빌리티 (Findability)
"사람들이 찾을 수 없습니다"라는 증상에는 일반적으로 네 가지 원인이 있으며, 각각 다른 해결 방법이 필요합니다. 이 스킬은 무엇을 먼저 변경할지 결정하는 데 도움을 줍니다. 즉, 불만 사항에서 원인을 분리하고, 이를 해결하는 가장 저렴한 수정 방안을 선택하며, 효과가 있었는지 보여주는 측정 지표를 설정합니다.
시작하기 전에
| 필요한 것 | 없을 경우 |
|---|---|
| 사람들이 무엇을 찾을 수 없는지, 그들이 누구인지, 그리고 어디서 찾았는지 | 질문하십시오. 모호하다면, 후보들을 나열하고 가설로 취급하십시오. |
| 사이트, 앱, 또는 적어도 그 내비게이션 | 질문하십시오. 이것 없이는 진단 계획만 작성할 수 있습니다. |
검색 로그 (CSV 형식): query,count,results, 가능한 경우 clicks | 무엇을 내보내야 하는지, 어떤 기간 동안인지 말씀해 주십시오. 진단 계획, 측정 지표, 빈 테이블을 제공하십시오. 로그가 무엇을 말했을지 추정하지 마십시오. |
| 분석 데이터, 지원 문의, 인벤토리 | 어떤 결론을 바꿀지 말하고, 해당 결론을 '미확인'으로 표시하십시오. |
방법
-
실패를 작업으로 작성하십시오. "[누가] [목표]를 위해 [어디]에서 [무엇]을 찾으려고 했는데, [어떤 일이] 발생했습니다." 불만 사항당 한 줄씩, 그들의 말 그대로 작성하십시오.
-
로그를 읽고 그 숫자를 사용하십시오.
node "${CLAUDE_SKILL_DIR}/scripts/search-log.mjs" searches.csv로그가 순위를 매기기에는 너무 작다고 말하면, 사람들이 입력한 단어 목록으로 사용하고 비율은 명시하지 마십시오. 내보내기 기간을 말하십시오; 스크립트는 알 수 없습니다.
-
처방하기 전에 진단하십시오. 다음 순서대로 원인을 분석하십시오. 각 원인은 이전 원인에 기반하기 때문입니다. 여러 원인이 동시에 적용될 수 있습니다. 각 결론을 '확인됨' 또는 '추론됨'으로 표시하십시오.
원인 확인 방법 일반적인 수정 스킬 누락: 존재하지 않음 사람들이 사용하는 모든 이름으로 찾아보십시오. 일치하는 콘텐츠가 전혀 없는 결과 0건 쿼리 생성하거나, 제공되지 않음을 명확히 말하십시오 content-inventory 잘못된 레이블: 다른 이름으로 존재함 그들의 단어가 결과 0건이거나 클릭이 없지만 콘텐츠는 다른 이름으로 존재함; pogo-sticking 발생 이름 변경, 동의어 추가 labeling 깊이 숨겨짐: 이름은 좋지만, 접근 경로가 없음 홈과 허브로부터의 단계를 세어보십시오; 고립된 페이지, 막다른 길, 유일한 경로인 깊은 페이지 매김, 해당 콘텐츠를 제공해야 할 섹션 페이지에서 시작된 검색을 찾으십시오 사람들이 이미 찾는 곳에 링크를 추가하거나 이동하십시오 navigation, sitemaps 검색 실패: 존재하고, 쿼리와 일치하지만, 결과가 잘못됨 상위 쿼리를 직접 실행하고 결과를 읽으십시오; 클릭이 없는 결과, 재구문, 결과 페이지 이탈 베스트 베트, 동의어, 인덱스 범위, 랭킹 Step 5 많은 파인더빌리티 문제는 검색 엔진보다 레이블과 그룹화를 수정하는 것이 더 저렴하므로, 엔진부터 시작하지 마십시오. 깊이 자체가 결함은 아닙니다: 세 번 클릭 규칙은 신화이며, 각 단계가 목표와 명확하게 관련되어 있다고 느껴질 때 사람들은 더 많이 클릭합니다.
-
어떤 경로가 작동해야 하는지 결정하십시오. 탐색과 검색을 모두 지원하십시오. 사람들은 둘 사이를 전환하기 때문입니다. 상위 쿼리는 홈에서 한 두 단계 안에 도달할 수 있어야 합니다.
사람 유형 강화할 경로 정확한 이름을 아는 경우 검색, 또는 A to Z 목록 필요는 알지만 이름을 모르는 경우 명확한 레이블로 탐색, 그 다음 패싯 탐색 중이거나 비교 중인 경우 탐색, 필터, 관련 링크 이전에 보던 것으로 돌아오는 경우 최근 항목, 저장된 보기, 바로가기 작업 중간인 경우 작업 중인 곳의 컨텍스트 링크 또는 신호 -
원인이 검색일 때 검색을 수정하십시오. 상위 쿼리에 대해 큐레이팅된 베스트 베트를 결과 상단에 배치하십시오. 스크립트의 변형 그룹에서 동의어 세트를 구축하되,
SYNONYM WOULD ANSWER로 표시된 것부터 시작한 다음, 사람만이 발견할 수 있는 약어나 전문 용어 등을 추가하십시오. 결과 없음 페이지가 막다른 길이 되지 않도록 하십시오. references/search-tuning.md에서 세 가지 모두와 내보내야 할 사항을 다룹니다. -
결정이 이루어지는 곳에 신호를 배치하십시오. 좋은 신호는 사람이 이미 가지고 있는 질문에, 선택을 하는 순간에, 이미 보고 있는 곳에서, 조용하고 저렴하게 답변합니다. 자동차 연료 게이지 옆에 연료 주입구 방향을 보여주는 화살표가 그 모델입니다. 신호나 개인화된 진입점을 추가하기 전에 references/routes-and-cues.md를 읽으십시오.
-
누군가 AI 채팅을 해결책으로 제안한다면, 먼저 테스트하십시오. 버튼과 메뉴를 통해 사람들은 행동할 수 있고 시스템이 무엇을 할 수 있는지 보여줍니다. 열린 채팅 상자는 첫 번째 작업을 느리게 하고 두 번째 작업은 전혀 하지 않습니다.
상황 더 나은 답변 제한적이고 알 수 있는 옵션 집합 버튼, 메뉴 또는 필터 사람들이 시스템이 무엇을 할 수 있는지 모름 눈에 보이는 구조; 빈 상자는 아무것도 가르쳐주지 않음 알려진 단계가 있는 반복 작업 직접 경로 콘텐츠 누락 또는 잘못된 레이블 먼저 수정하십시오; 채팅은 없는 것을 검색할 수 없음 진정으로 개방형이며 매번 다르게 표현됨 채팅이 그 자리를 차지할 수 있으며, 그 주변에 구조가 있어야 함 -
실제로 수집할 수 있는 측정 지표를 설정하십시오. 변경하기 전에 기준선을 확보하고, 문제당 하나의 측정 지표를 설정하십시오. 기준선이 없으면 그렇게 말하십시오.
측정 지표 출처 목표 간단한 항목을 찾는 시간 사람들을 대상으로 한 시간 제한 작업 테스트 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 |