업체 카드 옆의 문의 버튼을 누르면 그 업체에게 바로 갈 것이라고 생각하기 쉽다. 실제 사이트의 목록과 접수 주체를 살피며 버튼의 수신 약속을 먼저 설명하는 구성이 필요하다고 판단했다.
목록에 있다는 사실과 연결됐다는 사실
목록은 정보를 찾게 돕지만 해당 업체가 접수를 받도록 연결됐다는 증거는 아니다. 원래 작업에서는 문의를 실제로 받는 주체와 목록에 보이는 주체를 구별하는 설명이 중요했다. 나는 존재하는 업체처럼 보이는 카드를 만드는 일보다 버튼 이후 누가 내용을 읽는지 분명하게 하는 일을 먼저 보았다.
공유 예제는 실제 업체 목록과 연락처를 가져오지 않았다. own과 listed라는 두 선언만 받으며 listed는 수신 상대를 제출 전에 확인해야 한다고 표시한다. 목록을 만들었다는 이유로 제휴가 맺어졌다고 쓰거나 직접 전달 성공을 보여 주지 않는다.
계산 맥락 안에 수신 설명을 넣었다
handoff 결과에는 계산 조건과 별도로 recipient가 들어간다. 자체 접수도 directPartnerDelivery는 false다. 목록 모드 역시 자동 전달이 아니라 확인이 필요한 상태다. submitted도 false로 남겨 이 모듈이 준비한 맥락과 완료된 접수를 구별했다.
이 예제가 실제 전달 경로를 인증하는 것은 아니다. 호출자가 선택한 모드를 일관된 설명으로 바꾸는 작은 함수다. 실제 시스템이라면 서버 설정과 수신함, 실패·재시도까지 확인해야 한다. 문구가 맞는다는 사실과 실제 메시지가 도착했다는 사실은 다른 검증이다.
버튼 주변의 문장이 행동의 의미를 정한다
같은 문의하기라는 문구라도 자체 상담을 요청하는 것과 특정 업체에 정보를 보내는 것은 다르다. 방문자가 행동하기 전에 이 차이를 볼 수 있어야 한다. 그래서 예제 선택기에 수신 방식 설명을 가까이 두고 결과 기록에도 반복한다. 설명을 읽으러 다른 페이지까지 이동해야만 수신 주체를 알게 만들지 않았다.
실제 개인정보 처리 문구와 동의를 이 합성 예제로 대신하지는 않는다. 이름과 연락처를 받지 않으며 어떤 법적 요건을 충족했다는 판단도 없다. 여기서 확인하는 것은 행동에 붙인 수신 설명이 모드와 어긋나지 않는지다.
접수 전과 접수 후의 동사를 구별한다
맥락을 준비했다, 접수를 요청했다, 수신함에 도착했다와 담당자가 확인했다는 서로 다른 상태다. 이번 함수는 첫 단계만 만든다. 이 구분이 없으면 단순한 버튼 반응을 전달 완료로 보여 줄 수 있다. 나는 성공 안내의 동사도 시스템이 확인한 사실에 맞아야 한다고 보았다.
목록에 있는 업체 이름이 설명 옆에 붙어 있으면 방문자는 그 이름을 수신 주체로 연결할 가능성이 있다. 실제 화면에서는 버튼 문구만 바꾸기보다 카드와 접수 안내의 거리, 다음 화면의 제목도 함께 검수해야 한다. 현재 예제는 이런 판단의 입력을 제공하고 실제 시선과 이해를 측정하지 않는다.
실제 접수를 붙일 때는 대상이 바뀌면 이전 설명과 동의가 그대로 따라가도 되는지 다시 확인해야 한다. 고정된 목록 문구가 서버의 현재 수신 설정을 영원히 대신할 수는 없다. 수신 관계를 별도 데이터로 다루는 이유도 변경 지점을 드러내기 위해서다.
운영 연결 전과 후의 검수를 구별한다
코어 17개 테스트에는 알 수 없는 수신 모드 거절과 직접 전달 표시가 거짓으로 남는 검사가 있다. 두 언어의 인라인 동작도 대역 실행했다. 실제 이메일 발송, 업체 제휴와 접수 처리 검수를 수행한 것은 아니다. 다운로드 패키지에는 그 경계를 사용 안내에 남겼다.
다른 디렉터리나 비교 사이트에서도 같은 질문이 필요하다. 이 버튼은 누구에게 무엇을 요청하는가. 나는 문의가 많이 온다는 문구보다 방문자와 운영자가 같은 행동을 예상하도록 만드는 설명을 남기고 싶었다. 실제 전송을 붙일 때는 그 예상이 결과와 일치하는지 끝까지 확인해야 한다.
실제 전송을 붙이면 접수 확인 번호와 전달 실패 안내도 수신 설명과 같은 기준으로 검수해야 한다. 지금 예제에서는 그런 번호를 만들어 전달 성공처럼 보여 주지 않았다.