문의 폼은 이렇게 설계합니다 — 전환되는 폼 UX

폼 항목은 몇 개까지 받아야 하나요?

우리가 폼을 설계할 때 가장 먼저 하는 일은 칸을 추가하는 게 아니라 덜어내는 것입니다. 영업팀은 보통 예산, 희망 일정, 지역, 회사 규모까지 한 번에 받고 싶어 합니다. 그런데 칸이 하나 늘 때마다 방문자가 중간에 그만둘 확률도 같이 올라갑니다. 그래서 우리는 모든 칸에 한 가지 질문을 던집니다. "이 칸이 비어 있으면 우리가 연락을 못 하나요?"

대부분의 첫 문의에는 연락처(이름과 전화 또는 이메일)와 문의 내용이면 충분합니다. 예산이나 일정처럼 영업에 필요한 정보는 첫 통화에서 자연스럽게 받을 수 있습니다. 처음부터 다 받으려다 아예 연락을 못 받는 것보다, 짧게 받아 대화를 시작하는 편이 결국 더 많은 문의로 이어집니다.

단계로 나눌까요, 한 화면에 다 보여줄까요?

정답은 항목 수에 달려 있습니다. 칸이 3~5개로 적으면 한 화면에 모두 보여주는 편이 빠릅니다. 스크롤 한 번 없이 전체를 파악하고 바로 채울 수 있기 때문입니다. 반대로 견적 문의처럼 칸이 많거나, 선택에 따라 다음 질문이 달라지는 폼은 단계로 나눕니다. 이때 '2 / 3' 같은 진행 표시를 두어 끝이 보이게 합니다.

단계를 나눌 때 우리가 지키는 원칙이 하나 있습니다. 가장 쉬운 질문을 첫 단계에 둔다는 것입니다. 이름이나 연락처처럼 답하기 쉬운 칸을 먼저 두면, 일단 시작한 사용자는 이미 들인 노력 때문에 끝까지 갈 가능성이 높아집니다. 처음부터 어려운 질문을 던지면 시작 자체를 안 합니다.

라벨과 플레이스홀더는 어떻게 쓰나요?

흔한 실수가 라벨을 없애고 플레이스홀더(칸 안의 흐린 글씨)로 대신하는 것입니다. 깔끔해 보이지만, 사용자가 입력을 시작하는 순간 그 글씨가 사라집니다. 칸을 절반쯤 채우다 멈추면 "여기가 이메일이었나 전화였나"를 다시 알 길이 없고, 다 쓴 뒤 오타를 점검하기도 어렵습니다.

그래서 우리는 라벨을 칸 위에 항상 보이게 둡니다. 플레이스홀더는 라벨 대체용이 아니라 '010-0000-0000'처럼 입력 형식의 예시로만 씁니다. 라벨 문구도 '성함', '연락 받으실 번호'처럼 사람이 말하듯 적습니다. 한 칸당 무엇을 적는지가 0.5초 안에 이해되어야 합니다.

오류 메시지는 어떻게 보여주나요?

가장 답답한 폼은 다 채우고 전송을 눌렀더니 화면이 통째로 빨개지면서 "입력값이 올바르지 않습니다"만 뜨는 폼입니다. 어디가 틀렸는지, 어떻게 고쳐야 하는지를 알 수 없습니다. 우리는 검증을 실시간으로, 칸 단위로 합니다. 사용자가 한 칸을 다 쓰고 다음으로 넘어가는 순간 그 칸을 점검하고, 문제가 있으면 그 칸 바로 아래에 짧게 알려줍니다.

문구도 다릅니다. '형식 오류' 대신 '전화번호는 숫자만 입력해 주세요'처럼 무엇을 어떻게 고치면 되는지 행동을 적습니다. 반대로 잘 입력한 칸에는 굳이 빨간불을 켜지 않습니다. 검증은 사용자를 혼내는 장치가 아니라, 한 번에 통과하도록 돕는 안내여야 합니다.

모바일에서 입력이 편하려면 무엇을 챙기나요?

문의 대부분이 휴대폰에서 들어옵니다. 그래서 우리는 칸마다 키보드 타입을 맞춥니다. 전화번호 칸은 숫자 키패드가 뜨도록, 이메일 칸은 '@'가 보이는 자판이 뜨도록 입력 타입을 지정합니다. 숫자를 적어야 하는데 일반 자판이 떠서 키를 바꾸게 만드는 것 자체가 마찰입니다.

여기에 자동완성을 켜서 브라우저에 저장된 이름·전화·이메일을 한 번 탭으로 채우게 합니다. 칸은 손가락으로 누르기 충분히 크게, 라벨과 칸 사이 간격도 넉넉히 둡니다. 작은 화면에서 칸을 잘못 누르거나 자판에 칸이 가려지는 일이 없도록 보는 것까지가 모바일 폼 설계입니다. 이런 화면별 점검 방식은 우리가 화면을 설계하는 방식에서 더 자세히 다룹니다.

개인정보 동의는 어디에 두나요?

개인정보 수집·이용 동의는 법적으로 필요하지만, 길고 어려운 약관이 전송 버튼 바로 위를 막고 있으면 그 자체가 이탈 지점이 됩니다. 우리는 동의 항목을 전송 버튼 바로 위에, 한 줄로 무엇에 동의하는지 보이게 두고, 자세한 내용은 펼쳐 볼 수 있게 합니다. 필수 동의와 선택(마케팅 수신) 동의는 분명히 구분합니다.

문구도 '아래 약관에 모두 동의합니다'처럼 뭉뚱그리지 않고, '문의 답변을 위해 연락처를 수집·이용하는 데 동의합니다'처럼 무엇을 왜 받는지 적습니다. 받는 정보가 적을수록 동의 문장도 짧아져, 항목을 줄이는 일이 동의 단계까지 가볍게 만듭니다.

전송 버튼을 누른 다음은요?

마지막 한 걸음이 의외로 자주 버려집니다. 전송 버튼을 누르는 순간 우리는 즉시 '전송 중' 상태를 표시하고 버튼을 잠급니다. 반응이 없으면 사용자는 안 눌렸나 싶어 여러 번 누르고, 그러면 같은 문의가 중복으로 접수됩니다. 버튼을 잠그면 이걸 막을 수 있습니다.

완료되면 빈 화면이나 새로고침이 아니라, '접수됐다'는 사실과 다음 단계를 보여줍니다. "문의가 접수됐습니다. 영업일 기준 하루 안에 적어 주신 번호로 연락드리겠습니다"처럼요. 사용자는 전송이 됐는지, 언제 답이 오는지를 그제야 안심합니다. 이 메시지의 문장 톤은 사이트 전체 어조와 맞춰야 하는데, 그 기준은 문장을 쓰는 방식에 정리해 두었습니다. 폼은 사이트 제작의 한 부분이며, 우리가 폼·화면·문장을 한 흐름으로 만드는 이유는 홈페이지 제작 안내와 우리는 이렇게 합니다에서 확인하실 수 있습니다. 지금 쓰는 폼이 문의를 놓치고 있는지 궁금하시면 무료 진단으로 점검해 드립니다.

제가 폼을 설계할 때 거치는 판단 순서는 이렇습니다. 칸을 더하기 전에, 이 길을 처음부터 끝까지 한 번 따라가 봅니다.

그리고 문의가 새는 자리는 늘 정해져 있습니다. 어느 단계에서 사람이 멈추고, 우리가 무엇으로 막는지 정리해 두었습니다.

이 두 장을 먼저 합의해 두면, 화면 디자인은 그 길 위에 얹기만 하면 됩니다.