홈페이지 문의 전환, 폼보다 먼저 고칠 정보 구조

문의가 막히는 지점은 보통 폼이 아니다

문의 버튼 색을 바꾸고 입력칸 수를 줄이는 작업은 눈에 잘 띕니다. 다만 방문자가 실제로 멈추는 지점은 종종 그 앞 페이지입니다. 이 서비스가 우리 일에 해당하는지, 지금 무엇을 결정하면 되는지, 문의 뒤에 어떤 대화가 오는지가 안 보이면 폼은 열리기 전에 접힙니다.

저녁에 여러 사이트 탭을 열어 두고 비교하는 담당자에게, 첫 화면이 서비스 범위 대신 분위기만 보여 주면 문의 버튼은 없는 것과 같습니다. 대표나 실무자가 원하는 것은 화려한 소개가 아니라, 지금 이 일이 우리 범위인지를 가리는 한 문장입니다.

홈페이지 문의 전환을 다루는 일은 입력칸 미관보다 정보 순서를 맞추는 일에 가깝습니다. 판단이 서지 않은 상태에서 회사 소개와 예산 칸을 한 번에 요구하면, 문의는 대화를 여는 창구가 아니라 숙제가 됩니다.

방문자가 결정을 내리는 순서로 페이지를 짠다

정보 구조는 메뉴 이름 나열이 아닙니다. 처음 들어온 사람이 같은 흐름으로 세 가지를 읽게 만드는 설계입니다. 이 일이 우리 범위인지, 지금 준비할 자료가 무엇인지, 누구에게 무엇을 물어보면 되는지입니다.

Studio OD 공개 웹사이트는 서비스 범위와 문의 경로를 이어 둡니다. 범위가 보이기 전에 문의만 앞에 두면, 방문자는 무엇을 써야 할지 모른 채 창을 닫습니다. 범위와 다음 행동이 먼저 보이면 문의는 설명이 아니라 확인 창구가 됩니다.

• 이 페이지를 보는 사람은 누구인가
• 그 사람이 지금 확인해야 하는 한 가지는 무엇인가
• 확인 뒤에 할 다음 행동은 무엇인가

메뉴에 회사 소개, 사업 영역, 문의하기가 모두 있어도 읽는 순서가 뒤섞이면 같은 정보가 반복됩니다. 방문자가 결정을 내리는 순서와 페이지 순서가 같아야 문의 경로가 자연스럽게 이어집니다.

한 화면에서 한 가지만 묻는다

영국 정부 디자인 시스템의 질문 페이지 패턴은 한 화면에 분명한 질문 하나를 두고, 그 정보가 왜 필요한지 설명하라고 합니다. 기업 홈페이지 문의에도 같은 원칙이 쓸모 있습니다. 회사명, 담당자, 일정, 첨부 파일을 한 화면에 몰아 넣으면 아직 정하지 못한 항목 앞에서 손이 멈춥니다.

일정이나 예산을 아직 내부에서 합의하지 못한 담당자에게는, 이미 알고 있는 사실만 묻는 편이 맞습니다. 현재 사이트 주소, 고치고 싶은 화면, 문의 목적처럼 지금 답할 수 있는 내용부터 받습니다. 다음 질문이 필요하면 그 칸이 왜 있는지를 한 줄로 적습니다.

한 질문을 마친 뒤에야 다음 칸이 나타나는 방식까지 쓰지 않아도 됩니다. 같은 페이지라도 질문 덩어리를 나누고, 각 덩어리 위에 그 정보가 어디에 쓰이는지 한 줄을 두면 충분합니다.

필요한 입력만 받고 이유를 밝힌다

가입 폼 권고는 복잡도를 낮추고 꼭 필요한 데이터만 요청하라고 합니다. 문의 폼도 같습니다. 제안서를 쓰기 위한 항목을 미리 다 받으려 하면, 첫 대화가 시작되기 전에 창이 닫힙니다.

• 지금 작업 범위를 나누는 데 쓰는 사실만 남긴다
• 필수 항목과 선택 항목을 글로 구분한다
• 첨부가 필요할 때만 이유를 붙여 요청한다

필드가 늘어나는 순간을 의심한다

내부 운영이 편해지도록 칸을 추가하면 그 부담은 방문자가 집니다. 담당자가 나중에 물어볼 내용을 미리 다 받으려 하지 마세요. 첫 문의는 대화를 여는 창구이지, 과업 전체를 접수하는 창구가 아닙니다. 비워 둔 칸이 많아 보일수록, 방문자는 아직 준비되지 않았다고 느낍니다.

입력 오류는 필드 옆에서 글로 설명한다

웹 접근성 기준은 감지된 입력 오류를 텍스트로 알리고, 무엇이 잘못됐는지 설명하라고 합니다. 테두리 색만 바꾸는 방식은 색 구분이 어려운 사람에게 전달되지 않습니다. 필수 항목입니다처럼 막연한 문구도 다음 행동을 알려 주지 않습니다.

• 어느 칸이 문제인지 필드 이름과 함께 적는다
• 어떤 형식이 필요한지 예시를 붙인다
• 전송이 실패한 뒤에도 이미 쓴 내용이 남게 한다

이메일 형식이 맞지 않으면 올바른 예시 한 줄을 붙이고, 필수 칸을 비웠으면 그 칸 이름과 함께 무엇이 비었는지 적습니다. 페이지 상단의 안내만으로는 어느 칸으로 돌아가야 하는지 찾기 어렵습니다.

문제를 칸 옆에 바로 보여 주면, 방문자는 페이지 맨 위에서 원인을 찾지 않아도 됩니다. 제출이 실제로 끝나는지도 살펴야 합니다. 문의 폼에서 전송 버튼이 응답하지 않거나 완료 화면이 애매하면, 같은 사람이 같은 내용을 다시 보내게 됩니다.

공개된 범위와 문의 질문을 같은 말로 맞춘다

정보 구조가 맞았는지는 폼 안이 아니라, 그 앞 문장과 폼 질문이 같은 말을 쓰는지로 확인합니다. 메인에서 브랜드 사이트와 운영 콘솔을 말해 놓고 폼에는 홈페이지 제작만 있으면, 방문자는 자신의 상황을 어느 칸에 써야 할지 모릅니다.

Studio OD 문의 경로를 기준으로 보면, 공개 범위에 있는 일만 묻고 그 밖의 추정은 비워 두는 편이 낫습니다. 확인되지 않은 성과나 기간, 비용을 페이지에 넣지 않는 것과 같은 태도입니다. 설명을 보태려다 말이 커지면, 이후 미팅에서 기대가 어긋납니다.

페이지에 없는 일을 폼에서 물어보면, 방문자는 그 일이 가능한 줄 알고 적어 보냅니다. 반대로 페이지에 있는 일을 폼에서 빠뜨리면, 담당자는 자기 상황을 어디에 써야 할지 고민합니다. 공개된 범위와 질문 목록을 같은 단어로 맞추는 일이 정보 구조의 마지막 점검입니다.

문의 전에 맞춰 둘 점검 목록

• 첫 화면에서 서비스 범위가 한 문장으로 읽히는가
• 문의 버튼 앞에 다음 단계가 보이는가
• 폼의 각 질문이 한 가지 사실만 묻는가
• 오류 문구가 칸 옆에서 고칠 방법을 알려 주는가
• 전송 후 무엇을 기다리면 되는지 적혀 있는가

폼 모양을 다듬는 일은 그다음에 해도 됩니다. 먼저 고칠 것은 방문자가 결정을 내리는 순서입니다. 그 순서가 분명하면 문의는 설득이 아니라 확인이 됩니다.