예약 시간을 옮기려는 사람에게 요청 방법을 알려 주는 가상의 지원 페이지를 검수한다고 하자. 본문에는 필요한 입력 정보와 접수 절차만 있고 실시간 빈자리나 확정 금액은 나오지 않는다. 그런데 도입에 ‘일정과 비용 고민을 한 번에 해결하세요’라고 쓰면 독자는 이 화면에서 새 예약까지 결정할 수 있다고 기대할 수 있다. 첫 문단의 범위는 실제로 마칠 수 있는 일부터 다시 정해야 한다.
첫 두 문장은 ‘기존 예약을 다른 날짜로 옮기고 싶을 때 변경 요청을 보내는 방법을 안내합니다. 요청에 필요한 정보와 접수 뒤 확인할 절차를 살펴보세요’처럼 고칠 수 있다. 이는 예시 문구이므로 실제 운영에서 받는 요청과 처리 순서에 맞춰 조정한다. 새 일정이 바로 확정되지 않는다면 접수와 확정의 차이가 뒤쪽 작은 주의문에만 남지 않도록 도입 다음의 단계 설명에서도 드러낸다.
비용 안내가 일부 들어 있다면 그 문단이 답하는 질문을 따로 확인한다. 변경 시 비용이 달라질 수 있는 조건을 설명하는 것과 최종 금액을 알려 주는 것은 다르다. 첫 문단에 전체 비용을 해결한다는 표현을 남긴 채 예외만 추가하지 않는다. 실제로 확인해야 할 조건을 소개하고 개별 금액 확인이 필요한 지점으로 이어 주면 이 페이지가 맡은 요청 절차와 비용 판단을 구분할 수 있다.
마지막으로 모바일에서 도입과 첫 소제목, 요청 버튼을 연달아 읽는다. 제목은 변경 요청인데 첫 항목이 신규 예약 소개이거나 버튼에 예약 확정이라고 쓰여 있으면 범위가 다시 흔들린다. 초안의 첫 두 문장 옆에 각각 대응하는 본문 위치를 적어 설명이 없는 약속을 찾는다. 발행 뒤 가능 시간이나 확정 여부를 묻는 문의가 반복되면 문장만 줄이지 말고 독자가 어느 단계에서 지원 범위를 넓게 받아들였는지 살핀다.
첫 안내를 고친 뒤에는 실제로 접수되지 않는 요청을 넣어 읽어 본다. 예를 들어 변경 신청 경로에서 신규 예약도 받는 것으로 이해될 여지가 있는지 살핀다. 별도 창구로 안내해야 하는 경우에는 그 이유와 이동할 위치를 가까이 두어 같은 내용을 다시 입력하기 전에 범위를 알게 한다.