폼 디자인

폼 디자인은(는) 무엇을 하나요?

폼은 조직이 무언가를 요청하고 사람이 시간, 노력, 위험으로 비용을 지불하는 대화입니다. 모든 질문이 그 자리를 정당화하고, 각 답변이 사람의 조건에 따라 제공될 수 있으며, 모든 실수가 조기에 포착되고 제자리에서 설명되며 작업 손실 없이 수정 가능할 때 제대로 작동합니다. 가장 흔한 모델 실패는 완성된 것처럼 보이지만 실제로는 그렇지 않은 폼입니다: 플레이스홀더 레이블, 임의의 필수 필드, 카드 번호에 type="number", autocomplete 없음, 브라우저 버블이나 빨간 테두리로만 표시되는 오류, "제출"이라고 쓰인 제출 버튼, 그리고 테스트된 유일한 경로인 성공 경로입니다.

interface-guidelines의 계층화된 원칙을 적용하세요(모든 사람이 사용할 수 있어야 함 > 진실을 말해야 함 > 의미를 전달해야 함 > 답변이 먼저 와야 함 > 실수는 회복 가능해야 함 > 고정되어 있어야 함 > 가능한 것이 보여야 함 > 관례 > 다듬기). 해당 스킬이 설치되어 있으면 먼저 SKILL.md를 읽으세요. 그 references/human-interface.md 섹션 3에는 기본 폼 규칙(표시 레이블, 선택 사항 표시, 붙여넣기, 유효성 검사 타이밍, 비활성화된 제출, 저장 동작)이 포함되어 있습니다. 이 스킬은 더 나아가며 이를 반복하지 않습니다.

브리핑

필드를 그리기 전에 다음 질문에 답하세요. 폼에 5개 이상의 질문이 있으면 기록하세요.

• 각 답변은 무엇에 사용되나요? 이를 사용하는 결정 또는 행동의 이름을 지정하세요. 사용처가 명명되지 않은 필드는 삭제합니다.
• 누가, 얼마나 자주, 어떤 기기에서 답변하나요? 평생 한 번 신청자가 휴대폰으로 하는 경우, 또는 하루에 200개 기록을 책상에서 입력하는 사무원의 경우입니다. 이에 따라 한 페이지에 하나의 질문 또는 하나의 조밀한 페이지를 결정합니다.
• 데이터는 누구의 것인가요? 본인의 데이터(자동 완성 적용, WCAG 1.3.5 적용) 또는 타인의 데이터(수령인, 환자, 직원이 입력하는 고객)입니까?
• 답변을 바로 알고 있나요? 여권 번호, 정책 ID, 작년 소득. 그렇지 않다면 미리 무엇을 준비해야 하는지 알리고 저장을 허용하세요.
• 잘못된 답변의 비용은 얼마이며, 제출 후 되돌릴 수 없는 것은 무엇입니까(결제, 법적 선언, 공개 게시물)?
• 응답자는 어디에 있나요? 국가, 문자 체계, 주소 형식, 전화번호 형식, 이름 구조.
• 시스템이 이미 알고 있는 것은 무엇인가요? 그것에 대해 절대 묻지 마세요(WCAG 3.3.7).
• 에이전트 독자: 에이전트가 누군가를 대신해 이 폼을 작성할 것인가요(자동 완성 확장, 브라우저 에이전트, 어시스턴트)? 공개된 모든 것에 대해 그렇다고 가정하세요.

규칙

덜 물어보기

• 설계하기 전에 필드를 삭제하세요. 각 필드는 "나중에 유용할 수 있음"이 아닌 지금 당장 명명된 용도가 있어야 합니다. Baymard는 평균 체크아웃에 8개면 충분한데 11.3개의 필드가 있음을 발견했습니다. 필드 수는 단계 수보다 더 해롭습니다. [P: Baymard 2024]
• 전체 이름은 하나의 필드로 수집하세요. 단, 이름 부분이 특정 동작(정렬, 공식 주소)을 유도하는 경우는 예외입니다. 많은 이름이 성과 이름으로 나뉘지 않습니다. 성을 필수로 요구하지 마세요. [S: W3C i18n; P: Baymard]
• 드물게 사용되는 필드는 링크 뒤에 숨기세요. 필수 입력이 아닌 경우: 주소 2행, 회사명, 쿠폰 코드. [P: Baymard]
• 청구지 주소를 배송지 주소로 기본 설정하고 청구지 필드를 숨기는 체크박스를 기본 선택하세요. [P: Baymard]
• 계정 생성은 거래 후에 제공하고, 거래 전의 장벽으로 제공하지 마세요. [P: Baymard]
• "모르겠습니다"를 허용하세요. 그것이 유효한 답변인 경우, 추측을 강요하지 마세요. [S: GOV.UK 질문 페이지]
• 유도할 수 있는 것은 유도하세요: 우편번호에서 도시와 지역(신뢰할 수 있는 경우), 번호에서 카드 유형, 주소 조회에서 국가. 유도된 값은 표시되고 편집 가능하게 유지하세요. [P: Baymard]

구조와 흐름

• 습관이 아닌 브리핑에서 형태를 선택하세요. 드물고, 스트레스가 많거나, 익숙하지 않은 작업: 페이지당 하나의 질문, 질문을 h1/legend로 사용. 빈번한 전문가 입력: 한 페이지, 그룹화, 키보드로 빠르게. GOV.UK는 모든 서비스를 하나씩 시작하고 연구가 그렇게 말할 때만 병합합니다. [S: GOV.UK 폼 구조]
• 사람이 생각하는 순서대로 질문을 정렬하고, 가장 쉽고 확실한 것부터 시작하며, 적용될 수 없는 질문은 아무도 보지 않도록 분기하세요. [S: GOV.UK; J]
• 시작하기 전에 필요한 것(문서, 시간, 비용)과 이후에 일어날 일을 알리세요. [S: GOV.UK 시작 페이지]
• 긴 다중 세션 폼은 작업 목록을 사용하고, 일반 상태와 저장 및 돌아오기 기능을 제공하세요. 사람들이 한 번에 끝낼 수 없거나 자신의 순서를 선택해야 하는 경우에만 사용하세요. [S: GOV.UK 작업 목록]
• 뒤로 가기가 작동해야 합니다. 질문 페이지에 뒤로 가기 링크를 포함하고 브라우저의 뒤로 가기 버튼을 절대 망가뜨리지 마세요. 돌아오면 이전 답변이 미리 채워져 표시됩니다. [S: GOV.UK]
• 결과가 중요한 흐름은 답변 확인 페이지로 끝내세요: 각 답변 옆에 "변경" 링크를 두고, 접근 가능한 이름이 필드를 명명하며("생년월일 변경"), 편집 후 요약 페이지로 돌아갑니다. [S: GOV.UK 답변 확인; WCAG 3.3.4]
• 다중 열 레이아웃은 사람과 에이전트 모두의 읽기 순서를 깨뜨립니다. 한 열을 사용하세요. 단, 자연스럽게 쌍을 이루는 짧은 필드(만료 월과 연도, 도시와 우편번호)는 예외입니다. [P: Baymard, Wroblewski; J]

레이블, 힌트 및 그룹화

• 레이블은 필드 위에 배치하세요. Penzo 2006이 보고한 속도 이점은 작고 비공식적인 시선 추적 테스트에서 나온 것이며 Das 2008에 의해 반박되었습니다. 레이블 상단 배치는 좁은 화면, 긴 번역, 확대/축소에서도 살아남기 때문에 선택하세요. 가장 빠르다는 증거 때문이 아닙니다. [E, 약함: Penzo 2006, Das 2008]
• 힌트는 레이블과 필드 사이에 배치하고 aria-describedby로 연결하세요. 형식 예시("예: 27 3 2007")는 힌트에 속하며, 절대 플레이스홀더에 넣지 마세요. [S: GOV.UK]
• 관련 컨트롤을 fieldset과 legend로 그룹화하세요: 모든 라디오 세트, 체크박스 세트, 다중 부분 답변(날짜, 카드 만료). legend는 질문입니다. [S: WCAG 1.3.1; GOV.UK]
• 한 페이지에 하나의 질문이 있는 경우, 레이블 또는 legend가 페이지 제목이 되어 스크린 리더가 한 번만 듣게 됩니다. [S: GOV.UK 질문 페이지]
• 선택적 필드는 "(선택 사항)"으로 표시하고 필수 필드에 별표를 사용하지 마세요. 대부분의 필드가 선택 사항이라면, 그 필드들이 여기에 속하는지 의문을 가져보세요. [S: GOV.UK]

입력 유형 및 자동 완성

• 사람에 관한 모든 필드에 autocomplete를 설정하고, 정확한 WHATWG 토큰(given-name, email, postal-code, cc-number, one-time-code, new-password)을 사용하세요. 이는 브라우저 자동 완성, 비밀번호 관리자, 에이전트 작성을 지원하며 WCAG 1.3.5 요구 사항입니다. 개인 데이터에 autocomplete="off"를 사용하는 것은 결함입니다. [S: WHATWG autofill; WCAG 1.3.5]
• 의미를 위해 type을 사용하고 키보드를 위해 inputmode를 사용하세요. 해당되는 경우 type="email", type="tel", type="url"을 사용하세요. 숫자로 구성된 식별자(카드, 우편번호, 계좌, 코드)는 type="text" inputmode="numeric"을 사용하고, 절대 type="number"를 사용하지 마세요. type="number"는 선행 0을 제거하고, 스크롤 시 변경되며, 긴 값을 반올림하고, 받아쓰기 소프트웨어를 혼동시킵니다. [S: GOV.UK 2020; MDN]
• 기본 컨트롤을 우선 사용하세요. 약 12개 미만의 폐쇄된 목록에는 select, 사람들이 비교해야 할 몇 가지 옵션에는 라디오, 국가와 같은 긴 목록에는 입력 시 자동 완성 기능이 있는 콤보박스를 사용하세요. 사용자 정의 드롭다운은 에이전트로부터 옵션을 숨깁니다. [S: APG; P: interface-guidelines에서 조사]
• 기억하기 쉬운 날짜는 세 개의 텍스트 필드(일, 월, 년)를 사용하며, 생년월일에는 bday-* 토큰을 사용하고 월 이름을 허용합니다. 날짜 선택기는 사람들이 달력을 기준으로 날짜를 선택하는 경우에만 적합합니다. [S: GOV.UK 날짜 입력]
• 예상 답변에 맞게 필드 크기를 조정하세요. 거리 너비의 우편번호 상자는 잘못된 힌트를 줍니다. [S: GOV.UK; J]
• 사람의 형식으로 답변을 수락하세요: 카드 및 전화번호의 공백과 대시, 우편번호의 모든 대소문자, 월 이름, 앞뒤 공백. 서버에서 정규화하세요. [S: GOV.UK]
• 필드별 패턴(이름, 국가별 주소, 전화, 돈, 카드, 파일)은 references/fields.md에 있습니다.

유효성 검사 및 오류

• 기본적으로 제출 시 유효성 검사; 인라인은 사람이 완료한 필드를 떠난 후에만 수행하고, 오류가 수정되는 즉시 지우세요. 첫 번째 키 입력 시 플래그를 지정하지 마세요. 증거는 상충됩니다: Bargas-Avila 2007은 완료 후 나열된 오류가 즉각적인 오류보다 나은 것으로 나타났고; Wroblewski 2009은 포커스 이탈 시 인라인 유효성 검사가 도움이 된다는 것을 발견했습니다(n=22). GOV.UK는 제출 시 유효성 검사를 수행합니다; Baymard는 포커스 이탈과 수정 시 오류 제거를 권장합니다. 폼 길이와 필드가 단독으로 확인 가능한지 여부에 따라 결정하세요. [E: Bargas-Avila 2007; E, 약함: Wroblewski 2009; S: GOV.UK; P: Baymard]
• 실패한 제출 시: 모든 답변을 유지하고, 문제당 하나의 링크로 상단에 오류 요약을 배치하여 해당 필드로 이동하고, 요약에 포커스를 이동하고, 페이지 제목 앞에 "Error: "를 접두사로 붙이고, 각 필드 옆에 동일한 문구를 표시하세요. [S: GOV.UK 오류 요약; WCAG 3.3.1]
• 각 메시지를 aria-describedby로 해당 필드에 연결하고(원한다면 aria-errormessage를 추가로 사용할 수 있지만, 스크린 리더 지원은 여전히 고르지 않음) aria-invalid="true"를 설정하세요. 메시지는 표시되는 텍스트여야 합니다. 에이전트 직렬화기는 aria-invalid를 삭제하지만 인접한 텍스트는 유지합니다. [S: WCAG 3.3.1; P: Roselli 2023; P: interface-guidelines에서 조사]
• 브라우저 유효성 검사 버블을 끄고(novalidate) 페이지에 메시지를 렌더링하세요. 버블은 사라지고, 요약에서 연결할 수 없으며, 페이지 텍스트가 아닙니다. 서버 유효성 검사는 권위를 유지합니다. [S: GOV.UK 유효성 검사]
• 수정 방법을 구체적으로 알려주는 오류를 작성하세요: "유효하지 않은 날짜"가 아닌 "과거의 생년월일을 입력하세요". 원인당 하나의 메시지(비어 있음, 잘못된 형식, 범위 초과)를 폼의 언어로 작성하세요. [S: GOV.UK 오류 메시지; WCAG 3.3.3]
• 편집으로 수정할 수 없는 조건(자격 미달, 계정 잠김, 서비스 중단) 은 필드 오류가 아닌 이유와 다음 단계를 설명하는 페이지여야 합니다. [S: GOV.UK]

로그인, 비밀번호, 패스키

• 비밀번호 관리자와 붙여넣기가 작동하도록 하세요. autocomplete="username"과 current-password 또는 new-password를 사용하고; 붙여넣기를 절대 차단하지 마세요; 64 미만의 maxlength를 사용하지 마세요; 비밀번호 표시를 제공하세요; 비밀번호 표시가 제공되면 비밀번호 확인 필드를 제거하세요. [S: NIST SP 800-63B-4 3.1.1.2; GOV.UK 비밀번호 입력; WCAG 3.3.8]
• 구성 규칙, 정기적인 만료, 힌트가 없어야 합니다. 대신 새 비밀번호를 알려진 유출 목록과 확인하고 거부 이유를 알리세요. [S: NIST SP 800-63B-4]
• 미리 선택을 강요하지 않고 패스키를 제공하세요: 사용자 이름 필드를 유지하고, autocomplete="username webauthn"과 조건부 WebAuthn 요청을 추가한 다음, 비밀번호 로그인 후 패스키 생성을 제공하세요. [S: WHATWG autofill; P: web.dev passkey autofill]
• 일회용 코드: 하나의 필드, autocomplete="one-time-code", inputmode="numeric", 붙여넣기 허용. 붙여넣은 코드를 거부하는 분할된 한 자리 상자는 WCAG 3.3.8을 위반합니다. [S: WCAG 3.3.8]
• 사용자 이름과 비밀번호 중 무엇이 잘못되었는지 알리지 마세요. [S: GOV.UK 비밀번호]
• 로그인을 퍼즐 CAPTCHA로 차단하지 마세요. 텍스트 및 논리 퍼즐은 인지적 대안 없이 WCAG 3.3.8을 위반합니다. [S: WCAG 3.3.8]

제출

• 제출 버튼은 결과를 명명하세요: "계정 만들기", "£42.00 결제", "신청서 보내기". 단계 사이에는 "계속"; 저장된 경우에만 "저장하고 계속". [S: GOV.UK 버튼; 기초]
• 법적, 금융, 데이터 삭제 제출은 취소 가능하거나, 확인되거나, 검토 단계를 통해 확인됩니다(WCAG 3.3.4). 검토는 정확히 무엇이 전송될 것인지와 그 비용을 보여줍니다. [S: WCAG 3.3.4]
• 제출은 멱등적이어야 합니다: 진행 중인 동안 재입력을 비활성화하고, 버튼에 진행률을 표시하며, 서버에서 멱등성 키로 보호하세요. 시간 초과 후 재시도는 두 번 청구되어서는 안 됩니다. [S: GOV.UK 버튼; P: Stripe 멱등성]
• 확인 페이지는 발생한 일, 참조 번호, 다음에 일어날 일을 명시하고, 새로 고침 후에도 유지됩니다. 토스트는 영수증이 아닙니다. [S: GOV.UK 확인 페이지; 기초]

에이전트 독자를 위해

• 모든 컨트롤에는 표시 레이블과 일치하는 프로그래밍 방식의 이름이 있고, 선택 사항은 열거 가능합니다(기본 select, 표시 라디오). [J]
• 제약 조건은 pattern 속성에만 있는 것이 아니라 제출 전에 표시되는 텍스트(형식, 길이, 허용 값)여야 합니다. [J]
• 오류는 수정될 때까지 안정적인, 필드 옆과 요약의 텍스트입니다. [J]
• 각 단계의 URL 또는 제목은 에이전트가 흐름 중 어디에 있는지 알려줍니다. 뒤로 가기 및 변경 경로가 존재합니다. [J]
• 외부인이 작성한 텍스트(이메일에서 미리 채워진, 추천 노트)는 레이블이나 지시문이 아닌 인용된 데이터로 표시됩니다. [J]
• 결과가 중요한 제출은 서버에 권한을 유지합니다: 답변 확인 페이지는 사람을 돕습니다. 그것을 클릭하여 통과하는 에이전트를 막지는 않습니다. [J]

빌드 순서

1. 각 답변의 사용처와 함께 질문을 나열하세요. 사용처가 없는 것은 삭제하세요.
2. 형태를 선택하세요: 한 페이지, 페이지당 하나의 질문, 또는 작업 목록. 분기를 스케치하세요.
3. 카피를 작성하세요: 질문, 힌트, 원인별 모든 오류 메시지, 버튼 레이블, 확인.
4. 기본 요소로 빌드하세요: label for, fieldset/legend, 올바른 type, inputmode, autocomplete, novalidate.
5. 서버 유효성 검사 및 멱등적 제출, 그런 다음 동일한 메시지를 사용하는 클라이언트 유효성 검사.
6. 오류 상태: 요약, 포커스, 제목 접두사, 인라인 메시지, 보존된 입력.
7. 답변 확인 및 확인 페이지; 다중 세션인 경우 저장 및 돌아오기.
8. 마지막으로 스타일을 지정하세요. 브랜드가 외관을 소유합니다(brand-identity).

검증

• node <form-design>/scripts/form-check.mjs <url|file|dist> --try-submit을 로컬 또는 테스트 빌드에 대해 실행하세요. 이름과 표시 레이블, autocomplete 유효성 및 목적, 입력 유형, 붙여넣기, 숨겨진 기본 라디오, 그룹 legend, 오류 연결, 실패한 제출 후 포커스, 제출 문구를 확인합니다. 오류 시 exit 1을 반환합니다. --try-submit은 실제로 제출합니다: 절대 프로덕션에 사용하지 마세요.
• node <interface-guidelines>/scripts/audit.mjs <url|dist>를 일반 렌더링 감사(대비, 대상, 키보드, 리플로우, 에이전트 안정성)를 위해 실행하세요.
• 실제 프로필로 비밀번호 관리자 및 브라우저 자동 완성을 사용하여 작성하세요: 모든 개인 필드가 채워지고 아무것도 잘못된 상자에 들어가지 않아야 합니다.
• 키보드만으로 작성하고, 320px에서 200% 텍스트로 작성하세요.
• 접근성 스냅샷만으로 에이전트로서 작성하세요: 이름으로 각 필드를 찾고, 모든 선택 사항을 읽고, 잘못 제출하고, 오류를 읽고, 수정하고, 완료하세요.
• 잘못된 데이터: 한 단어 이름, 아포스트로피와 악센트가 있는 60자 이름, 우편번호가 없는 일본 주소와 아일랜드 주소, 공백이 포함된 붙여넣은 카드 번호, 제출 더블 클릭, 흐름 중간의 세션 시간 초과.

함정

• 레이블 대신 플레이스홀더를 사용하거나, 테두리로 축소되어 대비에 실패하는 플로팅 레이블.
• 카드, 전화, 우편번호 또는 코드에 type="number"를 사용.
• 개인 데이터에 autocomplete="off"
• 에이전트가 열거할 수 없는 사용자 정의 선택 컨트롤.
• 제출 버튼에 "제출"이라고만 표시.
• 붙여넣기 차단 또는 비밀번호 필드에 maxlength 설정.
• 오류 메시지가 표시 텍스트가 아니라 title 속성 또는 aria-label로만 제공.
• 다중 열 레이아웃이 필드를 시각적으로 그룹화하지만 읽기 순서와 포커스 순서를 깨뜨림.
• 여러 세션 폼에 저장 및 돌아오기 기능이 없음.
• 서버 측 유효성 검사가 없거나 서버와 다른 오류 메시지 사용.
• 스크린 리더 또는 에이전트가 오류 없이 통과할 수 있지만 시력이 있는 사용자는 문제가 있는, 레이블과 일치하지 않는 접근 가능한 이름.

참조

• interface-guidelines — 모든 UI에 대한 계층화된 원칙.
• references/human-interface.md — 기본 폼 규칙.
• references/fields.md — 필드별 패턴.
• references/accessibility.md — 프레임워크별 접근성 구현.
• scripts/form-check.mjs — 검증 스크립트.

설치

이 스킬을 Claude Code에 설치하세요:

claude add skill thecatthatflies/form-design