내부 검색이 불편하다는 의견이 있다고 곧바로 새 검색 시스템부터 도입할 필요는 없다. 실제 실패 사례를 모으면 자료가 없어서 생긴 문제와 자료는 있는데 못 찾는 문제가 나뉜다. 검색어, 기대한 문서, 나온 결과를 함께 기록하는 것이 첫 작업이다. 이 구분 없이 기능만 바꾸면 콘텐츠의 빈틈은 그대로 남고 유지할 도구만 늘어날 수 있다.
우선순위는 검색 횟수와 실패의 영향을 함께 본다. 자주 입력되는 단어라도 단순한 철자 차이라면 비교적 작은 수정으로 해결할 수 있다. 문의 방법이나 이용 조건처럼 중요한 자료를 찾지 못하는 문제는 빈도가 낮아도 검토 가치가 있다. 개인정보가 포함된 입력은 분석 자료를 공유할 때 불필요하게 노출되지 않도록 다루고 집계에 필요한 범위를 정한다.
편집 작업에는 제목과 설명 보완, 누락 자료 작성, 오래된 문서 정리가 들어간다. 개발 작업에는 검색 대상 설정이나 결과 표시 방식의 수정이 포함될 수 있다. 두 작업을 분리해 담당자를 정하되 목표 문서에 도달하는 공통 검증 사례를 남긴다. 결과 없음 화면도 실제로 작동하는 재검색과 분류 이동 경로가 있는지 확인한다.
작은 범위의 수정부터 적용하고 같은 검색어로 다시 확인한다. 처리한 항목 수만 세지 말고 기대한 문서를 찾을 수 있게 됐는지 기록한다. 해결되지 않은 경우에는 검색 규칙과 원문 내용 중 무엇을 더 봐야 하는지 적는다. 이후 운영 시간에는 새로운 실패 검색어를 검토하는 시간을 남겨 두어, 초기 정비 뒤에 생긴 문제도 작업 목록으로 들어오게 한다.
실패 검색어를 고를 때는 대표 문서가 실제로 존재하는지 먼저 확인한다. 검색 기능을 고쳐도 답이 없는 질문은 해결되지 않는다. 반대로 공개된 안내가 있는데 결과 목록의 제목이 모호해 선택하지 못한다면 신규 글 작성보다 제목과 설명 정리가 우선일 수 있다. 같은 실패라도 자료 부재, 발견 실패, 선택 실패를 구분하면 예산을 투입할 위치가 달라진다.
개선안을 시험할 검색어는 수정 전에 고정해 둔다. 결과가 좋아 보이는 단어만 나중에 골라 비교하면 실제로 해결한 범위를 알기 어렵다. 띄어쓰기나 짧은 표현처럼 이용자가 자연스럽게 입력할 변형을 함께 남기되, 모든 변형을 별도 콘텐츠로 만들 필요는 없다.
개발과 편집이 모두 필요한 문제는 완료 조건을 공동으로 정한다. 제목을 수정했지만 검색 결과에 예전 설명이 남는다면 편집 작업 완료와 검색 반영 완료를 나누어 둔다. 새 기능 도입을 검토할 때도 먼저 해결할 실제 질문 묶음을 제시해야 기능 목록이 아니라 이용자가 찾을 답을 기준으로 효과를 확인할 수 있다.
검색 결과가 아니라 도착한 문서의 답까지 확인한다.