트리 테스트

메뉴 이름과 묶음은 대개 만드는 사람의 머릿속 기준으로 정해집니다. 결제 수단 변경을 요금제와 같은 묶음에 두는 것은 회사 안에서 자연스럽습니다. 청구를 다루는 팀이 하나여서 둘을 같이 관리하기 때문입니다. 사용자는 그 사정을 모른 채 내 계정 아래에서 결제를 찾습니다.

문제는 이 어긋남이 늦게 드러난다는 데 있었습니다. 화면을 다 그리고 사용성 테스트를, 곧 실제 과업을 시켜 보며 막히는 지점을 관찰하는 평가를 돌리면 참여자가 못 찾는 장면은 보입니다. 그런데 원인을 가릴 수 없습니다. 이름이 낯설어서인지, 글자가 작아서인지, 그 메뉴가 화면 오른쪽 아래에 있어서인지 한꺼번에 섞여 있습니다.

게다가 그 시점에는 고치는 값이 이미 비쌉니다. 메뉴 한 단을 옮기면 그 아래 화면 스무 장의 제목과 이동 경로를 함께 손봐야 합니다. 구조가 틀렸다는 것을 알면서도 다음 분기로 미루는 결정이 여기서 나옵니다.

트리 테스트는 그 순서를 뒤집습니다. 그릴 것을 하나도 그리지 않은 채 메뉴 글자만 목록으로 세워 두고, 사람들이 그 이름만 보고 목적지에 닿는지 먼저 재는 방식입니다. 정보 구조를, 곧 내용을 어떻게 나누고 무엇이라 이름 붙일지 정한 뼈대를 시험대에 올리는 자리입니다.

시험할 메뉴 구조를 글자만으로 적어 두고, 참여자에게 과업을 주어 그 목록을 파고 들어가 답이 있을 자리를 고르게 합니다.

1. 구조를 글로 적습니다. 보통 1단에서 3단까지 계층으로 세우고, 화면과 아이콘과 검색창은 넣지 않습니다. 참여자가 본 것은 접혀 있는 목록뿐이고, 한 항목을 누르면 그 아래가 펼쳐집니다.
2. 과업을 씁니다. 정답 단어를 문제에 넣지 않는 것이 이 단계의 전부입니다. "요금제를 찾아 보세요" 는 답을 알려 준 문장이고, "회사 카드가 바뀌어 결제에 쓰는 카드를 교체하려 합니다. 어디로 가겠습니까" 로 바꾸면 이름을 짚는 능력을 봅니다. 한 번에 여섯에서 열 개를 넘기지 않습니다.
3. 참여자를 모읍니다. 이 방법은 비율로 읽는 정량 조사 쪽이라 30명에서 50명을 목표로 합니다. 전용 온라인 도구로 링크만 보내면 되니 모집만 되면 수집은 이틀 안에 끝납니다.
4. 돌립니다. 참여자는 목록을 펼쳐 내려가고, 아니라고 판단하면 위로 되돌아 나올 수 있습니다. 이 되돌아간 기록이 뒤에서 가장 쓸모 있는 자료가 됩니다.
5. 세 숫자로 읽습니다. 과업마다 정답에 닿은 비율, 한 번도 되돌아 나오지 않고 곧장 닿은 비율, 그리고 참여자들이 처음 들어간 1단 항목의 분포입니다.

세 숫자를 함께 보면 무엇이 문제인지 좁혀집니다. 결제 카드 교체 과업의 성공률이 41퍼센트인데 곧장 닿은 비율이 18퍼센트라면, 절반 넘는 사람이 헤매다 결국 찾았다는 뜻입니다. 여기에 처음 들어간 항목이 설정에 몰려 있으면, 문제는 정답 자리의 이름이 아니라 설정이 너무 많은 것을 품고 있다는 데 있습니다.

화면이 아직 없거나 있는 구조를 바꾸려는 시점에 맞습니다. 그릴 것이 없어도 돌아가니 기획 단계에서 꺼낼 수 있는 몇 안 되는 조사입니다.

개편 전후를 견주는 자리에서 특히 값이 큽니다. 지금 구조와 새 구조를 각각 한 벌씩 만들어 다른 참여자 집단에 돌리면 두 성공률을 나란히 놓을 수 있습니다. 40퍼센트에서 72퍼센트로 올랐다는 문장은 화면을 그리기 전에 개편을 설득하는 근거가 됩니다.

한계는 셋입니다.

1. 성공률의 절대값을 제품의 성공률로 읽으면 안 됩니다. 실제 화면에는 검색창과 최근 문서 목록과 안내 문구가 있어 사용자는 여기서 나온 수치보다 잘 찾습니다. 이 숫자는 구조끼리 견주는 상대값입니다.
2. 이름과 위계만 봅니다. 그 메뉴가 화면에서 눈에 띄는지, 버튼이 접혀 있는지는 이 방법으로 알 수 없습니다.
3. 참여자가 목록을 위에서 아래로 훑기 때문에 실제보다 꼼꼼해집니다. 실제 사용자는 세 번째 항목에서 이미 아무것이나 누릅니다.

"화면 그리기 전에 트리 테스트부터 돌리죠. 다 그려 놓고 이름 바꾸면 스무 장을 다시 손대야 해요."

구조를 고치는 값이 싼 시점에 구조를 검증하자는 제안입니다.

"결제 과업 성공률이 41퍼센트인데, 처음 클릭이 설정에 몰렸어요."

정답 자리가 아니라 그 옆 항목의 이름이 사람을 끌어가고 있다는 진단입니다.

"그건 트리 테스트로는 안 나와요. 화면에서 눈에 띄는지를 봐야 하니까 퍼스트 클릭으로 가죠."

이름 문제와 시각 문제를 구분해 도구를 바꾸자는 말입니다.

페이지덱에서는 민서가 문서 권한 메뉴를 개편하기 전에 이 조사를 돌렸습니다. 현재 구조와 새 구조 두 벌을 만들어 유료 플랜 관리자 40명에게 과업 여덟 개를 보냈고, 지현은 과업 문구에 정답 단어가 섞여 있지 않은지만 봤습니다.

결과에서 먼저 바뀐 것은 구조가 아니라 이름 두 개였습니다. 새 구조의 성공률이 더 높기는 했는데 두 구조 모두 공유 설정 과업에서 절반이 실패했습니다. 두 벌에 같은 이름을 쓴 항목이 문제였던 것입니다.

다섯 명이면 충분하다고 생각하는 경우가 가장 많습니다. 사용성 테스트에서 다섯 명이면 큰 문제를 대체로 걸러 낸다는 관행이 널리 알려져 자연스럽게 옮겨옵니다. 하지만 트리 테스트가 내놓는 것은 관찰이 아니라 비율입니다. 참여자가 8명이면 한 사람이 12퍼센트씩을 움직여 성공률 37퍼센트와 50퍼센트가 같은 자료가 됩니다. 그 숫자로 구조를 결정하면 우연을 따라간 셈이 됩니다.

성공률이 낮으면 구조가 틀렸다고 단정하는 것도 흔합니다. 숫자가 선명하니 판정하기 쉬워 보입니다. 다만 낮은 성공률에는 원인이 셋 있습니다. 항목 이름이 낯선 경우, 과업 문구가 실제 사용자가 쓰지 않는 말로 적힌 경우, 그리고 그 항목이 두 갈래 어디에 있어도 이상하지 않은 경우입니다. 마지막 경우에는 이름을 몇 번 바꿔도 값이 오르지 않고 같은 항목을 두 자리에 모두 두는 편이 맞습니다. 처음 클릭 분포를 보지 않으면 이 셋을 가릴 수 없어 이름만 계속 고치게 됩니다.