숫자는 ‘무엇’을, 사용성 테스트는 ‘왜’를 보여줍니다

분석 데이터를 보면 무슨 일이 일어나는지는 정확히 알 수 있습니다. 가입 2단계에서 60%가 이탈한다는 식으로요. 하지만 왜 그러는지는 데이터 어디에도 나오지 않죠. 이 틈을 메우는 방법이 사용성 테스트입니다. 실제 사용자가 제품을 쓰는 모습을 지켜보면 그 ‘왜’가 비로소 보이거든요.

사용성 테스트란?

사용성 테스트는 실제 사용자를 대표하는 사람들이 제품으로 진짜 과제를 수행하는 모습을 관찰해서, 제품이 어디서 도움이 되고 어디서 발목을 잡는지 알아내는 리서치 방법입니다. 핵심은 실제로 써 볼 때 무슨 일이 벌어지는지 지켜보는 데 있습니다. "이 디자인이 마음에 드세요?"라고 물어서는 알 수 없는 것들이죠.

국제 표준 ISO 9241-11은 사용성을 "특정 사용자가 특정 목표를 얼마나 잘 달성하는가"로 정의하고, 세 가지 기준을 제시합니다.

• 효과성(Effectiveness): 과제를 끝까지 완료할 수 있는가?
• 효율성(Efficiency): 얼마나 많은 노력이 드는가?
• 만족도(Satisfaction): 그 경험은 어떻게 느껴지는가?

사용성 테스트는 이 세 가지를 현미경으로 들여다보는 일입니다. 이 방법을 널리 알린 야콥 닐슨(Jakob Nielsen)은 이렇게 말했습니다.

최고의 UX를 만들려면, 사용자가 말하는 것이 아니라 실제로 하는 행동에 주목하세요.

사람들이 하는 말과 실제 행동은 자주 어긋나는데, 진짜 배울 거리는 그 틈에 있습니다. 어떤 화면이 "괜찮다"고 말하면서도 눈앞에서 엉뚱한 버튼을 세 번이나 누르는 식이죠. 그 행동이 바로 데이터입니다.

유저 테스트 vs 사용성 테스트, 무엇이 다를까?

그런데 용어부터 좀 헷갈립니다. "유저 테스트"는 사용자가 관여하는 거의 모든 리서치를 두루 가리키는 느슨한 말이고, "사용성 테스트"는 그 안에서 사용 편의성에 초점을 둔 구체적인 방법입니다.

실무에서는 이름보다, 각각 어떤 질문에 답하려는 조사인지로 구분하는 편이 쓸모 있습니다.

즉 "유저 테스트"에는 인터뷰, 설문, 콘셉트 테스트, 그리고 사용성 테스트가 모두 들어갈 수 있습니다. 누군가 "유저 테스트하자"고 하면 어떤 테스트를 의도한 말인지 한 번 되물을 필요가 있죠. 이걸 만들지 말지를 검증하려는 걸까요, 아니면 이미 만든 걸 사람들이 쓸 수 있는지 확인하려는 걸까요? 둘은 전혀 다른 조사거든요.

왜 사용성 테스트를 해야 할까?

안 하면 결국 추측에 기대게 되기 때문입니다. 테스트를 제대로 설계해서 돌리고 나면 이런 것들이 남습니다.

• 구체적이고 고칠 수 있는 문제: "온보딩이 헷갈린다"가 아니라 "5명 중 4명이 '계속' 버튼이 비활성처럼 보여서 놓쳤다".
• 논쟁을 끝내는 근거: 실제 사용자가 헤매는 장면 앞에서는 목소리 큰 의견도 힘을 잃습니다.
• 더 싼 수정 비용: 출시 전에는 디자인 한 번 손보면 끝날 일이, 출시 뒤에는 익숙해진 사용자와 쌓인 데이터까지 얽혀 큰 재작업이 됩니다.
• 오래 남는 공감: 우리가 "당연하다"고 생각한 기능에서 사용자가 막히는 걸 보고 나면 팀의 사고방식이 달라집니다.

언제 하면 좋을까?

사용성 테스트는 만드는 과정 곳곳에서 꺼내 쓰는 도구입니다.

• 초기 프로토타입 단계: 코드를 짜기 전에 종이나 클릭형 목업으로 먼저 테스트합니다.
• 출시 직전: 치명적인 문제를 아직 싸게 고칠 수 있을 때 잡습니다.
• 운영 중인 제품: 데이터로는 설명되지 않는 이탈을 발견했을 때 그 원인을 찾습니다.
• 꾸준히: 잘하는 팀일수록 작게, 자주 테스트합니다. 1년에 한 번 몰아서 하는 팀보다 훨씬 많이 배우죠.

모더레이티드 vs 언모더레이티드

세션을 진행하는 방식은 크게 두 가지인데, 잘하는 게 서로 다릅니다.

모더레이티드는 진행자가 실시간으로 과제를 안내하면서, 참가자가 멈칫한 바로 그 순간 "방금 왜 망설이셨어요?"라고 물을 수 있는 방식입니다. 결과와 함께 이유까지 이해해야 할 때 제격이죠. 언모더레이티드는 깊이 대신 속도를 택하는 방식이라, 과제가 단순하고 데이터를 빠르게 많이 모으고 싶을 때 유용합니다.

사용성 테스트는 어떻게 진행될까?

모더레이티드 세션은 보통 이런 흐름으로 진행됩니다.

1. 목표 정하기. 무엇을 알고 싶은지 정합니다. 이를테면 "신규 사용자가 도움 없이 첫 데이터 소스를 연결할 수 있는가?" 같은 것이죠.
2. 과제 쓰기가이드사용성 테스트 태스크, 지시문이 아니라 시나리오로 쓰세요. 목표를 현실적인 시도로 바꾸되, 지시문이 아니라 시나리오처럼 표현합니다.
3. 참가자 모집. 실제 사용자와 닮은 사람을 찾습니다. 생각보다 적은 인원이면 충분합니다(아래에서 다룹니다).
4. 세션 진행가이드참가자가 막혔을 때, 사용성 테스트 진행자는 뭐라고 말해야 할까요?. 과제를 주고 조용히 지켜봅니다. 무엇을 하는지, 어디서 망설이는지, 무슨 말을 하는지를 시간 기록과 함께 메모합니다.
5. 분석과 공유가이드테스트는 끝났는데, 이 노트 더미로 뭘 하죠?. 관찰을 패턴으로 묶고 문제의 우선순위를 매겨, 팀이 읽고 바로 움직일 수 있는 리포트로 만듭니다.

그런데 애써 얻은 인사이트가 가장 많이 묻히는 곳이 바로 이 마지막 단계입니다. 노트는 문서 여기저기 흩어지고, 녹화는 아무도 다시 보지 않고, 인사이트는 정작 고칠 사람에게 닿지 못하죠. 이 대목에서 Interbang 같은 도구가 쓸모 있습니다. 태그한 노트가 녹취록의 그 순간과 계속 연결돼 있고 성공률 같은 측정치도 자동으로 집계되니, 번거로운 정리를 건너뛰고 관찰에서 곧장 다음 행동으로 넘어갈 수 있거든요.

참가자는 몇 명이 필요할까?

대부분이 예상하는 것보다 적습니다. 닐슨과 랜다우어(Nielsen & Landauer)의 잘 알려진 연구에 따르면 약 5명만 테스트해도 한 흐름의 사용성 문제 중 대략 85%가 드러납니다. 그 이상은 수확 체감 구간이라, 여섯 번째 사람을 모집하기보다 찾은 문제를 고치고 다시 테스트하는 편이 낫습니다. 구체적인 계산과 5명으로 부족한 경우는 참가자 수를 다룬 글리서치5명이면 충분할까? 사용성 테스트 참가자 수의 진짜 답에서 더 깊이 다룹니다.

자주 묻는 질문

사용성 테스트는 A/B 테스트와 같은 건가요? 다릅니다. A/B 테스트는 실제 트래픽으로 두 버전을 비교해 어느 쪽 지표가 좋은지 봅니다. 사용성 테스트는 소수의 사람이 한 버전을 쓰는 모습을 지켜보며 왜 잘 되거나 안 되는지를 이해하죠. 묻는 질문 자체가 달라서 서로 잘 맞는 짝입니다.

녹음이 꼭 필요한가요? 도움은 되지만 필수는 아닙니다. 시간 기록을 곁들인 꼼꼼한 노트만으로도 큰 문제는 충분히 찾을 수 있습니다. 녹화나 녹취록이 있으면 그 순간을 다시 확인하고 근거로 공유할 수 있으니, 있으면 좋은 보너스 정도로 생각하세요.

한 세션은 얼마나 걸리나요? 모더레이티드 세션은 보통 참가자 한 명당 30~60분을 권합니다. 피로가 쌓이기 전에 현실적인 과제 몇 개를 시도하기에 적당한 길이입니다.

누가 진행해야 하나요? 기본 틀만 갖추면 팀 누구라도 진행할 수 있습니다. 많이 배우는 데 전담 리서처가 꼭 필요한 건 아닙니다. 명확한 목표, 현실적인 과제, 그리고 조용히 지켜보는 절제만 있으면 됩니다.