폼 입력 경험
폼은 사용자가 시스템과 나누는 가장 직접적인 대화입니다. 같은 입력 항목이라도 안내와 반응 방식에 따라 경험이 크게 달라집니다. 폼 입력 경험은 이 대화를 사용자 편에서 설계하기 위한 기준입니다.
이 문서는 입력의 경험을 다룹니다. 구조와 마크업 규칙은 폼 및 테이블 패턴을 따릅니다.
폼 입력 경험의 개념
섹션 제목: “폼 입력 경험의 개념”폼 입력 경험은 폼을 입력 칸의 나열이 아니라 사용자와 주고받는 대화의 흐름으로 바라보는 방식입니다.
- 사용자는 한 번에 하나씩 입력하며 반응을 기대합니다.
- 안내가 늦으면 오류를 뒤늦게 발견합니다.
- 안내가 지나치면 입력 자체를 방해합니다.
폼은 입력을 끝까지 마치도록 돕는 과정으로 설계합니다.
유효성 검사 시점
섹션 제목: “유효성 검사 시점”검사는 사용자를 방해하지 않는 시점에 이뤄져야 합니다.
- 입력하는 도중에는 오류를 성급하게 띄우지 않습니다.
- 입력이 끝난 뒤(포커스 이동)나 제출 시점에 검사합니다.
- 한 번 오류가 표시된 항목은 고치는 즉시 반응합니다.
검사 시점이 어긋나면 아직 입력 중인 사용자에게 오류부터 들이미는 경험이 됩니다.
오류 표현 방식
섹션 제목: “오류 표현 방식”오류는 문제를 알리는 데서 끝나지 않고 해결을 안내해야 합니다.
- 오류 메시지는 해당 입력 항목 가까이에 표시합니다.
- 무엇이 잘못됐는지가 아니라 어떻게 고치는지를 알려줍니다.
- 오류 상태는 상태 기반 UI의
data-state로 표현합니다.
“오류가 발생했습니다”보다 “이메일에 @를 포함해 주세요”가 사용자를 앞으로 나아가게 합니다.
제출·블러 시 검사된 입력은 data-state="error"가 되고,
i_error 문구가 해당 입력 바로 옆에서 고치는 방법을 안내합니다.
label과 입력은 for·id로 연결한 채 유지합니다.
<form class="form_login"> <div class="i_field" data-state="error"> <label class="i_label" for="login_email">이메일</label> <input class="i_input" id="login_email" type="email" name="email" value="minyeong" aria-describedby="login_email_error"> <p class="i_error" id="login_email_error">이메일에 @를 포함해 주세요.</p> </div></form>입력 안내
섹션 제목: “입력 안내”안내는 입력을 돕되, 입력한 내용을 가리지 않아야 합니다.
- 항목의 이름과 의미는
label로 명확히 전달합니다. placeholder는 예시일 뿐, 항목 설명을 대신하지 않습니다.- 필수·선택 여부와 형식은 입력 전에 미리 알립니다.
label과 입력 요소의 연결은
키보드 내비게이션과 접근성의 기본 전제이기도 합니다.
폼 입력 경험의 목적
섹션 제목: “폼 입력 경험의 목적”폼 입력 경험은 사용자가 막히거나 되돌아가지 않고 입력을 끝까지 마칠 수 있도록 만들기 위한 기준입니다.
대화가 매끄러울수록 사용자는 폼을 부담이 아니라 자연스러운 과정으로 느낍니다.