멘탈 모델

제품이 잘 안 쓰일 때 원인을 사람 쪽에서 찾던 시절이 길었습니다. 설명서를 안 읽었다고 정리하고 안내 문구를 늘렸는데, 문구를 붙여도 같은 자리에서 같은 문의가 계속 들어왔습니다.

문제는 사용자가 기능을 몰라서가 아니라 이미 다른 그림을 들고 있어서 생깁니다. 사람은 처음 보는 물건 앞에서 비슷한 것을 쓴 경험을 끌어와 이건 이렇게 돌아가겠거니 하는 그림을 즉석에서 만들고, 그 그림대로 손을 댑니다. 그림이 맞으면 설명 없이도 잘 쓰고, 틀리면 화면에 적힌 안내를 읽고도 자기 그림을 믿습니다.

페이지덱에서 실제로 이런 문의가 들어왔습니다. 문서를 다른 폴더로 옮겼는데 원래 폴더에도 그대로 있다는 내용이었고, 사용자는 그것을 버그라고 적었습니다. 제품은 옮기기를 양쪽에서 보이게 하는 기능으로 만들어 두었으니 설계대로 동작한 것이었습니다. 하지만 사용자는 폴더를 현실의 서류철처럼 여기고 있었습니다. 서류를 한 칸에서 꺼내 다른 칸에 넣으면 원래 칸은 비어야 하는데 그렇지 않았으니 고장으로 읽힌 겁니다. 멘탈 모델은 이런 불일치를 사용자의 실수가 아니라 설계의 문제로 옮겨 놓기 위해 쓰는 말입니다.

사용자의 머릿속 그림과 제품의 실제 구조가 각각 따로 있고, 그 사이를 화면이 중개하면서 셋이 맞물립니다.

구분해서 봐야 할 그림이 세 개입니다.

1. 사용자의 그림입니다. 이전에 쓴 다른 제품, 현실의 물건, 주변에서 들은 이야기로 만들어집니다. 정확할 필요는 없고 자기 목적을 이루는 데 쓸 수 있으면 됩니다. 이메일이 실제로 어떤 경로로 전달되는지 몰라도 사람들은 매일 메일을 보냅니다.
2. 제품의 실제 구조입니다. 데이터가 어디에 저장되고 무엇이 무엇을 참조하는지이고, 문서 하나가 여러 폴더에 동시에 속할 수 있는지가 여기서 정해집니다.
3. 화면이 보여 주는 그림입니다. 사용자는 실제 구조를 직접 볼 수 없고 화면만 봅니다. 그래서 화면이 실제 구조를 어떻게 비추느냐가 사용자의 그림을 만듭니다. 생김새만으로 무엇을 할 수 있는지 알려 주는 어포던스나 조작 가능함을 알리려고 일부러 붙인 시그니파이어도 결국 이 그림을 손보는 수단입니다.

셋이 어긋나는 방향은 두 가지입니다. 실제 구조가 사용자의 그림과 다른 경우에는 구조를 바꾸거나, 바꿀 수 없으면 화면이 다르다는 사실을 먼저 알려야 합니다. 앞의 폴더 문제라면 옮기기와 추가하기를 다른 이름의 두 동작으로 갈라 두는 것이 화면 쪽 해법입니다.

다른 하나는 구조는 사용자의 그림과 맞는데 화면이 그걸 못 비추는 경우입니다. 이쪽이 고치기 쉽습니다. 라벨 하나, 안내 문구 한 줄로 해결되는 일이 많아서 UX 라이팅이 가장 싸게 듣는 자리이기도 합니다.

가장 자주 쓰이는 자리는 이름을 정할 때입니다. 메뉴와 버튼에 무슨 말을 적을지, 기능을 어떤 묶음으로 나눌지를 정하는 정보 구조 작업은 사실상 사용자의 그림을 추측하는 일입니다. 내부에서 부르던 이름을 그대로 올리면 실제 구조는 정확히 비추되 아무도 못 알아보는 화면이 됩니다.

새 개념을 들여올 때도 씁니다. 사용자에게 없던 개념을 설명해야 할 때는 이미 가진 그림 하나를 빌려 옵니다. 폴더, 휴지통, 잠금 같은 말이 전부 그렇게 빌려 온 것들입니다. 빌려 오면 설명이 줄어드는 대신 그 그림의 기대까지 따라옵니다. 휴지통이라고 부르면 사람들은 되살릴 수 있다고 기대합니다.

다른 제품에서 익힌 방식이 여기서도 통할 것으로 기대한다는 야콥의 법칙은 이 개념을 설계 지침으로 바꿔 놓은 것에 가깝습니다. 그림은 대부분 다른 제품에서 만들어져 오기 때문에, 널리 쓰이는 방식을 굳이 바꾸면 신선하다는 인상보다 헤맨다는 인상이 먼저 남습니다.

확인하는 방법은 물어보는 것이 아니라 시켜 보는 것입니다. 실제 과업을 주고 막히는 지점을 보는 사용성 테스트에서 사용자가 손을 멈추거나 엉뚱한 곳을 누르는 순간이 두 그림이 어긋난 지점입니다. 새 사용자가 자리 잡도록 돕는 온보딩도 같은 관찰에서 출발합니다. 첫 화면에 무엇을 먼저 둘지는 사용자가 이미 아는 것이 정합니다.

"사용자는 이걸 서류철처럼 생각해요. 옮기면 원래 자리에서 없어질 거라고 기대하죠."

문의가 들어온 이유를 기능 설명이 아니라 사용자의 기대에서 찾는 말입니다.

"기능이 문제가 아니라 이름이 문제예요. 지금 이름이 다른 걸 기대하게 만들어요."

구조를 바꾸지 않고 화면 쪽에서 고칠 수 있다는 판단입니다.

"이 흐름은 다른 툴이랑 다르게 가고 있어요. 그만한 이유가 있나요?"

익숙한 방식을 벗어나는 선택에 근거를 요구하는 말입니다.

페이지덱에서는 앞의 폴더 문의가 쌓이자 민서가 다섯 명을 불러 같은 과업을 시켜 봤습니다. 문서를 다른 폴더로 옮겨 보라고 했더니 다섯 명 중 네 명이 원래 폴더를 다시 열어 문서가 남아 있는지 확인했습니다. 옮겼다는 말을 듣고 원래 자리가 비었으리라 기대했다는 뜻입니다.

민서는 구조를 바꾸자고 하지 않았습니다. 여러 폴더에 동시에 두는 기능은 팀 단위 제품에 필요했기 때문입니다. 대신 메뉴에서 옮기기를 빼고 폴더에 추가와 이 폴더에서 빼기로 나눴습니다. 문의는 다음 달에 거의 사라졌습니다.

사용자를 교육하면 그림이 바뀐다고 보는 시각이 가장 흔합니다. 제품의 구조가 이미 정해져 있으니 설명으로 메우는 쪽이 빨라 보이기 때문입니다. 실제로 사람들은 쓰기 전에 안내를 읽지 않습니다. 목적이 있어 들어왔으니 바로 손을 대고, 막힌 뒤에야 읽습니다. 안내 문구로 덮어 둔 불일치는 문의를 줄이지 못하고, 대신 같은 자리에 문구만 계속 늘어나 화면이 무거워집니다. 안내가 길어지는 자리는 대개 설계가 어긋났다는 신호로 읽습니다.

사용자의 그림이 하나라고 보는 것도 잦은 오해입니다. 사용자는 이렇게 생각한다는 문장이 팀 안에서 오갈 때 그 사용자는 대개 한 사람을 가리킵니다. 실제로는 어떤 제품을 쓰다 왔느냐에 따라 그림이 갈립니다. 문서 툴을 오래 쓴 사람과 메신저에서 파일을 주고받던 사람은 공유라는 말에 다른 것을 기대합니다. 그래서 어느 그림에 맞출지를 고르는 일이 따라붙고, 그 선택은 주 사용자층을 정하는 결정과 같은 것이 됩니다.