에러를 처리하는 일은 팀 프로젝트다.
에러 메시지는 일상적으로 등장한다. 서버가 다운되거나, 인터넷 연결이 안 되어 있거나, 비밀번호를 틀렸을 때처럼 다양한 상황에서 에러 메시지가 나타난다. 그때 "무언가 잘못되었습니다"라고 에러 메시지는 알려주지만 도대체 뭐가 잘못되었다는 걸까? 무슨 일이 벌어졌고, 유저는 이 상황을 어떻게 해결할 수 있을까?
약 1년 전, Wix에서는 내부적으로 에러 메시지가 위의 질문들에 대한 답을 주지 못한다는 사실을 깨달았다. Wix에서는 대략 1,000여개의 에러 메시지를 한 달 동안 수정했다. 문제를 깨달았을 때 잽싸게 행동해야 한다는 걸 알기 때문이다.
이 작업을 완료하니, 우리는 어떤 에러 메시지가 좋은지, 나쁜지를 정의내릴 수 있게 되었다.
잘못된 에러 메시지
위의 예시가 잘못된 이유는 다음과 같다.
1. 부적절한 어조를 사용하고 있다.
: 만약 의사가 수술을 하고 있는 도중에 갑자기 "아이쿠! 뭔가 잘못됐네...."라고 말한다면 그걸 듣고 싶은 사람이 있을까? 에러는 말랑말랑하고 귀여운 무언가가 아니다. 우리는 이걸 유저에게 진지하고, 그들이 겪고 있는 문제를 충분히 이해하고 있다는 듯이 전해야 한다.
2. 전문용어를 사용하고 있다.
: 유저 중심의 디자인이 대세인 세상이지만, 전문용어는 여전히 에러 메시지에 슬금슬금 들어와있다. "유저의 데이터를 불러올 수 없습니다?" 사용자에게 중요한 건 전문적인/기술적인 어떤 것이 아니다. 단지 무엇이 잘못되었고 그걸 어떻게 고칠 수 있는지를 알고 싶을 뿐이다.
3. 책임을 전가한다.
: 문제를 발생시킨 행동보다는 문제 자체에 집중을 해야 한다. 유저가 한 액션으로 인해 특정 오류 메시지가 떴더라도 사용자에게 수치심을 주어선 안 된다. 또한, 제삼자에게 책임을 전가하는 것도 좋지 않은 행위다. 이는 Wix의 부담을 어느정도 덜어주었을지는 몰라도 Wix가 프로페셔널해 보이는 일에는 도움이 되지 않는다. 오히려 Wix의 프로페셔널함을 방해한다. "XX가 지금 응답하지 않습니다"보다는"XX와 연결하는 데에 문제가 있습니다"라고 차라리 말하는 게 낫다.
4. 이유 없이 일반적인 액션만 명령한다
: 만약 내부에서 에러의 원인을 알고도 유저에게 말하지 않는다면, 그 사용자들에게 궁극적으로 좋지 않은 경험을 가져다 줄 수 있다.
[낱선의 코멘트]
그러니까 한 마디로
앗! 에러가 발생했어요.
XX가 지금 응답하지 않아, OO님의 데이터를 불러올 수 없어요. 나중에 다시 시도해주세요.
이 문장은 유저가 취해야 할 액션이 명확하지 않고, 유저가 알 필요 없는 정보를 제공하고 있으며, 제삼자에게 책임을 전가하고 있다는 뜻이다.
가장 문제가 되는 지점은 '유저가 취해야 할 액션이 명확하지 않다'는 점 아닐까.
좋은 에러 메시지
1. 무슨 문제가, 왜 생겼는지 말해준다.
: 무슨 문제가 생겼는지 매우 명확하게 말해줘야 한다. 이는 비주얼 작업과 텍스트가 함께 조화를 이뤄야 가능하다. 기술적인 문제가 있었다는 설명밖에 할 수 없어도 오류가 발생한 이유는 반드시 설명해야 한다. Wix에서는 공간만 충분하다면 "우리의 문제다"라고 말하기로 결정했다. 이는 사용자의 잘못이 아니라는 것을 다시 한 번 강조하기 위해서였다.
2. 안심할 수 있게 만든다.
: 가능한 경우, 에러에 영향을 받지 않은 항목을 알려주자. 예를 들어, 이메일이 전송되지 않았음에도 불구하고 변경사항이 초안으로 저장되었다는 사실 같은 것이 있다.
3. 공감해라.
: 지나치게 사과하는 것은 지양하는 게 좋겠지만, 상황이 허락한다면 "부탁하는" 어휘를 사용하는 게 좋겠다. 어쩌면 정말 심각한 상황일 수도 있고, 현재 서비스가 문제 해결을 도울 수 없는 상황일 수도 있다. 그럴 때 서비스는 더 공감하기 위해 "부탁하는" 어휘를 사용해야 할 수도 있다.
4. 유저가 문제를 해결할 수 있도록 도와야 한다.
: 유저에게 이 문제를 당장 해결할 수 있는 방법을 알려줘야 한다. 주어진 공간이 적다면? "이 문제를 해결하는 방법 알아보기" 또는 "이 문제를 해결하려면 어떻게 해야 합니까?"와 같은 문제 설명 링크가 포함된 문서를 보내주자.
5. 빠져나갈 수 있는 길은 꼭 만들어두자.
: 만약 유저가 문제를 해결하지 못했거나, 문제가 계속 발생할 여지가 있다면 고객센터로 연결하는 경로를 제공하자.
이제 무엇이 좋고 나쁜 메시지의 원인이 되는지 명확히 정의했으므로, Wix는 잘못된 메시지를 제거하기로 했다.
잘못된 에러 메시지 삭제에 대처하는 방법
콘텐츠 관리 시스템에 검색한 결과, "error"라는 단어가 포함된 콘텐츠가 7,643개가 있었다. 모두 검토가 필요했다. 기준을 세운 후 검토를 진행한 다음, "도움이 되지 않는다"고 판단되는 모든 에러 메시지 목록을 개발자에게 전달했다.
개발자들은 메시지가 뜨는 원인, 메시지 발생 빈도 및 문제 해결을 위해 취할 수 있는 조치들을 조사했다. 제품 매니저, UX 디자이너 및 UX 라이터는 해결책을 떠올렸다. 때로는 단순한 콘텐츠 변경일 때도 있었지만 때로는 완전히 새로운 에러 메시지 작성이 필요했다. 그리고 대부분은 추가 개발 작업이 필요했다.
먼저 처리해야 할 오류의 우선순위를 정하고 작업을 진행했는데, 우선 순위는 오류가 발생하는 빈도와 이로 인해 사용자가 플로우를 완료할 수 없게 되었는지 여부에 초점을 맞췄다. 그리고 1주에서 4주까지 마일스톤을 설정해 일이 중단되지 않도록 세팅했다.
레슨 런
포괄적인 메시지와 불분명한 메시지 사이에는 차이가 분명히 존재했다. "오류가 발생했습니다.(Something was wrong)"이라는 포괄적인 메시지가 많았지만 불분명한 메시지들도 많았다. 후자 역시 저자와 마찬가지로 좋지 않기 때문에 주의를 기울일 필요가 있다.
포괄적인 메시지는 사용자에게 현재 무언가가 잘못되었음을 알리는 것 외에는 어떠한 것도 알려주지 않는다. 불분명한 메시지는 무엇이 잘못되었는지 설명하려고 했으나 혼란스러운 언어를 사용해 불분명해졌다.
(포괄적인 메시지: 오류가 발생하여 이 작업을 완료할 수 없습니다.
불분명한 메시지: 요청 권한을 허용한 뒤 다시 시도하세요.)
대부분 내용상의 문제는 아니다. Wix의 CEO이자 이 프로젝트가 시작된 이유인 아바사이 아브라함은 모든 직원에게 이메일을 돌렸다. "오류는 잘못된 개발과 제품의 결과다. 우리는 모두 함께 그걸 신경써야 한다"
그리고 그의 말처럼, Wix의 직원들은 이 메시지들을 함께 고쳐나갔다. 개발자들은 에러를 조사하고 매핑했고, 제품 관리자는 우선순위를 정하고 작업을 만들어나가야 했다. UX 디자이너는 새로운 플로우에 디자인을 제공해야 했고, UX 라이터들은 수천 개의 오류 메시지를 쓰고 다시 써야 했다.
UX 라이터들은 더 많은 질문을 해야 했다. 예전에는 개발자가 우리에게 이렇게 말하곤 했다. "여기에 들어갈 일반적인 에러 메시지 하나가 필요해요. 하나 더 추가할 수 있어요?"라고. 그러면 UX 라이터들은 대개 "그럼요"라고 대답했을 것이다. 예비 메시지거나 자주 등장하지 않는 메시지라고 생각했기 때문이다. 그러나 이제는 "왜 유저에게 이 화면이 표시되는가", "백그라운드에서는 무슨 일이 일어나고 있는가"에 대해 물어봐야 했다.
우리는 배움의 기회를 놓쳤다. 사전에 문제를 예방하기보다는 일일이 대응하는 편이었다. 우리는 전략적인 생각 없이 메시지를 쓰고 다시 쓰는 데 급급했다.
Wix는 "친구와 대화하는 것처럼 써라"라는 모토가 있다. 유저의 프로세스 전체에 걸쳐 친구가 되는 것을 진심으로 믿고 있는 사람들이었지만, 우리는 험단을 좋아하지만 삶이 힘들 때 전화를 받지 않는 그런 친구에 가까웠다는 게 밝혀졌다. 그건 Wix가 원하는 친구가 아니기 때문에 우리는 정말로 깊이 파고들어서 우리가 할 수 있는 최선을 다하지 않았다는 것을 인정해야만 했다.
우리가 함께 일하면 더 좋은 제품을 만들 수 있다. 오글거리긴 하지만, 사실이다.