폼 오류 상태는 사용자가 실수했다는 사실을 알려주는 화면이 아니라, 다음 행동을 안내하는 화면입니다. 오류 문구가 친절해 보여도 어느 필드를 어떻게 고쳐야 하는지 알 수 없다면 좋은 UI가 아닙니다. 가입, 문의, 결제, 신청 폼처럼 전환과 연결된 화면에서는 오류 처리 방식이 곧 사용 경험의 품질이 됩니다.
오류는 발생한 위치 가까이에 보여주기
상단에 “입력값을 확인해주세요”만 보여주면 사용자는 다시 모든 항목을 훑어야 합니다. 오류가 난 필드 바로 아래에 이유와 해결 방법을 보여주면 수정 시간이 줄어듭니다. 여러 항목에서 동시에 오류가 발생한 경우에는 첫 오류 필드로 초점을 이동시키는 방식도 도움이 됩니다.
| 상단 알림 | 전체 제출이 실패했다는 사실을 알려주는 용도로만 사용합니다. |
|---|---|
| 필드 하단 문구 | 해당 입력값의 문제와 해결 방법을 직접 설명합니다. |
| 색상 강조 | 오류 필드를 빠르게 찾도록 돕되 색만으로 의미를 전달하지 않습니다. |
| 초점 이동 | 키보드 사용자도 바로 수정 위치로 이동할 수 있게 합니다. |
오류 문구는 원인과 해결을 함께 써야 합니다
“유효하지 않습니다”는 짧지만 사용자가 무엇을 바꿔야 하는지 알려주지 않습니다. “이메일 주소에 @를 포함해주세요”처럼 원인과 해결을 함께 쓰면 바로 수정할 수 있습니다. 비밀번호 오류도 “8자 이상 입력해주세요”와 “영문과 숫자를 함께 입력해주세요”처럼 기준을 나누어 말하는 편이 좋습니다.
필수와 선택은 제출 전에 구분하기
사용자가 제출 버튼을 누른 뒤에야 필수 항목을 알게 되면 폼은 불필요하게 느려집니다. 필수 항목은 라벨에서 먼저 알려주고, 선택 항목은 정말 선택 가능한지 문구로 확인해주어야 합니다. 모든 항목에 별표를 붙이는 방식은 오히려 정보 구분을 흐릴 수 있습니다.
- 필수 항목은 라벨이나 섹션 설명에서 미리 드러냅니다.
- 선택 항목은 비워도 제출 가능한지 분명하게 둡니다.
- 입력 예시는 실제 형식과 같은 형태로 제공합니다.
버튼 상태는 기다림과 실패를 구분해야 합니다
제출 버튼을 누른 뒤 아무 변화가 없으면 사용자는 여러 번 클릭할 수 있습니다. 로딩 상태, 성공 상태, 실패 상태를 분리하면 시스템이 반응하고 있다는 느낌을 줄 수 있습니다. 단, 실패 상태에서는 버튼만 바꾸지 말고 어떤 항목을 고쳐야 하는지 함께 보여주어야 합니다.
색상 외의 단서를 함께 제공하기
오류를 빨간색으로만 표시하면 색을 구분하기 어려운 사용자에게 정보가 전달되지 않을 수 있습니다. 아이콘, 문구, 테두리, ARIA 속성처럼 여러 단서를 함께 사용하면 접근성이 좋아집니다. 오류 문구는 화면 읽기 도구에서도 필드와 연결되어야 합니다.
복구 흐름을 짧게 만들기
사용자가 오류를 고친 뒤 다시 제출하기까지의 흐름도 중요합니다. 수정한 필드의 오류 문구는 즉시 사라지거나 다음 제출 시점에 정확히 갱신되어야 합니다. 이미 올바르게 입력한 값은 유지되어야 하며, 실패 후 모든 필드가 초기화되는 방식은 피해야 합니다.
| 좋은 오류 | “휴대폰 번호는 숫자 11자리로 입력해주세요.” |
|---|---|
| 약한 오류 | “입력값이 올바르지 않습니다.” |
| 좋은 복구 | 수정한 값은 유지하고 첫 오류 위치로 이동합니다. |
| 약한 복구 | 제출 실패 후 모든 입력값을 지웁니다. |
포트폴리오에서 설명할 포인트
폼 오류 상태를 포트폴리오에 넣을 때는 화면이 빨갛게 바뀐 모습만 보여주지 말고, 사용자가 어떻게 복구하는지 흐름으로 보여주는 편이 좋습니다. 오류 발견, 원인 이해, 수정, 재제출까지 이어지는 과정을 설명하면 UI 설계 능력이 더 분명하게 드러납니다.
좋은 오류 상태는 사용자를 탓하지 않고 다음 행동을 좁혀줍니다. 문구, 위치, 버튼 상태, 접근성을 함께 설계하면 작은 폼도 신뢰할 수 있는 화면이 됩니다.
실제 입력 흐름으로 오류 상태 검수하기
폼 오류 상태는 정적인 화면만 봐서는 부족합니다. 사용자가 값을 입력하고, 제출하고, 오류를 보고, 다시 고치는 과정을 순서대로 눌러봐야 합니다. 이때 이미 입력한 값이 유지되는지, 첫 오류 위치로 자연스럽게 이동하는지, 오류 문구가 수정 후 사라지는지 확인해야 합니다.
- 빈 값 제출, 형식 오류, 중복 값처럼 서로 다른 실패 상황을 따로 테스트합니다.
- 키보드만 사용해도 오류 필드와 버튼으로 이동할 수 있는지 확인합니다.
- 오류가 해결된 뒤 성공 메시지나 다음 단계가 분명하게 보이는지 봅니다.
작은 폼이라도 오류 흐름이 나쁘면 사용자는 서비스 전체를 불안하게 느낍니다. 반대로 실패 상황을 잘 안내하면 복잡한 신청 절차도 신뢰를 줄 수 있습니다. 포트폴리오에서는 정상 화면보다 오류와 복구 흐름을 함께 보여주는 편이 UI 설계 능력을 더 정확히 설명합니다.
오류 데이터를 개선에 연결하기
폼 오류가 자주 발생하는 필드는 UI가 충분히 설명하지 못했다는 신호일 수 있습니다. 특정 항목에서 반복적으로 실패한다면 오류 문구만 고칠 것이 아니라 라벨, 예시, 입력 형식, 키보드 타입까지 함께 봐야 합니다. 휴대폰 번호 입력에서 하이픈 허용 여부가 불분명하거나, 이메일 예시가 실제 형식과 다르면 사용자는 같은 실수를 반복합니다.
개선 후에는 제출 성공률뿐 아니라 오류 후 재제출까지 걸린 시간을 같이 보면 좋습니다. 좋은 오류 설계는 실패를 없애는 것보다 실패에서 빨리 회복하게 만듭니다.