개발자의 글쓰기 3장 - 사용자와 소통하는 에러 메시지 쓰기

 

01 에러 메시지를 쓰기 전에 에러부터 없애자

 

친절한 404, 불친절한 404

사용자가 404 에러 페이지를 만나게 되는 이유는

1. 사용자가 URL을 잘못 입력한 경우
2. 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우

첫 번째 경우는 죄송할 이유가 없다. 문제는 두 번째 경우다.

클릭 시 해당 페이지가 없는 경우, 이를 깨진 링크 또는 죽은 링크라고 한다.

 

깨진 링크는 개발자의 책임이다

 

사이트 안에서 링크로 연결되다 깨진 것은 브로큰링크체크닷컴에 들어가서 확인이 가능하다.

또는, 다른 사이트에서 연결된 링크가 깨진 경우가 있다. 특히 검색 엔진이 페이지를 수집했는데,

이후에 페이지 URL이 바뀌거나 페이지를 삭제했는데도 검색 엔진에 원래 페이지를 그대로 갖고 있다가 링크로

연결하는 경우가 있다.

예를 들어, 구글 서치콘솔을 이용하면 구글 검색 엔진에서 특정 사이트의 깨진 링크를 쉽게 찾아낼 수 있다.

 

사용자 에러에 대처하는 메시지

회원가입 실패를 예로 들면, 사용자가 무엇을 잘못했는지 알려줘야 한다.

 

회원 가입을 진행할 수 없습니다. → 휴대폰 번호를 잘못 입력하셔서 회원가입을 진행할 수 없습니다.

 

그런데 사용자 입장에선 정확히 입력했다고 생각하면 왜 에러가 생겼는지 모를 일이다.

그래서 에러를 해결할 방법을 사용자에게 정확히 알려줘야한다.

 

휴대폰 번호를 잘못 입력하셔서 회원가입을 진행할 수 없습니다.

휴대폰 번호 입력란에는 숫자만 입력하십시오.

 

에러 메시지의 목적은 사용자에게 에러가 났음을 알려주는 것이 아닌,

사용자 스스로 에러를 해결하게 하는 것이다.

• [에러 내용] 오류로 인한 문제와 종류 : 회원가입을 진행할 수 없습니다.
• [에러 원인] 오류를 발생시킨 직접적 근본적 원인 : 휴대전화 번호를 잘못 입력하셨습니다.
• [에러 해결 방법] 사용자가 오류를 해결할 가장 쉽고 빠른 방법 : 휴대전화 번호 입력란에는 숫자만 입력하십시오.

에러 메시지를 보여주는 순서

에러 내용과 원인이 복잡할 경우엔?

에러 내용 및 원인을 구구절절 말하기보다는 에러 해결 방법을 먼저 얘기하는 편이 사용자에게 훨씬 낫다.

• [에러 해결 방법] 3초 후에 다시 시도하십시오.
• [에러 원인] 아이템을 인계받을 상대방에게 다른 사용자가 아이템을 인계하는 중이어서 동시에 인계할 수 없습니다.
• [에러 내용] 요청하신 아이템의 인계를 시간 내에 처리하지 못했습니다.

에러 내용과 원인을 합쳐서 쓰면 문장이 복문이 되어 매끄럽지 않을 때가 많다.

이 경우, 에러 내용을 없애고 원인만 간단히 작성해도 해결 방법이 먼저 나오기 때문에 사용자가 충분히 이해할 수 있다.

 

3초 후에 다시 시도하십시오.

상대방이 다른 사용자의 아이템을 인계받는 중입니다.

 

 

오락가락 메시지와 버튼 메시지

‘예’ 버튼을 누르면 어떤 결과가 벌어질 지 예상되지 않는다.

(편집한 내용이 취소돼서 다른 페이지 이동하는지, 편집 내용이 취소될 수 있으니 페이지를 떠나는 행위를 취소하는지)

‘아니오’ 버튼도 마찬가지다.

상황이 애매해진 이유는 ‘취소’라는 단어를 두 번 써서 그렇다. 취소를 아예 쓰지 말고 행동에만 집중하면 오해를 없앨 수 있다.

여기서 좀 더 나아가면, 버튼에 ‘예’ ‘아니요’를 쓰는 것은 좋지 않다.

버튼의 본래 역할은 특정한 행동을 유도하는 것이기 때문이다. (페이스북 알림창 참고)

 

‘예’ 버튼은 ‘삭제하고 이동하기’ 버튼으로,

‘아니요’ 버튼은 ‘계속 편집하기’ 버튼으로 표현해도 좋다.

 

 

03 사용자의 에러를 줄이는 메시지 구조화

 

버튼의 순서

확인이 오른쪽에 있는 이유는 행동의 연속성 때문.

우리는 글을 쓸 때 왼쪽에서 오른쪽으로, 방향 표시할 때도 왼쪽에서 오른쪽으로 화살표를 그린다.

다만 OS, 국가에 따라 순서가 바뀌기도 한다.

국가나 서비스마다 순서가 다 다른 현 시점에서 표준을 정하는 것은 사실상 불가능하다.

따라서 일관된 사용자 경험을 주기 위해 서비스 내에서 일관성을 가지는 것이 좋다.

 

 

04 에러 메시지 대신 예방 메시지를 쓰자

 

 

서비스를 이해하면 에러를 예방할 수 있다

호텔 예약하는 앱을 예로 들어보자.

기본적으로 오늘 이후만 가능하다. 오늘 이전 날짜를 선택하면 당연히 에러가 발생한다.

사용자에게 ‘날짜를 잘못 선택하셨습니다. 오늘 이후 날짜를 선택하십시오.’ 라는 에러 메시지를

출력하는 것 보단, 오늘 이전 날짜를 선택할 수 없도록 비활성화하는 것이 훨씬 효율적이다.

(실제로 이 단순한 아이디어는 많은 예약 사이트의 달력 표시 방법을 바꿨다.)

 

닭이 먼저? 알이 먼저?

ERP에서 사용자가 결재를 하려고 하는 경우, 보통 “결제를 요청하시겠습니까?”하고 확인창이 뜬다.

사용자가 실수로 결재 요청을 했다면 되돌릴 기회를 주거나 결재 요청 전에 결재 여부를 다시 확인하는 절차다.

여기서 두 가지 방법이 존재하는데

1. 재확인 방식: 결재 요청 → 재확인 → 결재 처리
2. 취소 방식: 결재 요청 → 결재 처리 + 취소 기능

이 두 방식 중 어떤 것이 더 좋을까?

개발자 입장에선 사용자에게 먼저 확정을 받는 것이 편하다. 단지 자바스크립트에서 confirm() 명령어 하나만으로도 충분하기 때문이다. 하지만 결재 요청을 취소하는 일은 DB에서 내용을 지워야 하니 번거로워진다.

개발 초기엔 재확인 방식을 많이 사용했지만 사용자들이 취소 기능을 요구하기 시작하면서

재확인과 취소 기능이 섞여 버렸다.

• 혼합 방식: 결재 요청 → 재확인 → 결재 처리 + 취소 기능

사용자 입장에서 보면, 재확인 방식에서는 사용자가 결재 요청 버튼을 누르는 순간 무조건 재확인해야 한다.

재확인은 곧 경고를 의미하고, 사용자의 의사결정은 근본적으로 실수가 잦고 믿을 수 없다고 보는 관점이다.

사용자가 실수로 결재 요청 버튼을 누르는 것을 막기 위해서라면 다른 방식을 사용하자.

결재 요청 버튼의 위치나 크기 등 다시 설정해야 옳다. 사용자가 스스로 취소할 수 있게 해야한다.

결국은 철학의 문제다.

 

사용자를 불완전한 존재로 인식하는 순간 모든 사용자의 행동에 경고로 대응하게 된다.

그러면 시스템도 불안해진다.

 

개발자도 자신만의 철학을 가져야 한다. 에러 메시지를 보여주기 전에 개발자 스스로 사용자를 어떤 관점으로 보는지 생각해 봐야 한다. 에러 메시지를 쓰기 전에 그 메시지가 꼭 필요한 것인지, 본래 역할을 제대로 수행하는지 고려해야 한다.

 

 

 

 

 

Ref.

개발자의 글쓰기 - 김철수