TL;DR
기획 인터뷰에서는 원하는 기능보다 고객이 선택 전에 확인했던 질문을 모으는 편이 유용합니다. 실제 문의 기록에서 개인 식별 정보를 제거하고, 질문이 생긴 상황과 판단에 필요했던 답을 함께 정리하면 페이지에 넣을 정보가 구체화됩니다.
내부의 주장과 고객의 질문을 분리하기
우리는 신뢰할 수 있는 회사라는 내부 표현은 고객이 어떻게 확인할지까지 설명하지 않습니다. 반면 담당자가 직접 작업하는지, 어디까지 제공하는지, 요청 전에 무엇을 준비해야 하는지는 실제 선택에 필요한 질문입니다. 인터뷰에서는 강점을 말해 달라고만 묻지 말고 최근 고객이 무엇을 되물었는지 구체적으로 요청해 보세요.
Google은 의도한 독자가 직접 찾아와도 유용하게 느낄 콘텐츠인지 평가하도록 안내합니다. 검색어를 꾸미기 전에 실제 고객의 판단을 돕는 질문을 확보하는 이유입니다. 다만 인터뷰에 나온 질문 한 건을 전체 고객의 공통 요구로 단정하지 않습니다. 어떤 상황에서 나온 질문인지 함께 보존해야 과도하게 일반화하지 않을 수 있습니다.
기록에서 개인 정보를 덜어내고 과제를 남기기
문의 메일을 기획 자료에 통째로 복사할 필요는 없습니다. 고객 이름과 연락처, 내부 금액, 민감한 사업 계획은 제거하고 질문의 의미를 옮깁니다. 예를 들어 특정 고객의 이름 대신 운영 담당자가 기존 자료를 이관할 수 있는지 물었다는 식으로 기록할 수 있습니다. 원문 보관이 필요한 업무라면 접근 범위와 사용 목적을 별도로 정해야 합니다.
페이지원이 제안하는 질문 카드에는 상황, 독자가 확인하려는 내용, 현재 답변 위치, 부족한 근거를 둡니다. 문의를 많이 받은 순서만으로 중요도를 정하지 말고, 답이 없을 때 다음 행동을 멈추게 되는 질문인지 살펴봅니다. 드물어도 계약 전 오해를 막는 질문은 화면에서 명확히 설명할 이유가 있습니다.
Google은 실제 경험과 깊이 있는 지식이 콘텐츠에 드러나는지를 유용성 평가 항목으로 제시합니다. 실무 담당자의 반복 설명과 예외 처리 경험은 일반적인 회사 소개 문장보다 구체적인 자료가 될 수 있습니다. 실제 경험이 아닌 가상 예시라면 예시라고 밝혀야 하고, 고객 사례를 공개할 수 있다는 뜻으로 해석해서는 안 됩니다.
질문을 페이지에 배치하는 결정
서비스의 포함 범위 질문은 서비스 상세에서 먼저 답하고, 회사의 작업 방식은 과정 안내에서 풀 수 있습니다. 문의 작성 시 필요한 입력 정보는 폼 가까이에 두는 것이 자연스럽습니다. 모든 질문을 FAQ 한 화면에 몰아두면 사용자가 필요한 순간에 답을 발견하지 못할 수 있습니다. 질문 카드에 가장 먼저 만날 위치와 추가 설명 위치를 따로 적어 두세요.
MDN은 폼을 설계하기 전에 필요한 데이터를 생각하고 간단한 초안을 만들 것을 권합니다. 인터뷰에서 수집한 질문은 문의 폼 항목을 고르는 근거로도 쓸 수 있습니다. 고객이 먼저 설명하기 어려워하는 전문 분류를 필수로 요구하기보다 담당자가 후속 대화에서 확인할 수 있는지 판단합니다. 고객 질문을 수집해 놓고 폼에서는 내부 분류만 강요하지 않는지 함께 점검해야 합니다.
관측하지 않은 빈도는 만들지 않기
기록이 충분하지 않다면 자주 묻는 질문이라고 확정하기보다 문의 전에 확인할 내용이라고 표현할 수 있습니다. 인터뷰한 담당자와 확인한 자료의 범위를 기록하고, 실제 운영에서 추가로 나온 질문을 같은 카드에 보완합니다. 질문이 반복돼도 답이 같으면 한 항목으로 묶고, 비슷한 표현이라도 조건이 다르면 차이를 남깁니다.
마무리
인터뷰 결과를 전달할 때는 질문을 얻은 맥락도 적습니다. 신규 방문자의 질문과 이미 계약한 고객의 운영 질문은 필요한 위치가 다릅니다. 계약 뒤에만 필요한 자세한 절차를 첫 화면에 모두 올리기보다, 공개 안내와 담당자용 자료를 나눠 제공할 수 있습니다. 인터뷰가 끝났다는 사실보다 그 질문이 어디에서 해결되는지가 최종 확인 대상입니다.
기획 인터뷰의 산출물은 좋은 말의 모음이 아니라 독자가 선택을 위해 필요한 답의 목록입니다. 익명화한 질문 카드와 배치 위치를 함께 정리하고, 확인하지 않은 사례나 빈도를 덧붙이지 않은 상태로 원고 설계에 넘기세요.