좋은 에러 메시지는 사용자가 스스로 고칠 수 있게 만든다

먼저 던질 질문

에러 메시지는 무엇을 말해야 하는가

핵심 관점

좋은 에러 메시지는 사과문도 기술 보고서도 아니다. 사용자가 문제를 이해하고 다음 행동을 선택할 수 있게 만드는 짧은 안내문이다.

상태가 잘 읽히는 장면

비밀번호는 8자 이상이어야 합니다.

숫자와 영문을 함께 입력해주세요처럼 해결 방법을 제공한다.

인터넷 연결을 확인한 뒤 다시 시도해주세요처럼 사용자가 할 수 있는 행동을 알려준다.

사용자를 막는 상태

Invalid input처럼 무엇이 잘못됐는지 알 수 없는 메시지.

문제가 발생했습니다만 반복하는 메시지.

상태 피드백 사례와 근거

에러 메시지는 문제, 위치, 해결 방법을 함께 말해야 한다

NN/g는 오류 메시지가 쉬운 언어로 문제를 설명하고 해결책을 제안해야 한다고 말한다. Invalid input 같은 문구는 개발자에게는 충분해도 사용자에게는 부족하다.

전화번호가 올바르지 않습니다보다 휴대폰 번호는 숫자 10~11자리로 입력해 주세요가 낫다. 사용자가 무엇을 바꾸어야 하는지 바로 알 수 있기 때문이다.

실무 해석

GOV.UK의 Error message와 Error summary는 필드 근처 오류와 상단 요약을 함께 사용한다. 프론트엔드에서는 aria-describedby, 오류 ID, focus management가 함께 설계되어야 한다.

피드백 설계 기준

• 무엇이 문제인지 말한다
• 왜 문제가 되었는지 필요한 만큼 설명한다
• 사용자가 할 수 있는 다음 행동을 제안한다

자주 빠지는 함정

정확한 기술 원인을 그대로 보여주는 것이 좋은 설명은 아니다. 사용자가 고칠 수 없는 정보를 많이 주면 메시지는 더 정확하지만 덜 유용해진다.

추가로 비교할 상태

• 기술 에러 문구와 사용자 문구의 전후 비교를 만든다
• 결제 실패, 로그인 실패, 파일 업로드 실패 메시지를 수집한다
• 사용자를 탓하지 않는 문장 사례를 모은다

상태 설계 질문

• 문제, 원인, 해결 방법이 모두 들어가는가
• 보안상 자세히 말하면 안 되는 오류도 다뤘는가

출처

• Nielsen Norman Group, Error-Message Guidelines: https://www.nngroup.com/articles/error-message-guidelines/
• GOV.UK Design System, Error message: https://design-system.service.gov.uk/components/error-message/
• GOV.UK Design System, Error summary: https://design-system.service.gov.uk/components/error-summary/
• W3C, Web Content Accessibility Guidelines WCAG 2.2: https://www.w3.org/TR/WCAG22/