사용자 경험

제품의 좋고 나쁨을 가리는 기준은 오랫동안 둘이었습니다. 기능이 있느냐 없느냐, 그리고 화면이 보기 좋으냐 아니냐입니다. 두 기준으로는 답이 안 나오는 질문이 하나 있었습니다. "기능은 경쟁사보다 많고 화면도 멀쩡한데 왜 사람들이 안 쓰죠."

해지 설문을 열어 보면 이유가 기능 목록 바깥에 흩어져 있습니다. "가입하고 나서 뭘 해야 할지 몰랐어요", "파일이 안 올라가는데 왜 그런지 안 알려 줘요", "느려서요", "문의했는데 사흘 뒤에 답이 왔어요". 네 사람 모두 제품을 떠났지만 그중 어느 것도 없는 기능 때문이 아닙니다. 첫 번째 사람은 가입 안내 메일이 무엇도 알려 주지 않아서, 두 번째 사람은 오류 문구가 "오류가 발생했습니다" 한 줄이어서, 세 번째 사람은 화면이 뜨는 데 8초가 걸려서, 네 번째 사람은 고객센터 응대가 늦어서 떠났습니다.

문제는 이 넷을 한 회의에서 다루지 못한다는 데 있었습니다. 안내 메일은 마케팅이, 오류 문구는 개발이, 속도는 서버가, 응대는 고객지원이 맡고 있었으니 각자의 자리에서는 모두 정상이었습니다. 한 사람이 겪은 하나의 경험을 네 조직이 네 조각으로 나눠 갖고 있었고, 그 조각들을 한자리에 놓고 볼 이름이 없었던 겁니다.

사용자 경험은 그 이름으로 만들어진 말입니다. 화면 안쪽만이 아니라 사람이 제품과 닿는 모든 지점을 한 덩어리로 묶습니다. 광고를 처음 본 순간, 가입 직후 받은 메일, 세 번째 방문에서 마주친 빈 화면, 결제 실패 알림, 해지하려고 찾아 헤맨 메뉴가 전부 같은 경험의 부분입니다. 그래서 이 말을 쓰기 시작한 팀은 "이 화면 어때요" 대신 "이 사람이 여기까지 오는 동안 무엇을 겪었나요" 를 묻게 됩니다.

이 말이 퍼진 뒤에 달라진 것은 도구가 아니라 회의 참석자였습니다. 예전에는 화면을 고치는 자리에 디자이너와 개발자만 앉았는데, 경험 전체를 놓고 보면 안내 메일을 쓰는 사람과 응대를 맡는 사람이 같은 표를 보고 있어야 합니다. 조각을 나눠 갖고 있던 네 조직이 한 사람의 하루를 따라가며 각자의 칸을 채우는 자리가 생긴 겁니다.

디자인 분야에서 이 말이 맨 위에 놓이는 까닭도 여기 있습니다. 정보 구조도 인터랙션도 문구도 각자 경험의 한 재료를 맡을 뿐이고, 그 재료들이 합쳐져 만들어 내는 결과에 붙은 이름이 사용자 경험입니다.

"UX가 안 좋다" 는 말만으로는 아무것도 고치지 못합니다. 무엇이 안 좋은지 짚어야 담당자가 정해지고 순서가 정해지는데, 그러려면 경험을 요소로 쪼개야 합니다. 이 분야는 두 갈래입니다. 경험을 이루는 품질 요소 다섯과, 그 요소를 빠짐없이 점검하게 해 주는 프레임워크입니다.

품질 요소는 경험을 재는 축을 하나씩 맡습니다. 순서가 있어서 앞의 것이 무너지면 뒤의 것이 의미를 잃습니다.

1. 유용성 — 이 제품이 실제로 필요한 일을 해결해 주는가. 가장 먼저 걸리는 관문입니다. 쓰기 아무리 쉬워도 필요 없는 일을 해 주는 기능은 안 쓰입니다. 협업 문서 제품에서 아무도 요청한 적 없는 폰트 효과 열 가지를 넣은 경우가 여기 걸립니다. 이 축은 디자인보다 앞에서 결정되는 일이 많아서, 무엇을 만들지 정하는 단계에서 이미 점수가 정해집니다.
2. 사용성 — 목적을 쉽고 정확하게 이룰 수 있는가. 기능이 있느냐가 아니라 그 기능에 닿기까지 몇 번 막히느냐를 봅니다. 문서를 공유하려는데 권한 설정 화면에서 읽기와 댓글과 편집 중 무엇을 골라야 할지 20초를 고민했다면 이 축에서 점수를 잃습니다. 20초는 짧아 보이지만 하루에 문서를 열두 번 공유하는 사람에게는 매일 4분이고, 그보다 나쁜 건 고민 끝에 잘못 고르는 경우입니다.
3. 발견성 — 원하는 것을 찾아낼 수 있는가. 사용성과 붙어 있지만 재는 순간이 다릅니다. 사용성은 기능을 찾은 다음의 이야기이고, 발견성은 그 전의 이야기입니다. 메뉴 세 단계 아래 숨은 기능은 만들어져 있어도 사용자에게는 없는 기능입니다. 이 축이 무너진 제품에서는 같은 기능을 만들어 달라는 요청이 고객센터로 계속 들어옵니다.
4. 신뢰성 — 믿고 맡길 만하다고 느끼는가. 저장 버튼을 눌렀는데 아무 표시도 없으면 사람은 정말 저장됐는지 확인하려고 새로고침을 합니다. 한 번 이런 일을 겪으면 그다음부터는 중요한 문서를 다른 곳에 한 벌 더 복사해 둡니다. 결제 화면에서 이 축이 무너지면 이탈이 즉시 일어납니다. 앞의 세 축은 나빠도 사람이 견디며 쓰지만, 이 축은 한 번 무너지면 되돌리는 데 몇 달이 걸립니다.
5. 매력성 — 쓰고 싶게 만드는가. 앞의 넷이 불편을 없애는 축이라면 이것은 다시 열고 싶게 만드는 축입니다. 기능이 같은 두 제품 중 하나가 더 많이 쓰이는 이유가 대개 여기 있습니다. 다만 앞의 넷이 안 된 상태에서 이 축만 손보면 겉만 바뀐 제품이 됩니다. 저장이 자주 실패하는 제품에 애니메이션을 얹으면 기다리는 시간만 늘어납니다.

다섯 축은 서로를 대신하지 못합니다. 한 축이 높다고 다른 축의 낮은 점수를 메워 주지 않고, 그래서 한 제품 안에서도 축마다 점수가 크게 갈립니다. 파일 보관 제품이 저장에 한 번도 실패한 적 없는데 원하는 파일을 찾는 데 1분이 걸린다면 신뢰성은 높고 발견성은 낮은 상태입니다. 이 둘을 평균 내 보통이라고 적으면 고칠 자리가 사라집니다.

프레임워크는 이 요소들을 한 틀에 모아 점검표로 쓰게 만든 갈래입니다. UX 허니콤은 경험의 품질을 일곱 갈래로 나눠 벌집 모양으로 늘어놓은 틀입니다. 위의 다섯에 두 가지가 더 붙습니다. 장애가 있거나 한 손이 막힌 상황에서도 쓸 수 있는지를 보는 접근성, 그리고 이 경험이 회사에도 값어치가 있는지를 보는 가치입니다. 마지막 항목이 들어 있는 이유는 사용자에게만 좋고 회사가 유지할 수 없는 경험은 오래가지 못하기 때문입니다.

이 틀의 쓸모는 빠뜨린 축을 드러내는 데 있습니다. 회의에서 화면 이야기만 40분 하다가 일곱 칸을 펼쳐 놓으면, 접근성 칸과 발견성 칸이 이번 분기에 한 번도 언급되지 않았다는 사실이 그 자리에서 보입니다. 일곱 칸을 다 채우라는 뜻은 아닙니다. 어느 칸을 이번에 포기했는지 알고 포기하자는 뜻입니다.

이 말이 실제로 오가는 자리는 셋입니다. 첫째는 들어온 불만을 나누는 자리입니다. 같은 불만이라도 어느 축에 넣느냐에 따라 맡는 사람과 해법이 갈립니다. 둘째는 만들 것을 고르는 자리입니다. 새 기능을 하나 더 붙일지 이미 있는 기능의 축 하나를 올릴지 견줄 때 이 구분이 판단 기준이 됩니다. 셋째는 고친 뒤 확인하는 자리입니다. 어느 축을 올리려 했는지 적어 두면 무엇으로 확인할지가 함께 정해집니다.

두 갈래는 이렇게 맞물립니다. 다섯 요소가 무엇을 볼지 알려 주고, 허니콤이 볼 것을 빠뜨리지 않게 해 줍니다. 문제를 축으로 쪼개고 나면 다음 질문이 자연히 나옵니다. "이번에 나빠진 건 어느 축인가." 이 질문에 답할 수 있게 되는 순간이 사용자 경험이 취향에서 일거리로 바뀌는 지점입니다.

"기능이 없어서가 아니라 UX 문제예요. 다 있는데 아무도 못 찾아요."

발견성 축이 무너져 있다는 진단이고, 새 기능 대신 구조를 손보자는 제안입니다.

"이번 분기는 새 기능 말고 사용자 경험을 손보는 데 쓰죠."

기능 추가를 멈추고 이미 만든 것의 품질을 올리는 쪽으로 자원을 옮기자는 말입니다.

"UX가 안 좋다고만 하지 말고 어느 축이 문제인지 짚어 주세요."

뭉뚱그린 평가로는 담당자도 순서도 정할 수 없으니 요소로 나눠 말해 달라는 요청입니다.

페이지덱에서 무료 사용자의 유료 전환율이 두 달째 제자리였을 때 지현이 먼저 꺼낸 답은 기능 추가였습니다. 경쟁 제품에 있는 문서 잠금 기능이 없어서라고 본 것입니다. 민서가 그전에 해지 설문 180건을 축별로 나눠 읽자고 제안했고, 결과는 예상과 달랐습니다. 기능이 없어서 떠났다는 응답은 11건이었고, 나머지 대부분은 공유 권한을 잘못 설정해 외부에 문서가 열린 일을 겪었거나, 반대로 동료가 못 열어서 다시 보내느라 시간을 쓴 경우였습니다.

같은 문제를 축으로 나누자 할 일이 셋으로 갈렸습니다. 권한 선택지의 이름이 무슨 뜻인지 알 수 없다는 부분은 UX 라이팅으로, 설정 화면이 문서 메뉴 안쪽에 숨어 있다는 부분은 발견성으로, 공유한 뒤 누가 볼 수 있는지 확인할 방법이 없다는 부분은 신뢰성으로 갔습니다. 세 가지 중 문구를 고치는 일이 가장 빨라서 먼저 나갔습니다. 읽기와 댓글과 편집이라는 이름을 각각 보기만 가능, 의견 남기기 가능, 직접 고치기 가능으로 바꾸고 각 줄 아래에 무엇을 할 수 없는지를 한 줄씩 붙인 것이 전부였는데, 권한 관련 문의가 한 달 만에 절반 아래로 떨어졌습니다. 문서 잠금 기능은 그해에 만들지 않았습니다.

이 사례에서 눈여겨볼 점은 설문을 읽은 순서입니다. 축을 정해 놓고 읽었기 때문에 같은 응답 180건에서 다른 답이 나왔습니다. 축 없이 읽었다면 "공유가 불편하다" 라는 한 덩어리로 묶였을 것이고, 그 결론으로는 무엇을 먼저 할지 정하지 못합니다. 같은 방식이 다음 분기에도 쓰였습니다. 태오가 속도 관련 문의를 모아 왔을 때 지현이 먼저 물은 것은 몇 초가 걸리느냐가 아니라 어느 축에 걸린 문제냐였습니다. 화면이 뜨는 데 8초가 걸리는 것은 사용성 쪽이지만 저장을 눌렀는데 저장됐는지 알 수 없는 것은 신뢰성 쪽이라, 걸린 초가 같아도 맡는 사람과 고치는 방법이 달랐습니다.

사용자 경험을 화면 디자인의 다른 이름으로 아는 경우가 가장 많습니다. UX 라는 말을 쓰는 사람이 대개 디자이너이고 결과물로 보이는 것이 화면이니 자연스러운 오해입니다. 하지만 앞서 본 해지 이유 넷 중 화면에서 일어난 일은 하나뿐이었습니다. 응답 속도와 안내 메일과 고객센터 응대는 디자이너가 손댈 수 없는 자리에 있습니다. 이 오해를 그대로 두면 경험 개선이 디자인팀 혼자의 과제가 되고, 정작 사용자를 떠나게 한 나머지 세 조각은 아무도 맡지 않은 채 남습니다. 디자인팀은 반년 동안 화면을 두 번 갈아엎었는데 해지율이 그대로인 상황이 이렇게 생깁니다.

사용자 경험은 취향 문제라 잴 수 없다고 보는 시각도 흔합니다. 좋은 경험을 한 문장으로 정의하기 어렵고 사람마다 다르게 느끼는 것도 사실이니 그렇게 보입니다. 그런데 축으로 쪼개면 각 축에 숫자를 붙일 수 있습니다. 과업을 끝낸 사람의 비율, 그 과업에 걸린 시간, 같은 기능을 몇 번 만에 찾았는지, 오류를 만난 뒤 돌아온 비율이 전부 잴 수 있는 값입니다. 이런 항목을 다섯 묶음으로 정리한 것이 HEART 프레임워크입니다. 재지 않으면 경험 개선은 목소리 큰 사람의 의견으로 결정되고, 고친 뒤에 나아졌는지도 알 수 없습니다. 숫자가 느낌을 대신하지는 못합니다. 다만 느낌만 있을 때는 지난달보다 나아졌다는 말에 아무도 동의하거나 반박할 수 없습니다.