코드 번호만으로는 다음 행동을 알 수 없습니다
문의 양식을 보냈는데 알 수 없는 영문과 숫자 조합만 화면에 나타난다면 이용자는 다시 시도해야 할지, 입력을 고쳐야 할지 판단하지 못합니다. 오류 문구는 무슨 일이 생겼는지와 지금 할 수 있는 일을 함께 알려 주어야 합니다. 내부 코드는 담당자가 원인을 추적하는 데는 도움이 되지만, 이용자에게 보이는 안내의 전부가 되어서는 곤란합니다.
따라서 오류 문구를 정리할 때에는 "이 문구를 처음 보는 사람이 다음에 무엇을 해야 하는지 알 수 있는가"를 기준으로 삼습니다.
이용자의 입력 문제와 서비스 문제를 구분합니다
오류에는 크게 두 가지가 있습니다. 필수 항목이 비었거나 형식이 맞지 않는 경우는 이용자가 바로 고칠 수 있으므로, 어떤 항목이 문제인지 그 칸 가까이에 표시하고 이미 입력한 다른 값은 지워지지 않게 합니다.
서버나 외부 인증 같은 서비스 쪽 문제라면 이용자가 잘못한 것처럼 표현하지 않습니다. 잠시 뒤에 다시 시도하거나 공식 지원 경로를 이용하도록 안내하고, 확인되지 않은 복구 시간을 약속하지 않습니다.
예약이나 결제에서는 처리 여부가 가장 중요합니다
예약이나 결제처럼 중요한 행동에서는 오류 화면이 떠도 요청이 실제로는 접수되었을 수 있습니다. 이때 상태를 확인시키지 않고 다시 제출하라고만 안내하면 중복 신청이 생길 위험이 있습니다. 현재 상태를 확인할 수 있는 경로를 제공하고, 운영자가 추가로 확인해야 한다면 필요한 정보를 최소한의 범위로만 요청합니다.
공개된 댓글이나 게시판에 개인정보를 남기도록 안내하는 문구는 쓰지 않습니다.
문구가 놓이는 위치와 전달 방식을 확인합니다
문구의 내용만큼 위치도 중요합니다. 화면 맨 위에 "오류가 발생했습니다"만 보이고 실제 문제가 있는 입력란은 아래쪽에 있으면 찾기 어렵습니다. 문제가 있는 항목 가까이에 설명을 두고, 키보드로 이동할 때나 화면 읽기 도구를 쓸 때에도 오류가 전달되는지 확인합니다.
색상만으로 오류를 구분하는 것도 피합니다. 색을 구별하기 어려운 이용자도 있으므로 문구나 기호를 함께 사용해야 합니다.
이용자용 문구와 내부 기록을 분리합니다
화면에 보이는 문구와 내부 로그는 목적이 다릅니다. 지원 담당자가 추적할 수 있도록 발생 시각이나 접수번호 정도를 남기되, 민감한 시스템 정보는 공개 화면에 드러내지 않습니다. 문의를 위해 화면 전체를 캡처하거나 민감한 입력값을 보내라고 요구하는 안내는 안전하지 않으므로 피합니다.
문구를 고친 뒤에는 실제 시스템의 동작과 문구가 일치하는지 모바일과 컴퓨터에서 각각 시험해 봅니다.
문구는 짧게, 순서는 상황 설명에서 행동으로 씁니다
문구의 구성은 단순할수록 좋습니다. 첫 문장에서 어떤 상황인지 한 줄로 말하고, 둘째 문장에서 지금 할 수 있는 행동을 알려 주는 순서가 읽기 쉽습니다. "요청을 처리하지 못했습니다. 입력한 내용은 그대로 두었으니 잠시 뒤 다시 보내 주세요"처럼 상황과 행동이 분리되어 있으면 이용자가 두 번 읽지 않아도 됩니다.
사과 표현이나 기술 용어는 필요한 만큼만 쓰고, 이용자에게 책임을 돌리는 표현은 피합니다. 같은 서비스 안에서는 비슷한 상황에 같은 어조의 문구를 쓰도록 맞추면 이용자가 문구를 학습하는 데도 도움이 됩니다. 문구 목록을 한 문서에 모아 두면 새 화면을 만들 때에도 기준을 잃지 않습니다.
출시 전에는 일부러 오류를 일으켜 보는 시험도 도움이 됩니다. 필수 항목을 비워 보내거나 인터넷 연결을 끊고 제출해 보면 실제 이용자가 보게 될 화면을 미리 확인할 수 있고, 문구가 상황을 정확히 설명하는지 점검할 기회가 됩니다.
같은 오류가 반복되면 원인을 고칩니다
문구를 아무리 친절하게 바꿔도 같은 오류가 반복된다면 문제의 원인은 그대로입니다. 오류가 몇 번이나 어떤 단계에서 발생하는지 기록해 두고, 반복되는 항목은 문구 개선에 그치지 않고 양식이나 시스템을 고치는 쪽으로 넘깁니다.
좋은 오류 문구는 이용자에게 코드를 해독하라고 요구하지 않고, 지금 자신의 작업이 어떤 상태인지 이해하고 안전한 다음 단계를 선택할 수 있게 돕습니다. 구체적인 문구는 사이트의 성격과 이용자에 맞춰 직접 시험하며 다듬으시기 바랍니다.