에러 메시지 쓰기
이 글은 온라인 비즈니스 소프트웨어를 제공하는 Wix의 UX Writer Jenni Nadler가 쓴 글을 번역, 요약했습니다.
원문
인생의 쓴맛을 겪는 중이라면 오류 메시지를 잘 쓰자
우리는 오류 메시지를 매일 만나는데 정말 무엇이 잘못되었고, 어떻게 고칠 수 있는지를 알려주는가?
이미지 출처. When life gives you lemons, write better error messages우리는 아니라고 판단했고, 그래서 수천 개의 오류 메시지를 바꾸는 Errorgate 2021에 돌입했다.
1. 나쁜 오류 메시지와 좋은 오류 메시지를 정의하자.
나쁜 오류 메시지
이미지 출처. When life gives you lemons, write better error messages부적합한 톤: 의사가 진찰을 하는데 갑자기 "Oops!, something went wrong..." 한다면 어떨까. 이 상황은 애교떨거나 포장할 때가 아니다. 서비스는 이 오류 상황을 심각하게 여기고, 이 일이 사용자에게 중요하다는 사실을 알려줘야 한다.
기술 용어: 디자인이 사용자 중심적으로 바뀌고 있지만 오류 메시지는 유독 기술 용어가 여전히 많다. we can't fetch your data? my credentials were denied? 기술은 사용자에게 중요하지 않다. 뭐가 잘못되고 어떻게 고치는가만 알면 된다.
비난 떠넘기기: 문제에 이르게 된 행동이 아니라 문제에만 집중하자. 사용자에게 수치심을 주지 말자. 그들의 행위로 이 오류가 생겼다 해도 말이다. 제 3의 서비스 업체에도 비난을 돌리지 말자고 결정했다. 이는 프로답지 않은 행동이다. "----가 응답하지 않습니다"가 아니라 "(우리가) ----에 연결하는데 문제가 있습니다"라고 하자.
너무 포괄적이다: 때로 왜 문제가 생겼는지 모를 때도 있지만 알 때도 있다. 알면서도 말하지 않는 건 극도로 나쁜 서비스이다.
좋은 오류 메시지
이미지 출처. When life gives you lemons, write better error messages무슨 일이 왜 일어났는지 말한다: 무슨 일이 일어났고, 일어나지 않았는지 명확하게 알려주자. '기술적인 문제가 있다' 밖에 할 말이 없다 해도 말이다. 우리는 공간이 허락한면 "우리 쪽의 문제"라고 말하기로 결정했다. 사용자의 잘못이 아니라고 재언급해 주는 것이다.
재확인해주자: 공간이 허락한다면 이 오류로 영향받지 않은 것이 무엇인지 알려주자. 예를 들면 이 변화로 이메일은 보내지 못했지만 임시 저장은 됬는가?
공감하자: 지나치게 자책할 필요는 없지만 사정이 허락한다면 "please"를 쓰자고 결정했다. 아마 진짜로 긴급한 상황일 수도 있고, 또는 우리가 절대 해결해 주지 못하는 것일 수도 있다. 그래도 "please를 쓸 것이다.
해결할 수 있도록 돕는다: 해결할 방법이 있다면 무엇인지 정확히 말하라. 공간이 모자르다면 “Learn how to resolve this”나 “How do I fix this?”같이 설명하는 링크 이름으로 해결 방법을 적은 글로 이동하게 하자.
돌아갈 길을 터주자: 문제를 해결할 수 없다면, 또는 계속 문제가 일어날 수 있다면 고객 센터에 연락할 수 있는 길을 제공하라.
2. 나쁜 오류 메시지 제거하기
우리는 컨텐트 매니지먼트 시스템을 뒤져서 "error"가 입력된 값을 7,643개 발견했다. 진정으로 기념비적인 과제다. 에러와 연관된 모든 콘텐츠를 살폈다. 그리고 "포괄적이거나" "도움 안되는" 오류 메시지 목록을 개발자에게 보냈다.
개발자들은 메시지를 하나 하나 보면서 이것이 어떤 코드에서 나왔는지를 mapping했다. 왜 이 메시지가 나오는지, 얼마나 자주 나오는지, 이 문제를 해결하기 위해 무엇을 할 수 있는지를 보았다.
이 오류 mapping을 근거로 프로덕트 매니저, UX 디자이너, 라이터가 모여 해결안을 생각했다. 때로는 간단하게 글자만 바꾸면 되지만 어떤 때는 완전히 새로운 메시지를 써야 한다. 많은 경우 추가 개발이 필요했다.
그리고 나서 어떤 메시지부터 우선적으로 바꿀지 우선 순위를 정했다. 얼마나 자주 발생하는지, 사용자가 행위를 끝마치는 것을 얼마나 방해하는지에 따라 결정했다.
3. 이 프로젝트로 배운 것
포괄적인 메시지와 불분명한 메시지는 다르다: 포괄적인 메시지는 "something went wrong"같은 것이다. 불분명한 메시지는 잘못된 것을 알려주기는 하는데 내용이 어렵다. 불불명한 메시지는 포괄적인 것만큼 나쁘다.
이미지 출처. When life gives you lemons, write better error messages단지 글 문제가 아니다: 포괄적인 오류 메시지는 나쁜 개발과 제품의 결과이다. 오류 메시지를 위해 Wix의 모든 사람들이 분야를 막론하고 협업했다. 개발자들은 관찰하고 매핑했다. 프로덕트 매니저는 우선 순위를 정하고 태스크를 정했다. 디자이너는 새로운 flow를 위한 디자인을 만들었다. UX Writer는 수천 개의 오류 메시지를 새롭게 썼다.
우리는 더 질문을 했어야 했다: 개발자들이 "여기 좀더 포괄적인 메시지가 필요해요. 한 문장 더 추가해 주실 수 있나요?"라고 요청했을 때 알았다고만 했다. "왜 사용자들이 이것을 보지요?" 라거나 "뒷 단에서 어떤 일이 일어나나요?"라고 잘 묻지 않았다.
배울 기회를 놓쳤다: 우리는 전략적인 사고없이 그저 닥치는대로 메시지를 쓰고 또 썼다.
우리는 나쁜 친구였다: Wix에는 "친구에게 말하듯이 써라"라는 경구가 있다. 우리는 정말 사용자를 친구처럼 대한다고 믿었다. 하지만 그저 수다나 떠는 친구였다. 정말 어려움을 겪을 때는 외면했다. 이것은 우리가 원하는 친구가 아니다. 우리는 더 깊이 파야 했다.
함께 할 때 좋은 제품을 만든다: 뻔한 말이지만 사실이다.
4. 이 과정을 통해 바뀐 것
오류 메시지에 대처하기 위한 cross functional 팀을 세웠다: 시니어 프로덕트 매니저, 프론트엔드와 백엔드 개발자, UX 디자이너와 UX 라이터로 구성됬다. 제품을 만들고 나서 사후책이 아닌 제품의 개발 사이클의 일부가 되었다.
공동 책임으로 인식하게 됬다: 프로덕트 메니저는 눈에 보이는 flow 뿐 아니라 오류나 끝단의 사례에 더 신경쓰게 되었다. 개발자들은 오류에 더 주의한다. 데이터 과학자들은 오류 상황을 적합하게 추적할 수 있도록 오류 분석에 더 공을 들인다.
론칭 후 한 달 후에 오류를 다시 본다: 새로운 제품이라면 어떤 오류가 생길지 알 수 없다. 그래서 론칭하고 한 달 후에 어떤 오류가 생기는지 리뷰하는 절차가 생겼다.
지속적인 리뷰 프로세스: 라이터들은 계속 오류 메시지를 관찰하고 다시 쓴다.
UX 라이터는 포괄적인 오류 메시지를 넘어서기 위해 도전한다 : 프로덕트 매니저나 개발자들이 "그냥 포괄적으로 갑시다." 라고 해도 우리는 '안돼'할 수 있는 힘이 생겼다.
