언모더레이티드 테스트

화면이 잘 쓰이는지 확인하는 표준은 사람을 불러 앉히는 것이었습니다. 모더레이티드 테스트는 진행자가 옆에서 과업을 주고 손이 멈춘 순간에 무엇을 찾고 있었는지 되묻습니다. 이유까지 얻으니 결과가 가장 촘촘합니다.

대신 한 명에 한 시간이 들고, 그 시간을 참여자와 진행자의 일정이 겹치는 자리에 넣어야 합니다. 조건에 맞는 사용자 다섯 명을 구하고 일정을 맞추는 데만 두 주가 갑니다. 관찰 정리와 보고를 더하면 한 회차가 3주입니다.

화면이 2주에 한 번씩 바뀌는 팀에서는 이 주기가 맞지 않았습니다. 민서가 초대 화면 테스트를 준비하며 참여자를 모으는 동안 그 화면이 두 번 바뀌었고, 결과가 나왔을 때 지적받은 버튼은 이미 없었습니다. 테스트가 틀린 게 아니라 늦은 것이었습니다.

원격으로 화면을 녹화하고 말소리를 담는 도구가 흔해지면서 다른 순서가 가능해졌습니다. 과업을 미리 적어 두고 참여자가 각자 편한 시각에 혼자 수행하는 방식입니다. 되물을 수는 없지만 같은 이유로 열 명을 하루에 돌립니다.

과업 문장을 미리 다 적어 두는 것에서 시작합니다. 현장에서 보충할 기회가 없어, 적어 둔 문장이 참여자가 받는 전부입니다.

1. 알고 싶은 것을 한 문장으로 적습니다. "초대 화면을 평가한다" 는 질문이 아닙니다. "초대할 사람의 메일 주소를 모르는 사용자가 초대를 끝내는가" 가 질문입니다.
2. 과업을 문장으로 적습니다. 화면에 있는 단어를 그대로 쓰면 답을 알려 주는 셈이 되니 피합니다. "초대 버튼을 누르세요" 가 아니라 "같은 팀 동료 한 명이 이 문서를 같이 보게 해 보세요" 입니다.
3. 참여자를 모읍니다. 이미 쓰고 있는 사용자 목록에서 고르거나 참여자를 중개하는 패널에서 삽니다. 패널은 조건을 넣으면 하루 안에 열 명을 붙여 주는 대신 제품을 처음 보는 사람들입니다.
4. 한 명으로 예행합니다. 옆자리 동료에게 같은 과업을 주고 문장만 읽고도 무엇을 하라는 것인지 알겠는지 봅니다. 여기서 안 걸린 모호한 문장은 열 명분 기록을 통째로 버리게 만듭니다.
5. 돌립니다. 화면 녹화와 함께 생각을 소리 내어 말해 달라고 요청하고 과업마다 제한 시간을 둡니다. 제한이 없으면 막힌 참여자가 12분을 헤매다 포기하고, 그 12분은 볼 사람에게도 부담입니다.
6. 봅니다. 참여자마다 성공 여부와 막힌 지점의 시각을 적고 같은 자리가 반복되는지 셉니다. 한 명이 막힌 자리는 그 사람 사정일 수 있지만 다섯 중 넷이 같은 자리에서 멈추면 화면 문제입니다.

마지막 단계를 건너뛰는 일이 잦습니다. 녹화가 쌓인 것과 결과가 나온 것은 다릅니다. 영상 열 개를 공유하고 끝내면 아무도 열지 않습니다. 남아야 할 것은 영상이 아니라 고칠 목록입니다.

맞는 자리는 과업이 분명하고 화면이 이미 있는 경우입니다. 가입, 초대, 결제처럼 시작과 끝이 있는 흐름에서 몇 명이 끝까지 가는지 세려면 가장 싸게 답을 줍니다. 프로토타입 단계에서도 됩니다. 프로토타입은 만들기 전에 반응을 보려고 임시로 구현한 것입니다.

숫자가 필요할 때도 이쪽입니다. 성공률이 40퍼센트라고 말하려면 다섯 명이 아니라 서른 명이 있어야 합니다.

한계는 되물을 수 없다는 한 가지에서 다 나옵니다.

1. 이유가 추측으로 남습니다. 3분간 같은 화면을 보고 있었다는 사실은 남지만 무엇을 찾고 있었는지는 안 남습니다. 말하기를 요청해도 절반은 조용히 수행합니다.
2. 과업을 오해한 채 끝까지 갑니다. 문장을 다르게 읽은 참여자는 다른 일을 하고 바로잡히지 않습니다. 그 기록은 분석에서 빠집니다.
3. 화면 밖 사정이 안 보입니다. 중간에 다른 창을 열었는지 옆에서 누가 말을 걸었는지 모르는 채로 소요 시간을 읽게 됩니다.
4. 처음 보는 사람의 반응이 섞입니다. 패널 참여자는 제품을 모르고, 실제 사용자가 몇 달 쌓아 온 습관도 없습니다.

그래서 탐색하는 조사에는 맞지 않습니다. 왜 이 기능을 안 쓰는지처럼 답의 모양을 모른 채 시작하는 질문은 되물을 수 있는 자리에서 다룹니다. 두 방법을 순서로 쓰기도 합니다. 먼저 혼자 하게 해 어디서 막히는지 세고, 가장 많이 막힌 자리 하나를 골라 사람을 불러 묻습니다.

"이번엔 언모더레이티드로 열 명 돌려서 성공률만 먼저 볼게요."

이유는 나중에 보고 지금은 몇 명이 끝까지 가는지 세겠다는 말입니다.

"과업 문장에 '초대' 라는 단어가 들어가면 안 돼요. 그게 찾을 버튼 이름이잖아요."

과업이 답을 알려 주고 있어 결과가 무의미해진다는 지적입니다.

"녹화 열 개 중 셋은 과업을 다르게 이해했어요. 그 셋은 빼고 세겠습니다."

되물을 수 없어 생긴 오해분을 분석에서 덜어 낸다는 뜻입니다.

페이지덱은 초대 흐름을 고치기 전에 이 방법을 썼습니다. 민서가 과업 두 개를 적고 패널에서 열두 명을 붙였습니다. 동료 한 명을 문서에 초대하기, 그 사람의 권한을 보기 전용으로 바꾸기였습니다.

첫 과업은 열둘 중 열하나가 끝냈고 두 번째는 넷이 끝냈습니다. 막힌 여덟 명은 모두 같은 자리에서 멈췄습니다. 권한을 바꾸는 메뉴가 이름 옆 작은 화살표 안에 있었고, 참여자들은 상단 설정 쪽을 계속 뒤졌습니다. 왜 설정을 먼저 봤는지는 기록에 없어, 민서가 그 한 가지만 들고 진행자를 붙인 테스트를 세 건 더 잡았습니다.

싸고 빠르니 사람을 부르는 방식을 대체한다고 읽는 경우가 가장 많습니다. 비용이 몇 분의 일이고 하루에 끝나니 그래 보입니다. 하지만 두 방법이 답하는 질문이 다릅니다. 혼자 하게 하면 어디서 몇 명이 막히는지가 나오고, 사람을 부르면 왜 막혔는지가 나옵니다. 어디만 알고 고치면 대개 그 자리를 키우거나 색을 바꾸는 선에서 끝나고, 원인이 이름에 있었으면 다음 회차에 같은 수가 같은 자리에서 막힙니다.

참여자를 많이 붙일수록 결과가 좋아진다고 보는 것도 흔합니다. 숫자가 늘면 신뢰가 오르는 것은 성공률 같은 값에 한정된 이야기입니다. 막히는 자리를 찾는 목적이라면 예닐곱 명에서 같은 문제가 반복되고, 서른 명을 돌리면 이미 찾은 문제를 서른 번 확인하며 볼 시간만 늘어납니다. 사람 수를 늘리기 전에 과업 문장을 먼저 봅니다. 여기서 어긋나면 백 명이어도 쓸 기록이 없습니다.