사용성 테스트를 한 번만 제대로 망해봤다면 압니다. "일단 확인하고 싶은 거 다 넣자"는 생각이 얼마나 위험한지를. 저도 처음 UT를 도입했을 때 태스크를 12개나 설계했다가 세션이 90분 가까이 늘어지는 경험을 했습니다. 이 글은 그 실패에서 건진 것들을 솔직하게 정리한 기록입니다.
태스크 설계: 적을수록 데이터가 살아남는다
사용성 테스트(UT)란 특정 태스크, 즉 사용자에게 주어진 구체적인 수행 과제를 설정하고 실제 행동을 관찰하는 리서치 방법입니다. 여기서 UT가 IDI(In-Depth Interview, 심층 인터뷰)와 다른 점은 명확합니다. IDI는 사용자의 인식과 경험, 감정을 탐색하는 데 집중하지만, UT는 앱이나 서비스 화면에서 사용자가 실제로 어떻게 움직이는지를 직접 눈으로 확인하는 방식입니다.
제가 직접 써봤는데, 이 차이를 처음부터 제대로 이해하지 못하면 태스크 설계 단계에서 바로 무너집니다. B2B SaaS 대시보드 리뉴얼 프로젝트에서 저는 "확인하고 싶은 기능이 많다"는 이유로 태스크를 12개 넣었습니다. 결과는 참담했습니다. 60분 기준이어야 할 세션이 90분 가까이 늘어졌고, 참가자의 집중력은 후반 30분에서 눈에 띄게 무너졌습니다. 마지막 3개 태스크에서 나온 데이터는 신뢰하기 어려운 수준이었고, 그 데이터를 들고 팀 내 보고를 하면서 스스로도 자신이 없었습니다.
그 이후로 저는 파일럿 테스트(Pilot Test)를 의무 절차로 도입했습니다. 파일럿 테스트란 본 세션 전에 내부 팀원이나 소수 인원을 대상으로 UT 전체 흐름을 먼저 시뮬레이션해보는 사전 검증 단계입니다. 이걸 한 번만 돌려봐도 시간 초과 태스크가 어디서 발생하는지 바로 눈에 들어옵니다. 저도 파일럿 이후 태스크를 12개에서 5~6개로 줄이는 과정을 거쳤고, 60분 안에 깔끔하게 마무리되면서 데이터 품질이 확연히 달라졌습니다.
태스크를 잘 설계하려면 시나리오 기반(Scenario-based)으로 접근하는 것이 효과적입니다. 시나리오 기반이란 "이 화면에서 버튼을 눌러보세요" 식의 지시형이 아니라, "오늘 처음 이 서비스를 쓰는 신규 사용자라고 가정하고, 지난달 팀 예산을 확인해보세요" 처럼 실제 상황을 설정해주는 방식입니다. 이렇게 맥락을 주면 사용자가 더 자연스럽게 행동하고, 관찰자도 의도치 않은 행동 패턴을 포착하기 수월해집니다.
태스크 설계 시 체크해야 할 핵심 포인트를 정리하면 다음과 같습니다.
- 태스크 수는 60분 기준 5~6개가 적정선이며, 서비스 복잡도에 따라 조절한다
- 파일럿 테스트를 반드시 1회 이상 진행하여 시간 초과 여부를 사전 검증한다
- 지시형이 아닌 시나리오 기반으로 태스크를 설계하여 자연스러운 행동을 유도한다
- 태스크 간 난이도 순서를 고려하여 참가자의 피로도를 분산시킨다
샘플 수와 스크리너 설문: 숫자보다 정밀도가 먼저다
"UT는 몇 명이나 해야 충분한가?"라는 질문을 현업에서 자주 받습니다. 정성 조사 기준으로는 6~10명이 적절하다는 것이 업계의 일반적인 권고입니다. 실제로 UX 리서치 분야의 고전적인 연구에서도 5명 정도의 사용자를 테스트하면 전체 사용성 문제의 80% 이상을 발견할 수 있다는 결과가 있습니다(출처: Nielsen Norman Group). 다만 이를 두고 "그러면 5명이면 충분하다"고 해석하는 분들도 있는데, 저는 조금 다르게 봅니다. 서비스 복잡도와 사용자 세그먼트(segment, 동일한 특성을 공유하는 사용자 집단) 수에 따라 유효 샘플은 달라질 수 있습니다.
통계적 유의미성(statistical significance)이 필요한 경우, 즉 "이 버튼 클릭률이 유의미하게 낮은가?"처럼 수치로 검증해야 하는 질문에는 정량 조사를 병행해야 합니다. 여기서 통계적 유의미성이란 측정된 결과가 단순히 우연이 아니라 실제 차이에서 비롯된 것임을 수학적으로 판단하는 기준으로, 일반적으로 표본이 수십 명 이상 필요합니다. 정성 UT 6~10명으로 도출한 인사이트를 정량 데이터로 검증하는 방식이 현실적으로 가장 탄탄한 접근입니다.
운영 측면에서 제가 직접 부딪혀서 배운 것 중 하나는 스크리너 설문(screener survey)의 중요성입니다. 스크리너 설문이란 UT에 적합한 참가자를 선별하기 위해 사전에 진행하는 자격 검증 설문입니다. 저는 초기에 이 부분을 대충 넘겼다가, 타깃이 아닌 사용자가 세션에 들어와 결과 전체가 흔들리는 경험을 했습니다. 그 뒤로는 스크리너 설문 설계에 최소 30분 이상을 투자하는 것을 원칙으로 삼고 있습니다.
개인정보 보호 프로세스 역시 운영 전에 반드시 갖춰야 합니다. 녹화 동의서, 데이터 보관 기간, 삭제 절차까지 문서화해두지 않으면 나중에 법적 리스크로 이어질 수 있습니다. 개인정보보호위원회의 가이드라인에 따르면 리서치 녹화 데이터는 수집 목적이 달성된 이후 지체 없이 파기해야 하며, 동의서에는 수집 목적과 보관 기간이 명시되어야 합니다(출처: 개인정보보호위원회).
관찰자 편향(observer bias)도 간과하기 쉬운 부분입니다. 관찰자 편향이란 테스트를 진행하는 사람이 자신이 기대하는 방향으로 상황을 해석하거나 개입하게 되는 현상입니다. 솔직히 이건 예상 밖이었습니다. 저도 저음에는 참가자가 막히는 상황을 보면 무의식 중에 힌트를 주려는 충동이 생겼습니다. 이를 막으려면 진행자가 미리 "Think Aloud(생각을 소리 내어 말하기)" 프로토콜을 안내하고, 개입 없이 침묵을 유지하는 훈련이 필요합니다.
결국 UT를 제대로 돌리려면 기술만큼이나 운영의 원칙이 중요합니다. 제 경험상 이건 좀 다릅니다. 잘 만든 태스크 하나가 잘못 설계된 12개짜리 세션보다 훨씬 많은 것을 알려줍니다.
UT를 처음 도입하려는 분들에게 드리고 싶은 말은 하나입니다. "지금 이 단계에서 UT가 정말 필요한가"를 먼저 물어보십시오. 서비스 유입 경로나 초기 고객 니즈를 파악해야 하는 단계라면 UT보다 사전 인터뷰나 설문이 더 적합합니다. UT는 개발이 어느 정도 완성된 후, 실제 화면에서 사용자의 행동을 점검할 때 가장 효과적입니다. 조사 방법론을 상황에 맞게 선택하는 것, 그게 좋은 리서치의 출발점입니다.