사용성 테스트
Usability Test
방법
사용자에게 실제 과업을 주고 해내는 과정을 지켜보며 어디서 막히는지 찾아, 화면과 흐름을 고칠 근거로 삼는 평가입니다.
등장 배경
화면을 다 만들어 놓고 팀이 모여 앉아 서로의 감을 겨루던 시절이 있었습니다. 한 사람은 이 버튼을 여기 두면 아무도 못 찾을 것 같다고 하고, 다른 사람은 자기는 바로 찾았으니 괜찮다고 합니다. 양쪽 다 근거가 자기 경험뿐이니 결론은 회의실에서 목소리가 큰 쪽으로 기울었습니다.
사용자에게 물어보자는 쪽도 사정이 나아지지 않았습니다. 화면을 보여 주고 어떠냐고 물으면 대부분 괜찮다고 답합니다. 만든 사람 앞에서 나쁘다고 말하기가 어렵고, 눈으로 훑는 것과 손으로 해 보는 것이 다르기도 합니다. 그렇게 괜찮다는 답을 받아 낸 화면이 출시 뒤에 초대 링크를 어디서 만드는지 모르겠다는 문의로 하루 스무 건씩 돌아왔습니다.
사용성 테스트는 묻는 일을 보는 일로 바꿔 두 문제를 한꺼번에 피합니다. 의견을 구하지 않고 과업을 줍니다. 동료를 초대해 보라고 말한 뒤 입을 닫고, 그 사람이 어느 메뉴를 먼저 열고 어디서 손이 멈추는지를 지켜봅니다. 못 찾겠다는 말을 듣지 않아도 못 찾는 장면이 눈앞에 남습니다.
사용 절차
과업 목록을 짜고, 조건에 맞는 참여자를 다섯 명쯤 모아, 한 명씩 그 과업을 하게 두고 막히는 지점을 적는 순서입니다. 한 사람에 30분에서 한 시간을 잡습니다.
- 알고 싶은 것을 과업 문장으로 옮깁니다. 초대 기능이 쉬운지 보고 싶다면 초대 기능을 평가해 달라고 하지 않고, 이 문서를 같은 팀 동료 두 명과 함께 볼 수 있게 해 달라고 시킵니다. 과업은 한 시간에 할 수 있는 양인 세 개에서 다섯 개로 줄입니다.
- 참여자를 모읍니다. 실제 사용자와 조건이 같아야 합니다. 5인 이상 팀에서 문서를 만드는 사람을 보려는데 혼자 쓰는 사람을 앉히면 막히는 자리가 달라집니다. 사람 수는 다섯이면 충분합니다. 크게 걸리는 문제는 앞의 세 명에서 대개 드러나고 여섯 번째부터는 같은 장면이 되풀이됩니다.
- 시작 전에 규칙을 알려 줍니다. 시험받는 쪽은 사람이 아니라 화면이고, 막히는 장면이야말로 찾던 것이라고 말해 둡니다. 이 말을 빼면 참여자가 못 하는 모습을 감추려 애쓰는 바람에 장면이 왜곡됩니다.
- 하게 두고 입을 닫습니다. 참여자가 멈춰 있으면 힌트를 주고 싶어지지만 그 침묵이 바로 얻으려던 자료입니다. 생각을 소리 내어 말해 달라고 부탁하면 왜 그 메뉴를 열었는지까지 남습니다.
- 과업마다 결과와 걸린 시간을 적습니다. 도움 없이 끝냈는지, 도움을 받아 끝냈는지, 못 끝냈는지 셋으로 나누고 막힌 지점을 함께 적습니다.
- 다섯 명의 기록을 겹쳐 놓고 같은 자리에서 막힌 횟수로 줄을 세웁니다. 다섯 중 넷이 같은 데서 멈췄다면 고칠 목록의 맨 위입니다. 한 명만 멈춘 자리는 그 사람 습관일 수 있어 보류합니다.
적합한 상황과 한계
눌러 볼 수 있는 것이 이미 있을 때 가장 잘 맞습니다. 손으로 해 보게 하는 방법이라 만질 것이 없으면 성립하지 않습니다. 그래서 무엇을 만들지가 아직 안 정해진 단계에서는 쓰지 않고, 만들 것이 정해진 뒤 그것이 통하는지 확인하는 자리에 둡니다.
숫자가 짚어 준 문제의 이유를 찾을 때도 잘 맞습니다. 가입 화면에서 절반이 빠져나간다는 사실은 기록에 나오지만 이유는 안 나옵니다. 다섯 명에게 같은 화면을 시켜 보면 인증 메일이 스팸함으로 가서 못 넘어가는 장면이 잡힙니다.
한계는 셋입니다. 첫째, 비율을 말할 수 없습니다. 다섯 중 넷이 막혔다고 전체 사용자의 80퍼센트가 막힌다고 옮기면 틀립니다. 비율이 필요하면 설문 조사로 수백 명에게 같은 질문을 던지거나 기록을 세야 합니다. 둘째, 이 방법이 답하는 것은 쓰기 쉬운지까지입니다. 이 기능이 필요한지는 답하지 못합니다. 셋째, 실험실 장면과 실제 사용 장면이 다릅니다. 참여자는 앞에 앉은 사람 때문에 평소보다 집중해 끝까지 해내고, 실제로는 같은 자리에서 그냥 창을 닫습니다. 이 틈은 현장에 찾아가는 필드 리서치나 2주간 기록을 남기게 하는 다이어리 스터디로 메웁니다.
실무 용례
"이 흐름 사용성 테스트 한 번 돌려 보고 결정하죠."
의견으로 갈리는 논쟁을 멈추고 다섯 명의 기록으로 판정하자는 제안입니다.
"다섯 명 중 네 명이 초대 버튼을 못 찾았어요. 위치부터 옮깁시다."
같은 자리에서 반복된 실패라서 사람 습관이 아니라 화면 문제라는 뜻입니다.
"이건 사용성 문제가 아니라 기능이 없는 거예요. 테스트로 나올 게 아닙니다."
과업을 시켜 봐도 답이 안 나오는 질문이니 다른 방법을 쓰자는 말입니다.
페이지덱에서는 민서가 새 초대 흐름 시안을 만들면 출시 전에 다섯 명을 불러 앉힙니다. 과업은 셋입니다. 문서 하나를 동료 두 명과 함께 보게 만들기, 그중 한 명의 권한을 읽기 전용으로 바꾸기, 외부인이 볼 수 있는 링크 만들기입니다. 민서가 진행하고 지현이 옆방에서 막힌 지점과 시간을 적습니다.
첫 회차에서 다섯 명 중 네 명이 두 번째 과업에서 멈췄습니다. 권한을 바꾸는 항목이 이름 옆 점 세 개 안에 숨어 있었습니다. 민서가 그 항목을 목록 바깥으로 꺼내 시안을 고치고 이틀 뒤 다른 다섯 명에게 같은 과업을 시켰습니다. 이번에는 다섯 명 모두 끝냈습니다.
흔한 오해
가장 흔한 오해는 사람 수가 많아야 믿을 만하다고 여기는 것입니다. 설문에서 수백 명을 모으는 것을 봤으니 여기도 그래야 할 것 같습니다. 하지만 이 방법이 찾는 것은 비율이 아니라 막히는 자리입니다. 같은 조건의 사용자라면 크게 걸리는 문제는 앞의 세 명에서 거의 다 드러나서, 스무 명을 불러도 같은 장면을 열일곱 번 더 봅니다. 다섯 명으로 한 번 돌리고 고쳐서 다시 다섯 명을 돌리는 편이 같은 기간에 문제를 두 배로 걷어 냅니다.
두 번째 오해는 출시 직전 검사로 여기는 것입니다. 이름에 테스트가 붙어 있으니 다 만든 뒤 합격 여부를 받는 절차처럼 들립니다. 그렇게 쓰면 개발이 끝난 화면에서 구조를 바꾸라는 결과가 나와도 일정 때문에 못 고치고, 손에 남는 것은 고칠 수 없는 문제 목록뿐입니다. 클릭만 되는 시안 단계에서 돌리면 같은 문제를 하루 만에 고칩니다.
자주 헷갈리는 용어
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16