오류 메시지

제품 안의 문구를 설계하는 일을 UX 라이팅이라고 부르기 전에는, 오류가 났을 때 화면에 뜨는 말이 대개 코드에서 그대로 새어 나온 문장이었습니다. "Error 500", "Invalid input", "요청 처리 중 오류가 발생했습니다" 같은 것들입니다. 개발자가 자기 자신에게 남긴 메모에 가까운 문장입니다. 시스템의 말로 무엇이 잘못됐는지만 적었을 뿐, 읽는 사람이 다음에 무엇을 해야 하는지는 없습니다.

읽는 사람 입장에서는 길이 끊깁니다. 원인을 알아야 하던 일을 계속하는데 화면은 알려 주지 않으니, 같은 버튼을 몇 번 더 눌러 보거나 사람에게 묻는 수밖에 없습니다.

페이지덱에도 그런 시기가 있었습니다. 수아에게 들어오는 문의 중 가장 많은 것이 "저장이 안 된다" 였고, 함께 온 화면 사진에는 언제나 같은 한 줄이 있었습니다. 요청 처리 중 오류가 발생했습니다. 수아는 그 줄로는 답을 못 하니 태오에게 물었고, 태오가 기록을 열어 파일 용량이 한도를 넘겼다는 사실을 찾아냈습니다. 화면이 한 줄만 다르게 적었으면 셋의 시간이 들지 않았을 일입니다.

오류 메시지는 이 자리를 문구 설계의 대상으로 끌어올린 개념입니다. 오류를 없애는 대신, 오류가 난 순간에도 사용자가 혼자 빠져나갈 수 있게 만드는 쪽으로 문제를 바꿔 놓았습니다.

한 줄 안에서 세 가지가 순서대로 일어납니다. 무슨 일이 벌어졌는지 알리고, 왜 그런지를 사람의 말로 좁히고, 지금 할 수 있는 일을 건넵니다. 앞의 둘만 있고 셋째가 없으면 읽는 사람은 고객센터로 갑니다.

1. 상태. 실패한 동작을 이름으로 적습니다. "오류가 발생했습니다" 가 아니라 "문서를 저장하지 못했습니다" 입니다. 어느 동작이 실패했는지 알아야 무엇을 잃었는지 가늠할 수 있습니다.
2. 원인. 시스템 용어가 아니라 사용자가 확인할 수 있는 조건으로 적습니다. "413 Payload Too Large" 가 아니라 "파일이 25MB를 넘습니다" 입니다. 원인을 정확히 알 수 없으면 지어내지 말고 범위만 적습니다. 서버 쪽 문제라 잠시 뒤 다시 하면 된다는 문장이 그런 경우입니다.
3. 다음 행동. 읽은 사람이 바로 할 수 있는 한 가지를 줍니다. 가능하면 문장이 아니라 버튼으로 줍니다. 파일이 크다는 메시지 옆에는 다시 고르기 버튼을, 연결이 끊겼다는 메시지 옆에는 다시 시도 버튼을 둡니다. 누르면 무슨 일이 벌어지는지 알려 주는 버튼 레이블이 여기서 문구의 절반을 맡습니다.

세부 규칙 둘이 더 붙습니다. 하나는 책임의 방향입니다. "잘못된 값을 입력하셨습니다" 는 읽는 사람을 지목하지만 "이 칸에는 숫자만 넣을 수 있습니다" 는 조건을 말합니다. 같은 사실인데 뒤쪽이 다음 행동에 더 가깝습니다. 다른 하나는 기술 정보의 처리입니다. 오류 코드는 지우지 말되 본문에서 빼고 작은 참조번호로 남깁니다. 대부분에게는 쓸모없지만 문의가 들어왔을 때 수아가 태오에게 건넬 유일한 단서입니다.

같은 내용이라도 어디에 띄우느냐에 따라 읽히기도 하고 그대로 사라지기도 합니다. 자리는 대체로 넷입니다.

1. 입력 칸 옆. 형식이 맞지 않는 값처럼 특정 칸에서 생긴 문제는 그 칸 바로 아래에 붙입니다. 화면 위쪽에 모아 띄우면 스무 칸짜리 양식에서 어느 칸이 문제인지 찾는 데 시간이 걸립니다. 입력 칸에 흐리게 적어 둔 예시인 플레이스홀더는 이 자리를 대신하지 못합니다. 입력을 시작하면 사라져서 정작 필요한 순간에 없기 때문입니다.
2. 화면 전체. 목록을 불러오지 못했거나 권한이 없는 것처럼 화면이 통째로 성립하지 않는 경우입니다. 이때는 문구 하나가 아니라 문제가 생겼음을 알리는 화면인 오류 상태 전체를 설계합니다. 보여 줄 내용이 없을 때 뜨는 빈 상태 문구와 생김새가 비슷해서, 데이터가 없는 것인지 못 불러온 것인지를 문장으로 구분해 줘야 합니다.
3. 띠와 토스트. 저장은 됐는데 동기화가 늦는 것처럼 하던 일을 막지 않는 문제에 씁니다. 몇 초 뒤 사라지는 토스트에는 되돌릴 수 없는 내용을 담지 않습니다. 자리를 비웠던 사용자는 그 줄을 못 읽습니다.
4. 제품 밖. 결제가 실패해 계정이 정지될 예정이라면 화면 안에서만 알려서는 늦습니다. 메일이나 알림은 제품을 보고 있지 않은 사람에게 가는 말이라, 무슨 일이 어디서 일어났는지가 한 줄에 다 들어 있어야 합니다.

자리를 정하는 기준은 하나입니다. 이 문제가 지금 하려던 일을 막는가. 막는다면 그 일이 벌어지는 자리에 붙이고, 막지 않으면 흐름 밖에 둡니다.

"이 오류 메시지 원인만 있고 다음 행동이 없어요."

읽고 나서 무엇을 할지 모르는 문구이니 한 줄을 더 붙이자는 뜻입니다.

"500 에러를 그대로 띄우지 말고 참조번호만 남기죠."

기술 정보는 문의 창구에서 쓰고 화면에서는 사람의 말로 적자는 제안입니다.

"이건 인라인으로 붙여야지 상단 토스트로 띄우면 못 봐요."

문제가 생긴 칸에서 멀리 떨어진 자리라 읽히지 않는다는 지적입니다.

페이지덱에서는 민서가 화면을 그리기 전에 그 화면에서 일이 어긋나는 경우를 먼저 적습니다. 파일이 큰 경우, 연결이 끊긴 경우, 권한이 없는 경우처럼 목록을 만들고 줄마다 문구를 채운 다음 그 줄이 들어갈 자리를 잡아 화면을 그립니다. 순서를 뒤집으면 정해진 폭에 말을 욱여넣게 되고, 가장 먼저 잘려 나가는 것이 원인과 다음 행동입니다.

사과가 들어가면 친절한 오류 메시지라고 보는 경우가 많습니다. 미안하다는 말이 태도를 보여 주니 자연스러운 오해입니다. 하지만 읽는 사람이 원하는 것은 위로가 아니라 다음 걸음입니다. "죄송합니다. 오류가 발생했습니다" 는 두 문장 다 할 수 있는 일을 늘려 주지 않습니다. 이 오해가 굳으면 문구 작업이 사과 표현을 고르는 일로 좁아지고, 원인과 다음 행동이 빠진 메시지는 그대로 남습니다.

문구는 화면을 다 만든 뒤에 채우면 된다고 보는 것도 흔합니다. 문장은 언제든 바꿀 수 있으니 그렇게 보입니다. 실제로는 자리가 먼저 정해지면 문구가 그 폭에 맞춰집니다. 한 줄만 들어가는 칸을 만들어 두면 조건과 다음 행동 중 하나를 버려야 하고, 대개 뒤쪽이 잘립니다. 시안에 임시 문장을 둔 채 검토를 넘기는 것도 같습니다. 그 화면이 읽히는지 아무도 확인하지 않은 채 개발까지 갑니다.