TL;DR
디자인 전에 필요한 페이지를 정보 목적과 화면 상태까지 포함해 목록으로 정리해야 합니다. 주소나 메뉴 이름만 세면 빈 목록, 제출 실패, 없는 페이지처럼 실제 이용에서 만나는 화면이 빠지기 쉽습니다.
메뉴 개수와 화면 개수가 다른 이유
상단 메뉴에 서비스, 회사 소개, 문의가 있다면 세 페이지로 보일 수 있습니다. 그러나 서비스 목록과 상세는 정보를 고르는 방식이 다르고, 문의 폼은 작성 전과 오류가 난 뒤의 안내가 다릅니다. 각각을 모두 별도 주소로 만들 필요는 없지만 디자인과 구현에서는 확인할 상태로 남겨야 합니다.
Google의 SEO 시작 가이드는 논리적인 사이트 구성이 사용자와 검색엔진이 페이지 관계를 이해하는 데 도움이 된다고 설명합니다. 화면 목록은 이 관계를 설계팀과 콘텐츠 담당자도 같은 방식으로 이해하게 하는 작업 도구입니다. 검색용 파일을 만들기 위한 절차가 아니라 정보가 어디에 있고 무엇으로 이어지는지 합의하는 과정입니다.
한 행에 목적과 입력 자료를 붙이기
페이지 이름 옆에는 대표 방문자, 답해야 할 질문, 필요한 원고나 이미지, 다음 경로를 적습니다. 서비스 상세라면 제공 범위와 제외 범위, 진행 과정, 문의 전 준비 자료가 들어갈 수 있습니다. 회사 소개라면 검증된 회사 정보와 실제 공개 가능한 사진이 필요할 수 있습니다. 없는 고객 실적을 채워 넣는 방식으로 공백을 해결하지 않습니다.
Google은 콘텐츠의 제목이나 주된 제목이 본문을 설명하는 유용한 요약인지 평가하도록 안내합니다. 따라서 목록의 임시 이름도 회사가 사용하는 내부 문서명보다 방문자가 찾을 내용을 드러내는 편이 좋습니다. 이름은 나중에 바뀔 수 있지만 각 화면이 답할 질문까지 계속 바뀌면 시안과 원고의 기준을 다시 맞춰야 합니다.
상태를 따로 기록하면 책임이 보이기 시작한다
문의 화면에는 빈 입력, 유효하지 않은 형식, 전송 중, 성공, 실패 상태를 붙입니다. 글 목록에는 글이 있을 때와 없을 때, 조건에 맞는 글이 없을 때를 구분합니다. 오류 화면에는 해당 상황이 왜 생겼는지와 어디로 돌아갈지 적습니다. 이를 화면 목록의 하위 항목으로 두면 페이지 수를 억지로 늘리지 않으면서 누락을 관리할 수 있습니다.
MDN은 폼 컨트롤에 값의 형식이나 조건을 검사하는 검증 기능과 용도를 설명하는 레이블을 제공할 수 있다고 설명합니다. 검증이 필요한 입력에는 잘못된 값을 받은 뒤 어떤 문구와 동작을 보여줄지 준비해야 합니다. 정상 예시 한 장만으로 문의 기능의 상태 설계가 끝났다고 볼 수 없는 이유입니다.
목록으로 시안과 실제 주소를 대조하기
시안이 나오면 각 화면을 목록의 목적과 연결합니다. 한 시안이 여러 페이지의 공통 틀이라면 어떤 내용이 달라지는지 표시합니다. 구현 뒤에는 실제 주소와 메뉴 연결, 필요한 자료의 반영 상태를 덧붙입니다. 주소가 생겼다는 사실과 원고 검토가 끝났다는 사실은 별도 칸으로 관리하세요.
공통 틀에서 빠진 조건도 찾아야 합니다. 긴 제목이 들어가는 서비스, 사진이 없는 글, 필수 항목이 많은 폼처럼 예외가 있는 대표 사례를 한 번씩 대입합니다. 검토자는 어떤 화면이 어느 목록 항목을 충족하는지 확인하고, 찾을 수 없는 항목은 누락 또는 범위 변경으로 분류합니다.
마무리
목록을 처음부터 지나치게 세밀하게 만들 필요는 없습니다. 대표 화면과 빠지기 쉬운 상태부터 작성하고 실제 검토에서 발견한 항목을 같은 목록에 추가합니다. 다만 뒤에서 생긴 화면을 별도 메신저에만 남기면 기준이 갈라집니다. 공유 파일을 여는 모든 담당자가 같은 기준을 보도록 단일 기준본의 위치를 고정합니다. 목록의 변경 날짜와 결정자를 기록하고 이전 버전과 무엇이 달라졌는지 확인할 수 있게 관리하세요. 임시 화면도 최종 공개 여부를 표시해야 고객이 보게 될 결과와 내부 검수용 화면을 혼동하지 않습니다.
페이지 목록의 가치는 총수를 세는 데 있지 않습니다. 정보 목적, 준비 자료, 화면 상태, 구현 주소를 연결해 제작 과정에서 무엇이 준비됐고 무엇이 빠졌는지 확인하는 기준으로 사용하세요.