발견성

기능을 만들어 두고도 아무도 쓰지 않는 일이 자주 있었습니다. 만든 쪽은 화면 어디에 무엇이 있는지 알고 있으니 다 되어 있다고 여겼고, 처음 들어온 사람은 그 자리를 찾지 못한 채 안 되는 제품이라고 판단했습니다. 같은 제품을 두고 두 사람이 정반대로 말하는데, 둘 다 자기 경험에는 정확했습니다.

이 어긋남은 대개 고객센터에서 먼저 드러났습니다. "문서를 여러 명이 같이 편집하게 해 주세요" 라는 요청이 한 달에 열 건씩 들어오는데, 그 기능은 반년 전에 나가 있었습니다. 담당자가 "이미 있습니다" 라고 답장을 쓰면서도 같은 요청이 왜 계속 들어오는지는 설명하지 못했습니다. 기능 목록에는 있고 사용자에게는 없는 상태였던 겁니다.

그러다 보니 사용자 경험이 나쁘다는 말로는 이 문제를 고칠 수 없었습니다. 기능이 부족한 것도 아니고, 찾은 다음에 쓰기 어려운 것도 아니었습니다. 찾기까지가 문제였고, 여기에 이름을 붙이고 나서야 무엇을 고칠지가 정해졌습니다. 고칠 대상이 기능이 아니라 메뉴 이름과 배치라는 사실이 그 이름 덕에 보이기 시작했습니다.

발견성은 사용자가 하려는 일을 떠올린 순간부터 그 일을 하는 자리에 닿기까지의 경로에서 결정됩니다. 기능의 품질이 아니라 경로의 길이와 표지판의 정확도가 점수를 매깁니다.

이 경로를 받치는 것이 넷입니다.

1. 정보 구조 — 내용을 어떻게 나누고 묶을지 정한 뼈대입니다. 팀이 만든 순서대로 메뉴를 나누면 사용자가 쓰는 순서와 어긋납니다. 권한 설정이 관리 메뉴에 있고 공유 링크 만들기가 문서 메뉴에 있으면, 둘 다 필요한 사용자는 매번 두 곳을 오갑니다.
2. 레이블링 — 메뉴와 버튼에 붙인 이름입니다. 회사 안에서만 쓰는 말이 그대로 나가는 일이 흔합니다. 워크스페이스 관리라고 적힌 메뉴 아래 결제 정보가 들어 있으면, 요금제를 바꾸려는 사람은 그 메뉴를 한 번도 열어 보지 않습니다.
3. 내비게이션 — 화면 사이를 오가게 해 주는 장치입니다. 지금 어디에 있는지, 위로 올라가면 무엇이 있는지를 화면이 계속 알려 줘야 사용자가 탐색을 이어 갑니다. 세 단계를 들어갔는데 돌아가는 길이 브라우저 뒤로 가기뿐이면, 한 번 헛짚은 사용자는 다시 들어가 보는 대신 그 자리에서 멈춥니다.
4. 검색 — 구조와 이름이 어긋났을 때 남은 통로입니다. 다만 검색은 사용자가 정확한 단어를 알고 있을 때만 작동합니다. 제품이 부르는 이름과 사용자가 떠올린 단어가 다르면 결과가 비어서 돌아옵니다.

네 가지 중 하나만 무너져도 경로가 끊깁니다. 이름이 정확해도 세 단계 아래 있으면 닿기 전에 포기하고, 한 단계에 있어도 이름이 낯설면 지나칩니다.

이 말이 실제로 나오는 자리는 셋입니다.

첫째, 새 기능을 어디에 놓을지 정하는 자리입니다. 만든 기능을 어느 메뉴에 넣을지는 취향 문제처럼 보이지만, 그 결정이 기능 채택률을 크게 가릅니다. 같은 기능을 상단 메뉴에 두느냐 설정 화면 안쪽에 두느냐에 따라 써 본 사용자 비율이 몇 배씩 갈립니다.

둘째, 낮은 사용률의 원인을 가르는 자리입니다. 어떤 기능을 8퍼센트만 쓴다면 이유는 둘 중 하나입니다. 필요가 없거나, 있는 줄 모르거나. 앞쪽이면 기능을 접는 게 맞고 뒤쪽이면 자리를 옮기면 됩니다. 두 원인에 필요한 조치가 정반대라서 섞어 두면 잘못된 결정을 합니다. 가르는 방법은 간단합니다. 그 기능을 한 번이라도 연 사용자가 얼마나 다시 쓰는지 보면 됩니다. 연 사람의 60퍼센트가 계속 쓰고 있다면 필요는 있는 것이고, 남은 문제는 나머지가 그 자리에 닿지 못한다는 것뿐입니다.

셋째, 조사 방법을 고르는 자리입니다. 발견성을 의심하면 화면을 만들기 전에도 확인할 수 있습니다. 트리 테스트는 메뉴 글자만 주고 길을 찾게 하고, 퍼스트 클릭 테스트는 화면 한 장에서 첫 클릭이 맞는 곳으로 가는지만 봅니다.

"기능이 없는 게 아니라 발견성이 낮은 거예요. 만들지 말고 자리부터 옮겨 봅시다."

같은 요청이 반복되는 원인이 기능 부재가 아니라 배치에 있다는 판단입니다.

"이 메뉴 이름으로는 발견성이 안 나와요. 우리끼리 쓰는 말이잖아요."

내부 용어가 그대로 화면에 나갔다는 지적입니다.

"검색으로 커버되니까 발견성은 괜찮습니다."

구조가 어긋난 것을 검색이 메우고 있다는 말이라, 대개 반박을 받습니다.

페이지덱에서 민서가 이 말을 꺼낸 건 문서 내보내기 기능 때문이었습니다. 나간 지 석 달이 지났는데 쓴 계정이 4퍼센트였고, 대신 같은 기능을 만들어 달라는 문의가 매주 들어왔습니다. 민서가 세션 리플레이로 문의를 남긴 사용자들의 화면을 되돌려 보니 여덟 명 중 여섯 명이 문서 우상단 점 세 개 메뉴를 열었다가 그냥 닫았습니다. 기능은 그 메뉴가 아니라 좌측 사이드바의 워크스페이스 설정 안에 있었습니다.

민서는 메뉴 위치만 옮기고 이름을 내보내기에서 PDF로 저장으로 바꿨습니다. 다른 것은 손대지 않았습니다. 6주 뒤 사용 계정은 19퍼센트가 됐고 같은 문의는 끊겼습니다. 지현이 로드맵에서 이 기능의 개선 항목 세 개를 지운 것도 이때입니다. 애초에 기능이 부족해서 안 쓰인 게 아니었으니 고칠 것도 없었습니다.

검색창을 달면 발견성이 해결된다고 보는 경우가 가장 많습니다. 못 찾는 게 문제니 찾는 도구를 주면 되겠다는 생각이라 이해할 만합니다. 하지만 검색은 사용자가 그 기능의 이름을 알고 있을 때만 통합니다. 무엇을 찾아야 하는지조차 모르는 사람, 그러니까 제품에 그런 기능이 있는 줄도 모르는 사람에게 빈 검색창은 아무 도움이 되지 않습니다. 검색을 붙여 두고 구조를 그대로 두면 검색어 기록에 아무것도 남지 않고, 팀은 문제가 없다고 오해하게 됩니다.

반대 방향의 오해도 흔합니다. 잘 보이게 하려고 기능을 전부 첫 화면에 꺼내 놓는 경우입니다. 메뉴가 서른 개면 서른 개 모두 눈에 띄지 않는 상태가 됩니다. 실제로는 아홉 개짜리 메뉴에서 찾던 것을 스물다섯 개짜리 메뉴에서는 못 찾습니다. 발견성을 올리는 일은 많이 보여 주는 게 아니라 지금 필요한 것을 눈에 띄게 하는 쪽에 가깝습니다.