클라이언트가 "사용자들이 이 기능을 잘 쓸 수 있을까요?"라고 물어왔을 때, 저는 확신 있게 대답할 수 없었습니다. 디자인은 완성했지만 실제 사용자 반응은 전혀 다를 수 있다는 걸 경험으로 알고 있었거든요. 그래서 저는 사용성 테스트를 제안했고, 5명의 참가자와 함께 프로토타입을 테스트했습니다. 결과는 예상 밖이었습니다. 제가 당연하다고 생각한 메뉴 구조가 참가자들에게는 전혀 직관적이지 않았고, 주문 과정에서 빠뜨린 수량 옵션 때문에 사용자 경험이 무너졌습니다. 이 경험 이후 저는 사용성 테스트를 모든 프로젝트의 필수 단계로 삼게 되었습니다.
사용성 테스트란 무엇이며 언제 하는가
사용성 테스트(Usability Testing)는 실제 사용자가 제품의 핵심 작업을 얼마나 쉽게 완료할 수 있는지 평가하는 UX 리서치 방법입니다. 여기서 사용성이란 제품이 사용자에게 얼마나 직관적이고 효율적인지를 의미하며, 단순히 '예쁜 디자인'이 아니라 '실제로 작동하는 디자인'인지를 검증하는 과정입니다(출처: Nielsen Norman Group).
저는 프로젝트 단계마다 다른 형태의 사용성 테스트를 진행합니다. 초기 아이디어 단계에서는 저충실도 프로토타입으로 개념 테스트를 하고, 인터랙티브 프로토타입이 완성되면 본격적인 사용성 테스트를 진행합니다. 제품 출시 전 단계가 가장 효과적인데, 이때 발견한 문제는 비교적 저렴한 비용으로 수정할 수 있기 때문입니다.
실제로 제가 진행했던 베이커리 웹사이트 프로젝트에서는 프로토타입 단계에서 테스트를 진행했습니다. 참가자 Alex는 무지개 케이크를 주문하려다가 유니콘 장식 수량을 지정할 수 없다는 문제를 발견했습니다. 또한 배치 위치를 메모할 섹션이 없어서 원하는 대로 주문할 수 없었죠. 만약 출시 후에 이 문제를 발견했다면 고객 불만과 함께 개발 비용까지 두 배로 들었을 겁니다.
사용성 테스트는 디자이너의 추측이 아닌 실제 사용자의 행동 데이터를 제공합니다. 제가 당연하다고 생각한 UI가 사용자에게는 전혀 직관적이지 않을 수 있다는 사실을 매번 깨닫게 됩니다.
모더레이트 vs 언모더레이트 사용성 테스트
사용성 테스트는 크게 두 가지 방식으로 나뉩니다. 모더레이트 사용성 테스트(Moderated Usability Testing)는 진행자가 실시간으로 참가자를 안내하며 피드백을 수집하는 방식입니다. 반면 언모더레이트 사용성 테스트(Unmoderated Usability Testing)는 참가자가 혼자서 작업을 완료하고, 그 과정을 녹화하여 나중에 분석하는 방식입니다(출처: UserTesting).
저는 최근 SaaS 대시보드 리디자인 프로젝트에서 모더레이트 테스트를 선택했습니다. 이유는 간단했습니다. 참가자가 특정 데이터 필터 기능을 사용할 때 실시간으로 "왜 이 버튼을 클릭하셨나요?"라고 물어볼 수 있었기 때문입니다. 첫 3건의 인터뷰에서는 표면적인 불만만 나왔지만, 5 Whys 기법을 적용한 후반 인터뷰에서 핵심을 찾았습니다. 관리자들이 원하는 건 데이터 자체가 아니라 빠른 의사결정을 위한 인사이트 요약이었습니다.
모더레이트 테스트의 장점은 다음과 같습니다.
- 진행자가 참가자의 행동을 실시간으로 관찰하고 후속 질문을 할 수 있음
- 참가자가 이해하지 못한 질문을 즉시 다시 설명할 수 있음
- 진행자와 참가자 간 라포(Rapport) 형성이 가능해 솔직한 피드백을 얻기 쉬움
하지만 제한사항도 분명합니다. 진행자가 의도치 않게 참가자에게 영향을 줄 수 있고, 일정 조율이 어렵습니다. 특히 야간 근무자나 한부모 가정처럼 평일 낮 시간이 불가능한 참가자는 모집하기 힘듭니다.
언모더레이트 테스트는 이런 유연성 문제를 해결합니다. 참가자가 자신의 시간과 공간에서 편하게 테스트를 완료할 수 있고, 진행자 없이 자연스러운 사용 패턴을 관찰할 수 있습니다. 하지만 참가자가 문제에 부딪혔을 때 도와줄 사람이 없고, 후속 질문도 불가능합니다. 제 경험상 민감한 주제일수록 언모더레이트 방식이 더 솔직한 답변을 끌어내는 경향이 있었습니다.
사용성 테스트 참가자 수는 몇 명이 적당한가
사용성 테스트에서 가장 많이 받는 질문이 "몇 명을 테스트해야 하나요?"입니다. 정답은 5명입니다. Nielsen Norman Group의 연구에 따르면 5명의 참가자로 전체 사용성 문제의 약 85%를 발견할 수 있습니다. 6명째부터는 새로운 문제 발견률이 급격히 떨어지기 때문에 비용 대비 효율이 낮아집니다.
저도 처음에는 "5명으로 충분할까?"라는 의구심이 있었습니다. 그래서 한 프로젝트에서 10명을 테스트했는데, 실제로 6번째 참가자부터는 이미 발견한 문제만 반복해서 나왔습니다. 그 이후로는 5명을 기본으로 진행하고, 예산이 넉넉하면 두 번째 라운드로 5명을 추가하는 방식을 선택합니다.
중요한 건 참가자 수보다 누구를 모집하느냐입니다. 타겟 사용자를 제대로 선정해야 의미 있는 피드백을 얻을 수 있습니다. 제가 진행한 개 산책 앱 테스트에서는 실제로 반려견을 키우고, 산책 서비스를 이용해본 경험이 있는 사람만 모집했습니다. 그렇지 않으면 "저는 개를 안 키워서 잘 모르겠는데요"라는 쓸모없는 답변만 나오기 때문입니다.
또한 테스트 범위에 따라 참가자 수를 조정할 수 있습니다. 전체 제품을 테스트한다면 5명으로 충분하지만, 여러 사용자 그룹(예: 관리자, 일반 사용자, 파워 유저)을 대상으로 한다면 각 그룹당 3~5명씩 모집해야 합니다.
사용성 테스트 실제 진행 과정과 주의사항
사용성 테스트는 참가자에게 작업 목록을 주고, 그 과정을 관찰하며 피드백을 수집하는 구조입니다. 저는 Gmail 라벨 기능 테스트를 예로 들겠습니다. 참가자 Jordan은 "쇼핑이라는 새 라벨을 만들어보세요"라는 작업을 받았는데, 라벨 생성 버튼을 찾지 못하고 구글 검색으로 방법을 찾아야 했습니다.
이 장면에서 제가 발견한 문제는 두 가지였습니다. 첫째, 라벨 만들기 기능이 설정 메뉴 깊숙이 숨겨져 있어서 접근성이 떨어진다는 점. 둘째, 사용자가 기능을 찾지 못하면 즉시 외부 검색에 의존한다는 행동 패턴입니다. 이건 디자인팀이 예상하지 못한 인사이트였습니다.
참가자 Alex는 도움말 버튼을 활용해서 라벨 생성 방법을 찾았지만, 이 과정에서도 "더 보기" 버튼을 클릭해야 한다는 추가 단계가 불편함으로 작용했습니다. 사용성 테스트의 핵심은 이렇게 디자이너가 놓친 마찰 지점(Friction Point)을 발견하는 것입니다.
테스트를 진행하면서 제가 주의하는 점은 참가자에게 절대 힌트를 주지 않는 것입니다. "여기 보이시죠?"라고 유도하는 순간, 테스트는 무의미해집니다. 대신 "지금 무슨 생각을 하고 계신가요?"라고 물으며 사고 과정을 들어야 합니다. 또한 참가자가 작업을 포기하려 할 때도 억지로 붙잡지 않습니다. 포기한다는 것 자체가 중요한 데이터니까요.
언모더레이트 테스트에서는 환경 통제가 불가능하다는 점을 인정해야 합니다. 참가자가 멀티태스킹을 할 수도 있고, 집중력이 떨어질 수도 있습니다. 하지만 그게 오히려 현실적인 사용 환경과 가깝다고 생각합니다. 실제 사용자도 업무 중에 이메일을 확인하고, TV를 보면서 앱을 쓰니까요.
사용성 테스트는 디자이너의 자존심을 꺾는 과정일 수 있습니다. 제가 공들인 디자인이 사용자에게는 불편하다는 피드백을 들을 때마다 마음이 아픕니다. 하지만 출시 후 실패하는 것보다는 훨씬 낫습니다. 이 테스트 덕분에 저는 설계한 요약 대시보드가 클라이언트 만족도 9.2/10을 받으며 추가 프로젝트까지 확보했습니다. 사용자의 목소리를 듣는 것, 그게 UX 디자인의 본질이라고 생각합니다.