사용성 테스트

Usability Test

방법

사용자에게 실제 과업을 주고 해내는 과정을 지켜보며 어디서 막히는지 찾아, 화면과 흐름을 고칠 근거로 삼는 평가입니다.

등장 배경

화면을 다 만들어 놓고 팀이 모여 앉아 서로의 감을 겨루던 시절이 있었습니다. 한 사람은 이 버튼을 여기 두면 아무도 못 찾을 것 같다고 하고, 다른 사람은 자기는 바로 찾았으니 괜찮다고 합니다. 양쪽 다 근거가 자기 경험뿐이니 결론은 회의실에서 목소리가 큰 쪽으로 기울었습니다.

사용자에게 물어보자는 쪽도 사정이 나아지지 않았습니다. 화면을 보여 주고 어떠냐고 물으면 대부분 괜찮다고 답합니다. 만든 사람 앞에서 나쁘다고 말하기가 어렵고, 눈으로 훑는 것과 손으로 해 보는 것이 다르기도 합니다. 그렇게 괜찮다는 답을 받아 낸 화면이 출시 뒤에 초대 링크를 어디서 만드는지 모르겠다는 문의로 하루 스무 건씩 돌아왔습니다.

사용성 테스트는 묻는 일을 보는 일로 바꿔 두 문제를 한꺼번에 피합니다. 의견을 구하지 않고 과업을 줍니다. 동료를 초대해 보라고 말한 뒤 입을 닫고, 그 사람이 어느 메뉴를 먼저 열고 어디서 손이 멈추는지를 지켜봅니다. 못 찾겠다는 말을 듣지 않아도 못 찾는 장면이 눈앞에 남습니다.

사용 절차

과업 목록을 짜고, 조건에 맞는 참여자를 다섯 명쯤 모아, 한 명씩 그 과업을 하게 두고 막히는 지점을 적는 순서입니다. 한 사람에 30분에서 한 시간을 잡습니다.

  1. 알고 싶은 것을 과업 문장으로 옮깁니다. 초대 기능이 쉬운지 보고 싶다면 초대 기능을 평가해 달라고 하지 않고, 이 문서를 같은 팀 동료 두 명과 함께 볼 수 있게 해 달라고 시킵니다. 과업은 한 시간에 할 수 있는 양인 세 개에서 다섯 개로 줄입니다.
  2. 참여자를 모읍니다. 실제 사용자와 조건이 같아야 합니다. 5인 이상 팀에서 문서를 만드는 사람을 보려는데 혼자 쓰는 사람을 앉히면 막히는 자리가 달라집니다. 사람 수는 다섯이면 충분합니다. 크게 걸리는 문제는 앞의 세 명에서 대개 드러나고 여섯 번째부터는 같은 장면이 되풀이됩니다.
  3. 시작 전에 규칙을 알려 줍니다. 시험받는 쪽은 사람이 아니라 화면이고, 막히는 장면이야말로 찾던 것이라고 말해 둡니다. 이 말을 빼면 참여자가 못 하는 모습을 감추려 애쓰는 바람에 장면이 왜곡됩니다.
  4. 하게 두고 입을 닫습니다. 참여자가 멈춰 있으면 힌트를 주고 싶어지지만 그 침묵이 바로 얻으려던 자료입니다. 생각을 소리 내어 말해 달라고 부탁하면 왜 그 메뉴를 열었는지까지 남습니다.
  5. 과업마다 결과와 걸린 시간을 적습니다. 도움 없이 끝냈는지, 도움을 받아 끝냈는지, 못 끝냈는지 셋으로 나누고 막힌 지점을 함께 적습니다.
  6. 다섯 명의 기록을 겹쳐 놓고 같은 자리에서 막힌 횟수로 줄을 세웁니다. 다섯 중 넷이 같은 데서 멈췄다면 고칠 목록의 맨 위입니다. 한 명만 멈춘 자리는 그 사람 습관일 수 있어 보류합니다.

적합한 상황과 한계

눌러 볼 수 있는 것이 이미 있을 때 가장 잘 맞습니다. 손으로 해 보게 하는 방법이라 만질 것이 없으면 성립하지 않습니다. 그래서 무엇을 만들지가 아직 안 정해진 단계에서는 쓰지 않고, 만들 것이 정해진 뒤 그것이 통하는지 확인하는 자리에 둡니다.

숫자가 짚어 준 문제의 이유를 찾을 때도 잘 맞습니다. 가입 화면에서 절반이 빠져나간다는 사실은 기록에 나오지만 이유는 안 나옵니다. 다섯 명에게 같은 화면을 시켜 보면 인증 메일이 스팸함으로 가서 못 넘어가는 장면이 잡힙니다.

한계는 셋입니다. 첫째, 비율을 말할 수 없습니다. 다섯 중 넷이 막혔다고 전체 사용자의 80퍼센트가 막힌다고 옮기면 틀립니다. 비율이 필요하면 설문 조사로 수백 명에게 같은 질문을 던지거나 기록을 세야 합니다. 둘째, 이 방법이 답하는 것은 쓰기 쉬운지까지입니다. 이 기능이 필요한지는 답하지 못합니다. 셋째, 실험실 장면과 실제 사용 장면이 다릅니다. 참여자는 앞에 앉은 사람 때문에 평소보다 집중해 끝까지 해내고, 실제로는 같은 자리에서 그냥 창을 닫습니다. 이 틈은 현장에 찾아가는 필드 리서치나 2주간 기록을 남기게 하는 다이어리 스터디로 메웁니다.

실무 용례

"이 흐름 사용성 테스트 한 번 돌려 보고 결정하죠."

의견으로 갈리는 논쟁을 멈추고 다섯 명의 기록으로 판정하자는 제안입니다.

"다섯 명 중 네 명이 초대 버튼을 못 찾았어요. 위치부터 옮깁시다."

같은 자리에서 반복된 실패라서 사람 습관이 아니라 화면 문제라는 뜻입니다.

"이건 사용성 문제가 아니라 기능이 없는 거예요. 테스트로 나올 게 아닙니다."

과업을 시켜 봐도 답이 안 나오는 질문이니 다른 방법을 쓰자는 말입니다.

페이지덱에서는 민서가 새 초대 흐름 시안을 만들면 출시 전에 다섯 명을 불러 앉힙니다. 과업은 셋입니다. 문서 하나를 동료 두 명과 함께 보게 만들기, 그중 한 명의 권한을 읽기 전용으로 바꾸기, 외부인이 볼 수 있는 링크 만들기입니다. 민서가 진행하고 지현이 옆방에서 막힌 지점과 시간을 적습니다.

첫 회차에서 다섯 명 중 네 명이 두 번째 과업에서 멈췄습니다. 권한을 바꾸는 항목이 이름 옆 점 세 개 안에 숨어 있었습니다. 민서가 그 항목을 목록 바깥으로 꺼내 시안을 고치고 이틀 뒤 다른 다섯 명에게 같은 과업을 시켰습니다. 이번에는 다섯 명 모두 끝냈습니다.

흔한 오해

가장 흔한 오해는 사람 수가 많아야 믿을 만하다고 여기는 것입니다. 설문에서 수백 명을 모으는 것을 봤으니 여기도 그래야 할 것 같습니다. 하지만 이 방법이 찾는 것은 비율이 아니라 막히는 자리입니다. 같은 조건의 사용자라면 크게 걸리는 문제는 앞의 세 명에서 거의 다 드러나서, 스무 명을 불러도 같은 장면을 열일곱 번 더 봅니다. 다섯 명으로 한 번 돌리고 고쳐서 다시 다섯 명을 돌리는 편이 같은 기간에 문제를 두 배로 걷어 냅니다.

두 번째 오해는 출시 직전 검사로 여기는 것입니다. 이름에 테스트가 붙어 있으니 다 만든 뒤 합격 여부를 받는 절차처럼 들립니다. 그렇게 쓰면 개발이 끝난 화면에서 구조를 바꾸라는 결과가 나와도 일정 때문에 못 고치고, 손에 남는 것은 고칠 수 없는 문제 목록뿐입니다. 클릭만 되는 시안 단계에서 돌리면 같은 문제를 하루 만에 고칩니다.

자주 헷갈리는 용어

용어무엇인가사용성 테스트와의 차이
사용성제품이 지닌 성질재려는 대상입니다. 사용성이 목적어고 사용성 테스트가 그것을 재는 도구입니다
고객 인터뷰경험을 듣는 대화말을 얻고 이쪽은 행동을 얻습니다. 필요한지를 묻는 자리가 인터뷰, 쉬운지를 보는 자리가 테스트입니다

같이 보면 좋은 페이지

  • 사용자 리서치

    이 방법이 어느 갈래에 속하고 언제 다른 것을 골라야 하는지 봅니다

  • 고객 인터뷰

    같은 사용자에게서 말을 얻는 짝이 되는 방법입니다

  • 사용성

    테스트로 재려는 것이 무엇인지 정의부터 확인합니다

마지막 업데이트 2026-09-16