좋은 에러 메시지와 나쁜 에러 메시지

✍ 기획자의 글쓰기 시리즈 [📝 좋은 에러 메시지와 나쁜 에러 메시지] (👀 간단 요약) 📌 나쁜 오류 메시지 : 부적합한 톤 ✓ 의사가 진찰을 하는데 갑자기 "Oops!, something went wrong..." 한다면? ✓ 이 상황은 애교 떨거나 포장할 때가 아니다 ✓ 서비스는 이 오류 상황을 심각하게 여기고, 이 일이 사용자에게 중요하다는 사실을 알려줘야 한다 📌 나쁜 오류 메시지 : 기술 용어 ✓ 디자인이 사용자 중심적으로 바뀌고 있지만 오류 메시지는 유독 기술 용어가 많다 ✓ 기술은 사용자에게 중요하지 않다. 뭐가 잘못되고 어떻게 고치는가만 알면 된다 📌 나쁜 오류 메시지 : 비난 떠넘기기 ✓ 문제에 이르게 된 행동이 아니라 문제에만 집중하자 ✓ 사용자에게 수치심을 주지 말자. 그들의 행위로 이 오류가 생겼다 해도 말이다 ✓ "-가 응답하지 않습니다"가 아니라 "(우리가) -에 연결하는데 문제가 있습니다"라고 하자 📌 좋은 오류 메시지 : 무슨 일이 왜 일어났는지 말한다 ✓ 무슨 일이 일어났고, 일어나지 않았는지 명확하게 알려주자 ✓ 기술적인 문제가 있다' 밖에 할 말이 없다 해도 말이다 📌 좋은 오류 메시지 : 재확인해주자 ✓ 공간이 허락한다면 이 오류로 영향받지 않은 것이 무엇인지 알려주자 ✓ 예를 들면 이 변화로 이메일은 보내지 못했지만 임시 저장은 됐는가? 📌 좋은 오류 메시지 : 해결할 수 있도록 돕는다 ✓ 해결할 방법이 있다면 무엇인지 정확히 말하라 ✓ “Learn how to resolve this”나 “How do I fix this?”같이 설명하는 링크를 활용하자 ✓ 문제를 해결할 수 없다면, 또는 계속 문제가 일어날 수 있다면 고객 센터에 연락할 수 있는 길을 제공하라 📌 함께 살펴보기 : 포괄적인 메시지와 불분명한 메시지는 다르다 ✓ 포괄적인 메시지와 불분명한 메시지는 다르다 ✓ 포괄적인 메시지는 "something went wrong"같은 것 ✓ 불분명한 메시지는 잘못된 것을 알려주기는 하는데 내용이 어렵다 📌 함께 살펴보기 : 단지 글 문제가 아니다 ✓ 포괄적인 오류 메시지는 나쁜 개발과 제품의 결과이다. ✓ 개발자들은 관찰하고 매핑했다. 프로덕트 매니저는 우선 순위를 정하고 태스크를 정했다. ✓ 디자이너는 새로운 flow를 위한 디자인을 만들었다. ✓ UX Writer는 수천 개의 오류 메시지를 새롭게 썼다. 📌 함께 살펴보기 : 우리는 더 질문을 했어야 했다 ✓ "왜 사용자들이 이것을 보지요?" 라거나 ✓ "뒷 단에서 어떤 일이 일어나나요?"라고 잘 묻지 않았다. ✓ 우리는 전략적인 사고없이 그저 닥치는대로 메시지를 쓰고 또 썼다. 📌 함께 살펴보기 : 공동 책임으로 인식하게 됐다 ✓ 프로덕트 매니저는 눈에 보이는 flow 뿐 아니라 오류나 끝단의 사례에 더 신경 ✓ 개발자들은 오류에 더 주의 ✓ 데이터 과학자들은 오류 상황을 적합하게 추적할 수 있도록 오류 분석