에러 피드백 UX 설계
사용자 반응 관찰에서 시작한 에러 메시지 개선
목차
- 에러 처리는 왜 필요한가?
- 에러 피드백 UX 설계 ← 현재 문서
- 에러 처리 원칙 세우기
- Client Side 렌더링 에러 처리
- Server Side 렌더링 에러 처리
- 이벤트 핸들러 시점 에러 처리
- 전역/공통/개별 에러 처리
문제 정의
사내 운영팀으로부터 어드민 사이트 오류 제보를 받았을 때입니다.
단순히 해당 오류만 수정하고 넘길 수도 있었지만, 근본적인 의문이 들어 디자이너분께 논의를 요청했습니다.
"사용자가 에러 화면에서 필요한 정보는 무엇일까요? 그리고 그 정보는 왜 필요할까요?"
사용자 반응 관찰
디자이너와 함께 운영팀(사용자)의 행동 패턴을 분석해 보았습니다.
- 당황: "어? 갑자기 왜 이러지?"
- 혼란: "내가 뭘 잘못 눌렀나? 뒤로 갔다 다시 하면 되나?" (불필요한 시행착오)
- 해결 시도: "모르겠네... 개발팀에 물어봐야겠다." (업무 중단 및 리소스 낭비)
해결 방법
이미 정론이 존재했습니다.
사용자를 안심시키고 정상적인 서비스 흐름으로 복귀시키기 위해, 아래의 항목이 들어가야 했습니다.
- 원인: 오류가 발생한 이유를 명확히 설명
- 해결 방법: 사용자가 스스로 조치할 수 있는 방법 안내
- 탈출 수단: 홈으로 이동하거나 이전 페이지로 돌아가는 경로 제공
- 추가적으로, 빠른 대응을 위해 오류 코드를 같이 노출하는 경우도 있었습니다.
안 좋은 예시
- 시스템 셧다운: 시스템 기본 에러 화면 노출
Application error: a client-side exception has occurred (see the browser console for more information)
- 불친절한 메시지: "알 수 없는 오류가 발생했습니다"와 같이 정보가 없는 안내
- 무응답: 버튼을 눌렀는데 화면 변화 없이 콘솔 에러만 발생하는 경우
좋은 예시
- 구체적 안내: "권한이 없습니다. 개발팀에
READ:COMMUNITY:LIST권한을 요청해 주세요." - 대안 제시: "서버 오류가 발생했습니다. 문제가 지속되면 [고객센터]에 문의해 주세요."
구현 방법
오류가 표시될 수 있는 경우마다, 오류 종류마다 적절한 에러 메시지가 노출되도록 구현했습니다.
성과
운영팀과 개발팀 간의 불필요한 커뮤니케이션 비용이 완전히 제거되었습니다.
다음 단계
UX 목표를 달성하려면, 에러를 어디서 잡고 어떻게 던져야 할까요?