모바일 문의 폼 UX: 상담 이탈을 줄이는 입력 화면 체크리스트

모바일 문의 폼을 고칠 때는 색이나 버튼 모양보다 질문 수, 입력 방식, 오류 복구, 제출 완료 화면을 먼저 봐야 합니다. 이름·연락처·문의 내용처럼 상담 시작에 꼭 필요한 정보만 받고, 각 입력란에는 보이는 레이블과 알맞은 자동완성 속성을 붙이세요.[1][3] 오류가 나면 사용자가 입력한 값은 남겨 둔 채 무엇을 어떻게 고쳐야 하는지 알려 주는 것이 기본입니다.[2][5]

질문을 줄이기 전에 상담 절차부터 그린다

폼이 길어지는 이유는 대개 여러 부서의 요구를 한 화면에 모았기 때문입니다. 상담 전에 반드시 알아야 하는 정보와 담당자가 통화하면서 확인해도 되는 정보를 나눠 보세요.[4] GOV.UK 디자인 시스템도 모든 질문에 수집 이유가 있어야 하며, 실제로 필요한 정보만 물으라고 권합니다.[4]

예를 들어 첫 상담 신청이라면 이름, 회신 수단, 문의 내용으로 시작할 수 있습니다. 예산, 사업자 규모, 상세 일정은 서비스에 따라 필요할 수 있지만 무조건 필수로 둘 이유는 없습니다. 선택 항목에는 선택이라고 적고, 왜 필요한지 짧게 설명하는 편이 별표만 붙이는 것보다 분명합니다.[4]

폼을 짧게 만든다는 이유로 필요한 설명까지 지우면 입력 실수가 늘어납니다.[1] 질문은 줄이고, 남은 질문의 뜻은 더 또렷하게 만드는 쪽이 낫습니다.

레이블과 자동완성으로 타이핑 부담을 낮춘다

플레이스홀더만으로 입력란의 용도를 설명하지 마세요. 사용자가 글자를 입력하면 플레이스홀더는 사라집니다.[1] W3C 웹 콘텐츠 접근성 지침(WCAG) 2.2는 사용자 입력이 필요한 경우 레이블이나 지시문을 제공하도록 요구하며, 예상 형식이 낯설거나 규칙이 있다면 그 형식도 알려 주라고 설명합니다.[1]

연락처 폼에는 눈에 보이는 레이블을 두고, HTML의 type과 autocomplete을 실제 목적에 맞게 설정합니다.[1][3] W3C는 autocomplete이 이름, 전화번호, 이메일 같은 입력 목적을 기계가 구분하게 해 브라우저 자동 채우기와 보조 기술에 도움을 준다고 설명합니다.[3]

<label for="customer-name">이름</label>
<input id="customer-name" name="name" autocomplete="name">

<label for="customer-tel">연락처</label>
<input id="customer-tel" name="tel" type="tel"
       inputmode="tel" autocomplete="tel">

<label for="customer-email">이메일 (선택)</label>
<input id="customer-email" name="email" type="email"
       autocomplete="email">

구현 뒤에는 휴대폰에서 자동완성이 실제로 뜨는지, 전화번호를 누를 때 알맞은 키패드가 열리는지 확인해야 합니다.[3] 속성 이름이 맞더라도 화면의 레이블과 입력 목적이 어긋나면 사용자는 더 헷갈립니다.[1][3]

오류 메시지는 실패 이유와 고칠 방법을 함께 쓴다

입력값이 올바르지 않습니다라는 문장은 어디가 왜 틀렸는지 알려 주지 않습니다.[2] 연락처를 숫자 10~11자리로 입력해 주세요처럼 대상과 수정 방법을 한 문장에 넣으세요.[2] W3C는 자동으로 감지한 입력 오류의 항목과 내용을 텍스트로 설명해야 한다고 정합니다.[2]

오류가 여러 개라면 화면 위쪽에 요약을 두고 각 입력란 가까이에도 같은 메시지를 표시합니다.[5] 색만 바꾸지 말고 글로 알려야 합니다.[2] 사용자가 이미 입력한 정상 값과 오류 값은 지우지 않는 편이 좋습니다.[5] GOV.UK의 검증 지침도 오류 후 폼을 다시 보여 줄 때 기존 입력을 보존하고, 상단 오류 요약과 필드 옆 메시지를 함께 제공하라고 안내합니다.[5]

오류 문구는 다음 순서로 점검할 수 있습니다.

1. 어느 입력란의 문제인지 문장만 읽어도 알 수 있는가
2. 비어 있는지, 형식이 다른지, 허용 길이를 넘었는지 구체적으로 말하는가
3. 사용자가 방금 입력한 다른 값은 그대로 남아 있는가
4. 키보드만 사용해도 오류 요약에서 해당 입력란으로 이동할 수 있는가
5. 화면 읽기 프로그램이 오류 발생과 대상 필드를 알 수 있는가

제출 버튼 뒤의 상태까지 문의 경험이다

버튼 이름은 보내기보다 상담 신청하기처럼 결과를 드러내는 문구가 낫습니다. 누른 뒤에는 처리 중임을 보여 주고 중복 제출을 막되, 비활성 상태만 남겨 두면 안 됩니다. 요청이 실패했다면 다시 시도할 수 있어야 하며 작성 내용도 보존해야 합니다.

성공 화면에는 접수 사실, 다음 연락 방식, 예상되는 다음 단계를 적습니다. 실제 응답 시간을 보장하지 못한다면 곧 연락드립니다처럼 모호한 약속을 만드는 대신 담당자가 확인 후 입력하신 연락처로 회신합니다라고 쓰는 편이 정직합니다. 완료 이벤트는 분석 도구에서 한 번만 기록되도록 성공 응답 이후에 전송하세요.

상담 신청 폼은 입력 화면에서 끝나지 않습니다. 제출, 서버 처리, 성공 또는 실패 안내까지 이어져야 한 번의 완성된 경험입니다.

휴대폰으로 15분 안에 점검하는 순서

디자인 파일만 보지 말고 실제 공개 주소에서 확인합니다. 개발자가 쓰는 최신 기기 하나로 끝내지 말고 화면이 작은 기기와 느린 네트워크 조건도 포함하세요.

• [ ] 첫 화면에서 필수 항목과 선택 항목이 구분된다
• [ ] 모든 입력란에 사라지지 않는 레이블이 있다
• [ ] 이름, 전화번호, 이메일 자동완성이 알맞게 동작한다
• [ ] 키보드가 현재 입력란과 제출 버튼을 가리지 않는다
• [ ] 빈 값과 잘못된 형식으로 제출해 오류 문구를 확인했다
• [ ] 오류 뒤에도 이미 입력한 값이 남는다
• [ ] 연속 탭이나 느린 응답에서도 문의가 중복 저장되지 않는다
• [ ] 성공 화면에서 접수와 다음 단계가 보인다
• [ ] 키보드만으로 처음부터 끝까지 제출할 수 있다
• [ ] 개인정보 수집 안내와 동의 항목이 실제 처리 방식과 맞는다

점검 중 발견한 문제는 전환율이 낮다처럼 크게 적지 말고 전화번호 오류 후 문의 내용이 지워짐처럼 재현 가능한 문장으로 남기세요. 그래야 개발자와 운영자가 같은 문제를 보고 고칠 수 있습니다.

폼을 새로 만들거나 기존 문의 흐름을 실제 사용자 여정까지 정리해야 한다면 POEMORA 웹 개발 서비스에서 화면 설계와 구현 범위를 함께 확인할 수 있습니다.