TL;DR
홈페이지 제작 목표는 회사가 원하는 결과와 방문자가 완료할 과제를 함께 적어야 검수할 수 있습니다. 문의 증가처럼 외부 요인이 섞인 기대와, 서비스 범위를 이해하고 문의를 접수할 수 있다는 납품 조건을 구분하는 것이 출발점입니다.
사업 목표를 화면 요구로 번역하기
브랜드를 알리고 싶다는 요청만으로는 첫 화면 문구나 필요한 기능을 정하기 어렵습니다. 누구에게 어떤 판단을 도울지 한 단계 더 내려가야 합니다. 예를 들어 서비스 도입을 검토하는 담당자가 제공 범위와 진행 방식을 확인하고 프로젝트 설명을 남기는 상황을 대표 과제로 정할 수 있습니다. 이는 실제 고객 성과가 아니라 기획을 위한 가상 상황입니다.
Google은 콘텐츠를 읽은 사람이 자신의 목표를 달성할 만큼 충분한 답을 얻는지를 평가하도록 안내합니다. 이 원칙을 프로젝트에 적용한다면 방문 이후의 행동을 단순한 클릭으로 끝내지 않습니다. 담당자가 자신에게 맞는 서비스인지 판단하는 데 어떤 정보가 필요한지 먼저 기록합니다. 내부에서 자랑하고 싶은 내용과 고객이 선택을 위해 확인할 내용이 다를 수 있기 때문입니다.
기대 지표와 납품 조건을 다른 칸에 적기
페이지원이 제안하는 목표표에는 사업상 기대, 대표 이용자, 이용 과제, 완료 증거, 확인 담당자를 둡니다. 사업상 기대에는 적합한 프로젝트 문의를 늘리고 싶다는 방향을 적습니다. 납품 조건에는 서비스의 포함 범위와 제외 범위를 확인할 수 있고, 필수 입력을 채우면 접수 결과를 확인할 수 있다고 적습니다.
문의 수나 계약 수는 운영 기간과 유입 조건을 정해 나중에 관측할 지표입니다. 사이트가 잘 열리고 폼이 작동한다는 확인만으로 문의 증가까지 달성했다고 쓰지 않습니다. 반대로 실제 문의가 아직 없다는 이유로 정상 동작한 제출 기능을 미완성으로 표시할 필요도 없습니다. 검수 결과와 운영 성과가 다른 질문에 답한다는 뜻입니다.
MDN은 폼을 사용자가 데이터를 입력해 서버로 보내거나 화면 상태를 바꾸는 상호작용 수단으로 설명합니다. 따라서 문의 기능의 완료 증거에는 접수 버튼의 모양보다 입력, 전송, 결과 안내가 실제로 이어지는지 포함해야 합니다. 담당자에게 알림이 필요한 범위라면 알림 도착과 실패 확인까지 별도 조건으로 적습니다.
프로젝트 전체의 공통 기준부터 합의하기
이 목표표는 개별 페이지의 버튼 배치표가 아닙니다. 여러 화면을 연결했을 때 사이트가 어떤 문제를 해결하는지 정하는 상위 기준입니다. 상세 페이지마다 읽고 나서 할 행동은 그다음에 나눕니다. 모든 페이지에 같은 문의 버튼이 있다는 사실만으로 프로젝트 목표가 명확해지는 것은 아닙니다.
Google은 유용한 콘텐츠를 평가할 때 사이트에 주된 목적이나 초점이 있는지도 묻습니다. 다른 목적의 요구가 추가되면 기존 목표를 돕는지부터 확인합니다. 채용 지원과 고객 문의가 모두 필요하다면 담당자, 접수 정보, 결과 안내를 분리합니다. 하나의 폼으로 묶는 편의 때문에 서로 다른 방문 과제를 흐리게 만들지 않습니다.
검수에서는 실제 과제를 끝까지 수행하기
검수자는 목표표의 대표 상황을 읽고 메뉴 탐색부터 정보 확인, 제출 결과까지 직접 수행합니다. 어느 화면에서 필요한 정보를 찾지 못했는지와 기대한 결과가 무엇이었는지 남깁니다. 느낌이 어색하다는 의견을 어떤 과제에서 막혔는지로 바꾸면 수정 범위를 정하기 쉬워집니다. 통과하지 못한 항목은 담당자와 다음 확인 조건을 함께 기록합니다.
마무리
검수에 사용할 계정이나 샘플 데이터도 목표와 맞춰야 합니다. 기존 고객만 아는 약어가 아니라 처음 방문한 담당자의 말로 과제를 적고, 별도 설명 없이 정보를 찾을 수 있는지 확인합니다. 안내를 듣고 성공한 결과와 스스로 완료한 결과를 구분하면 실제로 어느 부분의 설명을 보완해야 할지 보입니다.
프로젝트 목표는 큰 숫자를 약속하는 문장이 아니라 제작과 검수의 방향을 맞추는 기준입니다. 사업 기대와 기능 완료를 나눈 목표표를 먼저 만들고, 그 기준으로 페이지별 요구와 운영 지표를 이어가면 됩니다.