Multi-Step Form
다단계 폼
다단계 폼은 하나의 긴 작업을 더 작은 페이지로 나눕니다. 제출하기 전에 답변을 확인합니다.
다른 예시
프로젝트 양식은 각 답변을 저장하고 사용자가 뒤로 갈 수 있게 합니다. 제출 후 검토 페이지와 하나의 영수증을 표시합니다.
주요 부분
- 01현재 단계
- 02페이지 목적
- 03뒤로 및 계속
- 04저장된 초안
- 05검증 및 검토
- 06제출 영수증
사용할 때
작업이 한 페이지에 너무 길거나 의미 있는 순서와 검토 단계가 있을 때 사용하세요.
다음 경우에는 사용하지 마세요
단계를 추가하기 위해 짧은 형식을 나누지 마세요. 사람들이 다시 돌아오거나 새로고침하거나 나중에 돌아올 때 답변을 유지하세요.
코드에서 사용된 이름
ordered steps + saved draft + validation + review + one final submit 출시하기 전에
Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages.
Outcome：Complete the task with 다단계 폼 (Multi-Step Form)。 User context：프로젝트 양식은 각 답변을 저장하고 사용자가 뒤로 갈 수 있게 합니다. 제출 후 검토 페이지와 하나의 영수증을 표시합니다. Recommended pattern：다단계 폼 (Multi-Step Form)。 Why it fits：작업이 한 페이지에 너무 길거나 의미 있는 순서와 검토 단계가 있을 때 사용하세요. Do not use it when：단계를 추가하기 위해 짧은 형식을 나누지 마세요. 사람들이 다시 돌아오거나 새로고침하거나 나중에 돌아올 때 답변을 유지하세요. Product requirements: Define the default, loading, empty, error, success, and recovery states. Keep user input. Give clear feedback after every action. Accessibility and resilience: Use semantic HTML, full keyboard access, and visible focus. Make the layout work when zoomed and support reduced motion. Follow the project’s current rules. Do not add a new UI library unless the project already uses it. Acceptance criteria: The main task works with keyboard only and at 320px width. Focus and status changes are announced. Check loading, failure, retry, cancel, and reduced-motion paths. Evidence and limits (evidence boundary)：하나의 공식 표준이 전체 용어를 통제하지 않음. 의미는 팀, 플랫폼 또는 프레임워크마다 달라질 수 있음. Unknowns to confirm: Product wording, data source, analytics events, supported devices and languages, and platform limits.
이 요청을 확인하세요
Review how 다단계 폼 (Multi-Step Form) is used now. Definition: 다단계 폼은 하나의 긴 작업을 더 작은 페이지로 나눕니다. 제출하기 전에 답변을 확인합니다. Release checks: Give each field a label that code can read. Link hints and errors, and keep entered values. Check autofill, keyboard order, validation timing, submit states, failure recovery, zoom, and languages. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.