데일리 UX라이팅 챌린지 DAY5 - 오류 대처하기
작업 중 프로그램이 갑자기 꺼졌을 때, 사용자에게 무엇을 알려야 하는가?
소설 쓰기의 정수, ctrl + s소설가 김영하가 <알쓸신잡 3>에서 남긴 어록이 있다.
"학생들이 소설 쓰기에서 중요한 것이 뭐냐고 물어볼 때 이렇게 답했어요. 백업이야."
비단 창작자뿐만 아니라 업무를 하는 모든 사람에게 '저장'은 정말 중요하다. 이를 간과하고 자동 저장이 되지 않는 툴로 작업을 한다면, 언제나 예기치 못한 사고가 벌어질 수 있다.
나는 올해 5월까지 인텔 맥북에어 기본형을 사용했다. 2020년도 초에 출시된 이 노트북은 조금만 무거운 툴을 돌려도 미친 이륙 소리와 함께 불안정한 퍼포먼스를 보였다. 내가 사자마자 한 달 뒤 출시된 M1 칩셋 맥북은 성능이 비교도 안 되게 좋았다. 하지만 도로 갖다 팔고 새 노트북을 살 수도 없는 노릇이었다.
나는 결국 눈물을 머금고 그 맥북과 함께 학부 내내 과제를 했고, 졸업작품을 위한 인디자인 작업까지 마쳤다. 인디자인이 조금만 복잡한 작업을 해도 버벅거리며 강제 종료될 때마다, 이루 말할 수 없는 내면의 깊은 분노가 차올랐다. 그 허망함을 너무도 잘 알기에, 오늘 챌린지의 시나리오에 이입이 잘 됐다.
DAY 5 시나리오
사용자는 디자인 작업을 하고 있습니다. 모바일 앱에서 디자인에 대해 비평하다가, 사용자의 휴대폰이 갑자기 꺼졌습니다. 사용자는 휴대폰을 재시작하고, 앱을 다시 켰습니다.
<챌린지>
앱을 다시 열었을 때 사용자가 즉시 보게 될 메시지를 작성하세요.
사용자는 무엇을 알아야 할까요? (만약 있다면) 콘텐츠를 복구하기 위해 어떤 단계를 거쳐야 할까요? 만약 콘텐츠를 복구할 수 없다면 어떻게 해야 할까요?
글자 수 : 헤드라인 40자, 본문 140자, 버튼 20자 이내 (영문 기준)
전략/가설 설정
오늘 과제는 DAY1, DAY3과 성격이 유사했다. 사용자가 부정적인 감정을 느끼고 있다는 점은 DAY1에서도 다룬 바 있고, '오류 메시지'라는 타입은 DAY3에서도 다뤘다. 다만, 오늘은 복구를 위한 프로세스를 설계해야 한다는 점이 달랐다.
우선 사용자 여정을 파악해 보자. 휴대폰이 갑자기 꺼졌다는 것은, 앱이 예기치 않게 종료되었다는 것을 뜻한다. 이 사실은 사용자도 잘 알고 있다. 그렇다면 이를 굳이 다시 알릴 필요가 있을까?
가령 헤드라인을 <예기치 못한 오류로 앱이 종료되었어요.>라고 구성한다고 하자. 언뜻 보면 무난하고 명확한 라이팅처럼 보이나, 이는 '사용자가 반드시 알아야 할 정보'는 아니다. 사용자가 지금 알고 싶어 하는 것은, 내 작업이 보존되었는가에 대한 여부다.
그러므로 헤드라인에서는 이 질문에 대한 답변부터 보여주는 게 맞다고 판단했다. 앱이 종료되기 전 사용자의 (저장하지 않은) 작업을 불러올 수 있는 버전과 없는 버전을 나눠야겠다고 생각했다.
1. 작업이 보존된 경우
이 경우는 부정적인 경험을 긍정적으로 전환할 절호의 기회다. 먼저 헤드라인에서 발 빠르게 사용자를 안심시켜야 할 것이다. 그리고 본문에서는 왜 이런 상황이 벌어졌는지를 알리고, 작업을 복구하기 위한 안내를 해야 한다.
워크플로우는 우선 버튼을 누르면 앱에서 저장한 사용자의 최근 작업 내역을 불러오고, 맞는지 확인하는 절차를 한 번 거쳐보려 했다. 그러나 곧 불필요하다는 생각이 들었다. 사용자는 지금 빠른 원상복구를 원하기 때문이다. 따라서 클릭 한 번으로 신속하게 이전 작업으로 돌아갈 수 있도록 설계 방향을 변경했다.
2. 작업이 보존되지 않은 경우
이 경우는 사용자가 좌절을 느낄 수밖에 없다. 이럴수록 라이팅은 사용자에게 진솔한 사과의 뜻을 전해야 한다. 휴대폰이 꺼진 이유가 앱의 문제가 아닐 확률이 높더라도, 사과는 사용자의 부정적인 감정을 낮추는 가장 효과적인 해결책이다. 필요한 건 상황을 정직하게 알리고, 다음 행동에 대한 구체적인 안내를 하는 것이다.
여기에서 과거 Notion에서 페이지를 삭제했을 때 문의를 통해 복구했던 경험을 떠올렸다. 중앙 서버에서 데이터가 관리되는 프로덕트라면, 앱 내에 '복구 요청 보내기'와 같은 추가 옵션을 제공할 수 있다. 이 절차는 설령 복구에 실패하더라도, 브랜드가 사용자의 데이터를 소중히 여기며 끝까지 책임지려 한다는 인상을 준다. 당장 나도 이 사건 이후 Notion에게 가지는 신뢰가 높아졌다. 그래서 최근 저장본을 불러오는 기본 버튼과, 복구 요청을 보내는 보조 버튼으로 나누는 전략을 세워봤다.
최종안
오늘은 피그마 템플릿을 바탕으로 간단히 작업했다.
작업 프로세스
1. 자동 저장이 성공적으로 된 경우
처음에는 "갑자기 앱이 종료되었지만, 다행히 최근 작업을 저장했어요."처럼 앱의 자동 저장 기능을 어필하며 사용자의 신뢰를 얻는 방식을 고려했다. 하지만 이내 생각을 바꿨다.
우선 본문이 길어져 어색하기도 하고, 그다음엔 정말 이것이 사용자에게 필요한 정보일까 하는 생각이 들었다. 예기치 못한 종료 후 작업이 보존된 것은 사용자가 당연히 기대하는 기본 기능이지, 프로덕트가 생색낼 '혜택'이 아니다. 이런 상황에서 프로덕트가 사용자에게 '나 잘했지?'라고 어필하는 것은 오히려 사용자에게 는 불필요한 소음이 될 수 있다. 전략\가설 설정에서도 언급했다시피, 사용자는 지금 작업하던 상태로 빠른 원상복귀만을 원하기 때문이다.
그래서 1번 케이스에서는 예기치 못한 종료라는 정보를 제거하고, 사용자가 빠르게 작업으로 복귀할 수 있도록 최대한 건조하고 간결한 문구를 썼다.
사실 본문을 굳이 넣어야 하나도 고민했다. 고심 끝에 헤드라인의 '작업 중이던 내용'을 '저장하지 않고 끝낸 작업'이라고 설명해 주는 텍스트만 넣었다. 대부분이 선택할 '불러오기'를 메인 버튼으로 넣었고, 사이드 버튼으로 "새 작업 시작하기"를 넣어 사용자의 선택지를 넓혔다.
2. 자동 저장에 실패한 경우
최종안을 보면 알겠지만, 왜 이런 상황이 발생했는지에 대한 정보와 함께, 사과를 전달하려 했다.
사용자가 알고 싶어 하는 정보 + 사과 + 다음 행동에 대한 적절한 안내를 모두 본문에 포함하다 보니, 케이스 1에 비해 본문이 훨씬 길어졌다.
작업을 할 때, 정보의 우선순위를 고려하여 사용자가 알고 싶은 순서대로 내용을 배열하고자 했다. 내가 생각한 우선순위는 이렇다
1) 작업 저장 여부 (헤드라인)
2) 이 상황이 발생한 원인 (본문)
3) 다음 행동 안내 (본문 + 버튼)
1), 2)를 모두 작성하고 3)을 쓰려할 때, 내가 사용자라면 무엇을 하고 싶을까에 대해 고민했다. 오류 메시지에서 단순히 '확인' 버튼만 제공하는 것은, 서비스가 책임을 회피한다는 인상을 줄 수 있다. 따라서 사용자가 문제 해결을 적극적으로 시도할 수 있도록, 최근 저장본을 불러오는 버튼과 유저 센터 복구를 요청하는 버튼을 함께 구성했다. 공들인 작업 중이었다면 복구 요청을, 아니라면 최근 저장본을 불러오는 식으로 사용자가 직접 판단하고 선택할 수 있을 것이다.
-
후기
최종안을 완성했어도 고민이 많이 남는다.
1. '작업 내용'은 옳은 표현일까?
- 시나리오에서 제시하는 사용자 상황은 '디자인에 대해 비평을 작성하는 중'이다. 이는 아마 텍스트 위주의 작업일 것이므로 <작성하시던 내용>이 더 정확할 수 있다. 하지만 디자인 앱이라는 프로덕트의 성격을 고려하여 더 보편적인 표현인 '작업'을 선택했다. 하지만 작업을 단독으로 문장에 넣어보니 어색했다. 그래서 작업하시던 내용, 진행 중인 작업, 작업 중이던 내용 등 여러 표현을 염두에 두고 비교하며 작업했다.
사실 내용이라는 단어는 contents라는 영단어를 직역한 것으로 알고 있다. 그래서 조금 더 옳은 국어 표현을 찾고 싶었다. 그러나 한글화 된 영어권 툴의 역사를 감안하면, 이미 다양한 디자인 툴에서 등장하는 '내용'이라는 단어가 갖는 보편성을 무시할 수 없었다. 표현의 정확함 만큼 중요한 것이 익숙함이라는 생각에서였다.
2. "작업 내용을 저장하지 못했습니다."는 옳은 표현일까?
- 이는 사용자가 직접 저장을 시도했다가 실패했을 때 나오는 문구 같다. 명확한 전달이라는 장점은 있지만, 갑작스러운 앱의 종료 -> 자동 저장 실패라는 맥락을 완벽히 담아내지 못했다는 아쉬움이 남았다. (여러분이라면 어떻게 쓰셨을 것 같나요?)
3. 쉼표는 언제 찍어야 할까?
- 본문을 중앙 정렬로 설정했기 때문에, 언어 단위와 무관한 줄 바꿈을 피하고 싶었다. 그래서 첫 번째 줄과 두 번째 줄 사이에 쉼표를 사용했다. 그러나 첫 줄 앞부분에 "죄송합니다."라는 독립된 문장 뒤에 쉼표가 포함된 두 번째 문장이 이어지다 보니, 어색해 보였다. 그래서 삭제했는데, 더 어색해 보였다. 문장의 간결성과 시각적 안정성을 모두 만족시키는 답을 찾고 싶은데, 어떻게 해야 할까?
그나저나 브런치를 올릴 때 바로 브라우저에 작성하는 편인데, 자꾸 쓰다가 로그아웃되어 글이 조금씩 날아가는 것 같다. 전체 선택 후 복붙을 주기적으로 해야 할 듯··· 오늘은 여기까지!
